Would you advise against reading and using the hash DOM node property? (Do you think it might be deprecated and removed in the future?)
What is it? For a link <a href='http://server/folder/page#the-hash'>, the value of the hash property is #the-hash. It seems to be present in all browsers, see the JavaScript Bible page 603, and I've tested Safari, Chrome, FF and IE and Opera.
Background: I use jQuery, but in IE 7 this: $(elem).attr('href'); doesn't return the href attribute, but rather the href prefixed with server address and the path to the page. Example: if the href is #the-hash then attr returns http://server/folder/page#the-hash in IE 7.
Here is a jsfiddle example.
If you stay away from every feature, API, etc that might possibly be deprecated sometime in the distant future, you'll never get anything done. They could deprecate alert tomorrow, or for...in (far more likely, but eh. that's beside the point.)
Worry about what's deprecated now. And location.hash is not. It's a full-fledged member of the HTML5 DOM, and will be for the foreseeable future. If it ever does end up deprecated, it'll probably still be supported for ages after, as a "living standard" (which is what HTML has allegedly become) makes things exceedingly hard to deprecate and/or remove.
Either way, if you want to change it later, you can.
Related
I was just stumbling upon Chapter 7.2 of the W3C HTML5 spec, where it is said
A node (in particular elements and text nodes) can be marked as inert.
Source: http://www.w3.org/TR/html5/single-page.html#inert-subtrees
Unfortunately, the specification does not say how to do it. Does anybody know?
I've already tried setting the "inert[='true']" attribute to an element ... does not work.
It seems to me, as this might be a HTML5 feature that nobody cared to implement or use so far ... caniuse.com does not even know of it ... but maybe I'm wrong?
It looks like the inert attribute may have been removed from the standard.
Early 2014. Posts about it seem to have dried up online so it is probably safe to assume we won't be able to use it.
The attribute inert exists in HTML 5.1.
HTML 5.1 has now progressed to a W3C recommendation, which is is essentially an endorsement that the proposal is ready for deployment to the public, so we should see the major browser makers starting to implement the recommendations if they haven't done so already.
Whilst caniuse has no information on browser support for the inert subtree yet, but I have raised an issue asking for it to be added.
I've written a quick fiddle which lets you see if your browser supports it (though Chromium/Chrome/Safari and FF do not at the time of writing).
There is a polyfill that could mimic the inert behavior to a node and its corresponding subtree. There is also a YouTube video on Google Chrome Developer's Channel showing this polyfill in action and displaying the power and uses for this behavior.
On buzgilla there is an excellent response explaining why it wasn't and won't be implemented in Firefox as an attribute.
There's no such attribute. If we implement this concept it'll be as part of <dialog>.
It's really confusing, this attribute with pointer-events would have been perfect and helpful for a lot of situations
I want to use the autocomplete attribute on a form on a webpage. Specifically, autocomplete="tel-local" and such (i.e. autocompletes that specify what goes in a field)
I'd like to know how widely supported it is, and, if possible, what browsers support it. My attempts to google it have failed...
Also, as far as I can think, even in browsers that fail to support it, using the attribute should not cause problems. Is there any problem that I can cause by using it?
The spec that I intend to use is https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#autofill (which, as far as I know, is the current spec).
The autocomplete attribute as such is well supported, see MDN info on input. However, this only applies to its original design, formally described in the W3C HTML5 Recommendation. Various drafts contained lists of other values, but they were dropped from the Rec due to lack of implementations. Such ideas are retained in the HTML 5.1 draft (work in progress) and in what the WHATWG group calls “Living HTML Standard” (a mutable document that expresses a person’s view of what is “standard HTML” today).
Support to values other than on and off in browsers is obscure. The current version of Firefox surely lacks support, since other values aren’t even reflected in the DOM, i.e. the autocomplete property of an element node cannot have other values (so e.g. autocomplete=tel-local is ignored, which normally means defaulting to autocomplete=on). Chrome and IE let you set the attribute to any value, in the sense of setting the property, but its effect appears to be undocumented. In Chrome, autocomplete=tel-local seems to have some effect, but to me it suggests just some text strings as values (perhaps due to some tests I have made previously).
The problem in support is that it may exist. It is then somewhat unpredictable how a browser implements the attribute.
I know the "align" attribute of the <div> tag has been deprecated for some time now, as well as many other attributes. But you can still use it in all browsers. Has any browser ever made a step to actually not support deprecated elements of any kind?
The reason I ask is because I stopped using div align not just because it's frowned upon, but because I thought some day it would be abandoned and unsupported, as oppose to just throwing warnings in my IDE.
<basefont>
Dropped in Firefox.
https://bugzilla.mozilla.org/show_bug.cgi?id=3875
Most depreciated elements take several revisions to be worked out "completely". This is because in the interest of backwards compatibility new browsers retain code for handling these elements. Most browsers try to avoid this in an effort to retain their own share of the market. As long as the elements are still used generally then there will most likely be some level of support for them so not to lose those that want to access the content that uses them.
No, there is no evidence of any deprecated element having been dropped from browsers. Besides, what you ask in the text of your question is about a deprecated attribute, not an element. The answer is the same, though.
I recall battling with the <layer> element back in the days of Netscape 4. There were definitely web pages that depended on it, but it's long gone.
But <layer> was never standardized, and I am not aware of anything that was in the HTML 2.0, HTML 3.2 or HTML 4.01 standards that has been completely abandoned by HTML5. Sometimes though, implementation requirements are written in such a way that doesn't actually require the browser to do what you'd expect of it or be consistent with what other browsers do. <blink> is one such element. <keygen> is another.
Note that HTML5 doesn't have "deprecated" elements and attributes, only "obsolete" ones. What this means is that the expectation is that browsers will support them forever, but that web authors should not use them because there are better ways of doing the same thing, or that they are harmful to either authors or users to have them on the page.
This works in chromium (and I assume every other major browser)
-html-
<invalid></invalid>
-css-
invalid {
color: red;
}
<invalid> represents an invalid element (not part of the html standard)
here is an example: http://jsfiddle.net/myhonor/4H7Hj/
But when I try this in IE, it doesn't work.
why is this and is there a way fix this (is it a DTD thing?)
That's just the way Internet Explorer works, up to and including version 8. To fix it, just call document.createElement with the name of the invalid element:
document.createElement('invalid');
Here's your updated jsFiddle. It's the same idea as all those HTML5 shivs you see. And, as everyone else has already suggested, writing valid HTML is usually the best solution :)
IE before version 9 doesn't automatically create DOM elements corresponding to any tags it doesn't recognize in the markup. This is the main reason why HTML5 elements don't work in older IEs, which require the HTML5 shiv to be included in order to work.
In this case, you're not even writing HTML5; you're writing your own markup language which is completely unrelated to HTML. The easiest way to fix this is to actually write HTML... or if you insist on making up your own tags, you have to create them manually as minitech demonstrates, but expect to wire them up entirely on your own.1
1 Elements that aren't recognized by a browser as part of HTML are typically created as HTMLUnknownElement objects in the DOM (this includes IE9 and newer), which It is said is done for forward compatibility (c.f. HTML5). These objects have the basic properties of HTMLElement, but besides that there isn't much else to go on...
Do you know of any differences in handling HTML tags/properties in different browsers? For example, I once saw a page with a input tag with a maxlength field set to "2o". Firefox and Opera ignore the "o", and set the max length to 2, while Internet Explorer ignores the field altogether. Do you know of any more?
(Note: seeing as this will probably be a list, it would be great if the general name of the difference was in bold text, like: Different erratic value handling in tag properties)
Bug Lists
Web developers have already compiled some pretty comprehensive lists; I think it's better to compile a list of resources than to duplicate those lists.
http://www.positioniseverything.net/
http://www.richinstyle.com/bugs/table.html
http://www.quirksmode.org/ (as mentioned by Kristopher Johnson)
Javascript
I agree with Craig - it's best to program Javascript using a library that handles differences between browsers (as well as simplify things like namespacing, AJAX event handling, and context). Here's the jump to Craig's answer (on this page).
CSS Resets
CSS Resets can really simplify web development. They override settings which vary slightly between browsers to give you a more common starting point. I like Yahoo's YUI Reset CSS.
Check out http://www.quirksmode.org/
If you are programming in javascript the best advice I can give is to use a javascript library instead of trying to roll your own. The libraries are well tested, and the corner cases are more likely to have been encountered.
Scriptalicious - http://script.aculo.us/
jQuery - http://jquery.com/
Microsoft AJAX - http://www.asp.net/ajax/
Dojo - http://dojotoolkit.org/
Prototype - http://www.prototypejs.org/
YUI - http://developer.yahoo.com/yui/
Do you know of any differences in handling HTML tags/properties in different browsers
Is this question asking for information on all differences, including DOM and CSS? Bit of a big topic. I thought the OP was asking about HTML behaviour specifically, not all this other stuff...
The one that really annoys me is IE's broken document.getElementById javascript function - in most browsers this will give you something that has the id you specify, IE is happy to give you something that has the value in the name attribute, even if there is something later in the document with the id you asked for.
I once saw a page with a input tag
with a maxlength field set to "2o".
In this specific case, you're talking about invalid code. The maxlength attribute can't contain letters, only numbers.
What browsers do with invalid code varies a great deal, as you can see for yourself.
If you're really asking "what do all the different browsers do when faced with HTML code that, for any one of an infinite number of reasons, is broken?", that way lies madness.
We can reduce the problem space a great deal by using valid code.
So, use valid HTML. Then you are left with two main problem areas:
browser bugs -- how the browser follows the HTML standard and what it does wrong
differences in browser defaults, like the amount of padding/margin it gives to the body
Inconsistent parsing of XHTML in HTML mode
HTML parsers are not designed to handle XML.
If an XHTML document is served as "text/html“ and the compatibilities guidelines are not followed you can get unexpected results.
Empty tags is one possible source of problems. <tag/> and <tag></tag> are equivalent in XML. However the HTML parser can interpret them in two ways.
For instance Opera and IE treat <br></br> as two <br> but Firefox and WebKit treat <br></br> as one <br>.