This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Just tried to validate a document with a <option> element. The syntax for the specific fragment was as follows: <select> <option label="Opel" value="opel"></option> <option label="Audi" value="audi" /> </select> The second option (Audi) has a label and a value, so according to the specs it admits an empty content model as well as end tag omission. I use the XHTML syntax which is allowed in HTML (though it has no effect). The response from the validator is error. More precisely Self-closing syntax (/>) used on a non-void HTML element. Ignoring the slash and treating as a start tag. Which is somehow confusing, as in this structure the option element is effectively treated as void (it cannot have both label+value and content). In fact when validating the same document as XHTML, the validator flags nothing. If the problem is in using the self-closing syntax in a non-void element, then the element is non-void as both HTML and XHTML (the validation for the latter does not take into account only well-formedness) and XHTML validation must report it accordingly. If, on the contrary, there's a bug in the validator not recognizing the void element, then it's HTML validator which must be corrected. It's the same issue as "<menuitem> content model" that I sent some weeks ago (still unresponded).
(In reply to Andrea Rendine from comment #0) > <option label="Opel" value="opel"></option> > <option label="Audi" value="audi" /> ... > The response from the validator is error. More precisely > Self-closing syntax (/>) used on a non-void HTML element. Ignoring the slash > and treating as a start tag. Yeah, conforms to the spec. ... > In fact when validating the same document as XHTML, the validator flags > nothing. Right. That's because in XML, <option label="Audi" value="audi" /> is exactly the same thing as <option label="Audi" value="audi" ></option> -- because in XML there is actually something called a "self-closing" tag. But in text/html, <option label="Audi" value="audi" /> is not the same thing as <option label="Audi" value="audi" ></option> at all -- because in text/html there is no such thing as a "self-closing" tag. In other words, in text/html that slash in the start tag has no meaning at all and no effect at all. > If the problem is in using the self-closing syntax in a non-void > element, No, because there's no such thing as "self-closing syntax" in text/html. The slash is irrelevant. The only problem is that the <option> element is not a void element, and per the spec in text/html it must have an end tag. But it does not have an end tag in your document. Hence the error. > then the element is non-void as both HTML and XHTML There is no such thing as a void element in XML. The term "void element" is something specific to text/html> > (the validation > for the latter does not take into account only well-formedness) and XHTML > validation must report it accordingly. No it must not, because there's no error to report. To an XML parser, <option label="Audi" value="audi" /> is exactly the same thing as <option label="Audi" value="audi" ></option>. > If, on the contrary, there's a bug in the validator not recognizing the void > element, then it's HTML validator which must be corrected. There's no bug in the validator for this case. The validator behavior here conforms to the spec.
My fault was not to see in detail the difference between W3 HTML5 spec and WHATWG HTML Living Standard. In the latter it is stated that the <option> end tag is omissible in HTML under certain conditions. This, and the fact that the element's content model with both @label and @value specified is *empty*, induced me to think that a syntax like <select><option label="foo" value="bar"></select> were allowed in HTML. Hence a polyglot syntax like the one in my example (I meant "void element in HTML representing an element without content in XHTML"). Now I know that end tag omission is non-standard for <option> and I'll set the <option></option> structure as polyglot.
Anyway, could I suggest something? In some elements the section "tag omission in text/HTML" is explicitly specified. In some elements it isn't. This is a problem in such cases - had I known that W3 HTML5 spec differs from the living standard in that it expects "Neither tag is omissible". This way it would be an author's fault to have it omitted.
(In reply to Andrea Rendine from comment #3) > Anyway, could I suggest something? In some elements the section "tag > omission in text/HTML" is explicitly specified. In some elements it isn't. > This is a problem in such cases - had I known that W3 HTML5 spec differs > from the living standard in that it expects "Neither tag is omissible". This > way it would be an author's fault to have it omitted. Are you asking for a spec change? Or what? As far as I can see there's nothing I can change in the validator in relation to this.
In fact there's nothing for the validator. Sorry, I'll refer to the spec for a suggestion.