[whatwg] IDL attribute reflecting enumerated attributes not limited to only know values

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.   `._.-(,_..'--(,_..'`-.;.'