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

On Wed, Aug 28, 2013 at 5:01 AM, Brian Kardell <bkardell@gmail.com> wrote:
> On Aug 28, 2013 1:20 AM, "Tab Atkins Jr." <jackalmage@gmail.com> wrote:
>> 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.
>
> 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.

Believe me, I don't like this solution either, but I think it's the
only reasonable way to solve the problem.  Otherwise we're stuck in
today's world, where we can't do *any* selector-affecting properties
at all.

On Wed, Aug 28, 2013 at 5:45 AM, Mike Sherov <mike.sherov@gmail.com> wrote:
> 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.

There's no way to do so at parsing time, because you have no idea what
rules apply to what elements, and thus what'll get used together.
You'd have to run cycle detection *every time* an element started
matching any rule which contained a selector-affecting property, which
I believe is far too great a cost to reasonably pay.

(We require this very thing for variables, but it's easier to do
because it's limited solely to custom properties.)

~TJ

Received on Wednesday, 28 August 2013 14:52:22 UTC