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
Related
I've been encountering some issues where HTML5 video elements will just not load, or the first second will load and then not play, or will load excruciatingly slowly. I'm still trying to debug, but right now the only question I could ask would be 'why isn't it working', which is really not a great question for SO.
But in the course of my debugging, I came across this little gem on W3Schools:
The preload attribute allows the author to provide a hint to the browser about what he/she thinks will lead to the best user experience. This attribute may be ignored in some instances.
Because W3Schools is... not that great, as we all know, they didn't bother to go into detail. This might be part of the problem, since the videos obviously aren't preloading properly. But regardless of whether this is the problem, I'm actually curious about this and can't seem to find any answers online.
The only answer I found was that the preload attribute isn't supported by some mobile browsers, and that it is ignored if the autoplay attribute is also present, but if it was that simple, I have to imagine they would have just said that.
So: when and why is the HTML5 video preload attribute ignored?
The short answer is that a browser can choose to ignore preload any time it wants to.
The longer answer is, the HTML spec gives no rules on when preload must be ignored or when it should be ignored. In fact, the HTML spec defines preload as literally just a hint, and due to that, the effect is that the spec places no hard requirements about it on browsers.
The preload attribute is intended to provide a hint to the user agent
about what the author thinks will lead to the best user experience.
The attribute may be ignored altogether, for example based on explicit
user preferences or based on the available connectivity.
So the result of that is, it’s a bit of free-for-all as far as what behavior you can expect to get in browsers. One browser may choose to ignore it in some particular case, while another may not.
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.
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.
How can I make the browser insert <p> tags instead of <br> tags when I press enter in a designMode IFrame? I get inconsistent behavior across Firefox, Chrome and IE and was wondering if there was some way to normalize this.
It seems you can't. Behaviour is not standardized and control for this is rudimentary at best
This is an interesting thread from May thie year on the matter: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-May/031577.html . It's discussing contenteditable rather than designMode but they're effectively very similar.
An email on the thread ( http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-May/031604.html ) from Simon Pieters (zcorpan) of Opera says:
Opera 11.10 has introduced
document.execCommand('opera-defaultblock','','div') to switch to using
<div>s instead of <p>s. ('p' is also allowed to switch back.) Apparently
WebKit considers implementing this as well.
https://bugs.webkit.org/show_bug.cgi?id=59961
Further in the thread there's also this email http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-May/031685.html by Markus Ernst including this comment:
I assume there are use cases for both generating <p>s and <br>s. The
IE/Opera approach has the advantage of allowing both, which is perfect
for text and basic HTML editing. From a WYSIWYG POV it might be best
to offer both options, so authors are not encouraged to add
server-side processing to change the output, which would break
WYSIWYG.
If the behavior is settable, it might even be a good idea to leave the
choice of the standard behavior to the UAs. Authors who have a reason
to care can set their preferred behavior, while other authors might
prefer to leave it as it was, so there is no change for their
existing users.
There's lots more on the thread about what people at the various browser makers think ought to happen, comments on some very strange existing behaviours, and general discussion about the problem involved in implementing it at all.
The currently very alpha spec for all this is at http://aryeh.name/spec/editing/editing.html
I have just started considering using the HTML 5 api for a Rails/JQuery project, so I can use that great data- attribute to store values.
I am worried though about browser compatibility issues. I have two questions (basic questions):
In order to use HTML 5, do people need to upgrade their browsers? How does that work?
Is there an up-to-the-day chart of what features each browser layout engine supports, more up-to-date than this Wikipedia article on comparing HTML layout engines and this When can I use... HTML 5 page?
Is it going to be an issue with people using IE6 for example? Lots of non-computer saavy people I've talked to who want to get an internet presence themselves use, and the people they talk to use, still, IE6!
If it's not an issue, and you can use HTML 5 on old browsers, how do you? Or what docs should I look at :)? Thanks.
Update: I will post some interesting links as I find them below.
FindMeByIP: "A simple app which reveals your browsers' support for CSS3 and HTML5 features in an easy to read format using Modernizr." - Browser Support for CSS3 and HTML5
It is not useful to consider HTML5 as a single entity, that browsers either ‘support’ or ‘don't support’. HTML5 is:
an attempt to codify widespread existing practice beyond the limits of what the previous W3 HTML and DOM standards had covered, such as IE and Firefox extensions that the other browsers have copied, and long-standing ‘DOM Level 0’ behaviours that everyone took for granted but weren't written into any spec before.
a random selection of new extensions not yet in widespread use, which it is hoped browser manufacturers will support. Some have already succeeded, heading into all new browsers already; some have been spun off into their own specifications (which is much more manageable for everyone), some are controversial, and some no-one cares about at all.
It has been, IMO, an enormous mistake to try to cover these two bases at once. I would have preferred an HTML 3.2-style ‘catch-up’ standard plus many separate extension specifications. But there's nothing can be done about it now.
HTML5 is also:
Not finished. The specification is massive, complicated, incomplete, and likely to change in details (or maybe more than that) before it becomes a proper standard. No-one can say they ‘support HTML5’ yet, because no-one knows yet what ‘HTML5’ is actually going to be.
In practical terms: there are some parts of HTML5 that have long been in use. There are some parts that you can use safely on modern browsers. There are some parts that you can use on new browsers except for IE. There are many parts you can use with fallback workarounds or ‘graceful degradation’. There are some parts you may never be able to use. For now you will have to learn each separately, because there won't be a browser that supports absolutely everything in HTML5 for many, many years. If ever. Add the extra features you like gradually as you go along and they're supported by a greater share of browsers; there will be no ‘big bang’ where everyone updates their browser at once.
As for data- attributes, well, yeah, you can kind of get away with using them, in that most browsers have always allowed any old attributes to go through anyway. This is typical of several HTML5 extensions, the browser doesn't need to explicitly ‘support’ it for it to work.
But since there are other ways of passing data (classes, comments, script blocks, etc.), I'm not wholly convinced it's worth dropping (universally supported, validatable against a fixed standard) HTML4/XHTML1 pages just for that one feature yet.
You might want to check out diveintohtml5.ep.io and modernizr.com.
Modernizr is a small and simple JavaScript library that helps you take advantage of emerging web technologies (CSS3, HTML 5) while still maintaining a fine level of control over older browsers that may not yet support these new technologies.
Here's an interactive chart of html feature support:
http://a.deveria.com/caniuse/
As you can see, there are a lot of browsers that support quite a few of the H5 features.
If you're using jQuery, concerned about interoperability, and the only reason you're investigating HTML5 is to use the data-* attribute set, then I would consider switching back to a better-supported doctype and using jQuery's $().data() method, which allows you to bind arbitrary pieces of data to DOM nodes, similar to how the data- attribute set does.
Example:
<button id="set">Click me!</button>
$('button#set').click(function(){
if($(this).data('name')){
alert('Clickin\' again so soon, ' + $(this).data('name') + '?');
}else{
$(this).data('name', prompt('Hey good lookin\', what\'s your name?', ''));
}
});
Try it out!
My answer might not be the one you would like but I would say - don't. Don't use HTML 5 just yet.
Use Protovis. It uses javascript and HMTL5. No Flash here. More important, Protovis has BSD license. So you can use it in commercial projects. Although D3 is the a newer project that authors of Protovis are working on.
Although this is an old(ish) question, the topic of browser support will always be relevant. There's no right way or wrong way to approach it, but take a look through one of the many browser feature support tables that show you what percentage of users will see a certain feature and then be brutal.
Don't try to please everyone. Don't kill yourself to catch a few percent of the Luddite's who are still using IE7. Next year, substitute that for IE8. Personally, I would be happy to lose 8% in order to spend that time on forward thinking practices rather than catering for those who don't know what an upgrade is.
Maybe your site will cause people to upgrade. These people will come round eventually.