Bikeshed: targetElement= seems long

[jakearchibald]

trafficstars

Alternatives:

• target=.foo - matches :target.
• =.foo - short, but maybe unclear.
• css(.foo) - short, but maybe introduces parsing issues since ( is part of CSS

[BigBlueHat]

CSS's :target is super greedy...apparently: https://jsbin.com/murasus/edit?html,output

It gladly reacted to:

#`~!@#$%^&*( )_-+=;:',<.>/?

as a fragment identifier which displays content in that demo using :target.

Essentially, there's no "delimiter" available for partitioning/changing the semantics of a Fragment Identifier in HTML...at least not as far as CSS is concerned (nor location.hash neither).

The ultimate takeaway being that one would have to define a "magic string" (in addition to the #) to trigger this processing. That would have the pragmatic effect of no longer being able to use that "magic string" as the id of an HTML element. 🐉 🐉 🐉 <-- dragons. 😢

Not sure if there are other options for extending/changing the URL semantics for HTML's media type...but that seems unlikely (given this as a backdrop).

Edit: updated fragment identifier to contain a space.

[nemzes]

querySelector would offer no length advantages, but at least would be consistent with the DOM Document API.

As for avoiding upsetting :target, the only strings that shouldn't match an id would be the ones with spaces in them, since that's the only character not allowed in the id attribute. Of course, at least Chrome and FF do match IDs with spaces, so… 🤷‍♂️

[ArthurSonzogni]

For you intention. There is already a special syntax using the fragment identifier to make an SVG document to be scrolled. You can even apply transformation other than translations.

Here is an example with the same SVG document displayed in 4 different way.

• https://betravis.github.io/icon-methods/bunny-sprite-sheet.svg
• https://betravis.github.io/icon-methods/bunny-sprite-sheet.svg#svgView(viewBox(0,0,100,100))
• https://betravis.github.io/icon-methods/bunny-sprite-sheet.svg#svgView(viewBox(100,0,100,100))
• https://betravis.github.io/icon-methods/bunny-sprite-sheet.svg#svgView(viewBox(200,0,100,100))

See https://www.w3.org/TR/SVG/linking.html

I think it is very close to the scroll-to-css proposal. For consistency, maybe it would be preferable using a syntax with parenthesis instead of a the equal symbol?

I like those two.

• #css(selector)
• #querySelector(selector)

[BigBlueHat]

The parenthesis pattern is historically the more preferable and more extensible. The tricky part is defining a fragment identifier for a media type that has something like a 20+ year history of use... SVG could define #svgView because they were also minting a new media type. HTML doesn't really have that "luxury."

[BigBlueHat]

I've updated the JSbin from earlier to contain a space: https://jsbin.com/murasus/edit?html,output

You can test the output with the fragment directly at this URL: https://output.jsbin.com/murasus#%60~!@#$%^&*(%20)_-+=;:',%3C.%3E/?

Note the escaped as %20--the id value just has a . The + sign based escaping doesn't work (because + is also valid in the id).

So it seems space is out as a possible delimiter.

[domenic]

There's no problem with adding new interpretations of fragment parameters to how browsers process HTML documents. We'd just update this section of the HTML standard ("For HTML documents (and HTML MIME types), the following processing model must be followed to determine what the indicated part of the document is."). It's not a luxury, just an easy change to make, like the many other hundreds of PRs that have been accepted to the HTML Standard.

[BigBlueHat]

@domenic great to know this sort of thing is something the WHATWG is open to considering adding.

Would scoping the use of any new (non-named section) fragment identifier(s) to a syntax that includes () (from XPointer and svgView() etc) be a good place to start?

There certainly seems to be historic and current interest in this sort of feature.

Thanks for the input @domenic.

[domenic]

No, I don't think we should restrict the semantic space like that. The proposal's use of a key=value syntax has several nice properties, as well as strong precedent in other media types and even in HTML via the media fragments spec. There may be reasons to consider a different syntax but we certainly shouldn't rule out the proposal as it stands.

[BigBlueHat]

@domenic not meaning to rule it out, it just reads as "parameters" (by definition) vs. a type of selection.

There's a table in this section of the Web Annotation Data Model spec (scroll down to second table) that has some examples of existing fragment identifiers.

Media fragments, for one, uses parameter style identifiers (i.e. xywh=50,50,640,480) to choose across it's predefined fragment dimensions.

SVG's viewBoxhttps://www.w3.org/TR/SVG11/coords.html#ViewBoxAttribute on the other hand defines a specific selector system--in addition to namedSection (as in HTML, etc) selection. The XPointer style syntax makes it clearer (imo) that the selector contained has unique semantics:

#svgView(viewBox(0, 0, 32, 32))
vs.
#icon-heart-view

as seen in this demo/article: https://css-tricks.com/svg-fragment-identifiers-work/#article-header-id-2

Since namedSection selection is what HTML does now, it would be my expectation given patterns seen across many other fragment identifier systems, that any new HTML selector system would follow that pattern and express a new "type" + selectors (and/or parameters) wrapped inside parenthesis (as SVG has done already).

Here are some XPointer Framework style selector options which map into existing selection systems in HTML: https://jsbin.com/cobukaf/edit?console,output

Console will output return values of each upon hash change (so you might have to click around a bit...).

[domenic]

Thanks for the overview. I understand that's your expectation, but I don't really share it personally.

[BigBlueHat]

@domenic regardless of differing opinions, would the WHATWG consider a proposal similar to what I've drafted in that JSbin link? https://jsbin.com/cobukaf/edit?console,output

[domenic]

See https://whatwg.org/working-mode#additions. The key thing is multi-implementer support; the proposal in this repository has one implementer at least. I'm not sure how many yours has.

[BigBlueHat]

@domenic one so far 😄--see WileyLabs/fragment-based-selection and its demo.

Currently supported fragment identifier "types" are #querySelector(), #querySelectorAll(), and #evaluate() (for XPath).

I'm also currently exploring the Selectors and States approach which is a bi-directional, 1-to-1 mapping to the selector system in Web Annotation Data Model (for which there's a converter). It's more verbose, but does have a growing list of implementations:

• Apache Annotator
• the Precise Links Web Extension
• and dokie.li (ex: #selector(type=TextQuoteSelector,exact=Annotations)

[domenic]

Sorry, to be clear, the WHATWG specifies features to be implemented by browsers, so browsers are the implementers I am referring to above.

[BigBlueHat]

@domenic you mentioned that "the proposal in this repository has one implementer at least" but I'm not finding which browser implements it. I'd understood that the WHATWG was open to polyfills as a way to present potential specifications, is that no longer the case?

[domenic]

See https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/aKI6doxffgQ.

Polyfills are definitely interesting and helpful when presenting specifications! However, they don't meet the implementer interest criteria for adding something to a standard; that's all I was saying.

[BigBlueHat]

@domenic thanks for that link. It wasn't clear from this repo (nor @bryanmcquade's GitHub user info) that this was a Google-backed spec that was on its way into Chrome.

Given that backstory, my concerns remain, but my ability to influence this potential Web feature's future is now curtailed by the fact that I don't work for a browser vendor and don't (consequently) have "commit bit" on an implementation. Which leaves me what options for participating in this process (asking sincerely, because I'd like to understand how this actually works in practice)?

[domenic]

In general everyone is welcome to have and contribute standards discussions, as you have been doing so far, before we got into these meta-points. That's a good way to influence standards, and everyone has these discussions together, browser vendor or not.

On the other hand, the standards process is not meant as a mechanism for forcing browsers to ship things against their will, which is why it's important to have support from (multiple!) implementers for proposals before merging them into a spec.

[csarven]

@domenic re https://github.com/bryanmcquade/scroll-to-css-selector/issues/5#issuecomment-391489271 , I'm genuinely curious: when you say browsers, are you referring to a specific / identifiable list or any?

What constitutes a significant browser implementation? Can it be specified along the following dimensions: developers, users, platforms, devices, features, conformance.. What are the thresholds for each? If there is documentation on this already, can you please point me to it?

[annevk]

@csarven https://whatwg.org/sg-agreement#qualifying-entity.

[hax]

It seems WHATWG is very like a Trust of 4 players (google, apple, mozilla and microsoft), because as the "Qualifying Entity" @annevk gave, even the other browsers in the caniuse list: UC (alibaba), Samsung, QQ (Tencent), Baidu will never be qualified.

Not to mention other inferior "implementations" like non-browser software (eg. Apache Annotator), browser addon/extensions (eg. the Precise Links Web Extension), web services (eg. dokie.li), polyfills...

And WHATWG already ordered W3C to hand over HTML/DOM spec to them at all... Yes, everyone still can join the discussion, but only the Trust can make decision. Fine.