bokand/page-collection

A proposal for links that open multiple URLs

page-collection's Issues

Is extending text/uri-list with magic comments a good idea?

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.

Typo: "weary" -> "wary"

How to feature detect from script

Previously we had script-based detection by checking for allow in <a> but #5 says allow is probably not the right keyword. I'm currently leaning to replacing allow with a new value for rel but that's no longer feature detectable from script.

Some potential options:

• Something specific for feature detection, e.g. 'multilink' in navigator
• Instead of a rel value add a new attribute, e.g. <a multi> which can be feature detected

The web uses "URL", not "URI"

See https://url.spec.whatwg.org/#url-apis-elsewhere.

I imagine you might be influenced by the existing text/uri-list MIME type. If reusing that is necessary, then maybe that's fine. But don't spread that further in the platform via a new URL scheme.

/cc @annevk

Dynamically constructed tab groups

One valuable use case this proposal can address is comparisons. Often users open a number of links in new tabs to compare search results, products, or other lists. These links might be from the same site or a variety of sites.

For a host website to provide this feature with the current proposal, they would either need to provide a pre-curated bundle of links, or require the user to click checkboxes (or similar) next to each link of interest before clicking another button to open them all.

A better UX could be enabling links to target named tab groups. This would allow a site to offer an appropriate button e.g. (+ Compare) next to items of interest, and each click would add a tab to the same group. The user could interact with the tab group, close tabs that are no longer useful, and return to the original page to add new tabs as they go. This would also indirectly help users curate tab lists to share or save later.

This pattern is already common on many sites, but requires custom implementations and only works on same-site content.

This is also somewhat possible today for browsers that support a secondary action to add to a tabbed group. This would make the experience more explicit and discoverable, and allow individual sites to better tailor the experience.

The interface might look like:

<a href='site-a.com/running-shoe' target="_tabgroup" tab-group-name="my-site:query=mens+shoes" tab-group-label="Mens Shoes">Compare Running Shoe</a>
<a href='site-b.com/dress-shoe' target="_tabgroup" tab-group-name="my-site:query=mens+shoes" tab-group-label="Mens Shoes">Compare Dress Shoe</a>
<a href='site-c.com/casual-shoe' target="_tabgroup" tab-group-name="my-site:query=mens+shoes" tab-group-label="Mens Shoes">Compare Casual Shoe</a>

Clicking each link would add it to the same tab group.

Other considerations:

It might be desirable to auto-namespace to the current site, tab, or even document, so different pages or sites can't open links in the same named groups unexpectedly. Scoping to the site may still be desirable for multi-page apps where the user compares things across multiple pages or from different tabs.

This can still combine with the existing proposal, to allow "Add these 3 products to the comparison".

Prior Art: Atom/RSS

This might be worth looking into.

Firefox used this for a type of bookmark folder in the past, I believe. Understanding why that feature was removed might be illuminating.

Some unescaped content in the explainer

Found two so far while skimming, but it'd be worth doing a re-read:

We also extended text/uri-list (in a backwards compatible way) to allow adding some configuration options. Options can be specified at the end of the resource by placing a key=value pair in a comment with ‘?’ as the first character. For example:

https://en.wikipedia.org/wiki/Cat https://www.reddit.com/r/catmemes/ #?group-name=Cat Links

Only a single configuration option will be supported at this time: group-name

and

A new HTML element (e.g. )

Reusing allow="" is a bit weird

allow="" already has a meaning related to permissions policy and <iframe>. Reusing it for <a>, presumably with a different set of tokens (not related to permissions policy), seems weird.