Open Bug 1844148 Opened 1 year ago Updated 1 year ago

Provide crop=center equivalent capability for HTML/CSS

Categories

(Core :: CSS Parsing and Computation, enhancement)

enhancement

Tracking

()

People

(Reporter: sfoster, Unassigned)

References

Details

XUL supports a crop=center attribute to ellipsize content in a non-overflowing, non-wrapping container. This removes characters from the middle of the string rather than the end, and puts the "..." in their place. This is especially useful for displaying things like filenames where truncating and adding the ellipsis at the end might elide critical information like the file extension, semver etc.
Being able to do this in HTML would unblock porting several firefox features away from XUL, and improve our truncation & display options in new HTML-based UI - in firefox and the ecosystem at large.

:emilio, not sure if this is the right component, but I'm sure you'll move it as necessary.

Flags: needinfo?(emilio)

Yeah so I forgot a bit how this all worked. The reason it works only on XUL (and <input type=file> labels) is because at least given how the code works now we need a source for the uncropped string. Also, as it works it can only render a text-node inside, not arbitrary stuff...

So I guess making it work for arbitrary content is a bit of a tbd problem. For a url or a link we could make it work with an special property or something. What would the markup look like for FF view?

Flags: needinfo?(emilio) → needinfo?(sfoster)

For what it's worth, the discussion for standardizing a way to do this happens in https://github.com/w3c/csswg-drafts/issues/3937.

Sebastian

(In reply to Emilio Cobos Álvarez (:emilio) from comment #2)

What would the markup look like for FF view?

You can check it out in about:firefoxview-next, but it's something like:

<span class="fxview-tab-row-url" id="fxview-tab-row-url">
          <!--?lit$9363306866$-->2023-07-15_13.37.16.jpg
        </span>

The comment node in there is an artifact from the lit.js library we are using, which uses it to track which elements need updating in its update/render loop as I understand it.

Flags: needinfo?(sfoster) → needinfo?(emilio)

I read some of the discussion from the csswg, and the potential complications given that even if you constrain it to inline content, you could still have all kinds of video, display:inline-block/inline-flex stuff, images etc. in there, and its really not at all clear how you could find the middle of that stuff and figure out where to crop. If you crop out an image from the middle, that might change the box height. Ugh. You would presumably need 2 passes where you full render, then split it in the middle with the ellipsis and render again. Whereas with truncating at the end, you can simply figure out how long your ellipsis will be and chop that much off the display frame (sorry if my terminology isnt right.). But I'm not sure anyone is asking for that. If its practical to enforce a constraint that this crop=center can only happen on an inline element with only text as its content, I think you'd hit 99% of the use cases.

Can't be on an inline, should probably be on a block/inline-block. The way the XUL stuff (and the <input type=file> label) works now is basically a block with a "source of truth" that's different than the DOM node (so the value attribute, basically, and the input value), that manages the internal text-node: https://searchfox.org/mozilla-central/rev/d6960b4e32d09bff32865694e32384eb9bca4af5/layout/generic/MiddleCroppingBlockFrame.h#22

I guess we could make it a leaf frame (so that it doesn't render the actual text nodes in the DOM), and use it as a source of truth. That seems like the simplest way.

Depends on: 1844195
Flags: needinfo?(emilio)
You need to log in before you can comment on or make changes to this bug.