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.
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 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.
I've done a little bit of playing around with the new HTML5 tags and read up on all the new ones at W3cschools, etc. and I'm a little confused.
If I create an HTML page that uses "areas", "sections", "asides", etc. Nothing happens? I have to manually style them - which is FINE, but am I missing something? What's the point of declaring a tag an "aside" if I have to make it ASIDE (common css: float:right;width:30%, sorta thing)?
Why not just stay with DIV tags and style them?
I also noticed new attributes, such as "draggable", but, surprise-surprise, it doesn't drag! I have to code it to drag too (javascript/jquery??) ? What's the point of declaring it draggable? I can create a div tag and drag it using JQuery, so someone please enlighten me as to what's so "whoopty doo" about html5?
This is how the web changes in respect to HTML.
First new tags are created by browser makers for advanced users to try out.
Then they are added to the standard
Then they actually get implemented in the various browsers and devices.
Then they become widespread and useful.
Then they become universal and are implemented by 99.9% of devices.
For the tags mentioned they are probably between steps 2 and 3
It may not be "whoopty doo" but this is how changes occurs in this system
Developers who accept, embrace and use this pattern of evolution help move this process along.
It's a bit zen-like.
Additionally, as Aaron points out in his comment above (+1), these particular tags are semantic tags for organizational/outlining and search engines, screen readers and the like. So you yourself may not see much up front for them.
Might not be the case but at least I know for me I make this mistake every now and then. Don't forget to include at the top <!DOCTYPE html>. Furthermore, not all browsers support HTML5 yet I believe so make sure the browser version you are using supports it (most of them should support it nowadays though).
Since a long time ago, when I found out about the W3C Validator, I made sure every HTML document I made was valid HTML.
However, I think sometimes it just isn't necessary to waste time making it valid. Of course, for actual Internet pages may be important, but is making pages on an Intranet, or even little front-ends that are used with other programs, when the HTML page renders correctly in the most used browsers (not necessarily counting IE 6 and 7).
I think I'm mostly talking about little improvements over code, such as wrapping every shown element of the page on <p> or <div> tags.
Making a page validate for its own sake is not really a business proposition. What happens for end-users (with their cranky browsers) is the real test.
That said, validating periodically will help you debug. It'll catch the more salient errors like unclosed tags. Which, in turn, does affect end-users. So treat validation like compiler warnings -- good for discipline.
It's the best practice, but it really comes down to an organizational requirement/desire. Is it important enough that standards add value for your organization? Or is it simply enough that it displays correctly? Often with intranets its the latter.
Making an HTML page "valid" is worth it if you intend to be future friendly. That is, when browsers begin to strip out deprecated or vendor specific tags, you will find your page displaying incorrectly.
Web standards are there for a reason - to ensure consistent display/output among web browsers and interpreters. Choosing to write your pages in non-compliant HTML is your decision. It is also, to take an old adage, your "funeral".
What happens when the browser of choice for the intranet changes? There really isn't a way to guarantee that the code you have will render correctly in EVERY browser. But in a lot of cases the browsers will be reasonably close to the standard. I think it also depends on how complex the page is because the chances it renders differently in different browsers increases as the complexity of the CSS and tag depth does. The best way is to write valid cross-browser code and test for target browsers. Its silly to think write-once and render the same everywhere is possible for all browsers. But adhering to the standards is the best way you can get close.
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.