Support CSS3 content property replacement of element (rather than pseudo-element)

NEW
Unassigned

Status

()

Core
CSS Parsing and Computation
P3
enhancement
14 years ago
4 months ago

People

(Reporter: SvendTofte, Unassigned)

Tracking

(Blocks: 4 bugs, {css3, dev-doc-needed, testcase})

Trunk
Future
css3, dev-doc-needed, testcase
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [parity-opera][parity-webkit-ish] [webcompat], URL)

Attachments

(1 attachment)

(Reporter)

Description

14 years ago
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.
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.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → WONTFIX
(Reporter)

Comment 2

14 years ago
Cool enough, just wanted to make sure what the policy was on yet-TR specs :)

Comment 3

14 years ago
*** Bug 215403 has been marked as a duplicate of this bug. ***

Comment 4

14 years ago
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.

Updated

14 years ago
Keywords: css3, testcase
OS: Windows 2000 → All
Hardware: PC → All
Summary: CSS "content" replacement doesn't work with total replacement → Support CSS3 content property

Updated

14 years ago
Status: RESOLVED → UNCONFIRMED
Resolution: WONTFIX → ---
Status: UNCONFIRMED → RESOLVED
Last Resolved: 14 years ago14 years ago
Resolution: --- → WONTFIX
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.
Severity: normal → enhancement
Status: RESOLVED → UNCONFIRMED
Resolution: WONTFIX → ---

Updated

14 years ago
Status: UNCONFIRMED → NEW
Ever confirmed: true
Priority: -- → P3
Target Milestone: --- → Future

Updated

13 years ago
Blocks: 39598

Updated

13 years ago
Blocks: 219417

Comment 6

13 years ago
*** Bug 219417 has been marked as a duplicate of this bug. ***

Updated

13 years ago
Blocks: 104312

Updated

13 years ago
Blocks: 40545
Summary: Support CSS3 content property → Support CSS3 content property replacement of element (rather than pseudo-element)
See also bug 309217, for the css3 content property's fallback lists.
*** Bug 315391 has been marked as a duplicate of this bug. ***
Assignee: dbaron → nobody
QA Contact: ian → style-system

Updated

9 years ago
Duplicate of this bug: 425766
Duplicate of this bug: 620782

Comment 11

6 years ago
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.
Duplicate of this bug: 689088
Comment hidden (advocacy)

Updated

6 years ago
Duplicate of this bug: 702088

Comment 15

6 years ago
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

6 years ago
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 hidden (abuse-reviewed)

Comment 18

6 years ago
(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

6 years ago
This bug 215083 blocks(?) bug No. 40545: 'labels' for 'option' tags, which is something implemented in all other browsers except FF ;)

Comment 20

6 years ago
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

6 years ago
Support all browsers: Safari, Opera, Google Chrome and even IE version 10.
(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.
(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
(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.
Whiteboard: [parity-opera][parity-webkit-ish]

Updated

6 years ago
Blocks: 714507
Comment hidden (abuse-reviewed)

Comment 26

5 years ago
Stable draft: http://www.w3.org/TR/css3-content/

Comment 27

5 years ago
(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 )

Updated

5 years ago
Duplicate of this bug: 765475

Comment 29

5 years ago
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

5 years ago
by the way, chrome doesn't implement this either.
(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 hidden (offtopic)
Duplicate of this bug: 830069
Comment hidden (obsolete)
@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?
Flags: needinfo?(dbaron)
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.)
Flags: needinfo?(dbaron)
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
Flags: needinfo?(dbaron)
Keywords: dev-doc-needed
FWIW, fantasai rewrote/updated the (2003-era) css-content-3 spec, and announced it back in June on www-style:
 https://lists.w3.org/Archives/Public/www-style/2016Jun/0137.html

Hopefully the modern spec has fewer of the possible-pitfalls that dbaron was hinting at in comment 36, and might be more directly implementable...
Flags: needinfo?(dbaron)
Oh, and since I accidentally cleared the needinfo? when adding the "See Also" in response to dholbert's comment -- I guess the real response to comment 37 is that this isn't a good choice of bug for somebody who hasn't already written some substantial Gecko code before.  Figuring out a reasonable plan for implementing it is at least multiple hours of work if not multiple days.
(In reply to Daniel Holbert [:dholbert] from comment #38)
> Hopefully the modern spec has fewer of the possible-pitfalls that dbaron was
> hinting at in comment 36, and might be more directly implementable...

As I pointed out in https://github.com/w3c/csswg-drafts/issues/821 , I don't think the spec is even clear enough to *tell* whether those pitfalls are still present.  (For example, does the spec expect url() to load images, videos, iframes, etc., or only images?  What does Blink do there?)
Blocks: 1239922

Updated

6 months ago
Whiteboard: [parity-opera][parity-webkit-ish] → [parity-opera][parity-webkit-ish] [webcompat]
Comment hidden (offtopic)
You need to log in before you can comment on or make changes to this bug.