[css-text-3] Segment Break Transformation Rules, U+200B, inline box boundaries, and display:none

[frivoal]

The Segment Break Transformation Rules says this:

If the character immediately before or immediately after the segment break is the zero-width space character (U+200B), then the break is removed, leaving behind the zero-width space.

It means that

aaaa​
bbbb

is rendered as if it were

aaaa​bbbb

I like it, but:

• If there is an inline box boundary between the U+200B and the segment break, does it still count as "immediately before or immediately after" or not? Since inline box boundaries are not meant to affect text layout, I'd say yes, but I don't know for sure that this is what the spec means. In other words, does

  aaaa<span>&#x200b;</span>
  bbbb
  

  get rendered as if it were

  aaaa<span>&#x200b;</span>bbbb
  

  or

  aaaa<span>&#x200b;</span> bbbb
  

• Assuming inline boundaries don't make a difference (otherwise the point is moot), does the display value of the U+200B matter? Obviously, if it has a display value that makes it not inline, then it does, but what if it's display none? In other words, does

  aaaa<span style=display:none>&#x200b;</span>
  bbbb
  

  get rendered as if it were

  aaaabbbb
  

  or

  aaaa bbbb
  

I'd propose clarifying the sentence to:

If the character immediately before or immediately after (ignoring any intervening inline box boundaries) the segment break is the zero-width space character (U+200B) and the computed value of the 'display' property on that character is not ''none'', then the break is removed, leaving behind the zero-width space.

I suppose the alternative would be to consider that this operation works on the element tree rather than the box tree, but that seems weird.

[fantasai]

1. Inline boundaries don't matter for white space processing generally, I don't see why we need to call it out for segment break transformations specifically. If you think it needs clarification generally, then let's clarify it generally.

2. If we needed to define the effect of display: none text here, we'd need to define the effect of display: none content in literally every section of every layout spec. That's going to make the specs incomprehensible and severely error-prone, therefore we're not going to do it. It's the job of display: none to define how it works.

[frivoal]

1. • Because Mozilla's implementation gets it wrong, and stops doing the thing we're asking for if there is an inline box boundary. That made me think that the "immediately before or after" bit could be misleading, and wanting to clarify.
   • There are other places inside white-space processing (and other places in this spec) where we do call it out explicitly (and found that we needed, for reasons similar to the previous point: when we don't, implementations get it wrong). In some of these places, we also state that out-of-flow elements also don't make a difference.
2. If it's clear that we're operating on the box tree, we may not need to say anything about display:none. But is it clear?

That said, I agree this applies to everything in this section, so instead of adding a clarification to each statement every time we notice a browser doing it wrong, we should go with a generic statement. How about adding something like this to 4.1:

For the purpose of operations described in this section, any intervening inline box boundaries are ignored when considering whether characters are next to each other, at the beginning or end of the line, or similar considerations.

Should we say something about out of flow elements? In most of section 4.1, it seems that they should be ignored as well, although I am not so sure for the Segment Break Transformation Rules.

[fantasai]

It's probably even more generic, honestly. Maybe it goes in the spec Intro somewhere, with an exception for https://drafts.csswg.org/css-text-3/#boundary-shaping ?

For the purpose of determining adjacency for text processing (such as white space processing, text transformation, line-breaking, etc.), and thus in general within this specification, intervening [=inline box=] boundaries and [=out-of-flow=] elements must be ignored. With respect to text shaping, however, see [[#boundary-shaping]].