[whatwg] Arbitrary HTML in option-elements

Olav Junker Kj?r wrote:
> It would be a useful feature if arbitrary HTML was allowed in option 
> elements. E.g. items in a dropdown could have different icons.

    Yeah, personally, I think we should look at adding the |icon| 
attribute to the <option> element.

> However, I think it's a bad idea to declare rendering undefined in this 
> case. (section 2.18)
> Since arbitrary HTML in option-elements is a genuinely useful feature, 
> some authors are probably going to take advantage of it, if it is 
> available in some implementations. This will lead to incompatibilities.

    I doubt that you'd see popular user agents implement support for 
undefined behavior unless there's a specific use case that becomes common.

> History shows that web authors don't care about what features is allowed 
> or forbidden according to the spec. They care about what features 
> actually works in "the real world", i.e. in the dominant existing 
> implementations - regardless of whether its official feature or an 
> undocumented error-handling behavior.

    That's somewhat true, but the bottom line is that they only use what 
works in the most popular browsers, and those browsers are only going to 
support undefined behavior if they see a reasonable use case. Otherwise, 
  it's much easier to just discard markup when the rendering behavior is 
undefined.

> Along the same lines, I think its a bit misleading to warn against 
> putting form-elements into select-elements because of usability-issues 
> (also section 2.18). The warning implies that you *can* put forms into 
> options, but usually shouldn't, while its actually forbidden by the DTD 
> in section A.

    Actually, this is a better point. It's one thing to give user agents 
flexibility in rendering, but it's another to allow them to violate the 
DTD. The spec can't require strict adherence to the DTD in one place and 
allow UA vendors to do what they want in another.

Received on Tuesday, 30 November 2004 10:48:58 UTC