[whatwg] reflected enumerated attributes feedback
ian at hixie.ch
Tue Nov 30 16:10:36 PST 2010
On Tue, 17 Aug 2010, Aryeh Gregor wrote:
> Actually, it goes further than that. Everyone but IE seems to just
> return the value of the content attribute when you do a get on the IDL
> <!doctype html>
> var el = document.createElement("form");
> el.setAttribute("method", "invalid value");
> IE alerts "get", everyone else alerts "invalid value". Are non-IE
> implementers interested in changing to match IE here? IE's behavior
> seems more useful.
On Mon, 23 Aug 2010, Mounir Lamouri wrote:
> This is actually a recent change in the specification so you should not
> expect to have all browsers working the same way. FWIW, Firefox
> nightlies already follow this change. That will be in beta5 too.
Yeah, this area of the spec in general has been in some flux and the
implementations are all somewhat away from interoperable.
On Thu, 26 Aug 2010, Aryeh Gregor wrote:
> On Thu, Aug 26, 2010 at 2:00 PM, Ian Hickson <ian at hixie.ch> wrote:
> >> * marquee.direction
> > What do browsers do for this one?
> Seems like they don't limit it to known values, at least Firefox/Opera/Chrome.
Ok. I've left the spec as-is.
> >> * 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.
> If we could change all these to limited without compat problems,
> though, it would be a nice little simplification -- enumerated
> attributes would all have the same reflection behavior.
True, though the interoperability we'd be losing is one of the few bits of
interoperability we have in this space!
> > The real question is, would implementing the spec lead to
> > compatibility issues?
> As Mounir Lamouri pointed out, Firefox nightlies already mostly
> implement the spec here, so I guess we'll find out. :) The spec is
> considerably nicer than preexisting behavior.
Ok, I've made the change for th.scope. If you could file bugs on getting
browsers on board with this that would be great. :-)
I haven't changed textareap.wrap because of wrap=off. That value still has
the browser put the attribute in the Soft state, but there is some CSS
magic that only happens for that value and I am concerned that there will
be pages depending on that keyword being detectable. (In particular,
changing this would mean that code like textarea.wrap = textarea.wrap
could change the layout, which seems bad.)
I haven't changed meta.httpEquiv because that one is much more likely to
have scripts examining the value irrespective of browser support.
Historically, that's been used as a kind of extension point; it being
enumerated is relatively recent.
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
More information about the whatwg