- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Thu, 02 Apr 2020 00:04:42 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-lists] Should collapsible space after inside ::marker be preserved?`. <details><summary>The full IRC log of that discussion</summary> <dael> Topic: [css-lists] Should collapsible space after inside ::marker be preserved?<br> <dael> github: https://github.com/w3c/csswg-drafts/issues/4891<br> <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.<br> <dael> oriol: When tried to impl some tests failed.<br> <dael> oriol: Problem is that [missed] usually doesn't matter if you add trailing or leading spaces<br> <dael> oriol: If you write open tag, text, closing tag or open tag, new line, text, another line, close tag it should look same<br> <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.<br> <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<br> <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<br> <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.<br> <TabAtkins> q+<br> <dael> oriol: Leaning option 1 which is do what FF is doing right now. Maybe less intuitive to authors but more consistent<br> <astearns> ack TabAtkins<br> <florian> q+<br> <smfr> q+<br> <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<br> <dbaron> +1 to TabAtkins<br> <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<br> <astearns> ack fantasai<br> <Zakim> fantasai, you wanted to ask about compat<br> <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<br> <dael> astearns: Anyone know?<br> <fantasai> s/micro/marker/<br> <dael> [several] no<br> <astearns> ack dbaron<br> <astearns> ack fantasai<br> <fantasai> +1 to option 1 being bad<br> <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<br> <astearns> ack florian<br> <dbaron> I think my preferences are probably 3 > 1 > 2, but that's not a very strong opinion.<br> <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<br> <dael> smfr: Compat question- make any difference what we choose for compat?<br> <astearns> ack smfr<br> <dael> florian: If it's similar to chrome and safari even with different logic it should be fine<br> <dael> smfr: Was this bugs on webpages or jsut seen in testing?<br> <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<br> <dael> fantasai: Space between li and content is not uncommon. I do imagine there's a number of web pages effected.<br> <dael> florian: But list inside is not common<br> <dael> fantasai: Yes, but it is used. Unlikely to break badly but won't look as intended<br> <dael> astearns: Not hearing consenus except no not 2. Split between 1 and 3. Is that the case or can resolve on 3?<br> <dael> oriol: Fine with 3<br> <dael> astearns: Objections to resolve on option 3<br> <dael> heycam: Are those internal pseudo classes?<br> <dael> florian: Start there and bikeshed later<br> <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<br> <dael> florian: Wondering if folks like glazou will be unhappy about things happening that cna't be replicated in an editor<br> <dael> astearns: We're out of time for the day.<br> <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<br> <dael> astearns: objections to option 3?<br> <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<br> <dbaron> +1 to fantasai, no need to add pseudo-classes right now. (Also, we'd had a totally different ::inside and ::outside proposal!)<br> <dael> astearns: Not resolving on option 3 but that's the direction we want to head in.<br> <dael> florian: Is difference observable fantasai?<br> <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<br> <dael> TabAtkins: Agree. Should say it happens and have a note<br> <dael> astearns: Thanks everyone<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4891#issuecomment-607548467 using your GitHub account
Received on Thursday, 2 April 2020 00:04:45 UTC