Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

[css-content] Implementations and spec disagree regarding content: url on elements #2889

Open
emilio opened this issue Jul 6, 2018 · 10 comments
Open

[css-content] Implementations and spec disagree regarding content: url on elements #2889

emilio opened this issue Jul 6, 2018 · 10 comments
Labels
css-content-3
Projects
Feb 2024 Agenda

Comments

@emilio
Copy link
Collaborator

emilio commented Jul 6, 2018 •
edited

Per spec, we're supposed to wrap the content in a box, and thus this:

<!doctype html>
<style>
div {
  content: url(..);
  border: 2px solid blue;
}
</style>
<div></div>

Is supposed to render a border on a block box, and the image as a replaced inline inside. Instead implementations replace the whole <div> with a replaced box.
@frivoal
Copy link
Collaborator

frivoal commented Jul 6, 2018

I don't think that spec is terribly reliable. It was completely abandoned for a while, and has been cleaned up somewhat, but I'd take the whole thing with a big grain of salt.

The editors (@fantasai @dauwhe ) would know more, but I suspect that for this spec, we're much more interested in aligning the spec with what implementations do (when we can figure out what that is) than in trying to push the implementations to match the spec.

@dauwhe
Copy link
Contributor

dauwhe commented Jul 6, 2018

Is supposed to render a border on a block box, and the image as a replaced inline inside.

The current draft says:

[using image in content property] makes the element or pseudo-element a replaced element, filled with the specified image. Its normal contents are suppressed and do not generate boxes, as if they were display: none.

But I'm probably missing something. As Florian said, this spec needs a lot of work. We cleaned out a lot of decades-old stuff a few years ago, but haven't yet had a chance to go through and look at everything from today's perspective.

@bzbarsky
Copy link

bzbarsky commented Jul 6, 2018

Note that UAs have different behavior for pseudo-elements and normal elements here, and the spec doesn't seem to reflect that.

@SelenIT
Copy link
Collaborator

SelenIT commented Jul 7, 2018 •
edited

Per the current draft, it seems that this different behavior for pseudo-elements seems to be a bug:

Note: If the value of <content-list> is a single <image>, it must instead be interpreted as a <content-replacement>.

I assume that now browsers treat pseudo-elements with only one <image> and with several <image>s in the content value the same way, and don't apply any special formatting rules in the former case (and never did this before).

@emilio
Copy link
Collaborator Author

emilio commented Jul 8, 2018

Yes, indeed I broke it in FF Nightly accidentally while implementing content for elements, see https://bugzilla.mozilla.org/show_bug.cgi?id=1473813.

@frivoal
Copy link
Collaborator

frivoal commented Jul 8, 2018

@dauwhe @fantasai (cc @astearns @atanassov ), given the known-to-be-unreliable state of the spec, how about adding one of these giant warnings to it, to make sure that any implementer looking at it treads with caution?

@SelenIT
Copy link
Collaborator

SelenIT commented Jul 8, 2018

But according to the current draft, this “broken” behavior seems to be correct. The problem is that it might be not compatible with existing content, but it’s a different issue, isn’t it?

@bzbarsky
Copy link

bzbarsky commented Jul 8, 2018

The point is, the current browser behavior for "content" on ::before and ::after is interoperable across all browsers, has been for well over a decade, and follows the existing and finalized CSS 2.1 spec.

If the draft wants to change the spec and make all browsers change behavior then chances are the draft is just flat-out wrong. Now you're correct that this only matters if there is lack of compatibility with existing content, but given how long the current behavior has been implemented in browsers and the existing standards situation, the burden of proof should be on anyone who wants to change the behavior to demonstrate lack of compat problems.

@SelenIT SelenIT mentioned this issue Oct 11, 2018
Open
@css-meeting-bot css-meeting-bot mentioned this issue Jul 27, 2020
Open
@fantasai
Copy link
Collaborator

fantasai commented Feb 5, 2024

The current status is that all implementations create a replaced element when content: <image> is applied to a normal element, and create an inline replaced child when content: <image> is applied to ::before. testcase

Agenda+ to discuss:

  • Whether we want to make an exception for ::before and ::after specifically, or for all pseudo-elements.
  • Whether anyone wants to investigate the Web compatibility of migrating ::before and ::after to match regular elements.

@astearns astearns added this to Unsorted regular in Feb 2024 Agenda Feb 8, 2024
@astearns astearns moved this from Unsorted regular to Monday afternoon in Feb 2024 Agenda Feb 11, 2024
@css-meeting-bot
Copy link
Member

The CSS Working Group just discussed [css-content] Implementations and spec disagree regarding content: url on elements, and agreed to the following:

  • RESOLVED: Fix spec to match current reality (but experiment with making reality better)
The full IRC log of that discussion <fremy> @tabatkins, how, crap, I don't have sound :/
<TabAtkins> emilio: when you use content:url() on an element, and have a single content item, then isntead of doing what the spec says (and what browsers do on pseudo-elements), we just create an image box
<TabAtkins> emilio: As far as I can tell that's required by compat, people expect image properties to apply to the image
<TabAtkins> emilio: It's unfortunate that the pseudo-element and element behavior differs
<TabAtkins> emilio: Are we ever going to pursue multiple content items in non-pseudos? In which case you need a wrapping box of sorts.
<TabAtkins> emilio: Would we want to try making pseudo-elements match content:url() elements? I suspect that's not compatible at this point, but maybe worth trying.
<TabAtkins> emilio: Alternative is just fixing the spec to match reality
<astearns> ack dbaron
<fremy> @tabatkins, restarted & fixed, my bad
<TabAtkins> (I feel like I rasied this exact issue like a decade ago)
<TabAtkins> dbaron: My memory is this spec went thru a bunch of design changes over its history
<TabAtkins> dbaron: One of the designs that was there for a while was...
<TabAtkins> dbaron: the content property had a syntactic distinction between a replaced-like thing and a fallback content
<TabAtkins> dbaron: the idea at one point was that the value space of 'content' was a series of comma-separated things, that made it like a replaced element
<TabAtkins> dbaron: And only the final entry was the space-separated multiple values that was compatible with the CSS2 version
<TabAtkins> dbaron: I think we're in a place where that particular design isn't comaptible anymore
<TabAtkins> dbaron: Since we have repalced behavior for a non-final item
<TabAtkins> dbaron: But I think it might still be a reasonable design space to have repalced behavior in some cases
<TabAtkins> dbaron: if you have repalced behavior, do you also want fallback if the image doesn't load
<TabAtkins> dbaron: I think that was in the spec at one point and taken out
<astearns> ack fantasai
<TabAtkins> fantasai: We do have alt text in the spec right now
<TabAtkins> fantasai: In the 'alt' property
<dbaron> s/the 'alt' property/a different mechanism/
<fantasai> s/In the 'alt' property/after the slash in the content property/
<TabAtkins> fantasai: It seems like we have compat on content:url() in ::before/after being not replaced, and being replaced on regular elements
<TabAtkins> fantasai: If we're doing comma-separated fallbacks, does that trigger replacement on ::before/after
<TabAtkins> fantasai: And do we want replacement on pseudo-elements other than before/after
<TabAtkins> dbaron: I think we might have had good reasons to not do it on other pseudos
<TabAtkins> fantasai: we can always make it *not* do replaced element by adding an empty string to the value
<fantasai> s/we can/authors can/
<TabAtkins> emilio: I'd be interested in trying to make ::before work like a regular element, creating a replaced box
<TabAtkins> emilio: If we implement it, don't find compat issues, will other engines be interested in following?
<TabAtkins> emilio: It might be a case where consistency isn't worth it, but I think it would be nice, and easy to implement either way
<TabAtkins> dbaron: It's literally a feature that's been around for 20 years, I'm worried about the implications of changing something like that
<TabAtkins> emilio: 'content' on ::before has always made an inline (not replaced)?
<TabAtkins> dbaron: Yeah. That's not a definitive "we can't", but I'm worried.
<TabAtkins> emilio: We should probably resolve on fixing spec to reality for now, and I can try to fix it.
<noamr> q+
<TabAtkins> florian: Either way we won't get complete consistency anyway, like text
<TabAtkins> emilio: Yeah so there's a separate question about if 'content: "foo"' will do anything on normal elements
<TabAtkins> emilio: content:none already breaks websites
<TabAtkins> florian: I think content:<string> does too, because it's done in bad clearfixes
<TabAtkins> florian: We had it working on normal elements in Opera and removed it
<astearns> ack noamr
<TabAtkins> noamr: If we want to fix or change anything, it would be good to get more dev feedback and what they're using it for.
<TabAtkins> astearns: So proposed resolution is fix spec to match current reality, but without prejudice.
<TabAtkins> fantasai: We can put an issue in about investigating the possibilities
<TabAtkins> RESOLVED: Fix spec to match current reality (but experiment with making reality better)
<astearns> ack fantasai
<TabAtkins> fantasai: that covers ::before/after and normal elements, what do we do for ::marker/etc
<TabAtkins> astearns: Are there spec fictions for ::marker/etc at the moment?
<TabAtkins> fantasai: I think it's undefined
<TabAtkins> florian: I think spec says 'normal' computes to itself, but that's it
<TabAtkins> florian: I think if we're not compat-constrained it works to have 'normal' produce the marker, otherwise it replaces
<TabAtkins> fantasai: So question is make it consistent with ::before or with elements
<TabAtkins> fantasai: I think compat-wise we can go either way on things that aren't ::before/after
<TabAtkins> fantasai: Spec claims the property applies to all tree-abiding pseudos.
<TabAtkins> astearns: So are you okay with opening a new issue for ::marker?
<TabAtkins> fantasai: I think the behavior bias question is part of this.
<TabAtkins> florian: I think biasing toward normal elements is better, having an anonymous inline is less controllable
<fremy> (Not sure if it's just me or not, since I already had audio issues, but the audio for fantasai and astearns is not very clear; florian is mostly fine)
<TabAtkins> emilio: I think for us, content:none will suppress marker and content:normal makes the marker, don't recall what else happens
<fantasai> TabAtkins: This has been awful for like a decade
<TabAtkins> emilio: Problem with making it behave like elements is we'd have a third behavior - multiple values still dont' work
<TabAtkins> oriol: For me it's more intuitive to align with before/after since they're all pseudos
<TabAtkins> fantasai: but if you're styling ::marker to be an image, you really want it to be replaced
<TabAtkins> oriol: I guess for marker you can always use list-style-image
<TabAtkins> florian: aligning with before/after is more consistent and simpler to teach, but less useful
<TabAtkins> fantasai: If we're investigating about switching things over
<TabAtkins> fantasai: In current spec say "do X if you're pseudo-element, do Y if you're normal", but keep investigation open, and if that turns out we can make pseudos repalced, we can do it for all of them; if we can't, we can rethink.
<TabAtkins> florian: The risk that we get compat-constrained *while* we're investigating is small
<TabAtkins> fantasai: And the properties that would make things problematic don't really apply to markers yet
<TabAtkins> astearns: So leave the resolution as it is, and take ::marker question to the investigation
<fantasai> I think authors would really like to be able to set the width/height of a marker image
<bramus> ScribeNick: bramus
<fantasai> so I think we should eventually make that work

@mozilla-apprentice mozilla-apprentice mentioned this issue Feb 12, 2024
Open
@chromium-helper chromium-helper mentioned this issue Feb 12, 2024
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
css-content-3
Projects
Feb 2024 Agenda
Monday morning
Milestone
No milestone
Development

No branches or pull requests
7 participants
@frivoal @SelenIT @fantasai @emilio @bzbarsky @dauwhe @css-meeting-bot