Add external span IDs

[nicoburns]

This associated a user-specified ID with each style span in a TreeBuilder, which can then be retrieved from a Cluster after layout (and notably from a Cluster created using Cluster::from_point).

This enables hit-testing of inline spans (for click and hover behaviour).

The current behaviour of Cluster::from_point isn't ideal for this application: it will try to find the "nearest" cluster even if the cursor isn't exactly above one (which makes sense for placing a caret but not for hover/click). But it's "good enough" for now, and I think we can add a new function for that in a followup.

Rendered using Parley + Blitz:

Screen.Recording.2024-12-17.at.07.51.41.mov

[DJMcNab]

Hmm. The way I solved a very similar problem in Masonry, which worked quite well, was to just make the Brush parameter contain the style id. You would then do a look-up from the style id to your painting property, and whatever other metadata you need (so for hover in this case)

My understanding is that something like this would be a future plan, but likely as part of the much more significant refactor discussed here.

[nicoburns]

Hmm. The way I solved a very similar problem in Masonry, which worked quite well, was to just make the Brush parameter contain the style id. You would then do a look-up from the style id to your painting property, and whatever other metadata you need (so for hover in this case)

My understanding is that something like this would be a future plan, but likely as part of the much more significant refactor discussed here.

Definitely looking forward to the refactor, but we I don't want to wait on it as my understanding is that it is likely to come as part of the switch to using harfruzz for shaping which is likely several months off at this point. In the meantime, we can improve the current API (and evolve it closer towards the new design in the process)

IMO it's a bit neater if it's separate as conceptually an ID is not a "style", but I suppose putting it in Brush would work (and then I guess you can use () for Brush until we remove it).

[xorgy]

Putting it in Brush does introduce some awkwardness around multiple stylistic brushes mapped to the same id, but I think it's good to limit the associated data on spans to the one field if we can. Might be worth making an example or a document for mixing ids with other data on a Brush.

The code itself I think is fine.

[xorgy]

@nicoburns could you run the format on this so it can be mergeable?

[DJMcNab]

If we are going to merge this, then my preference would be to tear out the Brush entirely at the same time.
They serve exactly the same purpose, except Brush is generic, with all the advantages and disadvantages that brings.

[waywardmonkeys]

I think I'm in agreement with Daniel's last comment and that shouldn't be merged in the current form.

[nicoburns]

I've formatted and rebased this because why not. But it sounds like we'll need to find a different design for this.

I think we will want to find a solution though, because parley::ResolvedStyle stores three instances of Brush: the main one + one for underlined text + one for strikethrough text, so implementing "span ids" on top of parley main means duplicating that id 3 times (or storing a dummy id twice).

Which brings up another point: should parley be dealing with underline and strikethrough styles at all. Most of the styles there look like they are just passed straight through. But perhaps there's something around the offset which is font-specific and parley is useful for?

@dfrg Would you anticipate Parley handling underline/strikethrough styles in a world where the main text colour "brush" is just an external ID? Or would those styles hang off the ID too?

[nicoburns]

Diff to switch Blitz from this PR to Parley main is https://github.com/DioxusLabs/blitz/pull/183/files. It's not awful, but it's definitely not as clean. In any case, it unblocks Blitz from using Parley main and/or a new release of Parley if we make one.

[dfrg]

In my parley-next vision, all style information that doesn’t directly affect layout would be hung off of a style/span id and be managed by the user. With that in mind, I’m fine with just removing the text decoration properties entirely.