search

bryanmcquade / scroll-to-css-selector

Explainer for supporting CSS selectors when navigating to a URL fragment
61 stars 1 forks source link

Why not use XPointer compatible syntax? #1

Open hax opened 6 years ago

hax commented 6 years ago

This proposal make me recall the old XPointer spec: https://www.w3.org/TR/xptr-framework/ and the (not very old) proposal from : http://simonstl.com/articles/cssFragID.html , which is also mentioned in the end of README. I'm curious why not use the XPointer compatible syntax like @simonstl 's proposal?

domenic commented 6 years ago

Then browsers would have to implement XPointer, right? Whereas they already implement CSS selectors.

Crissov commented 6 years ago

Why would they have to support XPointer? Itʼs just about #css(…) vs. #targetElement=…, where there are apparently already implementations of the former. This proposal needs to better explain why it needs to reinvent the wheel.

Furthermore, the identifier targetElement does not seem like a sound choice because a Selector may match more than one node, which also does not need to be an element. Some implementations may be able to do something useful with a whole selection of text (and markup) instead of a void target anchor.

domenic commented 6 years ago

CSS selectors only match elements.

BigBlueHat commented 6 years ago

Then browsers would have to implement XPointer, right? Whereas they already implement CSS selectors.

I think the suggest of @hax was to use an "XPointer compatible syntax" (i.e. https://www.w3.org/TR/xptr-framework/#syntax ) as opposed to #targetElement= which reads more like a key/value pair than a "framework" for extensible selectors (on of which might be CSS).

Crissov commented 6 years ago

@domenic Only if you count pseudo elements as elements.

domenic commented 6 years ago

Sorry, I'll be precise: they only match elements when used in places other than CSS style sheet rule productions.

hax commented 6 years ago

Thank you @BigBlueHat for clarify my question.

@domenic I hope I would make my question clearer.

I never imagine there is any possibility browser vendors will implement the old XPointer specs, I'm just curious about the reason of the syntax choice because README mentions the old proposals.

For example, a fictitious reason could be "we don't choose XPointer compatible syntax because we browser vendors hate XML and never want developers associate it with the concept of XPointer."

PS. As an old developer, I will be very grateful if someone could disclose the dark history of XPointer specs --- why they were accepted as W3C recommendations but rejected by all browser vendors. Though this is totally unrelated to this issue. Thanks.