W3C home > Mailing lists > Public > www-style@w3.org > August 2013

Re: :stuck psuedo class WAS: specifying position:sticky

From: Mike Sherov <mike.sherov@gmail.com>
Date: Wed, 28 Aug 2013 08:45:28 -0400
Message-ID: <8584700508398728986@unknownmsgid>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
Cc: Brian Kardell <bkardell@gmail.com>, Ojan Vafai <ojan@chromium.org>, Corey Ford <cford@mozilla.com>, "www-style@w3.org" <www-style@w3.org>, "L. David Baron" <dbaron@dbaron.org>
Mike Sherov
Chief Technologist
SNAP Interactive, Inc. | Ticker: STVI
http://snap-interactive.com | http://ayi.com

On Aug 28, 2013, at 1:22 AM, "Tab Atkins Jr." <jackalmage@gmail.com> wrote:

> On Tue, Aug 27, 2013 at 7:10 PM, Brian Kardell <bkardell@gmail.com> wrote:
>> On Tue, Aug 27, 2013 at 9:27 PM, Tab Atkins Jr. <jackalmage@gmail.com>
>> wrote:
>>> On Tue, Aug 27, 2013 at 5:34 PM, Ojan Vafai <ojan@chromium.org> wrote:
>>>> This may be too early, but I think we should add a pseudo-class for
>>>> position:sticky's that are stuck to an edge. This lets you easily style
>>>> the
>>>> stuck element (e.g. with a box-shadow).
>>>
>>> Immediately bringing up the obvious question of what ":stuck {
>>> position: static; }" does.
>>>
>>> I think we can't avoid this problem forever, and that the right
>>> solution is to define a set of "selector-affecting properties" and
>>> "property-affected selectors", and say that you can't set any of the
>>> former in a style rule whose selector contains one of the latter.
>>>
>>> (That is, you can't *just* say "you can't set position inside a :stuck
>>> rule", because as soon as another property/selector (foo-prop and
>>> :foo), you can just set 'foo-prop' inside of :stuck and then set
>>> 'position' inside of :foo and run into circularity again.  You have to
>>> treat the whole set of properties as infectious to the whole set of
>>> selectors.)
>>
>>
>> Wow - I think my mind just exploded.  Can you (or anyone who understands)
>> try explaining that again with some slightly more intuitively named
>> fictitious prop/selectors so I can try wrapping my head around what you are
>> saying in that last paragraph? or explain the relationship you are
>> explaining another way that leads to circularity?  It seems like you are
>> saying that if we had a simple "setting the following properties in a :stuck
>> rule has no effect..." that is some other way to hit circularity because of
>> another (new) situation like it?  Is it only in the case where the
>> properties overlap between two of them or something?  Perhaps I am being
>> dense, but my mind is spinning.
>
> Okay, better example. ^_^  Assume that my Toggle States suggestion
> also exists: <http://tabatkins.github.io/specs/css-toggle-states/Overview.html#checked-problems>
>
> You could then write code like:
>
> .foo { position: sticky; }
> .foo:stuck {
>  toggle-states: 2;
>  toggle-initial: 1;
>  /* makes it match :checked */
> }
> .foo:checked {
>  position: static;
>  /* makes it not match :stuck */
> }
>
> If you get stuck, you match :checked. If you're checked, you're
> unstuck.  Circles!
>
> Instead, 'position' and the 'toggle-*' properties are both defined as
> "selector-affecting properties", and :stuck and :checked are
> "property-affected selectors", so you can't use any of those
> properties in blocks with either of those selectors.

I'm concerned that we may paint ourselves into a corner this way if we
use such a broad brush. As the list of selector-affecting properties
and property-affected selectors grows, we exponentially reduce the
list of properties that can be applied to selectors, no? We then risk
becoming strongly disincentivized to create new property-affected
selectors or selector-affecting properties for fear of reducing the
utility of existing ones.

It seems there should be a way to detect cyclical rules that originate
from a selector-affecting property declaration (although I can't speak
to any complexity it adds to the cascade) and when detected, consider
that rule as invalid.

Apologies if I'm being overly reductive. I'm sure there's a bunch of
edge cases I may not be considering.

>
> ~TJ
>
Received on Wednesday, 28 August 2013 12:46:00 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:33 UTC