[whatwg] IDL attribute reflecting enumerated attributes not limited to only know values
Ian Hickson
ian at hixie.ch
Fri Aug 6 12:01:16 PDT 2010
On Tue, 8 Jun 2010, Mounir Lamouri wrote:
>
> An example where this behavior seems buggy:
> - input.type and button.type: every browser makes it return "text" if
> @type isn't set to a known value. If we follow the specifications, .type
> should return the current value of @type.
Fixed.
> Examples where having another behavior would help:
> - method, formmethod, enctype and formenctype have a list of
> keywords/states with a default missing value. It would be great to have
> the IDL attribute returning the current state instead of the content.
> So, scripts wouldn't have to look at the content, checking for values
> they know and falling-back to the default value to know the current state.
Done. This appears to be a compatibility fix for enctype and a
compatibility change for method, based on Chrome's current behaviour.
> - 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?
> Maybe, instead of having some attributes "limited to only known values"
> we could have some attributes "not limited to only known values", thus
> inverting the default reflecting behavior for enumerated attriutes ?
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).
--
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