Proposing other fragment directives

[BigBlueHat]

Based on this line from the current spec...

The only directive introduced in this spec is the text directive but others could be added in the future.

Proposing additional fragment directives was certainly foreseen. What is the suggested best way to propose/explore new fragment directives?

Thanks!
🎩

[bokand]

That's a good question though I don't have a definitive answer.

I've been dragging my feet a bit but it's next in my queue to start merging this spec into WHATWG HTML (issue). Given that, and that this is all based on HTML document fragment processing, it probably makes most sense to follow any processes for HTML features. i.e. maybe start by filing an issue on the HTML repo?

[BigBlueHat]

I am a bit concerned that this spec (and others like it) are moving into the WHATWG HTML spec and not standing on their own. It's a URL design pattern that has applicability beyond HTML. Regardless, I'll post an issue there when I have something writ up in a way that presents value to HTML. Thanks!

[bokand]

The directive is part of the fragment - fragment processing is defined in each mime-type so I think it necessarily needs to be in HTML, though perhaps if it's useful elsewhere parts of it could be hoisted up into something more broad.

[bokand]

Closing this issue since I think there's nothing actionable here.

[Crissov]

The spec as currently written is mostly tailored to HTML and should be moved there, but I agree that Text Fragments should be available as a standalone spec, just like Media Fragments (temporal and spatial).

[BigBlueHat]

I keep forgetting that spec-wise fragments are MIME media type defined. I do like @Crissov's suggestion of writing up something like the Media Fragments spec, and I'll likely take that approach for the stuff I have in mind...then we'll see if/when the registries will get updated to match.

Much thanks for all the guidance @bokand!