-
Notifications
You must be signed in to change notification settings - Fork 56
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
Comments
Is it worth having any similarity to RFC 5147's mechanism? |
Hi - just noting that the assessment of the questionnaire appears blank. |
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.
Sorry - I misunderstood the template. Here is the questionnaire: https://github.com/bokand/ScrollToTextFragment/blob/master/security-privacy-questionnaire.md |
Some additional thoughts for consideration based on research & exploration we’ve been doing: https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/master/Fragments/explainer.md |
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? |
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! |
We had a discussion about this at our telecon last week. |
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 For From some of the questions in the notes:
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.
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.
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 |
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:
vs.
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. |
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. |
@annevk left a comment on WICG/scroll-to-text-fragment#70 after it was merged:
Is there an issue filed on HTML to track this work, @bokand? |
Marking as |
Thanks for the feedback, we'll make the changes.
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 believe this was in reply to my suggestion:
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 |
FYI: There's a question in whatwg/#5523 about whether we should move |
I replied there pointing out a flaw in the reasoning, but that was never followed up on. |
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. |
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. |
FWIW, I agree with @annevk's comment here: whatwg/html#5523 (comment) |
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! |
Thank you @hober and TAG for the review and constructive feedback!
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.
The current spec is monkey-patching HTML so I think it makes sense to move there if/when we can get additional implementer interest. |
In addition, Blink now has an intent to ship support for the |
@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. |
こんにちは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:
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):
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.
The text was updated successfully, but these errors were encountered: