- From: Tab Atkins Jr. via GitHub <sysbot+gh@w3.org>
- Date: Tue, 12 Nov 2024 23:46:33 +0000
- To: public-css-archive@w3.org
* Yes, in general I'm somewhat opposed to behaviors that are only indicated by a *lack* of something, when we can avoid it. Having a default is good, but it's much easier to define/reference/teach when there's an actual value that produces the behavior. * You're right, `value` doesn't actually add anything over `type(*)`. So yeah, I think just using `type(*)` is fine. * Dropping `<number px>` would knock out some cases that could *potentially* be useful (accepting an attribute which can be *either* a percentage *or* a number that should be interpreted as px), but I think that's okay now that we have such an easy way to write the simple case. Previously, even the simple case was hard (requiring a wrapping `calc()`), so addressing the complex case at the same time as making the simple case easier was worthwhile. So yeah, I think we can drop `<number px>` unless/until it's requested. So, the exact proposal is that the parsing specifier for `attr()` can be either: * `type(<syntax>)`, allowing the full range of `<syntax>` values and resembling custom functions' grammar. * `string`, meaning "take the value of the attribute exactly as written", aka the current behavior. (This is also the default if omitted.) * `px`/etc (all defined CSS units), meaning "parse as a number, and then give it that unit". Aka, `attr(foo px)` is identical in behavior to `calc(attr(foo type(<number>)) * 1px)`. -- GitHub Notification of comment by tabatkins Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/11035#issuecomment-2471871211 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 12 November 2024 23:46:34 UTC