- From: Sebastian Zartner via GitHub <noreply@w3.org>
- Date: Mon, 18 Aug 2025 22:00:52 +0000
- To: public-css-archive@w3.org
Actually, I just had a thought again about the [approach I suggested earlier](https://github.com/w3c/csswg-drafts/issues/3937#issuecomment-1624382903) (which we resolved on to use as a starting point) and realized it has two flaws: 1. It allows nonsensical combinations of values like `text-overflow-handling: ellipsis fade; text-overflow-position: middle;`. 2. It introduces an `auto` value for `text-overflow-handling` to accommodate the different behavior for when `overflow-position` is set to `middle`. So here's an idea for a different approach that handles those two issues gracefully: Only extend the syntax of `text-overflow` to handle middle-cropping and keep it a longhand. ```ebnf text-overflow = [ [ clip | <overflow-marker> ] && [ start | end ]? ]{1,2} | [ <text-overflow-handling> && middle ] <overflow-marker> = ellipsis | <string> | fade | <fade()> ``` Doing so, we ensure that there's only one value allowed in combination with `middle`, `clip` is disallowed in combination with `middle`, ellipsizing can be restricted to the start, avoids ambiguities regarding start and end ellipsizing, and the initial value of `clip` can stay unchanged. Examples: Ellipsizing in the middle: ```css text-overflow: ellipsis middle; ``` Ellipsizing at the start: ```css text-overflow: ellipsis start; ``` Ellipsizing at the start and fading at the end: ```css text-overflow: ellipsis start fade end; ``` Repeating `start` or `end` should be invalid. This approach doesn't allow to apply the values for the handling and the position independently, though I believe there's no need for that. That syntax can still be extended later on to allow weighted ellipsizing as mentioned in previous comments and #5417. Sebastian -- GitHub Notification of comment by SebastianZ Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3937#issuecomment-3198556039 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 18 August 2025 22:00:53 UTC