- From: Miriam Suzanne via GitHub <sysbot+gh@w3.org>
- Date: Thu, 23 Sep 2021 02:21:34 +0000
- To: public-css-archive@w3.org
I understand that there are use-cases where an author might want to exclude some elements/margins from the impact of `margin-trim`. I do not think it's true that those use-cases align cleanly with a distinction between flow-types (in-flow, float, or abspos). In all cases, I would expect the default of margin-trim to trim all box-edge margins. From there, it seems to me like the more important question is: do we need a way for some elements to override that container-imposed trimming. On the call, @bfgeek linked this example: https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=9645 This "image-with-whitespace next to text" is a common pattern, although neither box in the demo reflects a clearly desirable outcome. - In most cases, authors will want the image "aligned" with the text (a bit of a fuzzy concept, which would be helped by `leading-trim`). - But it is true that there are some cases where the image (or other box) gets "extra" whitespace. In both cases, this same basic pattern is now achieved with a variety layout methods -- float, flexbox, and grid -- depending on subtle details of sizing and alignment and content. From an author perspective, there is not a consistent relationship between which layout technique is used, and how the author would want box-edge margins handled. In the case where one child element does need to keep margins intact, there are several options: - that extra space can be applied as `padding` rather than `margin` - the author can manually remove `margin` on individual elements, rather than using `margin-trim` on the container - we could provide a way for elements to "opt out" of `margin-trim` (something similar to the [`margin-break` property](https://drafts.csswg.org/css-break-4/#break-margins), which handles per-element margin-truncating rules in fragmentation contexts). That last option would make sense to me. But attempting to auto-opt-out an entire category of elements (based on their relationship to flow) feels like an unreliable heuristic, and doesn't match any consistent author patterns that I've seen. -- GitHub Notification of comment by mirisuzanne Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3256#issuecomment-925461193 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 23 September 2021 02:21:36 UTC