- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 06 May 2020 15:06:20 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `Switch line-breaking handling of atomic inlines`. <details><summary>The full IRC log of that discussion</summary> <astearns> topic: Switch line-breaking handling of atomic inlines<br> <astearns> github: https://github.com/w3c/csswg-drafts/issues/4949<br> <fremy> fantasai: we had defined atomic inlines to work like ideographic characters<br> <fremy> fantasai: but that is unfortunatley not web compatible<br> <fremy> fantasai: even if this would be a nicer behavior<br> <fremy> fantasai: but since forever, atomic inlines have allowed breaking opportunities<br> <fremy> fantasai: so we accepted our fate<br> <fremy> fantasai: but there are use cases for the correct behavior though<br> <fremy> fantasai: so there was a question of how to swtich to that behavior<br> <fremy> fantasai: line-break not being auto ===> atomic treated as ID<br> <fremy> fantasai: another option: wrap-before/after to control wrapping before a particular inline, so you could have values to prevent/avoid<br> <fremy> fantasai: one of them could be this smart behavior<br> <fremy> fantasai: so, do we want to introduce a switch of behavior toggle<br> <fremy> fantasai: and if so, which option?<br> <fremy> fantasai: an issue would be that this won't be very visible to most languages<br> <fremy> fantasai: and koji was afraid some people might set it, then have big effects for CJK languages<br> <fremy> fantasai: the other option is more targetted<br> <fantasai> s/big/subtle/<br> <myles> q+<br> <fremy> fantasai: but it has the downside you have to target each element independtly<br> <astearns> q?<br> <astearns> ack fantasai<br> <Zakim> fantasai, you wanted to ask if 'contain:layout' trapping scroll snapping is actually what we wnt<br> <fremy> florian: one other issue is that the line breaking properties currently don't exist anywhere<br> <fremy> florian: so adding new behavior to them is wishful thinking<br> <koji> +q<br> <xfq_> ack my<br> <fremy> myles: in all the ebooks that use images-as-text I have seen, they use a class on these images<br> <astearns> ack myles<br> <faceless2_> +1 to myles<br> <fremy> myles: so the rule to target them all is very easy<br> <astearns> ack koji<br> <fremy> koji: in the github issue, we said it's fine with the property, but we want a different feature<br> <fremy> koji: the proposal was to pretend that atomic inline was a line-breaking class<br> <fremy> koji: and as we discussed in other issues, we have to resolve the ambiguity between elements boundaries<br> <fremy> koji: and maybe that should be discussed in that context<br> <fremy> koji: I like that idea that was proposed on github<br> <fremy> koji: I talked to ICU people to see if that would be possible<br> <fremy> koji: but that didn't get an approval<br> <faceless2_> q+<br> <fremy> koji: so they suggested to pick a specific character instead<br> <fremy> fantasai: I'm fine with selecting one specific character we consider to be representative of ID<br> <fremy> fantasai: it would be confusing for people to have to pick on char<br> <fremy> fantasai: the mapping can be implementation detail<br> <fantasai> s/on/a/<br> <fremy> koji: i agree<br> <astearns> ack faceless2_<br> <fremy> faceless2: I agree with koji, that proposal is quite flexible<br> <fremy> florian: if this means we are going to prioritize implementing these properties, I agree<br> <fremy> florian: but this is a very useful case for us<br> <fremy> florian: and just pushing it to a new level doesn't do much for us<br> <faceless2_> We've implemented already I believe.<br> <faceless2_> pending testing, of course...<br> <fremy> myles: priority of the feature > stage of the spec<br> <fremy> myles: we should design the feature well, not worry to much about which spec level we put things in<br> <fantasai> +1<br> <fremy> florian: yes, but what we are wanting to do is tie this to a new property nobody implemented<br> <fremy> florian: and we don't know if that property itself will survive or still function in the same way<br> <fremy> myles: I think it's true, but if this happens, we can revisit later<br> <fremy> astearns: I agree with myles here<br> <fremy> astearns: also, it's very separate to how line-break works today<br> <fremy> astearns: this extra switch doesn't sound like very good design to me<br> <fremy> florian: ok, I rescind earlier's me comment<br> <fremy> astearns: sounds like we are in agreement to resolve to add one more value to wrap-before/after, which would specify which chararcter we want to emulate<br> <fremy> astearns: is that correcT?<br> <fremy> faceless2_: does that make sense as a single property?<br> <fremy> koji: yes, maybe we want only want property, a "wrap" shorthand<br> <fremy> fantasai: but he also mentioned that it was rather non-specific as a name<br> <fremy> fantasai: and could be confusing<br> <fremy> fantasai: also, this wouldn't encompass "wrap-inside"<br> <fremy> fantasai: but maybe "wrap-as: ideographic"<br> <fremy> koji: I like that naming<br> <fremy> koji: maybe we can have different ideas<br> <fremy> koji: but one nice thing is if you apply on an inline box, we can have each side apply to the first/last character of the inline<br> <fremy> fantasai: yes<br> <fremy> florian: I dont like wrap-as: avoid<br> <fremy> florian: maybe wrap-outside: ideographic/avoid ?<br> <fremy> fantasai: I like that<br> <fremy> fantasai: I am worried about changing the class of the chars though<br> <fremy> fantasai: because it also affects the breaking between first and second<br> <fremy> fantasai: so I would say "for the purpose of breaking before" the first character<br> <fremy> fantasai: (abc) + wrap-outside: avoid should not affect breaking between a and b<br> <fremy> koji: not sure I see what is wrong<br> <fremy> fantasai: because that is affecting the inside of the element<br> <fremy> fantasai: while we are trying to change the behavior outside<br> <fremy> koji: yeah i understood correctly<br> <fremy> koji: I have use case for that I think<br> <fremy> koji: elements never break, unless it's inline block<br> <fremy> myles: but this issue is about atomics?<br> <fantasai> https://www.w3.org/TR/css-text-4/#wrap-before<br> <fremy> fantasai: yeah but wrap-before applies to inlines too<br> <fremy> fantasai: so we need to define an effect for them as well<br> <fremy> koji: hence what I proposed<br> <fremy> fantasai: then I would prefer another property<br> <fremy> fantasai: I really don't find the proposal to change the breaking inside for changing the behavior outside<br> <fremy> astearns: and that would allows combinations too?<br> <fremy> fantasai: yes, but there is no combination that makes sense<br> <fremy> fantasai: (flex is special, and the others don't care about character class)<br> <fremy> fantasai: but if that's not possible to implement<br> <fremy> fantasai: then we need another property<br> <fremy> myles: yes, it's worth talking about implementatibility<br> <fremy> myles: when we compute the line breaking opportunities, we have a big string, and opportunities<br> <fremy> myles: the model we propose with before/after is not compatible with how line breaker work today<br> <fremy> myles: so I am in favor of a single property that works on both sides<br> <faceless2_> q+<br> <fremy> astearns: if it doesn't really make sense to have separate switches for both sides<br> <fremy> astearns: then a new property that affects both is better<br> <faceless2_> <p>a <span style="margin-left: 5em; white-space:pre>&#0a;</span> b</p><br> <astearns> ack faceless2_<br> <fremy> astearns: correct?<br> <fremy> faceless2_: we had one use case where this didn't apply to an atomic inline<br> <fremy> faceless2_: (...)_<br> <fremy> fantasai: yeah, I don't think we were proposing to remove the properties alltogether<br> <fremy> fantasai: just that for the specific use case of atomic inlines, we should have a separate one<br> <faceless2_> My example above was a case where suppressing line-breaking before a non-atomic inline was useful - in that example we would want to prevent the break before the <span>, due to the force break inside it.<br> <fremy> astearns: ok, so what I am hearing is support for "wrap-as" with values for atomic inline<br> <fremy> myles: and editors need to figure out interactions with the rest<br> <fremy> fantasai: I don't think it<br> <fremy> fantasai: .... is too difficult<br> <fremy> koji: what about the values? a string would be nice?<br> <fremy> fantasai: I am ok with the spec behavior described as that<br> <fremy> fantasai: but I would rather specify keywords<br> <fremy> fantasai: that would be map to some specific strings<br> <fremy> myles: was the proposal for the string to be a single char?<br> <fremy> myles: or "ideographic"<br> <fremy> koji: no, the char between quotes<br> <fremy> myles: then I think I agree with florian and fantasai<br> <fremy> fantasai: and I don't think people will even see this behavior as using ideographic<br> <faceless2_> -1000 to nomal<br> <fremy> florian: "normal"?<br> <fremy> astearns: doesn't mean much to me though<br> <fremy> fantasai: I think it's decent name; "normal" is ID just because<br> <fremy> fantasai: it happens ID is the best char to map to to have the desired behavior<br> <fremy> astearns: proposed resolution is to add "wrap-as" and values, details TBD later<br> <fremy> astearns: RESOLVED: add "wrap-as" and values, details TBD later<br> <fremy> florian: level 3?<br> <fremy> fantasai: no ^_^<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4949#issuecomment-624705207 using your GitHub account
Received on Wednesday, 6 May 2020 15:06:22 UTC