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

[csswg-drafts] [css-cascade] Define "Applies to" better (#5565)

From: Florian Rivoal via GitHub <sysbot+gh@w3.org>
Date: Thu, 01 Oct 2020 05:11:34 +0000
To: public-css-archive@w3.org
Message-ID: <issues.opened-712488284-1601529093-sysbot+gh@w3.org>
frivoal has just created a new issue for https://github.com/w3c/csswg-drafts:

== [css-cascade] Define "Applies to" better ==
(Forked from https://github.com/w3c/csswg-drafts/issues/1861#issuecomment-691751716)

The precise effect of "applying" or "not applying" tends to vary a fair bit. The statement in [cascade-3](https://drafts.csswg.org/css-cascade-3/#applies-to) is generic enough that it's probably fine in all cases, but I am not sure it helps more than it hurts when it comes to gray zones and other ambiguities.

For instance, css-text has a bunch of things that apply to inline boxes. If you try and apply them to block boxes, it inherits into the (possibly anonymous) inline boxes, and has an effect that way. This is not in contradiction with the spec's statement, since indeed, there is no effect on the block box, and its only through inheritance that anything happens, but the statement does not shed any light on this situation.

Another one would be `writing-mode` and `text-orientation`, which don't apply to various table parts, yet still influence the calculation of [font relative length units](https://drafts.csswg.org/css-values/#font-relative-length) on these same elements through the computed value. Still not necessarily a contradiction if you're strict about it, but not really helping either.

PR https://github.com/w3c/csswg-drafts/pull/5562 is one attempt to improve this. We could also make a separate section about this.

cc: @fantasai @tabatkins 

Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5565 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 1 October 2020 05:11:36 UTC

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