You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It's pretty clever. But adding load-bearing comments to any format is fraught, and this seems like no exception. I can see pros and cons, but let me focus this issue mostly on the cons, to provide a counterpoint to the current explainer.
If the idea is to reuse an existing format to take advantage of existing content, then there might be compat concerns with that existing content. Or, concerns about the existing software/users that consume text/uri-list content, being confused by all these page-collections-oriented comments showing up in their ecosystem.
On the other hand, if you think that there is likely not enough existing content out there for compat concerns to manifest, or enough of an ecosystem out there to be confused by these new comments... then is the text/uri-list format really worth building on in the first place?
The requirement that the extended text/uri-list format be isomorphically encodable in a uri-list [sic] scheme is also somewhat restrictive. Although the ? in URL <-> #? mapping is pretty close, the one envisaged in https://github.com/bokand/page-collection#hierarchical-lists is not at all close.
An alternative path that might be worth investigating is a custom format which does not have existing content out there to cause compat and ecosystem concerns. This format could have first-class support for extensibility of the type you're envisioning, and could even be designed from the beginning to be isomorphic to a corresponding URL scheme.
The text was updated successfully, but these errors were encountered:
I just chatted with @vmpstr about this. The appeal of using text/uri-list is that we're avoiding creating a new type that's almost-but-not-quite the same as an existing one, like x-moz-url.
While we have some hypothetical ideas about how this could be developed in the future, our current requirements for load-bearing comments are all optional/decorative in nature: a name for the group and potentially a "theme color".
IMHO, given this is quite experimental and the proposed extensions to text/uri-list being limited and non-essential to the functionality, I'd still lean to using text/uri-list. But I agree with your concerns so I think we can be more explicit about saying that if the idea proves successful and there's demand for expanded scope we would create a new format for the expanded use cases.
(we may want to reconsider aspects of the scheme in light of this though)
It's pretty clever. But adding load-bearing comments to any format is fraught, and this seems like no exception. I can see pros and cons, but let me focus this issue mostly on the cons, to provide a counterpoint to the current explainer.
If the idea is to reuse an existing format to take advantage of existing content, then there might be compat concerns with that existing content. Or, concerns about the existing software/users that consume text/uri-list content, being confused by all these page-collections-oriented comments showing up in their ecosystem.
On the other hand, if you think that there is likely not enough existing content out there for compat concerns to manifest, or enough of an ecosystem out there to be confused by these new comments... then is the text/uri-list format really worth building on in the first place?
The requirement that the extended text/uri-list format be isomorphically encodable in a
uri-list
[sic] scheme is also somewhat restrictive. Although the?
in URL <->#?
mapping is pretty close, the one envisaged in https://github.com/bokand/page-collection#hierarchical-lists is not at all close.An alternative path that might be worth investigating is a custom format which does not have existing content out there to cause compat and ecosystem concerns. This format could have first-class support for extensibility of the type you're envisioning, and could even be designed from the beginning to be isomorphic to a corresponding URL scheme.
The text was updated successfully, but these errors were encountered: