- From: Ian Hickson <ian@hixie.ch>
- Date: Wed, 7 Jul 2004 15:24:21 +0000 (UTC)
On Tue, 6 Jul 2004, Matthew Raymond wrote: > > The <fallback> element would only render when the "list" attribute > for element "combo1" is not correctly processed by the user agent. That's still basically equivalent to <legacy value="Web Forms 2.0">, except now instead of being coarsely defined (in terms of specs) it's defined in terms of features, like in SVG. The fact that SVG's feature list section is an entire multipage appendix, and the fact that in my experience with DOM hasFeature() and CSS product documentation ("we support X") it is nearly impossible to decide when you should claim to support a feature or not, both encourage me to avoid such a solution. > It would of course render when the |list| attribute isn't supported on > the system, but it would also render if |list| had an invalid value. How is that different that <datalist>, then? > Any UA implementing <fallback> need not provide a mechanism for what > standards it supports. It need only verify that it could not process a > specific element and/or attribute. In this way, the user doesn't even > have to know what standard the element or attribute belongs to. If we had the equivalent of this for CSS, would IE claim that it processed position:fixed, or not? If not, why not? There is definitely code there that does _something_ with that value, and the value is not ignored as per the specs. If so, why? What IE does with the spec could in no way be described as useful support for that feature. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Wednesday, 7 July 2004 08:24:21 UTC