Last Comment Bug 435426 - implement css3-values extensions to attr()
: implement css3-values extensions to attr()
Status: NEW
[DevRel:P2]
: dev-doc-needed, DevAdvocacy
Product: Core
Classification: Components
Component: CSS Parsing and Computation (show other bugs)
: Trunk
: All All
: P3 enhancement with 96 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
: Jet Villegas (:jet)
Mentors:
http://dev.w3.org/csswg/css-values-3/...
Depends on: 332335
Blocks: css3-values css3test 1265343
  Show dependency treegraph
 
Reported: 2008-05-23 08:34 PDT by Zack Weinberg (:zwol)
Modified: 2016-10-06 20:58 PDT (History)
74 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
?


Attachments

Description Zack Weinberg (:zwol) 2008-05-23 08:34:22 PDT
We should implement css3-values' extensions to the attr() function:
http://www.w3.org/TR/css3-values/#attr
Comment 1 Jesse Ruderman 2008-11-30 21:48:34 PST
URL is now http://www.w3.org/TR/css3-values/#attribute
Comment 2 Lea Verou 2011-04-13 07:13:43 PDT
Any updates on this? IE9 supports it since version 9.
Comment 3 Zéfling 2014-02-25 15:35:29 PST
No plan to support this? CSS Variables is supported by Gecko but not attr(), it's little strange for me...Is it is more complex ?
Comment 4 Pavel Ivanov [:ivanovpavel][:pivanov] UX 2014-02-26 12:55:34 PST Comment hidden (me-too, notechnicalvalue)
Comment 5 Girish Sharma [:Optimizer] 2014-03-23 11:25:32 PDT Comment hidden (me-too, notechnicalvalue)
Comment 6 Greg Weng [:snowmantw][:gweng][:λ] 2014-03-23 18:22:32 PDT Comment hidden (me-too, notechnicalvalue)
Comment 7 Cameron McCormack (:heycam) 2014-03-23 18:27:54 PDT
Please do not use "+1" comments to indicate support for a bug, which cause a bunch of emails to be sent; use votes instead.
Comment 8 Kohei Yoshino [:kohei] 2015-01-22 21:36:00 PST
The MDN article already describes the CSS3 syntax.
https://developer.mozilla.org/en-US/docs/Web/CSS/attr

I'd like to see this implemented, so inline styles, that need to be marked as "unsafe" in CSP directives, can be replaced with data attributes.
Comment 9 Jean-Yves Perrier [:teoli] 2015-01-23 01:44:30 PST
Switched back to ddn: that way, when this bug is resolved, we will be notified, update the compat data in the article, add it to Fx XY for developers.

Rule of thumb: never set ddc on a non-RESOLVED bug.

Sorry for the spam.
Comment 10 brunoais 2015-01-24 02:20:09 PST
I'm not quite understanding.
Why is this not implemented yet? Is it that no one wants to implement? Is there discussion missing? Is it too hard? Is there an error in the spec or any kind that creates reluctance in applying it?...?
Why?
Comment 11 Kumar Harsh 2015-02-12 03:51:06 PST
Not trying to be spammy, but the last comment, which has unfortunately been marked as spam, does have an underlying point. I really can not find any concrete discussion around this issue. Is there any plan to support this feature?
Comment 12 Zack Weinberg (:zwol) 2015-02-12 06:56:25 PST
I am not aware of any controversy over the spec or any sentiment that this is not a desirable feature.  I think it's just that everyone who knows how to implement it is too busy with other things.  I regret that I can neither give you any kind of time frame for when we might get around to it, nor suggest any good place for you to raise the issue in hopes of changing people's priorities.

I have cleared the spam tag on comment 10.  Bug herders: honest expressions of user frustration are not spam.
Comment 13 Kumar Harsh 2015-02-12 08:20:47 PST
Thank you for an honest answer Zack. Yes, that's the rather sad part about small features like these... Perhaps no one is giving it much thought because Chrome hadn't done it yet.
Comment 14 yair even or 2015-02-12 08:52:43 PST
@kumar(In reply to Kumar Harsh from comment #13)
> Thank you for an honest answer Zack. Yes, that's the rather sad part about
> small features like these... Perhaps no one is giving it much thought
> because Chrome hadn't done it yet.

There is nothing small about this feature!!! it has the potential for amazing things for the web! I've been waiting for this for long years, so much could have been done smarter using such ability. It hurts me that you don't understand the greatness and how hugely important it is.
Comment 15 Zack Weinberg (:zwol) 2015-02-12 09:03:26 PST
(In reply to yair even or from comment #14)
> There is nothing small about this feature!!! it has the potential for
> amazing things for the web! I've been waiting for this for long years, so
> much could have been done smarter using such ability. It hurts me that you
> don't understand the greatness and how hugely important it is.

One thing that may not be obvious from the outside: *browser* developers are not necessarily very good *web* developers.  Speaking personally, I understand what the attr() extensions in CSS3 Values *do*, but I haven't ever encountered a situation where I *needed* them for something.

I said that there was no good place to raise the issue, and that's true in the narrow sense that complaining here will not change anyone's priorities, and complaining on Mozilla's development mailing lists won't help either.  But here's something constructive you *could* do: write an essay, on your own blog or similar venue, in which you demonstrate that this is a valuable thing to have.  Give a bunch of examples of things you either can't do or that require a lot of tedious working-around in the absence of this feature.  That will help us and others understand why you want it.
Comment 16 yair even or 2015-02-12 09:28:52 PST
There is a famous blog post that explain this situation by telling a nice story - http://www.thegrumpyprogrammer.com/2014/11/its-users-stupid.html
Comment 17 Zack Weinberg (:zwol) 2015-02-12 09:49:56 PST
(In reply to yair even or from comment #16)
> There is a famous blog post that explain this situation by telling a nice
> story - http://www.thegrumpyprogrammer.com/2014/11/its-users-stupid.html

That is a great anecdote, and let me explain why it means you should write that essay on your own blog like I suggested.

Situation 1: Imagine that you are the LibreOffice developers, in the anecdote, and someone comes to you and says "we want to do iterative calculations in our spreadsheets" - but they don't tell you why.

Now situation 2: you're still the LibreOffice developers, but now someone comes and says "we want to do iterative calculations because look, here is this library of spreadsheets that solve mechanical engineering problems for us in Excel and if only they also worked in LibO we could run them on our supercomputer."

You'd be a lot more sympathetic to the request in the second case, wouldn't you?

It's the same deal with attr() extensions.  We're currently in situation 1, and you could move us to situation 2 if you wrote that essay.
Comment 18 Lea Verou 2015-02-12 11:22:45 PST
There have been use cases, which is why it was added to the spec in the first place. Nothing gets added without use cases. It’s ridiculous to ask of developers to bring you more use cases just to implement the spec. Just look up the relevant discussions & minutes in www-style!
Comment 19 Kumar Harsh 2015-02-12 11:45:47 PST
@Lea, I think what Zack is trying  to say is that WE have to amass more proof to show the browser engineers that this is really a pain point... otherwise they'll be just sounding their time fixing other stuff... I myself remember reading up on this nifty possibly on Chris Coyer's css tricks blog, and was amazed by the possibilities. I believe that was quite a while back, and there should be many more articles already on the web. I'll compile a list tomorrow.
Comment 20 David Baron :dbaron: ⌚️UTC-10 2015-02-12 14:28:40 PST
I think the main use cases for this were actually around the goal of being able to explain all of HTML's presentational behavior using CSS, something that's become less of a goal lately now that HTML5 has added a lot more behavior that would be harder to explain.  So the use cases that I remember from when it was added appear, today, rather weak.  Seeing other real use cases would be helpful, although filling up this bug too much will make the bug unreadable.

It's also worth pointing out that this is a pretty large change; I would say it most likely is substantially larger than CSS Variables, and probably imposes more architectural constraints on the engine, although maybe there are clever ways to do parts of it that I haven't thought of.
Comment 21 Kumar Harsh 2015-02-12 21:59:48 PST
David Walsh had a small post about it here: http://davidwalsh.name/css-content-attr

Then, there's Lea Verou's own blog, which has a much more detailed coverage on attr(): http://lea.verou.me/2010/09/on-attr-and-calc/

The best "implementation" I found was a polyfill, which simulates the attr() property. You can find the polyfill here: http://codepen.io/FWeinb/pen/Dsdkr

As a simple google search shows, there are already a number of people wanting it, and talking about it, for quite some time now.
Comment 22 Florian Rivoal 2015-03-31 23:24:36 PDT
Here's an example from a css specification showcasing a situation where numerical information present in the markup (and correctly so, as it is semantic information, not merely presentational) would be useful to access from css via the extended attr() syntax.

http://dev.w3.org/csswg/css-egg/#celestial-css
Comment 23 Andy Earnshaw 2015-07-08 06:49:06 PDT
One use case is the ability to achieve parity between custom HTML elements and some replaced elements.  For instance, <video>, <img>, <iframe>, <object>, <canvas> and others all allow specifying `height` and `width` as attributes.  Mimicking this is difficult with a custom HTML element, but could be made simpler with these extensions to attr():

    my-customelement {
        width: attr(width px, 300px);
        height: attr(height px, 150px);
    }
Comment 24 Chris Rebert 2015-10-05 18:01:02 PDT
The progress bar use case in Lea's blog post (linked in comment #21) is made more compelling when you consider that a strict Content Security Policy makes the inline `style="width: X%"` alternative unusable.
Example: https://github.com/twbs/bootstrap/issues/17785
Comment 25 dotnetCarpenter 2015-10-10 13:16:30 PDT
dev-doc seems to be there: https://developer.mozilla.org/en/docs/Web/CSS/attr
But unfortunately using it doesn't work on other properties than content.
<div class="hero" data-image-src="images/photosliderpicture.png"></div>
.hero {
  background-image: attr(data-image-src url);
}
Comment 26 Jean-Yves Perrier [:teoli] 2015-10-10 14:45:58 PDT
Yes, as written in the page you linked (see Browser compatibility) and as the topic of this non-resolved bug is.
Comment 27 Sebastian Zartner [:sebo] 2016-02-03 03:04:31 PST
Completely agreeing with Lea's statement in comment 18, here's still a simple use case:
Adjust the width of an input field according to its max-length.

The code for may look like this:

data:text/html,<input maxlength="5" style="box-sizing:content-box;width:attr(maxlength ch, 10ch);">

Sebastian
Comment 28 dotnetCarpenter 2016-02-03 04:43:43 PST Comment hidden (typo)
Comment 29 dotnetCarpenter 2016-02-03 04:47:15 PST Comment hidden (typo)
Comment 30 Jen Simmons [:jensimmons] 2016-06-03 13:55:59 PDT
This would be very useful in combination with CSS Shapes. 

Here's an example: 
  http://labs.jensimmons.com/examples/shapes-5.html
or the same example on CodePen
  http://codepen.io/jensimmons/pen/bedqqQ?editors=1100

by using 

    img {
      shape-outside: attr(src url);
    }

an author can control a shape by referencing the image that content should be floated around. This will make it very easy to use Shapes in the context of a Content Management System.

Note You need to log in before you can comment on or make changes to this bug.