- From: Bernhard Fey via GitHub <sysbot+gh@w3.org>
- Date: Tue, 10 Jan 2023 11:06:54 +0000
- To: public-css-archive@w3.org
We discussed this and while, as expected, we didn't come up with any simple solutions, I'll summarize our opinions and ideas: We broke the containing block down into it's four coordinates: inline-start: the start edge of the first visual fragment of the first line (equal to specified single line behavior) block-start: the start edge of the first visual fragment of the first line (equal to specified single line behavior) inline-end: the line box end edge* of the first line (basically extend the fragment to the end, similar to block fragments being extended to the end of pages or columns) block-end: either the end edge of the last visual fragment of the last line (equal to specified single line behavior). Alternatively, though not preferred by us, the end edge of the first line** (Firefox-like). *"line box end edge" could be defined in different ways with regard to how it interacts with floats. It could ignore floats, i.e. use the inline-end content edge of the inline formatting context box. Alternatively floats could be taken into account, either just the ones affecting the first line or (if block-end uses the last line) all affecting any of the lines, i.e. using the maximum or minimum of the line ends. **"end edge of the first line" is something we were not able to define. Using the end edge of the last fragment of the first line didn't seem right, as we already actively ignore that fragment for inline-end. First fragment, fragment bounding box and line box all didn't feel right either. (Using the last line instead seems to solve that, though.) One colleague brought up a more out-of-the-box approach that we feel worth discussing: To enable anchoring boxes both at the (visual) start as well as the end of the multi-line inline in all cases a conditional behavior could be introduced. Let's say the condition is handled via a property with the values: `start` (initial), `end` and `auto`. `auto` computes to `end` when `inset-inline-start` is `auto` and `inset-inline-end` is non-`auto`, and to `start` otherwise. The property isn't necessary as the `auto` behavior could always be used. But this might be to big of a change and a too far reaching effect of different `inset-inline-*` values. If the condition is start the behavior is Firefox-like. If it is end it is as well, but uses the last line instead of the first, so `inset-inline-end` is actually relative to the visual end of the multi-line inline, like for a single line inline. (Our approach of extending inline fragments to the line edge at their split points could be combined with this approach.) -- GitHub Notification of comment by bernhardf-ro Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8284#issuecomment-1377088341 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 10 January 2023 11:06:56 UTC