Can I somehow load a "broken" DOM tree in JavaScript
for example if someone forget to close a tag..
The current page? ...if this is an HTML document (ie. not served as XHTML) then the browser will auto-close (and even attempt to 'fix') certain elements that may at first appear 'broken'. When reading the current DOM, you are reading the fixed version. However, if the page is in fact 'broken' (or is just not standards compliant) then different browsers will 'fix' it differently. Depending on how broken is "broken", this may or may not be OK. If you are wanting this to work cross-browser, then this is probably not OK.
Related
I have an annoying white space below footer problem, and no matter how long I have searched for the answer I cannot find it, because it doesn't seem to be anything I can do in CSS to solve the problem. Also, the problem is not on every page... it arbitrarily selects (seemingly) random pages within the website, which made me think that perhaps it is happening as a result of some javascript code that I cannot seem to locate as being the offending party.
Anyway, after hours of scrolling through websites, I decided to load the website without javascript and sure enough the white space disappeared. As a somewhat novice programmer, I'm not really sure what to do next. I put
<div class="clear"></div>
right before in my header, and voila, it worked... no more white space on any of the pages. So technically, I guess this resolves my problem, at least visually, but since I'm a novice, I have no idea what the potential repercussions are for this? Is it okay to leave it? Could I try something else? Does this problem sound familiar to anyone? Many thanks in advance for your help! I don't know if you'll need more info than this.
Just to be clear, I'm developing a child theme in Wordpress off of someone else's theme. The website is a multisite, and the other site on the multisite doesn't seem to be broken at all, despite having nearly all the same elements. One of the few differences is a Contact Form 7 form where they each have their own instance of a CF7 form. When I attempted to add some javascript to the CF7 form, I believe that's when it broke. Since I only added it to one website (within the form itself), I think that's why only one website broke with the white space underneath. Simply removing the code wasn't enough.
By the way, I should add I have had this problem with this website before, and my (weird) solution at that time was to rename the links of the pages where the white gap was showing up... and sure enough, it worked. Obviously, as my site grows backlinks I don't want to keep doing that.
So, is my rudimentary fix enough?
As APAD1 said, the <!DOCTYPE> declaration must always be the very first element in the HTML document, otherwise it will have no effect! The fact that placing <div class="clear"></div> before the <!DOCTYPE> declaration seemed to fix your problem indicates that the white-space was somehow the related to or caused by the browser defaults for that particular HTML rendering mode.
Also, what browser are you using? You're not using Internet Explorer, are you? Different browsers or even different versions of the same browser may render your page differently.
As for the <!DOCTYPE> declaration, it is needed to indicate a particular layout mode the browser should enter.
In Internet Explorer, for example, the omission of a <!DOCTYPE> declaration may cause the browser to enter Quirks mode, as opposed to a Standards-Compliance mode. Note that <!DOCTYPE html> is used for HTML5 documents, whereas something like:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">`
...is used for HTML4. The (X)HTML doctype declaration is used to put the browser into a particular layout/rendering mode. Different rendering modes result in different CSS default styles. It is likely that some combination of CSS rules are resulting in the unexpected white-space.
I suggest you become familiar with (or at least play around with) Firebug (a FireFox extension), the Webkit Inspector ("Developer Tools") that comes in Google Chrome and Safari, and/or the IE Developer Tools. All of these tools allow you to "inspect" elements in the Document Object Model (DOM) for your webpage. These tools will even let you view and modify the HTML source code and CSS rules for elements in the DOM. (Please be aware any changes you make with these tools will not be saved and therefore are not persistent!) This means that using one of these tools, you can select your footer element and view its applied ("computed") CSS styles. This is especially helpful in not only troubleshooting your webpage or WordPress theme, but also in developing it.
So, to sum up:
If you don't place the <!DOCTYPE> declaration as the first element, then you might as well omit it altogether.
The <!DOCTYPE> declaration places the browser in a particular layout mode that has certain CSS defaults.
A combination of CSS rules is likely resulting in the unexpected white-space.
You may use browser "developer tools" such as FireBug to inspect (and modify) your webpage.
Okay, this is resolved (as of right now). The problem was a plugin conflict that was writing javascript to the footer. It only caused a problem when I added javascript to the Contact Form 7 plugin.
To resolve the issue, I edited the HTML in firebug as you suggested, Alex. Once I found out the offending plugin I disabled the conflicting scripts.
Thanks for all your help, guys. This is resolved.
I have a page, generated by a server that has bad LI elements, with two closing li tags
<li>Whatever</li></li>
All jQuery operations work fine in Firefox, but not in IE (7 and 8). I want to remove the duplicate </li> before I start my functions, how do I do it?
Not possible to fix via the client, unless you have a browser that defies logical sense. jQuery controls the DOM, not the raw HTML, and as a result, it can't edit the scrubbed broken tag. Just fix your server-side script.
If you really want a hacky, terrible, awful JS solution, you can AJAX request the page itself after that page is loaded, remove the AJAX call from the page (to avoid an infinite loop), remove the broken elements and then load that HTML in a new window. PLEASE never do that.
If possible you should of course fix the code that generates the page.
If that's not possible, you have a rough road ahead. You can't fix the markup, because it's parsed before you can do anything about it, so you have to fix whatever the browser generated from the broken markup.
Each browser will have a different way of handling the incorrect code, so you have to test every possible browser that you can get your hands on, including every current version of Internet Explorer (7, 8, 9, 10 and possibly 6). That is a pain in the ass, as you can only have one version of IE installed at a time. Luckily you can use the developer tools in newer versions to simulate older versions, however it's still not a 100% accurate emulation.
Some browsers may ignore the extra ending tags, and some amy add extra list elements. You have to write code that handles whatever each browser generated from the markup, and fix the elements.
I've seen several threads about reading contents, but nothing on writing to noscript.
$('body').append('<noscript><div></div></noscript>');
In Chrome and IE9 I get a noscript-element with a empty div inside like I expect, but in IE7 and IE8 I just get a empty noscript-element without the div inside.
Example: http://jsfiddle.net/cEMNS/
Is there a way to add HTML inside the noscript-tag that works in all browsers? What I need is to add some tracking code into a noscript-element at the end of the page, but the info I need isn't available until after document ready.
Edit: I'm getting a lot of comments on "why". It's some poorly done tracking library that requires this. We don't have access to the code to change it. Regardless, I find it interesting that it works in some browsers and not in others since jQuery was supposed to work equally in all browsers. Is it simply a bug?
Edit2: (2 years later) Adding a noscript on the browser doesn't make sense, I know. My only excuse not the question the task I had was because of lack of sleep, like everyone else in the project. But my rationale was that jQuery should behave the same on all browsers and someone might want to do this on the server.
Regardless of the tracking code, what you are doing (or are required to do) makes no sense!
Why? There are two cases possible here:
user has JavaScript enabled in which case the NOSCRIPT get's inserted into the DOM but is ignored by the browser (does nothing)
user does not have JavaScript enabled, NOSCRIPT does not get inserted and does not "execute"
The end result of both cases is that nothing actually happens.
Just an idea: You could try giving your noscript tag an ID, and then try to use native js.
for example:
$('body').append('<noscript id="myTestNoScript"></noscript>');
document.getElementById('myTestNoScript').innerHTML = '<div></div>';
I would claim that if it does not work with native js, it will not work with any library (feel free to correct me on this one).
I tried following simple HTML code:
<html>
<body>
<noscript>I'm a noscript tag.</noscript>
</body>
</html>
Then I did analyse this with IE8 (in IE7 mode) and his integrated code insprector. Apparently the IE7 checks are script allowed. If so he declared it as empty. And empty tags will be ignored. Unfortunatly I could not try that with disabled script option, because only the Systemadministrator can change the settings (here at my work).
What I can assure you, the noscript does exists. If you add
alert($('noscript').size());
after the creation, the result will be 1.
This question already has answers here:
Does the <script> tag position in HTML affects performance of the webpage?
(8 answers)
Closed 9 years ago.
In all the documentation I see the jQuery script tag beneath <title> in the head, but then when I go into some other sites (the initializr template is the first off the top of my head), they drop it into the bottom of the body (you know, right before </body>).
Which of these two is right?
Quoting the YDN Best Practices for Speeding Up Your Web Site:
Put Scripts at the Bottom
The problem caused by scripts is that they block parallel downloads. The HTTP/1.1 specification suggests that browsers download no more than two components in parallel per hostname. If you serve your images from multiple hostnames, you can get more than two downloads to occur in parallel. While a script is downloading, however, the browser won't start any other downloads, even on different hostnames.
In some situations it's not easy to move scripts to the bottom. If, for example, the script uses document.write to insert part of the page's content, it can't be moved lower in the page. There might also be scoping issues. In many cases, there are ways to workaround these situations.
An alternative suggestion that often comes up is to use deferred scripts. The DEFER attribute indicates that the script does not contain document.write, and is a clue to browsers that they can continue rendering. Unfortunately, Firefox doesn't support the DEFER attribute. In Internet Explorer, the script may be deferred, but not as much as desired. If a script can be deferred, it can also be moved to the bottom of the page. That will make your web pages load faster.
It's funny that people used to say that I should be slapped upside the head for doing that when I said that in 2009 and now it's suddenly a best practice... Some progress.
Well, I think you need to put this inside a $(document).ready(function() { so that the document is actually ready before you are calling the jQuery. Personally I also put just before the </body>. Now given that both works, is there a 'right' way, or it's just a question of personal preference?
Would love to listen from experts, though.
Steve Souders' book High Performance Web Sites recommends putting scripts at the bottom, before the </body> tag. You can also find this documented at the developer.yahoo.com site here. (It's the fourth recommendation in the list.)
I generally put the scripts at the bottom, before my '' tag and have had few issues with this. I've noticed that this helps performance on older browsers like IE7 a lot more than it does with newer ones like FF3.6, Chrome and IE9. The older browsers only support 2 parallel downloads, whereas the newer ones support something 6 connections. The blocking, as a result, isn't as noticeable.
Hope this helps!
Placing scripts at the bottom has performance benefits:
Where should I put <script> tags in HTML markup?
I need to make the user to be able to select some text, click a button and make the server remember the selection for the next time.
I've extensively read through SO's questions and answers, tried some libraries, but without luck: haven't found a reliable tool yet.
It isn't important how the selection's boundaries are identified: it could be "nth textNode, mth char", or "nth char of text", or "nth char of html", or whatever, as long as it allows the server to identify the points in the document; what really matter is that, selecting the same words of the same document must give the same result on chrome, safari, IE, firefox.
EDIT: I don't need it to work everywhere on the internet: just on one site, where the document's structure is fixed and only the content of a single div (or the like) will change.
Try my Rangy library and its Serializer module. I'm not convinced it's exactly what you want because you mentioned the server remembering the selection, whereas my suggestion uses cookies, and the serialized selection will vary between browsers. However, it does do as you described in the first paragraph.
On the other hand, it's pretty much impossible to write something that will work for all browsers and all pages, since browsers interpret HTML differently and build different DOMs.