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

[Aryeh Gregor]

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).

See discussion last Tuesday in #whatwg:

http://krijnhoetmer.nl/irc-logs/whatwg/20100803#l-875

Some notable lines:

# [20:56] <annevk5> I think we should change all enumerable attributes
to be limited like that
# [20:57] <annevk5> it makes sense to ignore on setting to unknown value
# [20:57] <annevk5> it is what <canvas> does as well
# [20:57] <annevk5> and gives the ability to do feature testing
# [20:58] <annevk5> I guess we should just implement it so the spec
can remove the whole concept of "limited to known values" and make it
part of the enumerable attributes definition
# [20:59] <volkmar> actually, some time ago i proposed (in a mail) to
move the default behavior to be limited to only known values
# [20:59] <volkmar> and if, needed, case by case, don't limit the attribute
# [21:02] <annevk5> AryehGregor, I suspect no content relies on this,
though I'm not a 100% sure of course
# [21:02] <annevk5> AryehGregor, the most problematic are probably
knew enumerated attributes on existing elements
# [21:02] <annevk5> s/knew/new/
# [21:03] <annevk5> I just went through the spec; there are not too
many either

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
* marquee.direction
* marquee.trueSpeed
* meta.httpEquiv
* textarea.wrap
* th.scope
* track.kind

It doesn't say either way for device.type (there's no line about it
having to reflect anything).  The contenteditable, draggable, and
spellcheck attributes have magic behavior of their own.

What do other implementers think about this?  Is the compat risk from
changing all of these to be limited to only known values worth it?  It
would make the platform more consistent -- there's no rhyme or reason
right now to which ones are limited to only known values and which
aren't.  Being limited to known values seems more convenient than not,
so if we can standardize on one, that's the better one.