W3C home > Mailing lists > Public > public-css-archive@w3.org > September 2017

Re: [csswg-drafts] [css-position] Events for stickiness changes

From: Roman Komarov via GitHub <sysbot+gh@w3.org>
Date: Fri, 22 Sep 2017 18:24:07 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-331524420-1506104635-sysbot+gh@w3.org>
I'd start with whitelisting a certain set of properties that are guaranteed to be safe, that would allow developers to achieve most of the use cases for sticky elements (the changes in background, shadow etc.). CSS already has a similar mechanism for stuff like `:first-letter`, so I don't see a problem with that.

After that it would be possible to start thinking on more complex cases. But I'd say that instead of thinking about this particular pseudoclass and properties, it would be better to start thinking on how to fix the circularity/loops issue for the whole CSS. Its frustrating that so many must-needed for devs things like the `:stuck`, container queries etc. are blocked by this circularity issue. My proposal would be to make it so any declaration that would create a loop (and I'd say it should be possible to implement this) should be just discarded. So for the 

``` CSS
.foo { toggle-states: 2; toggle-initial: 1; } /* makes it checked */
:checked { position: sticky; }
:stuck { toggle-states: none; }

here we apply everything in the specificity order and at the moment something would create a contradiction, it just wouldn't be applied. So, in that case, the `toggle-states: none;` from the `:stuck` just wouldn't apply.

But even if that would be hard to implement, we still could **at first** allow the safe cases that would allow people to do stuff much easier already. That would so much more helpful than just discarding ideas completely.

GitHub Notification of comment by kizu
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/1660#issuecomment-331524420 using your GitHub account
Received on Friday, 22 September 2017 18:23:58 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 06:41:18 UTC