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

Re: [csswg-drafts] [css-values-4] Switch advanced attr() to being var()-like (#4482)

From: Xiaocheng Hu via GitHub <sysbot+gh@w3.org>
Date: Wed, 13 May 2020 00:23:56 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-627669709-1589329435-sysbot+gh@w3.org>
The latest spec seems very generous on the fallback value:

> 2. Otherwise, if the `attr()` function has a fallback value as its last argument, replace the `attr()` function by the fallback value. If there are any `var()` or `attr()` references in the fallback, substitute them as well.

This is different from the [old CSS3 spec](https://drafts.csswg.org/css-values-3/#attr-notation) that, we no longer verify the fallback against the given type.

So I got a few questions:

1. Is this change intentional? In other words, do we still want to verify fallback against the given type? Btw, some developers may assume that we do verify the fallback, like we do that for registered custom properties.

2. (If yes for 1) When using the fallback, while the given type is a specific unit (e.g., `px`), do we want to parse the fallback as a number or a pixel value? For example, should we resolve `attr(something-invalid px, 100)` into `100` or `100px`?

Note: There's [an existing WPT](https://source.chromium.org/chromium/chromium/src/+/master:third_party/blink/web_tests/external/wpt/css/css-values/attr-px-invalid-cast.html?q=attr%5C(.*%5C)%20file:external%2Fwpt%2Fcss) expecting `100`

3. (If yes for 1) When the attribute value itself is valid against the given type but the fallback isn't, is the `attr()` still valid at computed time? Again, some developers may assume no, similar to registered custom properties.

GitHub Notification of comment by xiaochengh
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4482#issuecomment-627669709 using your GitHub account
Received on Wednesday, 13 May 2020 00:23:58 UTC

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