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.
Related
I'm starting some work on some input fields.
I have a decision to make whether to carry out an action on the input:focus itself, or on a larger parent area focus.
In order to make the parent focusable, I intend to add a tabindex -1.
I've looked around and know that this stuff has been around a long time, but before I set off on a particular route, it would be good to know whether this works cross browser.
In terms of browsers I need to support, IE10 up, Chrome, Firefox, and the new "IE6", Android (3.0 upwards).
I'd appreciate any feedback as this is not something I can find out on caniuse and not something I can test widely at this stage.
Yes and no.
The HTML5 specification's notes on tabindex state:
If the value is a negative integer
The user agent must set the element's tabindex focus flag, but should not allow the element to be reached using sequential focus navigation.
However the HTML401 specification's notes on tabindex state:
This attribute specifies the position of the current element in the tabbing order for the current document. This value must be a number between 0 and 32767. User agents should ignore leading zeros.
If the browser supports HTML5 or ignores the HTML401 specification's implementation notes you're good to go. I have no idea what you mean by the new "IE6", but the other browsers you mention all implement HTML5.
Yes. It's been supported for years.
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 was hoping to use HTML5's input control (with range type) to allow our users to click up/down and increment/decrement a value represented inside of the control.
After taking a look at supported browsers: http://www.w3schools.com/html5/html5_form_input_types.asp, I found that this control was not supported in all the browsers I need it to be supported in.
I did a bit of Googling, but am not sure what keywords I should be using to dig up a more friendly version of this control. It seems all references to the words 'input' and 'range' immediately point me to the HTML5 version.
Does anyone know how I could emulate this functionality while still supporting IE8 and all modern browsers?
HTML5 Input range polyfill could be used.
Details are in this URL :
http://www.frequency-decoder.com/2010/11/18/unobtrusive-slider-control-html5-input-range-polyfill/
Also, www.HTML5Please.com is an excellent site when stuck with fall back or polyfill doubts.
I have tried to find an answer to this in the W3C HTML specifications, but haven't had any luck so far.
For example, if I have the following HTML code:
<body>
<p>
<foo>bar</foo>
</p>
</body>
Does W3C specify how a user agent should handle this? E.g should the "foo" element be completely ignored? Should the "foo" element be ignored but the content "bar" parsed?
Also, is it even "legal" to do this?
Edit: Some excellent answers from all of you! I totally agree that it would be bad practice to embed generic XML unless, possibly, if you have complete control over which browser your users will use. I was mostly curious about what actually would or should happen if such markup were to be produced :-)
The HTML spec doesn't say much about it, other than:
The HTMLUnknownElement interface must be used for HTML elements that are not defined by this specification (or other applicable specifications).
This can be verified in conforming browsers using the following JavaScript code in the console:
Object.prototype.toString.call(document.createElement("foo"));
//-> "[object HTMLUnknownElement]"
However, some browsers either don't follow the specification here yet. For instance, Chrome 13 gives [object HTMLElement], IE 8 gives [object HTMLGenericElement] (IE 9 is correct).
As far as I'm aware, all browsers will parse <foo> as an element, but default styling and behaviour is not guaranteed to be the same. Where HTMLUnknownElement is implemented and the spec is followed, it should inherit directly from HTMLElement and, therefore, have many of the default properties found on other elements.
Please note that your HTML will not validate when you have non-standard elements in your markup. It's also worth mentioning that search engine crawlers, screen readers and other software will not be able to extract semantic meaning from these elements.
Further reading:
Why generic XML on the web is a bad idea and 386: Generic Elements; Still a Bad Idea - Anne van Kesteren's blog (2005, 2010)
Some excellent advice from #Andy E. This is just some add-ons to that.
The HTML5 draft does define how to parse unknown elements, however, it is distinctly non-trivial. To see the rules, see http://dev.w3.org/html5/spec/tree-construction.html
Note that the first version of Firefox to use these rules is FireFox 4, and the first version of IE to use the rules is IE 10. Older versions have a number of different and often very strange behaviours.
HTML has no notion of "legality", only validity or conformance to a standard. You are free to decide whether you want your pages to conform to any particular standard or not. There is no W3C standard of HTML where use of arbitrarily named elements is conforming.
It is generally advisable to make your HTML conforming to avoid unpredictable errors in browsers and other HTML consumers that you haven't tested against.
"bar" should definitely be rendered. For example, in the HTML5 video element, the contents of the element contain fallback content to be displayed in older browsers for exactly this reason. It's also why people traditionally put comments around style declarations:
<style><!--
(styling goes here)
--></style>
to hide the styling information from pre-HTML 4 browsers. (I think the comments aren't considered good practice any more.)
I frequently end up storing data in DOM elements and make heavy use of custom data attributes and JQuery. I know the HTML5 spec says data attributes should have the data- prefix, but as far as I can tell there's no harm in naming my attributes whatever I want.
Problem?
The only problem is in validation. Non-standard element attributes are not valid HTML5. So, there is no harm in them, but the danger of operating outside of any spec is that it may not be supported in the future or by a specific user-agent. You also run the risk that in the future, the spec will include your non-standard attribute, but it will mean something else entirely than what you intended. Worse case scenario, you have to go update the page when a new feature of the spec is implemented.
In the case of element attributes, it should work in all browsers.
Check out http://msdn.microsoft.com/en-us/library/ms536429%28VS.85%29.aspx for info on this subject as it pertains to Internet Explorer.
If you're OK with invalid HTML, then there's no problem. People have been doing it your way for years, so it's unlikely that any browsers will break the behavior you expect.