[css-lists] Should collapsible space after inside ::marker be preserved? #4891
Labels
css-lists-3
Current Work
Comments
|
The CSS Working Group just discussed The full IRC log of that discussion<dael> Topic: [css-lists] Should collapsible space after inside ::marker be preserved?<dael> github: https://github.com//issues/4891 <dael> oriol: Follow up of #4448 where we resolved ::market is whitespace pre in user origin. b/c outside markers are a block contrain and we wanted to preserve these. <dael> oriol: When tried to impl some tests failed. <dael> oriol: Problem is that [missed] usually doesn't matter if you add trailing or leading spaces <dael> oriol: If you write open tag, text, closing tag or open tag, new line, text, another line, close tag it should look same <dael> oriol: If we assign whitespace pre to marker the spaces are no longer at beginning. They collapse as a space but not completely removed. <dael> oriol: If no space at beginning of list item you get one space. If there's additional space youg et 2 spaces. There no interop. In FF you get two spaces if there's space in the beginning. Other browsers it doesn't matter <dael> oriol: Not sure which we want. 3 options. 1) keep resolution and say FF is right there should be 2 spaces. 2) Keep whitespace pre and add some magic which says if you have sequence of collapsable spaces just inside you remove the spaces even if trailing space of marker is not collapsable. This is behavior of non-FF but magic is annoying and error prone <dael> oriol: 3) Only set whitepsace pre to outside markers but not inside ones. Closer to what Chromium is doing thought chromium assigns it kind of hacky. Proper way with selectors is defining marker-outside and marker-inside. If in future we say that the list style position property applies to ::marker instead of originating list item we have a supplarity. <TabAtkins> q+ <dael> oriol: Leaning option 1 which is do what FF is doing right now. Maybe less intuitive to authors but more consistent <astearns> ack TabAtkins <florian> q+ <smfr> q+ <dael> TabAtkins: Option 3 was discared for circularity but I don't think need to be conerned. Onlyr eason to allow is set within a single list some markers outside and some inside and I don't know why we would make that easy. I don't think that will ever be the case. Never be a circularity for ::marker so we could through magic or pseudo let you style inside and outside different <dbaron> +1 to TabAtkins <dael> TabAtkins: I think that's reasonable b/c I don't like display FF gives. I think Chrome behavior is good, but need to solve it a good way <astearns> ack fantasai <Zakim> fantasai, you wanted to ask about compat <dael> fantasai: I'm wondering if FF behavior is regression from earlier FF. Switch between inside and outside is old feature. I wonder if it has always been that you would get double whitespace in past or if relatively new since re-write micro code <dael> astearns: Anyone know? <fantasai> s/micro/marker/ <dael> [several] no <astearns> ack dbaron <astearns> ack fantasai <fantasai> +1 to option 1 being bad <dael> dbaron: TabAtkins covered part of what i would say. Other thing is I think having whitespace in markup in block matter is bad so I think option 1 is bad. Little surprised FF does that <astearns> ack florian <dbaron> I think my preferences are probably 3 > 1 > 2, but that's not a very strong opinion. <dael> florian: I agree with TabAtkins. I prefer 3 between 1 and 3. THere's also option 2 and I would like to not do this. CSS 3 text is already sufficiently complicated.. It's hard to spec and complicated and I would prefer not to add <dael> smfr: Compat question- make any difference what we choose for compat? <astearns> ack smfr <dael> florian: If it's similar to chrome and safari even with different logic it should be fine <dael> smfr: Was this bugs on webpages or jsut seen in testing? <dael> oriol: Me impl ::marker. Currently Chromium sets it in style adjuster. For outside it sets whitespace to pre and for inside it's the list item. When I tried to impl the previous resolution some internal tests failed and I noticed this. I don't know any webpages in wild <dael> fantasai: Space between li and content is not uncommon. I do imagine there's a number of web pages effected. <dael> florian: But list inside is not common <dael> fantasai: Yes, but it is used. Unlikely to break badly but won't look as intended <dael> astearns: Not hearing consenus except no not 2. Split between 1 and 3. Is that the case or can resolve on 3? <dael> oriol: Fine with 3 <dael> astearns: Objections to resolve on option 3 <dael> heycam: Are those internal pseudo classes? <dael> florian: Start there and bikeshed later <dael> TabAtkins: Until a use case I don't think need to expose. But safe to do so if someone is motivated to champion that <dael> florian: Wondering if folks like glazou will be unhappy about things happening that cna't be replicated in an editor <dael> astearns: We're out of time for the day. <dael> astearns: I suggest we resolve on 3 so oriol can try and perhaps come back with results. People can raise new objections if they like <dael> astearns: objections to option 3? <dael> fantasai: I'm happy to put in spec there's a magic difference but not sure we want to spec it's with pseudo classes. If we want to say some kind of magic and UA can figure it out we can. If we're doing a pseudo class we should draw that up <dbaron> +1 to fantasai, no need to add pseudo-classes right now. (Also, we'd had a totally different ::inside and ::outside proposal!) <dael> astearns: Not resolving on option 3 but that's the direction we want to head in. <dael> florian: Is difference observable fantasai? <dael> fantasai: i don't know. But don't want more detail in spec then needed in case UA wants to think of a way to do it <dael> TabAtkins: Agree. Should say it happens and have a note <dael> astearns: Thanks everyone |
|
The CSS Working Group just discussed The full IRC log of that discussion<dael> Topic: end<dael> astearns: We'll go back to the issue and add spec text there <dael> fantasai: There was a proposal that eats whitespace. We could use that. <dael> astearns: whitespace-trim or something like that? <dael> fantasai: Yeah. That's another option. We can re-use that and set it on the marker and it's pretty normal. <fantasai> https://www.w3.org/TR/css-text-4/#white-space-trim <dael> astearns: Interesting <dael> florian: Magic is bad but a generic system is fine <dbaron> github: https://github.com//issues/4891 <dael> fantasai: That's my recommendation. Use that property to do magic. <dael> oriol: Impl? <dael> fantasai: No <dael> TabAtkins: Not certain it works. We want to preserve whitespace but we don't want whitespace from marker and content start to both preserve. <dael> dbaron: Don't think that'st he case. Shouldn't have different mark up depending on spaces after li. Not collapsing 2 things, get rid of one <dael> TabAtkins: How with trim? <dael> fantasai: Set it on after marker <florian> https://drafts.csswg.org/css-text-4/#white-space-trim <fantasai> ::marker { text-space-trim: discard-after } <fantasai> ScribeNick: fantasai <fantasai> florian: Interesting approach to solving it, would also be useful for other things <fantasai> florian: My concern with option 2 was I didn't want a special magical kind of white space, avoids having to define all the weird cases like does it hang at the end of a line etc. <fantasai> florian: Probably need to define how the discarding interacts with bidi, but needs to be defined either way for the feature ... <fantasai> Meeting closed. |
|
General consensus was that (2) was bad because it was hacky, (1) was probably bad both due to compat and because whitespace at the beginning of an element generally shouldn't have an effect, and (3) would actually be fine (notably, we didn't feel Oriol's concern was realistic, so no circularity would ever arise). We didn't have to literally specify that (3) was achieved thru pseudo-classes; rather we could just say that UAs could magically distinguish, but note that this is amenable to pseudo-classes should we ever wish to expose it to authors. However, a better variant of (2) was presented after the close of the meeting, which is to specify |
|
I like the idea in @tabatkins last comment if the property is actually implemented, so that it can be overridden by authors. The upside of using an :inside and :outside pseudo class is that even if this is just conceptual, and actually implemented some other way, authors can still override that behavior by using a blunter selector. |
|
The spec issue says
But in https://bugzil.la/145075#c12 @MatsPalmgren argues that by default, a list item sized with min-content shouldn't have a line break between the marker and the first word of the list item. So another proposal would be text-space-collapse: preserve-spaces;
text-space-trim: discard-after;
text-wrap: nowrap; |
5 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
In #4448 (comment) we resolved that ::marker should have
white-space: prein UA origin. That is needed for outside markers, and we decided to keep it simple and also apply it to inside markers.But consider this case:
For block container elements like
<li>, leading and trailing space doesn't matter. So just looking at the HTML, some authors may think that bothTextwill be aligned equally.However, the ::marker is inserted at the very beginning of the
<li>, and since it's inside, it behaves as a normal inline. So the leading space is no longer at the beginning of the line, and is not trimmed in §4.1.2.1.Since the ::marker has a trailing space, both list items could still look the same via §4.1.1:
But that doesn't apply if the ::marker has
white-space: pre. So the 1st list item ends up with 1 space and the 2nd list item with 2 spaces.What behavior do we want here? We don't have interoperability:
In Chromium (both legacy and LayoutNG), WebKit and old Edge, the texts are aligned:
In Firefox, they aren't:
So I guess we can choose among:
white-space: pre. Firefox is correct, changing Chromium will be trivial.white-space: prebut add some magic that if a text ::marker has a trailing space and is followed by collapsible spaces, then these collapsible spaces are removed, even if the ::marker space is not collapsible. This will keep Chromium's behavior but implementing this magic would be annoying.white-space: prein UA origin. This is close to what Chromium does right now. But I guess doing this properly would need pseudo-classes like::marker:insideand::marker:outside, even if just for internal use, but that would create a circularity if in the future we allow settinglist-style-positionin the ::marker itself.I lean towards 1.
The text was updated successfully, but these errors were encountered: