Last Comment Bug 215083 - Support CSS3 content property replacement of element (rather than pseudo-element)
: Support CSS3 content property replacement of element (rather than pseudo-elem...
Status: NEW
[parity-opera][parity-webkit-ish]
: css3, dev-doc-needed, testcase
Product: Core
Classification: Components
Component: CSS Parsing and Computation (show other bugs)
: Trunk
: All All
: P3 enhancement with 48 votes (vote)
: Future
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
http://dev.w3.org/csswg/css3-content/
: 215403 315391 425766 620782 689088 702088 830069 (view as bug list)
Depends on:
Blocks: 39598 option-label 104312 714507 219417
  Show dependency treegraph
 
Reported: 2003-08-04 18:23 PDT by SvendTofte
Modified: 2016-01-06 17:23 PST (History)
48 users (show)
iseki.m.aa: needinfo? (dbaron)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Test Case (372 bytes, text/html)
2003-08-07 09:54 PDT, Anne (:annevk)
no flags Details

Description SvendTofte 2003-08-04 18:23:51 PDT
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5b) Gecko/20030804
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5b) Gecko/20030804

Using the css property "content", to replace an element
  acronym , abbr { content:attr(title); }
doesn't work. Only when using :before or :after, does the content display. Opera
seems to be able to do it, and the W3 working draft seem pretty clear, on how it
should work.

http://www.w3.org/TR/css3-content/#content

Maybe this shouldn't be filed, since the spec isn't a TR yet? If so, sorry for
wasting your time :)

Reproducible: Always

Steps to Reproduce:
1. Go to url

Actual Results:  
Mozilla didn't replace the element content, with the contents of the responding
elements title attribute.

Expected Results:  
It should replace the element content, with the value of it's title attribute.
Comment 1 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2003-08-04 19:27:45 PDT
This spec is nowhere near Candidate Recommendation and is thus not ready for
implementation.  I think it just clutters up bug lists to have bugs on such
things, so marking as wontfix, for now, anyway.
Comment 2 SvendTofte 2003-08-04 20:30:40 PDT
Cool enough, just wanted to make sure what the policy was on yet-TR specs :)
Comment 3 Bill Mason 2003-08-07 07:24:31 PDT
*** Bug 215403 has been marked as a duplicate of this bug. ***
Comment 4 Anne (:annevk) 2003-08-07 09:54:26 PDT
Created attachment 129370 [details]
Test Case

Sorry for the duplicate. I searched Bugzilla and I didn't found any bug/feature
request about this.

About the test case:
 The text should be: "The rule is applied", as it is in Opera 7.11.
Comment 5 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2004-01-22 10:19:56 PST
I'll reopen, but I don't want to encourage this, because it just makes real bugs
harder to find, and I certainly don't want a bug for every feature we haven't
implemented.
Comment 6 Justin Wood (:Callek) 2004-06-23 21:00:56 PDT
*** Bug 219417 has been marked as a duplicate of this bug. ***
Comment 7 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2005-09-19 16:06:53 PDT
See also bug 309217, for the css3 content property's fallback lists.
Comment 8 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2005-11-08 12:38:15 PST
*** Bug 315391 has been marked as a duplicate of this bug. ***
Comment 9 Jesse Ruderman 2008-03-28 13:28:31 PDT
*** Bug 425766 has been marked as a duplicate of this bug. ***
Comment 10 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2010-12-21 16:29:25 PST
*** Bug 620782 has been marked as a duplicate of this bug. ***
Comment 11 Martin Suchan 2011-02-17 12:09:07 PST
Sorry for my duplicate, but anyway. This issue has been opened 7 years ago(!) and it is still unsolved? The usage of 'label' in 'option' tag is well defined since 1999 in HTML 4.01 Specification and should be working, imho:
http://test.suchan.cz/test.html
http://www.w3.org/TR/html401/interact/forms.html#h-17.6
OPTION Attribute definitions
When rendering a menu choice, user agents should use the value of the label attribute of the OPTION element as the choice. If this attribute is not specified, user agents should use the contents of the OPTION element.
Comment 12 Boris Zbarsky [:bz] (Out June 25-July 6) 2011-09-25 22:29:49 PDT
*** Bug 689088 has been marked as a duplicate of this bug. ***
Comment 13 Alexei 2011-11-12 23:08:16 PST
Well, when you fix it?
Comment 14 j.j. 2011-11-13 02:35:59 PST
*** Bug 702088 has been marked as a duplicate of this bug. ***
Comment 15 j.j. 2011-11-13 02:41:39 PST
Alexei, (In reply to Alexei from comment #13)
> Well, when you fix it?

Not before there is s specification. 
You re-reported this twice no, please stop it! (bug 689088 comment 5)
Comment 16 Martin Suchan 2011-11-14 04:24:16 PST
At least the 'label' attribute in 'option' tags should be fixed (it's part of basic HTML 4.01 specification) - it works in IE, Chrome, Safari and Opera, so why not in FF?
https://bugzilla.mozilla.org/show_bug.cgi?id=40545
Compare this page in FF and Chrome/IE http://jsfiddle.net/jPKQz/3/
Comment 17 Alexei 2011-11-21 04:58:19 PST
Firefox is getting worse! Soon come to the point that this browser will be ****.
Comment 18 Lea Verou 2011-11-21 09:34:00 PST
(In reply to Alexei from comment #17)
> Firefox is getting worse! Soon come to the point that this browser will be
> ****.

O RLY? Which other browser do you think implements this? Lemme give you a hint: Only Opera.
Comment 19 Martin Suchan 2011-11-21 10:42:23 PST
This bug 215083 blocks(?) bug No. 40545: 'labels' for 'option' tags, which is something implemented in all other browsers except FF ;)
Comment 20 j.j. 2011-11-21 23:29:02 PST
People, please read
  https://bugzilla.mozilla.org/page.cgi?id=etiquette.html
before adding more comments. (Reading this ideally would prompt you to stop commenting)

(And comments about bug 40545 are mostly unrelated here. Fixing bug 215083 is not the one and only option to fix that bug.)
Comment 21 Alexei 2011-11-25 20:21:39 PST
Support all browsers: Safari, Opera, Google Chrome and even IE version 10.
Comment 22 :Ms2ger 2011-11-26 01:59:26 PST
(In reply to Alexei from comment #21)
> Support all browsers: Safari, Opera, Google Chrome and even IE version 10.

For ::before and ::after, yes. This bug is explicitly about div { content: "Hi"; }, which is currently only supported in Opera.
Comment 23 philippe (part-time) 2011-11-26 03:26:38 PST
(In reply to Ms2ger from comment #22)
> (In reply to Alexei from comment #21)
> > Support all browsers: Safari, Opera, Google Chrome and even IE version 10.
> 
> For ::before and ::after, yes. This bug is explicitly about div { content:
> "Hi"; }, which is currently only supported in Opera.

WebKit (Safari 5.1, Chrome something) supports div { content: url(path/to/image/png); }; but div { content: 'foo bar'; } is unfortunately not yet supported.

see also this thread: http://lists.w3.org/Archives/Public/www-style/2011Nov/thread.html#msg451
Comment 24 :Ms2ger 2011-11-26 03:30:16 PST
(In reply to philippe from comment #23)
> (In reply to Ms2ger from comment #22)
> > (In reply to Alexei from comment #21)
> > > Support all browsers: Safari, Opera, Google Chrome and even IE version 10.
> > 
> > For ::before and ::after, yes. This bug is explicitly about div { content:
> > "Hi"; }, which is currently only supported in Opera.
> 
> WebKit (Safari 5.1, Chrome something) supports div { content:
> url(path/to/image/png); }; but div { content: 'foo bar'; } is unfortunately
> not yet supported.

I didn't know that; thanks for the correction.
Comment 25 Alexei 2012-01-13 04:30:11 PST Comment hidden (abuse)
Comment 26 Alexei 2012-04-05 01:41:54 PDT
Stable draft: http://www.w3.org/TR/css3-content/
Comment 27 j.j. 2012-04-05 05:04:02 PDT
(In reply to Alexei from comment #26)
> Stable draft: http://www.w3.org/TR/css3-content/

This draft is not stable and out of date. Current draft is in URL field.

(Alexei, sorry, some of your comments here and in other bugs aren't helpful at all. You can not speed up the implementation process this way. Please read
https://bugzilla.mozilla.org/page.cgi?id=etiquette.html )
Comment 28 Mardeg 2012-06-16 05:42:35 PDT
*** Bug 765475 has been marked as a duplicate of this bug. ***
Comment 29 Jim Michaels 2012-06-16 22:51:32 PDT
for reference, this is in css 2.1 TR as well. not sure why 2.1 is in TR right now.
http://www.w3.org/TR/CSS21/generate.html#propdef-content
I see no date on this document.
Comment 30 Jim Michaels 2012-06-16 22:53:33 PDT
by the way, chrome doesn't implement this either.
Comment 31 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2012-06-16 23:04:36 PDT
(In reply to Jim Michaels from comment #29)
> for reference, this is in css 2.1 TR as well. not sure why 2.1 is in TR
> right now.
> http://www.w3.org/TR/CSS21/generate.html#propdef-content
> I see no date on this document.

No, in CSS 2.1 it's only for the :before and :after pseudo-elements.
Comment 32 Jim Michaels 2012-06-30 16:36:26 PDT Comment hidden (offtopic)
Comment 33 Boris Zbarsky [:bz] (Out June 25-July 6) 2013-01-13 06:50:50 PST
*** Bug 830069 has been marked as a duplicate of this bug. ***
Comment 34 Alexei03a 2013-01-13 15:21:24 PST Comment hidden (obsolete)
Comment 35 Gordon P. Hemsley [:GPHemsley] 2013-11-02 14:54:48 PDT
@dbaron: What would it take to implement this? I note the spec is no longer being maintained, and "should not be used as a guide for implementations". Is there a problem with the spec? Would you be available as a mentor?
Comment 36 David Baron :dbaron: ⌚️UTC-7 (review requests must explain patch) 2014-02-27 22:54:08 PST
I think the first step to implementing this would be to figure out what the state of the spec is -- how solid it is, how much working group consensus there is behind it, etc.  I think it was probably reasonably well-specified, but it might not all make sense anymore.

I'd be willing to mentor somebody doing that, I think, though they'd need to be willing to do that without extremely detailed guidance.


Implementation wouldn't be trivial; it would require some to frame construction code, figuring out how it should interact with things like image loading, frame loading, and loading of any other resource types that would be supported (video?).  (I wonder if the feature would work better if, instead of url(), the arguments made it clear whether the resource was an image or frame before it was loaded.  That would certainly be helpful from an implementation perspective, and may well be more efficient.)
Comment 37 Masaya Iseki[:isk](UTC+9) 2014-03-20 05:51:37 PDT
I'm interested in solving this bug.
But I don't have enough knowledge to solve it.

If you don't mind, would you please tell me the overview how to implement it?
I have read the document[1] but this document is too old. 

[1]http://dxr.mozilla.org/mozilla-central/source/layout/doc

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