- From: Ian Hickson <ian@hixie.ch>
- Date: Fri, 9 Dec 2011 20:53:36 +0000 (UTC)
- To: Boris Zbarsky <bzbarsky@MIT.EDU>
- cc: HTML WG <public-html@w3.org>
On Mon, 9 May 2011, Boris Zbarsky wrote:
>
> Consider this testcase:
>
> <!DOCTYPE html>
> <style>
> input { color: black; }
> input:hover { color: white; }
> </style>
> <label for="x">Hover me</label>
> <input id="x" type="button" value="A button">
>
> Observed behavior in browsers is that hovering the label puts the button into
> :hover state in WebKit but not in Gecko, Presto, or Trident. Similar for
> :active.
>
> However for controls that have native themed hover/active state, at least
> Gecko and Trident _do_ put the control into that native themed state when the
> label is hovered or activated. They just don't change the actual CSS-exposed
> :hover and :active state.
>
> See discussion in https://bugzilla.mozilla.org/show_bug.cgi?id=426082 where we
> implemented the current Gecko behavior.
>
> I would like to change the Gecko behavior here to match WebKit's, both because
> it would eliminate this weird dichotomy between native theme state and CSS
> state and because frankly it happens to be simpler to implement given some
> other changes I'm making. ;)
>
> Should the spec describe behavior here? Would Opera and Microsoft be willing
> to match WebKit and Gecko on this?
I think it's probably best to just leave this to the // combinator in
Selectors, as in:
label:hover input, label:hover /for/ input { ... }
--
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Friday, 9 December 2011 20:54:44 UTC