I've come across a situation where it would be helpful to know whether a given node has been distributed into a content node. There's a native Shadow DOM function node.getDestinationInsertionPoints() that's very helpful for this purpose, but I don't see a version of this in the polyfill world.
I can work around the need for this by doing my own inspection of a node's parent chain, but it'd be nicer to rely on the standard (?) getDestinationInsertionPoints() function. Does -- or will -- the Shadow DOM polyfill support this in older browsers?
The ShadowDOM polyfill should now support a polyfilled version of getDestinationInsertionPoints(). This particular change should be available in 0.3.x: https://github.com/polymer/polymer/releases
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.
A number of developers have been wondering how graceful degradation should be approached in custom elements (or Polymer elements). This is for the use-case where either polyfills are not being used, Web Components are not supported or JavaScript is simply switched off.
Does anyone have thoughts on how this should be done?
There are two types of custom elements we're usually interested in adding support for graceful degradation to: Custom Elements that extend native HTML tags and Custom Elements which do not.
Custom Elements support natively extending elements already baked into the platform (e.g <button>, <input>). One way of doing this is using the is syntax. So, if you're extending a built-in, I believe the most direct way to ensure graceful degradation is to use the is syntax as follows: <button is="my-button"> rather than <my-button></my-button>.
Some examples of where I could see this working well are:
Fancy input fields:
<input is="fancy-input" type="text" value="So fancy">
Custom video players:
<video is="custom-player" src="amazeballs.mp4">
Music visualizers:
<audio is="music-visualizer" src="track.ogg">
This way if a browser without Custom Element cannot understand the is syntax, the element being extending should still work with a degraded experience.
What about Custom Elements where you are not extending a specific built-in? For example: <my-preload-animation>.
One approach I've been taking to this is specifying fallback content in the Light DOM:
<my-preload-animation>
Loading...
</my-preload-animation>
If a browser without Custom Element support interprets the tag as HTMLUnknownElement, the fallback (a loading message) will still be rendered. This (appears) to work for simple elements.
For more complex ones (e.g if you're making use of <content>/<shadow> in your element), I remove the fallback via script when my custom element is upgraded.
I think that's reasonable. This is how most (not all) HTML elements work. Check out this blast from the past: http://code.tutsplus.com/tutorials/quick-tip-html5-video-with-a-fallback-to-flash--net-9982
I am thinking about starting to use some HTML5 elements in my sites. With the varying lack of support for HTML5 in Internet Explorer I was considering using HTML5shiv. I have read that I would need to set the CSS for various unrecognised elements to be block level and also the possibility of issues with loading HTML5 elements via ajax.
I would like to know what issues others have encountered when using this script. Thanks.
If you're going to dynamically load HTML5 elements you'll need the innershiv. You'll also need to bear in mind that if the IE user has JavaScript disabled, it won't work at all.
I've found the existing solution to be highly unreliable when used in real world scenarios - it's fine for noddy little "hello world" examples but as soon as the pages start getting more complex then you will find that styles will stop applying on some requests etc.
It's not a very nice answer, but the truth is that if you need to support older IE versions then you basically can't rely on being able to style HTML5 elements reliably. If you can get away with using the elements but use superflous markup (divs etc.) to do things like layout then you might get away with it, but then it depends what you consider to be the lesser of the two evils : Loads of noddy markup or no IE support.
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.