Re: [whatwg] default select item that does not satisfy required attr.
On Fri, 24 Feb 2006, Ric Hardacre wrote: from the web forms doc in the comment at the bottom: * have a way of marking the first option of a select as the default but have it not satisfy a new required= attribute on select so that you can have selects that require a valid value. my proposed solution: [...] * A fairly common situation for web authors is to have two lists, where the contents of the second depends on the value of the first. Is here any way we could extend the current model to include this functionality? [...] On Fri, 24 Feb 2006, dolphinling wrote: [...] I think the solutions proposed here (not quoted above for brevity) are interesting. However, I think, as with my earlier e-mail today, we should probably wait until the current crop of forms features is more widely implemented before adding more features. Thus, I haven't actually added these features yet. Cheers, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] default select item that does not satisfy required attr.
Ric Hardacre wrote: from the web forms doc in the comment at the bottom: * have a way of marking the first option of a select as the default but have it not satisfy a new required= attribute on select so that you can have selects that require a valid value. my proposed solution: whoops, i bashed out my markup examples quickly and totally fooed up some of it, specifically i should have optgroup label=text, but anyway, they were supposed to demonstrate the default semantic, also if a better word can be used than default for the option flag then so be it. ric
Re: [whatwg] default select item that does not satisfy required attr.
Ric Hardacre wrote: from the web forms doc in the comment at the bottom: * have a way of marking the first option of a select as the default but have it not satisfy a new required= attribute on select so that you can have selects that require a valid value. How about just a new element (or even a current element) that can be put inside select but isn't option? That would make most sense semantically, since it would be something in the select that wasn't an option. What do current UAs do with known non-option elements and unknown elements in select? Alternatively, if that doesn't work, why not hack it with option disabled selected ? That works fine on Firefox trunk, at least, haven't checked other browsers. It can even be styled to appear how you want it. It's not optimal semantically (as that's not really an option), but it's no worse than HTML 4 (actually, it *is* HTML 4). -- dolphinling http://dolphinling.net/
Re: [whatwg] default select item that does not satisfy required attr.
dolphinling wrote: What do current UAs do with known non-option elements and unknown elements in select? Replying to myself, it seems that Firefox trunk ignores all three of text not in any element, text in a known non-option element, and text in an unknown element, when served as text/html, even not including them in the DOM. When served as application/xhtml+xml, they are displayed as would be expected (inside the dropdown, p with margins, etc.), but p selected=selected does not make the p the first thing shown. So it appears my first idea is infeasable backwards-compatibly. -- dolphinling http://dolphinling.net/
