-
Notifications
You must be signed in to change notification settings - Fork 689
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
[css-lists] How should spaces be treated in markers? #4448
Comments
Three observations on this:
So if removing newlines does prove critical, you can't allow the user to override white-space on the ::marker, in case they try to keep newlines. (edit: this is on the presumption that |
The styling restrictions on |
Replying to @faceless2 points above:
True, but it's also trivial for authors to use a non-collapsing space if that's what they want:
Currently, outside markers are aligned outside the inline/block start/start edge but I think we should enable authors to align the marker elsewhere in the future, for example
That doesn't preclude supporting multi-line markers though. We could use the first linebox in the marker to implement that legacy behavior.
Agreed, an inside marker should just be a normal inline box by default. I'm strongly in favor of allowing authors to style it with |
I tend to think that trailing spaces should collapse. That's consistent with how this behaves: <style>
div::before { content: '::before '; display: inline-block; }
</style>
<div>item</div> As I suggested in #3771, we should consider an outside |
I'm not that sure about non-inherited properties. But I tend to agree for inherited properties (except
The point is that Also, IMO using U+00A0 is semantically wrong, non-breaking spaces are supposed to be used to avoid breaks between specific pairs of words, not to avoid whitespace collapsing (I know it's a lost battle, but still). The proper way to control whitespace collapsing is the So I tend to think
|
Markers are separated from the body of the list with white-space. If you collapse that away by default, a space character in (Incidentally, although Safari currently doesn't support Re. the marker alignment, you've already got https://drafts.csswg.org/css-lists-3/#marker-side which allows a little control. @MatsPalmgren, does this cover the case you had in mind? My main concern with block-axis marker positions, multi-line markers etc is that the css-lists modules seems to have had considerably less love than it deserves. List bullets were first described in HTML 1, and from what I can see browsers haven't changed much in the way they position them since then.
My point is there seems to be relatively little appetite (for both the specification and implementations) to move forward. For that to change, I'd be inclined to severely limit the scope of what markers can do - at least for |
Actually it's a bit more complicated, and depends on
You can force the U+2022 character with
Well, WebKit shipped a limited version of ::marker 2 years ago, more recently Firefox shipped it completely, in Chromium I have implemented the WebKit behavior behind a flag and I'm working on completing it. This allows marker customizations, and will be much more powerful when we start accepting more properties in it. So things are moving forward, though it's true that outside positioning is heavily underspecified. |
That seems reasonable to me, on the condition that the property works normally so that authors can override it as they see fit.
Using the same value for both seems better to me. Fwiw, when I experimentally added |
I was thinking of hypothetical marker positions where the marker's inline-axis end edge (and its trailing space) isn't adjacent to the principal box. (I'm not sure if that's possible with |
On re-reading my post I should clarify my observation on the relative lack of momentum on css-lists isn't a dig. The fact list bullets are largely as they were 20 years ago clearly means that end-users are not shouting about them the way they are over... well, over everything else I suppose. We've recently got it working, so from the perspective of a clean-room implementation the spec is noticeably thinner than much of the rest of CSS - that's the basis for my comment, no more. I'm fully aware of the effort required to specify this completely and now our W3C membership is complete, hope to pitch in on this over the next few months. |
Here's my proposal for this issue:
I think those changes would define how white-space should be handled unambiguously. |
Nice - although if I'm being picky, it should be |
The CSS Working Group just discussed
The full IRC log of that discussion<dael> Topic: [css-lists] How should spaces be treated in markers?<dael> github: https://github.com//issues/4448#issuecomment-552605582 <dael> oriol: When have sequence of whitespaces it's controlled by whitespace property. Doesn't apply to marker] elements. Can't say it's inherited. Markers have outside position. one of the effects is it blockifies. If you have a block where spaces at end would collapse they are instead completely removed <dael> oriol: All native content styles use suffix that end with a space and if the markers have an outside position and then space disappears it's bad <dael> oriol: Proposal in GH was a solution with 3 parts. 1) Say the whitespace property applies to marker elements. 2) by defaults in UA-origin markers should be assigned whitespace as pre to preserve spaces, but let authors pick another value. 3) make it explicit this outside position blockifies the marker so if some author changes whitespace value to normal they shouldn't get surprised if space disappears when they have an outside marker <dael> astearns: Makes sense to me <dael> fantasai: Questions. First it's well understood what would happen with a preserved linebreak with an inside marker. One with an outside marker is not defined. We would need to figure out how alignment works with markers and define what that means when you have multi-line text. Have a concern about that <dael> fantasai: Alternative is to define a new value pre-spaces that preseves spaces but not linebreaks. That would solve problem of introducing preserved linebreaks <dael> fantasai: Other option is we have to define what it is with an outside marker. <fantasai> s/what it is with/how to handle multiple lines of text in/ <dael> AmeliaBR: To follow up on collapsing value that preserves spaces but converts linebreaks sounds like SVG legacy value possibly. There's a value on the spec for SVG legacy stuff <dael> fantasai: Vaguely remember it, but don't remember SVG behavior <dael> heycam: I think it drops new lines and preserves spaces <dael> fantasai: Maybe solution is to make sure that ends up in CSS text spec and assign it to ::marker and !important so author can't override until we figure out how outside markers are aligned <dael> astearns: Wondering if makes sense to put on linebreaks and use pre and if you put a linebreak in a marker something weird will happen <dael> fantasai: Eventually markers will be stylable in a variety of ways. Why not now is we don't have a layout model. We want to go there. Not a good idea to have browsers do different things <dael> astearns: Not saying linebreak is different in each browser. Once you put a line break in and it's preserved something will happen and we have to spec this in the layout model anyway <dael> fantasai: If we go with permitting we don't have a magic that makes them go away. We'd have a whitespace value that makes it go away and make the rule UA level !important so author doens't override. THat's one way to handle it which gives you consistent model <dael> astearns: I thought it was part of this solution's design that authors would have way of changing UA stylesheet value <AmeliaBR> for reference, here's the SVG spec about this: https://svgwg.org/svg2-draft/text.html#LegacyXMLSpace ; looks like the last plan was to map it to a separate `text-space-collapse` property (https://drafts.csswg.org/css-text-4/#white-space-collapsing) <dael> oriol: Mats wants authors to be able to customize. Not that strong with that, though I wouldn't mind. He was strongly in favor of letting authors customize it <dael> heycam: Alternative might be change definitions of counter styles to not allow a space. THat would only work if we don't have authors using custom counter styles with spaces <dael> fantasai: Can't be that many since it's a very new feature <fantasai> s/not allow a space/use a non-breaking space/ <dael> AmeliaBR: Compat issue is if you want markers spec with market pseudo element and content property to behave similar to how markers spec with list style properties behave. That's the compat issue <dael> heycam: Not just counters, but normal content property <fantasai> AmeliaBR, text-space-collapse was a longhand of white-space <dael> oriol: Can define contents of marker by setting list-style-type to a string or in marker element you set content property to random string which can contain spaces or line breaks <dael> astearns: Since our layout model for markers is likely to need to deal with these I'm inclined to go with Mats solution as-is and not worry what happens with linebreaks until we get to point os spec marker layout <dael> fantasai: Concern there is we will get whatever behavior falls out of current impl which may not be interop. If it is interop it might not be what we want. <dael> astearns: As far as I understand we don' have line breaks in marker strings now unless author adds it. If there is a problem it's fairly constrained. <dael> florian: Want to make sure we don't need to add new values of whitespace <dael> fantasai: Looks like SVG one satisfies the constraint <dael> AmeliaBR: If we're officially define as undefined we should be limited. Everyone agrees when marker is inline position so part of normal block flow that line breaking and whitespace handling behaves the same. Undefined bit is with outside markers because exact box model of that isn't defined <dael> florian: Partly underfines for inline. If behaves as everything else, but is it inherits or from UA stylesheet? <dael> AmeliaBR: WOuld like a decision on that b/c seems not as dependant on markers <dael> florian: If there is a value on UA stylesheet it applies to inline and not. If it's inherit we have an answer <dael> florian: We might still want to define a tweak if you're in the special layout but I hope not. Not sure how we define inline and not outside <dael> AmeliaBR: Problem with outside markers is the whitespace property if you insert a linebreak not sure how would effect alignment of marker position. THat's the undefined part until we spec how markers are aligned. THe do you preserve linebreaks or not sounds like something we could decide on <dael> florian: If we can resolve on whitespace property being inherit that's fine. But I don't htink we can do inline alone <dael> fantasai: Trailing spce is preserved. IT needs to be value that does tno collapse <dael> astearns: Can we resolve on whitespace applies to markers, there's a UA stylesheet rule about blockified markers, and levae the value in the air for now <dael> fantasai: I'm okay resolving it's pre for now. Of the values we have available it's the only one that preserves spaces <dael> florian: pre-wrap or break-spaces <heycam> (-moz-pre-space is the internal value name we have for SVG xml:space="preserve" text) <dael> astearns: Obj: Take Mats 3 part proposal leaving value of UA stylesheet in the air as a separate issue <fantasai> I was thinking pre-space or pre-spaces :) <dael> RESOLVED: Take Mats 3 part proposal leaving actual value of UA stylesheet in the air as a separate issue to be determined later |
Leave Agenda+ tagged so we can follow-up on the decision of whether to use |
I don't like |
Actually I got misleaded, in Chromium outside markers are LayoutBlockFlow but this doesn't mean like But I guess #4574 is related, if outside markers are out-of-flow, then they should be blockified indeed. |
The CSS Working Group just discussed
The full IRC log of that discussion<dael> Topic: [css-lists] How should spaces be treated in markers?<dael> github: https://github.com//issues/4448 <pes> (im going to jump off the call, thank you for the time, very encouraged by the conversation. I’m looking forwarwd to working with you all to solve the problem!) <dael> oriol: Revisiting a resolution we had. I said that browsers seemingly do when you have an outside marker that's blockified and we made it explicit in the resolution so that if they don't have whitespace then trailing spaces are reserved <dael> oriol: I had been confused by internal termonology and in Chromium they are inline blocks. Outside markers generate a block container and that's what matters. If we want to reflect reality maybe should weaken resolution. Say they should generate block containers and then leave it to impl if it's block or inline level <dael> Rossen_: This is same behavior we have in EdgeHTML so I support your proposal <fantasai> wfm <dael> astearns: Proposal is modify previous resolution? I see point 3 in previous resolution that outside marker box has display value blockfied. <dael> oriol: It's generates block container not blockifies. It could be an inline block containers. <dael> fantasai: I think we might clarify outside display type is undefined? <fantasai> https://drafts.csswg.org/css-text-4/#white-space-trim might also be interesting <dael> Rossen_: Could be inline. Did that when we impl outside markers the first time. In order to achieve good baseline alignment for list items that best way to model this was to wrap the list item markets in anon inline blocks with appropriate offset and deal with them. <dael> Rossen_: Undefined or inline. Not sure if inline will make a difference <dael> fantasai: Markers have a particular interaction with positioning and line positioned to. When we decide they might have their own display:outside value. I'm happy to have it undefined. <dael> fantasai: Haven't figured out the model <dael> Rossen_: I don't want display:undefined <dael> fantasai: We can call it inline-block for now so gCS returns. Not sure if that matters <dael> oriol: FF does blockify into a block box so it seems behavior is different in impl <fantasai> s/returns/returns consistently across UAs/ <dael> dbaron: I don't think difference is a big deal for us but should ask Mats <dael> Rossen_: Going back to the proposed resolution I think the understanding is well defined <fantasai> I think the two options we have going forward is either an outer display value of 'marker' or an outer display value of 'inline' and a 'position' value of 'marker' ... or something like that. <dael> astearns: Prop: An outside marker box does not have its display value blockified, it generates a block container <dael> astearns: Correct? <dael> oriol: Should we cover what FF does? <dael> oriol: You said it's not blockfied, but in FF it is. Maybe should say it may be blockfied <dael> astearns: Yes, sorry. Previous was it has its display value blockified and we're not going to require that. Will require it generates a block container. <Rossen_> sgtm <dael> astearns: Then can figure out outside container later <dael> astearns: Object to reverse previous blockification requirement and require generating a block container <dael> RESOLVED: reverse previous blockification requirement and require generating a block container <dael> oriol: Whitespaces; want to preserve by default and resolved to do this to assign whitespace value in user agent origin. Then how to handle new lines. In SVG there way a value for this- should we add to CSS or use Whitespace:pre <dael> fantasai: We say the value is pre for now and UA may transform to spaces and we can try and figure out what to do in the future <dael> astearns: Reasonable <Rossen_> wfm <dael> astearns: Concerns about UA stylesheet uses pre as the value and let borwsers opt into processing new lines? <dael> florian: Compat with browsers inside case? Or outside only? <dael> oriol: Chromium outside markers get whitespace:pre but inside inherits. In legacy spaces were preserved. In FF if the content property is normal then spaces are preserved like pre but if you spec something other than normal it uses whitespace inherited from list. It's probably compat b/c FF and legacy chromium preserve <dael> fantasai: We should reduce magic switching and make it a simple control <dael> florian: Would not nec be magic could have pseudo class, but not convinced we need to <dael> fantasai: No, let's keep it simple. <dael> fantasai: just make it pre. How many people are doing a custom string? Almost nobody. <dael> astearns: florian do you object? <dael> florian: No, just wanted to get it out there <dael> astearns: Obj to use pre as the value in UA stylesheet with text about poss processing new lines? <dael> RESOLVED: use pre as the value in UA stylesheet with text about possibly processing new lines |
LayoutNG was already setting 'white-space: pre' for outside markers with 'content: normal', but not for inside markers or non-normal 'content'. The CSSWG resolved in w3c/csswg-drafts#4448 that 'white-space: pre' should always be used by default, but letting authors override it if they desire another behavior. This patch implements that. Note this changes the default behavior for inside markers in LayoutNG, even when the CSSMarkerPseudoElement flag is disabled. But this should be safe since both Chromium legacy and Firefox preserve spaces by default. This change has no effect in legacy, since it ignores 'white-space' in markers. BUG=457718 TEST=external/wpt/css/css-pseudo/marker-default-styles.html TEST=external/wpt/css/css-pseudo/marker-white-space-default.html TEST=external/wpt/css/css-pseudo/marker-white-space-normal.html The marker-white-space-default and marker-white-space-normal tests fail in legacy because 'content' is not supported yet. The latter also fails because 'white-space' is ignored in legacy markers. Change-Id: I07cf6c5bd9d55e016fe84f4854bd825bdcc8c66a
Adding |
@Loirooriol Mind reviewing? :) (Feel free to close and mark Commenter Satisfied if it looks good to you.) |
@Loirooriol Done, thanks! |
Thanks, looks great! |
The
white-space
property doesn't apply to markers, but how do spaces behave in markers?Consider
The results in Firefox, Chromium legacy and Chromium with LayoutNG and look like
That is:
content
obeys thewhite-space
property inherited from the list-item.list-style-type
ignoreswhite-space
, andlist-style-type
will obeywhite-space
after https://bugzil.la/1542807list-style-type
ignoreswhite-space
, andlist-style-type
obeys thewhite-space
property inherited from the list-itemlist-style-type
useswhite-space: pre
What's the expected behavior?
The text was updated successfully, but these errors were encountered: