- From: jfkthame via GitHub <noreply@w3.org>
- Date: Tue, 14 Oct 2025 08:56:51 +0000
- To: public-css-archive@w3.org
Thinking about this again, I'm feeling less in favor of `-inset` here. Not sure how well I can articulate this, but fwiw.... To my mind, `inset` properties are about adjusting their target element _in relation to another element_ (a parent or containing box). Given an element that is being sized or placed within an area that has been defined by some external thing, it makes sense to have the ability to "inset" (or expand, by use of negative inset) that area. But with decoration lines, it's not readily apparent to an author that there is any such "container" to apply insets to. The decoration line seems more like an attribute of a range of text, and its length is determined by the length of that text, not in relation to some containing element, so the idea of "insetting" from such a container is a little odd. Arguably the inline element (or pseudo, e.g. `::selection`) that defines the decorating line could be considered that container, and the spec talks of the "decorating box", so insets can reasonably be applied to that box, but I don't think this is a model that will generally be at the front of an author's mind. To an author, a decorating line is an independent thing that simply appears below (or above) a range of text. The property under discussion here directly adjusts the length of that line, by "trimming" a certain amount from each end, not by "insetting" it from a containing area. (As for negative values, a negative "trim" extends and a negative "inset" expands; these seem equally reasonable concepts to me.) -- GitHub Notification of comment by jfkthame Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8402#issuecomment-3400800231 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 14 October 2025 08:56:52 UTC