[css-values-5] `attr()` support extended capabilities #521

brandonmcconnell · 2023-10-03T20:33:26Z

Description

The attr() CSS function is used to retrieve the value of an attribute of the selected element and use it in the stylesheet. It can also be used on pseudo-elements, in which case the value of the attribute on the pseudo-element's originating element is returned. (MDN)

Specification

CSS Values and Units Module Level 5
# attr-notation

Open Issues

[css-values] Security concerns regarding attr() w3c/csswg-drafts#5092
[css-values] attr()'s url type seems wrong w3c/csswg-drafts#5079
attr() support extended capabilities (Interop 2023) #86 (not open, but a related issue from Interop 2023)

Tests

The below list of tests was generated using wpt-find (wpt-find -mlc 'attr(')

Current Implementations

Blink
Gecko
WebKit

Standards Positions

Gecko/Mozilla
- Intent to prototype and ship: CSS attr() fallback (related bug)
Chromium/Blink
- Intent to Implement and Ship: CSS advanced attr() function
- Intent to Prototype: CSS advanced attr() function (Was: Intent to Implement and Ship)

Browser bug reports

Developer discussions

Some posts in support of attr():

X/Twitter

StackOverflow

If you search X/Twitter for "CSS attr" you will see plenty of posts from people excited about and/or curious about the future features of CSS attr(). You'd also see many posts echoing one opinion calling the attr() useless, especially in comparison to CSS custom properties.

I'd like to disagree with that sentiment, but… he's right. As the attr() function stands today, attr() is really only useful when trying to pull plain text from attributes to display using a pseudo-element.

It's mostly useless, but it doesn't have to be.

With these newer features, attr() would be exceedingly useful, not taking the place of CSS custom properties by any means but rather bridging the gap between markup values and CSS values. This would stand as a very productive separation of concerns.

Polls & Surveys

No response

Existing Usage

No response

Workarounds

The primary workaround for this is to use CSS custom properties, but this has several drawbacks and only lives in the markup in the form of inline styles. One of the greatest advantages of attr() is the ability to utilize the values set on the markup.

To achieve this with CSS custom properties, one would need to apply those values twice, once to the attributes for actual markup functionality and again as a CSS custom property for CSS usage. Example:

<!-- tightly coupled redundancies in the attributes vs. inline styles -->
<progress min="0" max="100" value="50" style="--min: 0; --max: 100; --value: 50;"></progress>

<style>
  progress {
    --percentage: calc((var(--value) - var(--min)) / (var(--max) - var(--min)) * 100%);
    background: linear-gradient(to right, green var(--percentage), white var(--percentage));
  }
</style>

With attr(), we can achieve this more concisely, using attribute values directly:

<!-- here, the styles will inherit from the attributes dynamically, so no need to set the explicit values twice -->
<progress min="0" max="100" value="50"></progress>

<style>
  progress {
    /* I'm using `attr()` directly in this calculation, but these values could also be abstracted to CSS custom properties for ease of reuse */
    --percentage: calc((attr(value number) - attr(min number)) / (attr(max number) - attr(min number)) * 100%);
    background: linear-gradient(to right, green var(--percentage), white var(--percentage));
  }
</style>

Accessibility Impact

Tightly coupled code can lead to inconsistencies due to human/developer-error when updates are made. The DRY coding principle would reasonably apply here.

Privacy Impact

This issue focuses on security concerns using attr(), but there are already good ideas re how to circumvent those issues, the primary of which would be whitelisting: w3c/csswg-drafts#5092

Other

No response

The text was updated successfully, but these errors were encountered:

webstrand · 2023-10-04T01:08:13Z

I like to use display: grid for <table> markup. Being able to write generic css that handles most of the built-in table attributes would be nice, e.g. rowspan colspan ...

thebabydino · 2023-10-04T07:37:39Z

Here's another use case: images with a spaced out gradient border that looks extracted from the image.

The markup for an image would be just

<figure>
	<img src='meow.jpg' alt='fluffy black cat'/>
</figure>

Then in the CSS, this would do the trick for the image with the spaced out "gradient" (actually very blurred) border:

img {
	border: solid 1em;
	border-image: filter(src(attr(src)), blur(99px)) 10%;
	padding: 1em; /* space between image and border */
	width: 12em;
	aspect-ratio: 1;
	object-fit: cover
}

No browser currently supports this and it's not just because of attr(). src() doesn't seem to be in any browser at the moment, while filter() is only supported in Safari (has been supported there for over 8 years at this point, but no other browser followed).

The current cross-browser solution feels needlessly complicated.

First, when I generate the HTML, add a --url custom property that uses the same image url from the src attribute.:

- let url = 'meow.jpg';

figure
	img(src=url style=`--url: url(${url})` alt='fluffy black cat')

Then in the CSS, I need all of this:

figure {
	display: grid;
	width: 16em;

	img, &::after {
		grid-area: 1/ 1;
		border: solid $b hsla(0, 0%, 0%, .001)
	}
	
	img {
		box-sizing: border-box;
		border-image: var(--url) 10%;
		padding: $b;
		width:100%;
		aspect-ratio: 1;
		object-fit: cover
	}
	
	&::after {
		backdrop-filter: blur(99px);
		mask: 
			linear-gradient(red 0 0) padding-box exclude, 
			linear-gradient(red 0 0);
		content: ''
	}
}

And this doesn't even include the -webkit--prefixed version for mask, which is still needed at this point (live demo).

With attr(), we can achieve this more concisely, using attribute values directly:

<!-- here, the styles will inherit from the attributes dynamically, so no need to set the explicit values twice -->
<progress min="0" max="100" value="50"></progress>

<style>
  progress {
    /* I'm using `attr()` directly in this calculation, but these values could also be abstracted to CSS custom properties for ease of reuse */
    --percentage: calc((attr(value number) - attr(min number)) / (attr(max number) - attr(min number)) * 100%);
    background: linear-gradient(to right, green var(--percentage), white var(--percentage));
  }
</style>

I'm intrigued! This looks very good in theory and I'd love to be able to use something like this for inputs! For example, for input[type=range], this would eliminate the need for JS as we wouldn't need to rely on a JS-updated custom property for the value, like I'm doing in this demo.

But one thing that confuses me is that I don't see the value attribute for such an input changing in DevTools as I drag the thumb. The actual value (that I update the --val custom property with) does change, but not the number value in the value attribute. So would attr(value) actually work, or would it just be always the same value set initially in the value attribute?

If attr(value) could work in calc() and could get updated on dragging the thumb, that would be wonderful. Because I currently use the --val attribute to compute quite a few things, for example the position of a tooltip value display and the number value shown in that tooltip. And since --val can only be updated via JS, no JS means no tooltip value display.

brandonmcconnell · 2023-10-04T09:05:47Z

@thebabydino Solid feedback all around. Examples like that greatly help to express this feature like this. Thank you!!

Re the value attribute updating, I've run into that as well a number if times and have a couple other proposals to address that—

[css-values-5] value() function

This proposal introduces a CSS function for incorporating the live value of an input, exactly as you've put it here
[css-properties-values-api] add support for scope-global variables

This proposal introduces a completely new way to work with CSS custom properties — globally.
(expand/collapse explainer)

Hypothetically, you could use @property to set up a custom property with a new global option on its @property config set to true. When the custom property is set up this way, it only ever has one value — that with the highest specificity. This way, we can set global values using states such as a checkbox or an input value and access it anywhere else in that scope.

For example, you could create a dark mode toggle checkbox somewhere on the page, and without needing to resort to some top-level :has() (not inherently bad, but an alternative), you could have that checkbox's checked state update the global value naturally, like this:
```
@property --color-bg {
  syntax: "<color>";
  inherits: true;
  initial-value: white; /* ⬜️ */
  global: true;
}
@property --color-text {
  syntax: "<color>";
  inherits: true;
  initial-value: black; /* ⬛️ */
  global: true;
}
#darkmode:checked {
  --color-bg: black; /* ⬛️ */
  --color-text: white; /* ⬜️ */
}
#page {
  background-color: var(--color-bg); /* ⬛️ */
  color: var(--color-text); /* ⬜️ */
}
```
A feature like this would be essential for exposing attributes as well as the value property of descendant elements that cannot otherwise expose them upwards. I'm considering this feature a dependency of my other value() proposal.

I would certainly appreciate any support you'd show to either of those proposals as well. Thank you 🙂

OnurGumus · 2023-10-04T09:53:17Z

In addition I would add, inline styles aren't very good for security and CSP perspective.

webstrand · 2023-10-04T15:24:40Z

@thebabydino

This looks very good in theory and I'd love to be able to use something like this for inputs! For example, for input[type=range]

This was my first thought, too. Range is a pain to style, currently: https://codepen.io/webstrand/pen/bGLXdPR

So would attr(value) actually work, or would it just be always the same value set initially in the value attribute?

Traditionally, <input> elements don't update their attribute when their value property changes. Changing this behavior would be a breaking change as there's quite a lot of things that reuse inputEl.getAttribute("value") to restore fields to their initial state. For instance <button type="reset"> looks at the attribute value to determine what to reset to.

I'm not sure I'd be a fan of adding special cases for attr(value) though.

brandonmcconnell · 2023-10-04T16:45:50Z

@webstrand I agree; I don't think we should introduce any special cases using attr() to retrieve dynamic values like the live value prop of an input.

If you're interested, take a peek at the other two proposals I mentioned, namely this one: [css-values-5] value() function

Re the value attribute updating, I've run into that as well a number if times and have a couple other proposals to address that—
[css-values-5] value() function

This proposal introduces a CSS function for incorporating the live value of an input, exactly as you've put it here
[css-properties-values-api] add support for scope-global variables

This proposal introduces a completely new way to work with CSS custom properties — globally.
(expand/collapse explainer)

Hypothetically, you could use @property to set up a custom property with a new global option on its @property config set to true. When the custom property is set up this way, it only ever has one value — that with the highest specificity. This way, we can set global values using states such as a checkbox or an input value and access it anywhere else in that scope.

For example, you could create a dark mode toggle checkbox somewhere on the page, and without needing to resort to some top-level :has() (not inherently bad, but an alternative), you could have that checkbox's checked state update the global value naturally, like this:
@property --color-bg {
  syntax: "<color>";
  inherits: true;
  initial-value: white; /* ⬜️ */
  global: true;
}
@property --color-text {
  syntax: "<color>";
  inherits: true;
  initial-value: black; /* ⬛️ */
  global: true;
}
#darkmode:checked {
  --color-bg: black; /* ⬛️ */
  --color-text: white; /* ⬜️ */
}
#page {
  background-color: var(--color-bg); /* ⬛️ */
  color: var(--color-text); /* ⬜️ */
}
A feature like this would be essential for exposing attributes as well as the value property of descendant elements that cannot otherwise expose them upwards. I'm considering this feature a dependency of my other value() proposal.

jacobrask · 2023-10-05T17:15:39Z

Another concrete example, an icon component that should be sized in rems to scale with the text, and also use mask-image to allow it to inherit the text color, so dual potential usage of attr in one class. Currently we do something like this

.icon {
  width: var(--_height);
  height: var(--_height);

  &[height='64'] {
    --_height: 4rem;
  }
  &[height='48'] {
    --_height: 3rem;
  }
  &[height='40'] {
    --_height: 2.5rem;
  }
  &[height='32'] {
    --_height: 2rem;
  }
  &[height='24'] {
    --_height: 1.5rem;
  }
  &[height='16'] {
    --_height: 1rem;
  }
  background-color: currentColor;
  mask-image: var(--icon-url);
}

brandonmcconnell · 2023-10-05T22:04:22Z

@jacobrask Great example. I've done something similar for custom progress bars:

<div class="progress-wrapper">
  <progress min=0 max=100 value=75></progress>
</div>

progress[min][max][value] {
  .progress-wrapper:has(&) {
    --percentage: calc((var(--value) - var(--min)) / (var(--max) - var(--min)) * 100%);
    height: 100vh;
    width: 100vw;
    background: linear-gradient(to right, red var(--percentage), white var(--percentage));
  }
  .progress-wrapper:has(&) & {
    display: none;
  }

  /* min */
  .progress-wrapper:has(&[min="0"]) { --min: 0; } /* ... */
  .progress-wrapper:has(&[min="100"]) { --min: 100; }

  /* max */
  .progress-wrapper:has(&[max="0"]) { --max: 0; } /* ... */
  .progress-wrapper:has(&[max="100"]) { --max: 100; }

  /* value */
  .progress-wrapper:has(&[value="0"]) { --value: 0; } /* ... */
  .progress-wrapper:has(&[value="100"]) { --value: 100; }
}

CodePen demo

bkardell · 2024-02-01T17:59:38Z

Thank you for proposing attr() support extended capabilities for inclusion in Interop 2024.

We wanted to let you know that this proposal was not selected to be part of Interop this year.

As of the deadline, the specifications for attr() support extended capabilities were not yet complete enough to allow interoperable implementations. To make progress on this area in the future, it will first be necessary to ensure that the feature has a clear specification in a standards track document.

For an overview of our process, see proposal selection. Thank you again for contributing to Interop 2024!

Posted on behalf of the Interop team.

brandonmcconnell · 2024-02-01T18:04:08Z

@bkardell What features from the official specification are not complete enough to move forward with this feature? The spec is complete and has been for years.

This feature has been suggested for the past few consecutive years via interop and otherwise.

More notably, this issue garnered more attention and praise and engagement than any other interop issue proposed, which I believe should be weighed heavily when considering proposed features for interop.

One of the primary functions of proposing issues for interop is to give the community the ability to vote on which issues they desire to see implemented in the web platform most. The results clearly show that this is a top priority if not THE top priority.

foolip · 2024-02-01T23:10:33Z

@brandonmcconnell you're right that there's a lot of developer demand for this, that is very clear. The issue with the spec isn't really that it's "not yet complete enough to allow interoperable implementations", but that there are security issues that at least the Chrome team believes are serious enough to need solving before shipping. That is the topic of w3c/csswg-drafts#5092, and we now have a sketch of a solution that might work. I am going to follow up on that work so that the security issues can be resolved. (I did take a look while we were evaluating proposals too, but there just wasn't enough time to fix it there and then.)

brandonmcconnell · 2024-05-18T18:25:22Z

@foolip (cc @tabatkins) Given the recent progress and resolutions in w3c/csswg-drafts#5092, and the exceeding demand on this interop proposal the past two consecutive years (#86 & #521), could we reconsider including it in this year's interop effort, as the blocker is now removed?

bkardell · 2024-05-20T16:54:34Z

We can't, as part of Interop 2024. Interop choices and tests are carefully chosen so that we have measurable goals that don't significantly change during the year... But don't be too disheartened by that answer: It doesn't mean teams can't all prioritize it independently -- in my opinion, another benefit of the Interop project is just that it gets us collectively thinking/talking about priorities... So, it's totally possible if the situation regarding specs is resolved, that it might get interoperable support in the same year without actually being a part of the Interop project.

brandonmcconnell · 2024-05-20T17:14:30Z

@bkardell Thanks, that's understandable 🙂

brandonmcconnell added the focus-area-proposal Focus Area Proposal label Oct 3, 2023

github-project-automation bot added this to Interop 2024 Oct 3, 2023

brandonmcconnell mentioned this issue Oct 3, 2023

attr() support extended capabilities (Interop 2023) #86

Closed

brandonmcconnell mentioned this issue Oct 11, 2023

Declarative custom functions w3c/csswg-drafts#7490

Open

brandonmcconnell changed the title ~~attr() support extended capabilities~~ [css-values-5] attr() support extended capabilities Oct 25, 2023

bkardell closed this as completed Feb 1, 2024

github-project-automation bot moved this to Done in Interop 2024 Feb 1, 2024

brandonmcconnell mentioned this issue Feb 29, 2024

Retrospective: Interop 2024 proposer experience #635

Closed

captainbrosset mentioned this issue Oct 30, 2024

Adds attr features web-platform-dx/web-features#2109

Merged

o-t-w mentioned this issue Dec 10, 2024

CSS advanced attr() function mozilla/standards-positions#1143

Open

o-t-w mentioned this issue Jan 8, 2025

CSS advanced attr() function WebKit/standards-positions#435

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[css-values-5] `attr()` support extended capabilities #521

[css-values-5] `attr()` support extended capabilities #521

brandonmcconnell commented Oct 3, 2023 •

edited

Loading

webstrand commented Oct 4, 2023

thebabydino commented Oct 4, 2023 •

edited

Loading

brandonmcconnell commented Oct 4, 2023

OnurGumus commented Oct 4, 2023

webstrand commented Oct 4, 2023

brandonmcconnell commented Oct 4, 2023 •

edited

Loading

jacobrask commented Oct 5, 2023 •

edited

Loading

brandonmcconnell commented Oct 5, 2023

bkardell commented Feb 1, 2024

brandonmcconnell commented Feb 1, 2024 •

edited

Loading

foolip commented Feb 1, 2024

brandonmcconnell commented May 18, 2024 •

edited

Loading

bkardell commented May 20, 2024

brandonmcconnell commented May 20, 2024 •

edited

Loading

[css-values-5] attr() support extended capabilities #521

[css-values-5] attr() support extended capabilities #521

Comments

brandonmcconnell commented Oct 3, 2023 • edited Loading

Description

Specification

Open Issues

Tests

Current Implementations

Standards Positions

Browser bug reports

Developer discussions

X/Twitter

StackOverflow

Polls & Surveys

Existing Usage

Workarounds

Accessibility Impact

Privacy Impact

Other

webstrand commented Oct 4, 2023

thebabydino commented Oct 4, 2023 • edited Loading

brandonmcconnell commented Oct 4, 2023

OnurGumus commented Oct 4, 2023

webstrand commented Oct 4, 2023

brandonmcconnell commented Oct 4, 2023 • edited Loading

jacobrask commented Oct 5, 2023 • edited Loading

brandonmcconnell commented Oct 5, 2023

bkardell commented Feb 1, 2024

brandonmcconnell commented Feb 1, 2024 • edited Loading

foolip commented Feb 1, 2024

brandonmcconnell commented May 18, 2024 • edited Loading

bkardell commented May 20, 2024

brandonmcconnell commented May 20, 2024 • edited Loading

[css-values-5] `attr()` support extended capabilities #521

[css-values-5] `attr()` support extended capabilities #521

brandonmcconnell commented Oct 3, 2023 •

edited

Loading

thebabydino commented Oct 4, 2023 •

edited

Loading

brandonmcconnell commented Oct 4, 2023 •

edited

Loading

jacobrask commented Oct 5, 2023 •

edited

Loading

brandonmcconnell commented Feb 1, 2024 •

edited

Loading

brandonmcconnell commented May 18, 2024 •

edited

Loading

brandonmcconnell commented May 20, 2024 •

edited

Loading