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

On Aug 28, 2013 1:20 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.
>
> ~TJ

Got it.. So, more generally speaking this is the result of defining states
which are themselves triggerable by properties of any rule... Right?  If
so, feels like it would be better to try to abstract a new pattern to avoid
the problem in the first place.... Otherwise it seems a little unintuitive
... Setting certain props this way (without what you explain) would often
be a non problem and, in fact, might allow useful things - but because some
combinations *could* be we would just shut them all down.  I don't have a
better answer at this time but that makes it seem unintuitive.