[whatwg] IDL attribute reflecting enumerated attributes not limited to only know values
Ian Hickson
ian at hixie.ch
Thu Aug 26 11:00:56 PDT 2010
On Fri, 6 Aug 2010, Aryeh Gregor wrote:
> On Fri, Aug 6, 2010 at 3:01 PM, Ian Hickson <ian at hixie.ch> wrote:
> > I'm happy to make more of them limited, especially new attributes or ones
> > that were already that way, but I'd rather not change the default as that
> > can have unexpected effects (e.g. some of the attributes are definitely
> > not so limited, and I don't recall which that might be).
>
> The enumerated attributes in the spec right now that are not limited to
> only known values are, by my count:
>
> * audio.preload, video.preload (note that at least WebKit appears to
> treat these as limited to known values already)
> * command.type
> * form.autocomplete, input.autocomplete
> * track.kind
These are all changed now.
> * marquee.direction
What do browsers do for this one?
> * marquee.trueSpeed
This is now a boolean attribute.
> * meta.httpEquiv
I'm pretty sure browsers don't treat this as limited to only known values.
> * th.scope
> * textarea.wrap
Browsers don't seem to limit these.
On Sat, 7 Aug 2010, Mounir Lamouri wrote:
> On 08/06/2010 09:01 PM, Ian Hickson wrote:
> >> - input.autocomplete: at the moment, it is returning the content but
> >> it could return the resulting autocompletion state which is maybe a
> >> bit more than just being limited to only known values but still in
> >> the same spirit.
> >
> > I haven't changed this; what's the use case for knowing the actual
> > state?
>
> Theoretically speaking, I think input.autocomplete should return the
> current autocompletion state because that would follow the actual idea
> of enumerated attributes limited to only known values.
There's a big difference between reflecting the state of the attribute
(what reflecting enumerated attributes does) and reflecting the state of
the actual feature (which is rare in the DOM).
> Indeed, these kind of enumerated attributes doesn't return the content
> value but the value associated with the current state and in that case
> the 'state' is the autocompletion state.
No, the attribute's state is based on its value and is distinct from the
actual autocompletion state.
> Practical speaking, autocomplete is mostly used in writing (authors want
> to force/disable autocomplete) and we can assume that a script reading
> this value is going to check if the element have autocompletion. Having
> input.autocomplete returning this state may prevent the authors to
> repeat the algorithm thus preventing errors and making further changes
> in specification easier (and transparent).
I don't follow.
> By the way, why autocomplete IDL attributes have been introduced in the
> specifications?
Completeness.
On Tue, 17 Aug 2010, Aryeh Gregor wrote:
>
> Test case:
>
> <!doctype html>
> <script>
> var el = document.createElement("form");
> el.setAttribute("method", "get");
> alert(el.method);
> el.setAttribute("method", "GET");
> alert(el.method);
> </script>
>
> Spec:
>
> """
> If a reflecting IDL attribute is a DOMString whose content attribute
> is an enumerated attribute, and the IDL attribute is limited to only
> known values, then, on getting, the IDL attribute must return the
> conforming value associated with the state the attribute is in (in its
> canonical case) . . .
> """
> http://www.whatwg.org/specs/web-apps/current-work/multipage/urls.html#reflecting-content-attributes-in-idl-attributes
>
> This says it should echo "GET" twice. Four out of the five browsers I
> tested in (Firefox 4 beta, Chrome dev, Safari 5, Opera 10.60) echo
> "get" and then "GET". IE8 and IE9PP4 echo "get" twice. I think the
> spec and IE are right here -- you should be able to test form.method
> == "GET" (or == "get", whichever) and have it work whenever it's in
> the GET state. However, since 4/5 of browsers disagree, I'm asking if
> anyone thinks the spec should be changed, before I file browser bugs.
The real question is, would implementing the spec lead to compatibility
issues?
--
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
More information about the whatwg
mailing list