- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Mon, 12 Feb 2024 17:34:56 +0000
- To: public-css-archive@w3.org
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)` <details><summary>The full IRC log of that discussion</summary> <fremy> @TabAtkins, how, crap, I don't have sound :/<br> <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<br> <TabAtkins> emilio: As far as I can tell that's required by compat, people expect image properties to apply to the image<br> <TabAtkins> emilio: It's unfortunate that the pseudo-element and element behavior differs<br> <TabAtkins> emilio: Are we ever going to pursue multiple content items in non-pseudos? In which case you need a wrapping box of sorts.<br> <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.<br> <TabAtkins> emilio: Alternative is just fixing the spec to match reality<br> <astearns> ack dbaron<br> <fremy> @TabAtkins, restarted & fixed, my bad<br> <TabAtkins> (I feel like I rasied this exact issue like a decade ago)<br> <TabAtkins> dbaron: My memory is this spec went thru a bunch of design changes over its history<br> <TabAtkins> dbaron: One of the designs that was there for a while was...<br> <TabAtkins> dbaron: the content property had a syntactic distinction between a replaced-like thing and a fallback content<br> <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<br> <TabAtkins> dbaron: And only the final entry was the space-separated multiple values that was compatible with the CSS2 version<br> <TabAtkins> dbaron: I think we're in a place where that particular design isn't comaptible anymore<br> <TabAtkins> dbaron: Since we have repalced behavior for a non-final item<br> <TabAtkins> dbaron: But I think it might still be a reasonable design space to have repalced behavior in some cases<br> <TabAtkins> dbaron: if you have repalced behavior, do you also want fallback if the image doesn't load<br> <TabAtkins> dbaron: I think that was in the spec at one point and taken out<br> <astearns> ack fantasai<br> <TabAtkins> fantasai: We do have alt text in the spec right now<br> <TabAtkins> fantasai: In the 'alt' property<br> <dbaron> s/the 'alt' property/a different mechanism/<br> <fantasai> s/In the 'alt' property/after the slash in the content property/<br> <TabAtkins> fantasai: It seems like we have compat on content:url() in ::before/after being not replaced, and being replaced on regular elements<br> <TabAtkins> fantasai: If we're doing comma-separated fallbacks, does that trigger replacement on ::before/after<br> <TabAtkins> fantasai: And do we want replacement on pseudo-elements other than before/after<br> <TabAtkins> dbaron: I think we might have had good reasons to not do it on other pseudos<br> <TabAtkins> fantasai: we can always make it *not* do replaced element by adding an empty string to the value<br> <fantasai> s/we can/authors can/<br> <TabAtkins> emilio: I'd be interested in trying to make ::before work like a regular element, creating a replaced box<br> <TabAtkins> emilio: If we implement it, don't find compat issues, will other engines be interested in following?<br> <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<br> <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<br> <TabAtkins> emilio: 'content' on ::before has always made an inline (not replaced)?<br> <TabAtkins> dbaron: Yeah. That's not a definitive "we can't", but I'm worried.<br> <TabAtkins> emilio: We should probably resolve on fixing spec to reality for now, and I can try to fix it.<br> <noamr> q+<br> <TabAtkins> florian: Either way we won't get complete consistency anyway, like text<br> <TabAtkins> emilio: Yeah so there's a separate question about if 'content: "foo"' will do anything on normal elements<br> <TabAtkins> emilio: content:none already breaks websites<br> <TabAtkins> florian: I think content:<string> does too, because it's done in bad clearfixes<br> <TabAtkins> florian: We had it working on normal elements in Opera and removed it<br> <astearns> ack noamr<br> <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.<br> <TabAtkins> astearns: So proposed resolution is fix spec to match current reality, but without prejudice.<br> <TabAtkins> fantasai: We can put an issue in about investigating the possibilities<br> <TabAtkins> RESOLVED: Fix spec to match current reality (but experiment with making reality better)<br> <astearns> ack fantasai<br> <TabAtkins> fantasai: that covers ::before/after and normal elements, what do we do for ::marker/etc<br> <TabAtkins> astearns: Are there spec fictions for ::marker/etc at the moment?<br> <TabAtkins> fantasai: I think it's undefined<br> <TabAtkins> florian: I think spec says 'normal' computes to itself, but that's it<br> <TabAtkins> florian: I think if we're not compat-constrained it works to have 'normal' produce the marker, otherwise it replaces<br> <TabAtkins> fantasai: So question is make it consistent with ::before or with elements<br> <TabAtkins> fantasai: I think compat-wise we can go either way on things that aren't ::before/after<br> <TabAtkins> fantasai: Spec claims the property applies to all tree-abiding pseudos.<br> <TabAtkins> astearns: So are you okay with opening a new issue for ::marker?<br> <TabAtkins> fantasai: I think the behavior bias question is part of this.<br> <TabAtkins> florian: I think biasing toward normal elements is better, having an anonymous inline is less controllable<br> <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)<br> <TabAtkins> emilio: I think for us, content:none will suppress marker and content:normal makes the marker, don't recall what else happens<br> <fantasai> TabAtkins: This has been awful for like a decade<br> <TabAtkins> emilio: Problem with making it behave like elements is we'd have a third behavior - multiple values still dont' work<br> <TabAtkins> oriol: For me it's more intuitive to align with before/after since they're all pseudos<br> <TabAtkins> fantasai: but if you're styling ::marker to be an image, you really want it to be replaced<br> <TabAtkins> oriol: I guess for marker you can always use list-style-image<br> <TabAtkins> florian: aligning with before/after is more consistent and simpler to teach, but less useful<br> <TabAtkins> fantasai: If we're investigating about switching things over<br> <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.<br> <TabAtkins> florian: The risk that we get compat-constrained *while* we're investigating is small<br> <TabAtkins> fantasai: And the properties that would make things problematic don't really apply to markers yet<br> <TabAtkins> astearns: So leave the resolution as it is, and take ::marker question to the investigation<br> <fantasai> I think authors would really like to be able to set the width/height of a marker image<br> <bramus> ScribeNick: bramus<br> <fantasai> so I think we should eventually make that work<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/2889#issuecomment-1939211839 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 12 February 2024 17:34:59 UTC