`##text=` instead of `##targetText=` ?
tigt opened this issue · 13 comments
I understand the desire to avoid clashing with existing ids, but it seems like the ## delimiter handles that problem already.
##text= seems just as clear and a lot briefer, which is important in URLs.
Yup, I agree. If the ## syntax survives then we should use a more compact identifier.
FWIW, there's the alternate POV that we should use the Web Annotation Fragment Syntax. IMHO, it's overly-verbose for our purposes so I'd prefer something like ##text=; perhaps as a shorthand to an also accepted #selector(type=TextQuoteSelector, ...). I'm not convinced of the value of reusing the fragment identifier syntax; though I do think they should have matching semantics so that the targetText can be mapped to TextQuoteSelector and vice-versa.
I also think it's overly verbose, and while it's great that it provides extensibility, in theory, to agents that understand web annotation, I don't see systems being able to interpret custom selectors minted by other systems. There may be still be some value in parsing them, recognizing the selector from the URI, but having a shorthand for the common types doesn't seem like a problem to me.
On reviewing the draft I thought similar, though I’d propose ##target
##target would be shorter than ##targetText (and also foregoes questions around the unusual camel case in a URLs), clearer than just text, and, indeed, conveniently close to CSS’ :target.
I think ##target is more ambiguous. One thought to the future is that this mechanism could be extended to allow different kinds of selectors (e.g. an image selector, or a CSS selector). If we went with ##target it would either have to somehow be amended to specify the type or all other selectors would be descriptive of the type by text would be #target which would be oddly inconsistent.
I think ##text is descriptive and specific enough and very concise.
Thanks! Interesting. I’d beg to differ, maybe we can bounce some ideas off another?
What I find problematic about text is that it’s super-generic, and that it doesn’t seem to set very useful expectations what’s to happen. A URL with a text parameter, at least to me, looks more like it passes input to the page rather than selecting something on it, let alone performing an action like jumping somewhere on the page. It could similarly mean a condition of sort.
target, then, although pretty general, too, has not only the advantage of being close to respective CSS pseudo class, but that it seems to justify a bit better the action to be happening here. What’s the target?—and the UA goes for it. To me, at least on thinking, that seems to match user expectations and their model a bit better. (Likewise on URL manipulations—I could see it as coming rather natural for a user to modify such string and have instant recognition that target only finds an aim if there is, indeed, such target on the page.)
That being said, we might just be on to something in that neither term may work that well. Brainstorming might help, soliciting more feedback, or otherwise broadening options.
target is already a bit overloaded with CSS’s idea of what it means (URL fragments), and HTML/JavaScript’s idea (a frame or new tab/window).
URLs implicitly mean navigation somewhere, so a text= parameter seems like it suggests navigating to a snippet of text just fine to me.
I also find it slightly confusing that :target would match an explicit ##target= and a regular hash fragment.
I like to stay with this for a moment because I like the question.
How about the following test: Which URL parameter, fragment or not, could not be called text, what part of a URL would this not fit?
If we find that this is broad, so broad that the name can be used for anything, how about at least exploring (only exploring) other names? It may not be target then (I don’t care about the particular name so much, and while I don’t agree with @tigt that text sounds like navigation, I see the point around things like @target), but maybe there’s a name that’s easy to understand without being so generic as to be associated with anything.
I don't think anything has to sound like navigation or not. If new behavior is being introduced, it will be learned. There's little reason, a priori, anyone should believe that a regular fragment is about navigation until they learn it.
However, on a related topic, I do find it interesting that the normal fragment syntax navigates to an element with the given id and that this is also how the # symbol is used by CSS. In other words, with CSS as a prior, it makes sense that http://example.com/page#foo navigates to the element with id="foo". It makes me wish we had available to us a different delimiter that had no existing use in CSS and functioned only as delimiter.
Let's imagine such a delimiter were available, and pretend that it's ›, for the sake of argument. It would be possible then that http://example.com/page›#foo goes to id="foo", http://example.com/page›.foo goes to class="foo" (with security caveats suggesting that UAs not implement this aside for the moment) and http://example.com/page›::text(foo). For why shouldn't we imagine that CSS could have a pseudo-element for text?
Alas, we're probably must make compromises. I don't think we should be very concerned with what people might think a new syntax means before they are familiar with it, because that is teachable. I do think we should be very concerned with how the terms and syntaxes we use are more or less consistent with adjacent specifications and behaviors, like CSS.
I think I agree that target feels clunky since everything in this syntactic position is target. Better to elide that which is implied and skip straight to specifying the type of said target, thus ##text.
Just to add to what's already been said: the syntax here is an extension of URL fragments, the purpose of which is to identify a subresource within the specified primary resource. Within that context, I think it's consistent that any mechanism is used to find a target within the page (as opposed to say, passing text to the page, which would nominally be achieved with a ? query string)
The spec and explainer have been updated to use :~:text=.... Chrome M79 also uses this updated syntax.
Echoing https://twitter.com/zcorpan/status/1182556480874176513, is the rationale behind :~:text=… documented anywhere?
https://groups.google.com/a/chromium.org/d/msg/blink-dev/zlLSxQ9BA8Y/iwqapGKlCwAJ explains that a thorough web compat investigation was done for :~:text=…, but it doesn’t explain how we ended up there.
cc @zcorpan