W3C home > Mailing lists > Public > public-css-archive@w3.org > October 2020

Re: [csswg-drafts] proposal: [css-variables] CSS variables in selectors (#3067)

From: Yair Even Or via GitHub <sysbot+gh@w3.org>
Date: Wed, 28 Oct 2020 11:38:49 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-717876971-1603885128-sysbot+gh@w3.org>
as someone working with CSS some ~20 years (not to brag, just to give perspective about my long experience with it) I think CSS variables should not be called "custom properties" because that limits the mind when thinking about them and forces a narrow view.

> Variables gain their values from properties on an element, but selectors aren't associated with any element

Why should they work like that? it's just limitation imposed by the spec, not not something that is technically impossible to achieve by simply agreeing to:

I suggest to think about variables as not "properties" but as "variables" which may only be fined within a scope of a selector, but are not confined to be used only as properties' values.

A browser's CSS interpreter sees this:

   .some-class:nth-child(var(--index))

And can safely assume to start looking for `--index` first in the selector `.some-class` and up from there, and whatever found is used, and if nothing found, the whole selector is ignored.

This behaviour is limited to selectors with `(...)`.

A step further in the road to extreme manipulation of selectors is:

    .some-class:var(--state, 'hover')


Imagine having the power to manipulate the rendered state, mimicking a user interaction...what would be the repercussions of such a powerful selector.. maybe security risk somehow? it is a highly-interesting prospect to consider.


-- 
GitHub Notification of comment by yairEO
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3067#issuecomment-717876971 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 28 October 2020 11:38:52 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 06:42:21 UTC