Bugzilla – Bug 952
Bring autocomplete microsyntax into line with current spec
Last modified: 2014-01-08 06:16:23 CET
In the last few months, the microsyntax for the value of the autocomplete attribute got a bit more complicated: http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#autofilling-form-controls:-the-autocomplete-attribute Filing this just as a reminder for now. This definitely seems like a case where it makes little sense to try to implement validator support for yet; both because Hixie seems to still be tweaking it, and because as far as I can tell at least, nobody's actually implemented it yet -- and it's not clear how much wide interest there is in actually implementing much of it, ever.
The extended syntax is now part of W3C HTML5 CR, too. There’s the problem that if you validate, say, a document with `autocomplete="section-blue shipping street-address"`, you get an error message that links to a document that specifically mentions this construct as an example. Confusing, isn’t it? Suggestion: Modify the check to accept any whitespace-separated list of name tokens, for now. Even disabling all checks for `autocomplete` values would be better than issuing error messages about constructs that are not errors (as per documents that are cited in the messages).
(In reply to Jukka K. Korpela from comment #1) > The extended syntax is now part of W3C HTML5 CR, too. It probably shouldn't be if no browsers actually implement support for it yet as currently specified. > There’s the problem that if you validate, say, a document with > `autocomplete="section-blue shipping street-address"`, you get an error > message that links to a document that specifically mentions this construct > as an example. Obviously the chance of any person in the real world ever using the `autocomplete="section-blue shipping street-address"` that exactly matches the example in the spec is effectively zero. So as far as I can see nobody testing actual content is ever going to run into as a case where they get an error for an autocomplete value, and follow the link in the error message and discover that the spec using that exact same value as an example. > Confusing, isn’t it? It'd only be confusing to somebody who was actually using anything like that kind of autocomplete value in a real-world document. Which as far as I can see nobody would be, since no browsers have implemented support for that syntax yet (and incidentally it so far doesn't seem to me any implementers have much interest at all in implementing that syntax). > Suggestion: Modify the check to accept any whitespace-separated list of name > tokens, for now. Why? As far as I know there are no browsers that yet actually support the autocomplete attribute having any value other than "on" or "off". So if the validator didn't report an error for values other than "on" or "off", it seems to me that would actually be harmful and bad for users. > Even disabling all checks for `autocomplete` values would > be better than issuing error messages about constructs that are not errors > (as per documents that are cited in the messages). I guess you might think otherwise if you were testing with real content that you wanted browsers to do something useful with for real end users. As long as most browsers only support "on" and "off" as values for autocomplete, the right thing for the validator to do is to emit an error for any values other than "on" or "off".
(In reply to Michael[tm] Smith from comment #2) > As far as I know there are no browsers that yet actually support the > autocomplete attribute having any value other than "on" or "off". That’s quite possible. Every new feature starts with zero implementations. The fact still is that the validator reports a construct as erroneous and says this referring to a candidate recommendation that says that it is correct. So what does the validator really check against? Some people’s opinion on what is correct and what is not, without even telling who these people are? Even then, an error message citing a document that is in conflict with the message is confusing, to put it mildly. What I mean is that if the validator does not try to match HTML5 CR, HTML 5.1 draft, or WHATWG HTML, it should not cite any of them. The validator is really defining its own HTML now. It would be a completely different matter to issue a *warning* saying that the value of an attribute is not supported by browsers yet.
see also bug 984