W3C home > Mailing lists > Public > public-css-archive@w3.org > November 2019

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

From: Mike Bremford via GitHub <sysbot+gh@w3.org>
Date: Tue, 05 Nov 2019 10:00:30 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-549751733-1572948019-sysbot+gh@w3.org>
I see no value in allowing image or position - I think you're opening a dangerous door once you allow structures like `<div data-foo="linear-gradient(red, blue)"/>`. Although adding resolution seems harmless enough.

For what it's worth we've implemented attr() as specified, although we're not yet shipping so that shouldn't factor into amy decision to change the definition. Yes, the type checking on parse seemed an unnecessary step, as the value is going to be validated again anywhere when you evaluate the property. I also agree the type is required - the most common use for attr() from where I sit is `attr(href uri)`, which only works if there is a type. And the distinction between "length" and "px" is also valuable.

@Crissov - as we read it, `attr` can already be used anywhere, including to represent color components - these are already valid expressions:

color: rgb(attr(red number), attr(green number), attr(blue number));
width: calc(50px * attr(multiplier number, 4));

But again, I don't think think there's any value in changing the `attr()` syntax to be some sort of calc-lite: You're not adding any new functionality with this suggestion, and the existing syntax is not impractical. Change for change's sake should be strongly discouraged.

However, as we're looking at attr I'd like to suggest removing the restriction on the fallback value not being an `attr()` expression itself. This restriction no longer makes sense if the values are being evaluated later, as they are for `var()`

GitHub Notification of comment by faceless2
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4482#issuecomment-549751733 using your GitHub account
Received on Tuesday, 5 November 2019 10:00:36 UTC

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