Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Scroll To Text #392

Closed
3 of 5 tasks
nickburris opened this issue Jul 2, 2019 · 44 comments
Closed
3 of 5 tasks

Scroll To Text #392

nickburris opened this issue Jul 2, 2019 · 44 comments

Comments

@nickburris
Copy link

nickburris commented Jul 2, 2019

こんにちはTAG!

I'm requesting a TAG review of:

Further details:

We recommend the explainer to be in Markdown. On top of the usual information expected in the explainer, it is strongly recommended to add:

  • Links to major pieces of multi-stakeholder review or discussion of this specification:
  • Links to major unresolved issues or opposition with this specification:

You should also know that...

One of our major discussion points currently is how the targetText= indicator should be delimited in the URL fragment. See https://github.com/bokand/ScrollToTextFragment/issues/15. The latest idea here is that we could use a double-hash syntax (e.g. example.com#fragment##targetText=example) to avoid breaking websites that use the fragment for routing/state. The browser would parse the ##targetText= identifier and then remove it from the fragment.

We'd prefer the TAG provide feedback as (please select one):

  • open issues in our GitHub repo for each point of feedback
  • open a single issue in our GitHub repo for the entire review
  • leave review feedback as a comment in this issue and @-notify [github usernames]

Please preview the issue and check that the links work before submitting. In particular, if anything links to a URL which requires authentication (e.g. Google document), please make sure anyone with the link can access the document.

¹ For background, see our explanation of how to write a good explainer.

@dbaron
Copy link
Member

dbaron commented Jul 10, 2019

Is it worth having any similarity to RFC 5147's mechanism?

@torgo
Copy link
Member

torgo commented Jul 10, 2019

Hi - just noting that the assessment of the questionnaire appears blank.

@nickburris
Copy link
Author

Is it worth having any similarity to RFC 5147's mechanism?

The problem with using character positions is that the references would be outdated much more quickly, for example if this were to be used for cross-references on Wikipedia, where articles are updated often. Naturally, text references will also go stale over time, but only when the actual target text is modified.

Hi - just noting that the assessment of the questionnaire appears blank.

Sorry - I misunderstood the template. Here is the questionnaire: https://github.com/bokand/ScrollToTextFragment/blob/master/security-privacy-questionnaire.md

@aarongustafson
Copy link

Some additional thoughts for consideration based on research & exploration we’ve been doing: https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/master/Fragments/explainer.md

@annevk
Copy link
Member

annevk commented Jul 12, 2019

I couldn't find a description of how "Restricted to pages without an opener (no window.open)" is managed. (In particular, if A1 opens a popup A2 which then navigates A1 to V, V won't have an opener, but we certainly don't want this to work there.)

@nickburris
Copy link
Author

I couldn't find a description of how "Restricted to pages without an opener (no window.open)" is managed. (In particular, if A1 opens a popup A2 which then navigates A1 to V, V won't have an opener, but we certainly don't want this to work there.)

The case you describe would indeed circumvent this. I'm not sure how we can mitigate this case - does anyone know of any precedent for this kind of restriction in spec already?

@alice alice self-assigned this Jul 19, 2019
@nickburris
Copy link
Author

FYI, we're currently exploring a way to improve web compatibility by placing the targetText behind a delimiter - e.g. a ## in the URL fragment separating the targetText which would then be stripped off and hidden from the page. This mitigates issues with sites that use the fragment for other purposes, e.g. https://www.webmd.com/skin-problems-and-treatments/lice-treatment#3##targetText=other%20options.-,Wet%20combing%20is%20one,or%20olive%20oil.,-But%20these%20may (from chromium bug 961440)

This is explored in https://github.com/bokand/ScrollToTextFragment/issues/15#issuecomment-496595958 and we'd appreciate TAG reviewers' thoughts on this issue!

@dbaron
Copy link
Member

dbaron commented Aug 7, 2019

We had a discussion about this at our telecon last week.

@dbaron
Copy link
Member

dbaron commented Aug 7, 2019

Another question about this: what's the story for feature detectability?

@bokand
Copy link

bokand commented Aug 8, 2019

Another question about this: what's the story for feature detectability?

I brought this up in WICG/scroll-to-text-fragment#19 - We should have some way to detect this feature but I'm not sure what the best way would be. Since there's no new JS APIs there's no obvious place to put it. Perhaps a bool on navigator? Or on URL? Neither feels especially intuitive. Is there an existing place for feature detecting things without a matching JS/CSS API?

For ##, we could feature detect that with (new URL('https://test.com/##)).hash.indexOf('##') >= 0 but we probably don't want to tie ## to targetText.

From some of the questions in the notes:

Peter: I remember Doug Schepers talking about an annotation system.

Probably WebAnnotations? We did look at this and our syntax is quite close to the TextQuoteSelector, the major difference being that we allow essentially a wild-card match on the exact portion to allow a more compact representation of a long snippet.

Peter: there's a lot of work that's been done with media fragments;

We also looked at media fragments and initially wanted to do something similar. However, we ran into the compatibility concerns for pages that don't expect a hash/use it for their own processing.

How will these URL be minted? From user doing text search in browser? Or something page will generate?

We expect two major use cases: external pages pointing to a sub-resource (e.g. search engine, Wikipedia references) as well as users highlighting a snippet and copying a direct link to it. In both these cases we're generating a hash for a page without it knowing about it prior. Hence why conflicting with existing uses of the hash for routing is a concern; we expect a large number of links containing a hash to pages that would previously not expect it.

The case of internal (within an origin) anchors is less interesting because it's already possible. Since the author controls both the anchor and the pointed to resource, they can simply annotate the desired location with an element-id and use a regular element-id fragment (and provide highlight styling using :target)

@BigBlueHat
Copy link

The Web Annotations WG did also create a fragment selector proposal as part of a note and there are a handful of existing implementations of those among web annotation tool providers--Apache Annotator among them (see demo).

So...Web Annotation Fragment Selectors:

https://annotator.apache.org/demo/#selector(type=TextQuoteSelector,exact=annotated%20world!))

vs.

https://example.org/##targetText=annotated%20world!

The Web Annotation Data Model (and it's Open Annotation predecessor) are widely used in digital heritage communities such as those using the International Image Interoperability Framework or projects like Pelagios or online article publishing tools like dokie.li. Additionally, general purpose web annotation systems like Hypothes.is and Pundit support Web Annotation Data Model compatible exports.

All of these communities would benefit from a text selection fragment identifier which was compatible with the Web Annotation Data Model structure such that conversions could be made between the two by existing implementations.

@plinss
Copy link
Member

plinss commented Dec 4, 2019

The spec needs to list which content types this type of fragment applies to, e.g. does this only work for html? what about plain/text documents? SVG? etc...

I'm not asserting which types of documents this should apply to, but the spec needs to be clear as fragments are interpreted according to the content type of the document.

@hober
Copy link
Contributor

hober commented Dec 4, 2019

@annevk left a comment on WICG/scroll-to-text-fragment#70 after it was merged:

That might be doable, yes, but it would require patching HTML.

Is there an issue filed on HTML to track this work, @bokand?

@hober hober added Progress: pending external feedback The TAG is waiting on response to comments/questions asked by the TAG during the review Progress: pending editor update TAG is waiting for a spec/explainer update labels Dec 4, 2019
@hober
Copy link
Contributor

hober commented Dec 4, 2019

Marking as pending external feedback while we wait for answers to the above questions, and pending editor update for my word boundary nits.

@bokand
Copy link

bokand commented Dec 5, 2019

This is definitely an improvement, thanks. I have more specific thoughts about the non-normative note beginning "Limiting matching to word boundaries," which are below. With the following changes, I'd be happy with this text.

Thanks for the feedback, we'll make the changes.

The spec needs to list which content types this type of fragment applies to, e.g. does this only work for html? what about plain/text documents? SVG? etc...

It's implied to be HTML documents only by section 2.3.4 allowTextFragmentDirectiveFlag since it makes the change in the HTML document loading steps. I agree it'd be useful to make this more explicit. Would a non-normative note be sufficient because of the above or does this need to be normative?

@annevk left a comment on WICG/scroll-to-text-fragment#70 after it was merged:

That might be doable, yes, but it would require patching HTML.

Is there an issue filed on HTML to track this work, @bokand?

I believe this was in reply to my suggestion:

Also, w.r.t. target="_self" rel="noopener", could we make a link with a text directive imply noopener semantics? I would think this is preferable to requiring links to add noopener since there are cases where that'll be difficult for the user and generally make this more difficult to use.

I just replied on the PR. I changed my mind on the above, I don't think it's critical to this proposal (details there). I think @annevk's original idea about target="_self" rel="noopener" would still be useful. Filed whatwg/html#5134.

@bokand
Copy link

bokand commented May 8, 2020

FYI: There's a question in whatwg/#5523 about whether we should move window.location.fragmentDirective from window.location to elsewhere (document.fragmentDirective?) due to the quirks of window.location. I'd appreciate if we got broader opinions on whether it's worth the work to make window.location smoothly extensible or if it should be avoided in new APIs.

@annevk
Copy link
Member

annevk commented May 9, 2020

I don't think it's critical to this proposal (details there).

I replied there pointing out a flaw in the reasoning, but that was never followed up on.

@bokand
Copy link

bokand commented May 12, 2020

Sorry - I still intend to get to it (along with a bunch of other outstanding issues) but have too many balls in the air. I'll carve out some time this week to look at that issue specifically.

@hober
Copy link
Contributor

hober commented May 27, 2020

The spec needs to list which content types this type of fragment applies to, e.g. does this only work for html? what about plain/text documents? SVG? etc...

It's implied to be HTML documents only by section 2.3.4 allowTextFragmentDirectiveFlag since it makes the change in the HTML document loading steps. I agree it'd be useful to make this more explicit. Would a non-normative note be sufficient because of the above or does this need to be normative?

I think you'll need to make at least some normative statements, yes, though perhaps most of this point could be captured in a non-normative note.

@hober
Copy link
Contributor

hober commented May 27, 2020

FYI: There's a question in whatwg/#5523 about whether we should move window.location.fragmentDirective from window.location to elsewhere (document.fragmentDirective?) due to the quirks of window.location.

FWIW, I agree with @annevk's comment here: whatwg/html#5523 (comment)

@hober hober added Progress: review complete Missing: venue Resolution: ambivalent and removed Progress: pending editor update TAG is waiting for a spec/explainer update Progress: pending external feedback The TAG is waiting on response to comments/questions asked by the TAG during the review Progress: in progress Missing: venue labels May 27, 2020
@hober
Copy link
Contributor

hober commented May 28, 2020

We took another look at this in this week's TAG F2F and we've decided to complete our review.

We're happy that you've tightened up the normative text around word boundaries that we were concerned with, and that you reached out to several other venues to solicit feedback (e.g. uri@w3.org).

We're (still) worried that this is a very significant change to URL syntax and processing that may not have gotten sufficient buy-in from the various relevant standards bodies and other stakeholders. We're also worried that this doesn't have a clear path to standardization. Where do you intend to take this after WICG?

Please file a new design review issue if you end up significantly altering your plans here. Thanks!

@hober hober closed this as completed May 28, 2020
@bokand
Copy link

bokand commented Jun 3, 2020

Thank you @hober and TAG for the review and constructive feedback!

We're (still) worried that this is a very significant change to URL syntax and processing

I'd just like to get clarification on this point - our original idea of mucking with URLs themselves was dropped. The proposal as it stands it entirely a change to fragment processing in HTML documents only. There are some significant changes here but this seems less scary than changes to URLs so I'd just like to confirm this comment is referring to the most up-to-date spec.

We're also worried that this doesn't have a clear path to standardization. Where do you intend to take this after WICG?

The current spec is monkey-patching HTML so I think it makes sense to move there if/when we can get additional implementer interest.

@lilles
Copy link

lilles commented Nov 23, 2020

In addition, Blink now has an intent to ship support for the ::target-text selector as specified in css-pseudo which supports styling the text fragment highlight.

@bokand
Copy link

bokand commented Nov 23, 2020

We're (still) worried that this is a very significant change to URL syntax and processing

I'd just like to get clarification on this point - our original idea of mucking with URLs themselves was dropped.

@hober A ping on clarifying this point; this is entirely specified as HTML fragment processing. The spec is now much clearer about how processing the fragment directive works and what it means for various edge cases to do with URLs.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment