Re: [csswg-drafts] [css-lists] How should spaces be treated in markers? (#4448)

The CSS Working Group just discussed `[css-lists] How should spaces be treated in markers?`, and agreed to the following:

* `RESOLVED: reverse previous blockification requirement and require generating a block container`
* `RESOLVED: use pre as the value in UA stylesheet with text about possibly processing new lines`

<details><summary>The full IRC log of that discussion</summary>
&lt;dael> Topic: [css-lists] How should spaces be treated in markers?<br>
&lt;dael> github: https://github.com/w3c/csswg-drafts/issues/4448<br>
&lt;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!)<br>
&lt;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<br>
&lt;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<br>
&lt;dael> Rossen_: This is same behavior we have in EdgeHTML so I support your proposal<br>
&lt;fantasai> wfm<br>
&lt;dael> astearns: Proposal is modify previous resolution? I see point 3 in previous resolution that outside marker box has display value blockfied.<br>
&lt;dael> oriol: It's generates block container not blockifies. It could be an inline block containers.<br>
&lt;dael> fantasai: I think we might clarify outside display type is undefined?<br>
&lt;fantasai> https://drafts.csswg.org/css-text-4/#white-space-trim might also be interesting<br>
&lt;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.<br>
&lt;dael> Rossen_: Undefined or inline. Not sure if inline will make a difference<br>
&lt;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.<br>
&lt;dael> fantasai: Haven't figured out the model<br>
&lt;dael> Rossen_: I don't want display:undefined<br>
&lt;dael> fantasai: We can call it inline-block for now so gCS returns. Not sure if that matters<br>
&lt;dael> oriol: FF does blockify into a block box so it seems behavior is different in impl<br>
&lt;fantasai> s/returns/returns consistently across UAs/<br>
&lt;dael> dbaron: I don't think difference is a big deal for us but should ask Mats<br>
&lt;dael> Rossen_: Going back to the proposed resolution I think the understanding is well defined<br>
&lt;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.<br>
&lt;dael> astearns: Prop: An outside marker box does not have its display value blockified, it generates a block container<br>
&lt;dael> astearns: Correct?<br>
&lt;dael> oriol: Should we cover what FF does?<br>
&lt;dael> oriol: You said it's not blockfied, but in FF it is. Maybe should say it may be blockfied<br>
&lt;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.<br>
&lt;Rossen_> sgtm<br>
&lt;dael> astearns: Then can figure out outside container later<br>
&lt;dael> astearns: Object to reverse previous blockification requirement and require generating a block container<br>
&lt;dael> RESOLVED: reverse previous blockification requirement and require generating a block container<br>
&lt;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<br>
&lt;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<br>
&lt;dael> astearns: Reasonable<br>
&lt;Rossen_> wfm<br>
&lt;dael> astearns: Concerns about UA stylesheet uses pre as the value and let borwsers opt into processing new lines?<br>
&lt;dael> florian: Compat with browsers inside case? Or outside only?<br>
&lt;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<br>
&lt;dael> fantasai: We should reduce magic switching and make it a simple control<br>
&lt;dael> florian: Would not nec be magic could have pseudo class, but not convinced we need to<br>
&lt;dael> fantasai: No, let's keep it simple.<br>
&lt;dael> fantasai: just make it pre. How many people are doing a custom string? Almost nobody.<br>
&lt;dael> astearns: florian do you object?<br>
&lt;dael> florian: No, just wanted to get it out there<br>
&lt;dael> astearns: Obj to use pre as the value in UA stylesheet with text about poss processing new lines?<br>
&lt;dael> RESOLVED: use pre as the value in UA stylesheet with text about possibly processing new lines<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4448#issuecomment-567144044 using your GitHub account

Received on Wednesday, 18 December 2019 18:02:09 UTC