Re: [selectors4] feedback

Oh, thanks for clarifying things for me.  After reflection, I was mostly
wondering how references could help reduce javascript code which modify
styles, like the jQuery .css() method.  Since references enable selecting
elements all over the document--not just child elements--this would
slightly reduce the need for javascript to modify style on user interaction.

I'm not quite sure if that goal is really in line with the path of css
development. I'm really speaking on my behalf when I say I would find that
very a useful feature.  So, this is why I suggested allowing not just id,
but to allow the attribute value as a kind of variable to be used in the
second complex selector for a tiny bit more flexibility.

>  Can we make the spec clearer?

I imagine I'm thinking too far beyond what is actually intended by the
proposal, which is why it was unclear to me.  I tend to think how I can
reduce various javascript in favor of more structured css, which is why
this proposal got my attention.  For the simpler function of simply
selecting the mate of an element by id, it is perfectly clear.


On Fri, Dec 6, 2013 at 2:44 PM, Simon Sapin <simon.sapin@exyr.org> wrote:

> On 06/12/2013 08:59, Gavin Engel wrote:
>
>> 2. It is somewhat non-intuitive as to where the reference (/for/)
>> applies to the second selector (/input/).  If we use a more complex
>>
>> example we can see this more clearly:
>>
>>     label:matches(:hover, :focus) /for/ .foo input { }
>>
>> Does the/for/'s id apply to the .foo or to the input?
>>
>
> It applies to .foo
>
> Combinators always describe the relationship between the two "compound
> selectors" they are in-between, nothing further.
>
> http://dev.w3.org/csswg/selectors4/#compound
>
>
>  I imagine it is
>> meant to always apply to the /final/ simple selector (/input/), even
>>
>> though reading from left-to-right the /for/ is next to .foo.  This makes
>> it somewhat non-intuitive.  It also removes the /possibility/ of
>> attaching the id to the first simple selector (/.foo/).
>>
>
> Why did you imagine that, if you also find it non-intuitive? Can we make
> the spec clearer?
>
> --
> Simon Sapin
>