Open rniwa opened 5 years ago
All right seems like the webapps people were pretty united on this a few years ago, so I've gone ahead and made this change.
Re-opening for CSSWG resolution.
Note testcase which shows that Firefox and Blink are currently honoring <base href=...>
when resolving fragment URLs, but WebKit does not.
The CSS Working Group just discussed [css-values] Clarify fragment URLs resolve against the current tree, not document tree
.
I'm not sure I understand the minutes. @Emilio or @astearns would you mind elaborating?
The idea here is that you want to have a same-node-tree reference, essentially id(foo)
, but all we have is url()
so the plan was that url(#foo)
would have special semantics (i.e., whenever the url()
argument starts with #
) and end up being a local reference. This would allow various SVG and CSS features to work better inside shadow trees.
Because to be clear, if they are not treated as local references, you can only target nodes in the main document tree, not the shadow tree.
Yeah, I'm not sure I understand what was being argued here either (I unfortunately had to miss this meeting).
@annevk @tabatkins my point was that there are two orthogonal issues:
<base>
is respected or we should just ignore and treat as local refs.I guess you would be opposed to honor <base>
and lookup inside shadow trees if the document uri matches?
Your first question was resolved back in the day, when we discussed this original behavior and I added the "local url" flag. Browser support was uncertain at the time but it was considered desirable to make the fragment URLs local-only.
The only new question was whether they were truly fragments resolved against the current page (thus only capable of resolving to IDs visible in the topmost light DOM) or if they were tree-specific (so you could target IDs in your shadow). The Webapps folks seemed reasonably consistent in wanting the latter, and that made sense to me, so I updated the spec here.
Apologies for not being around to introduce the topic properly, this was meant to just be a review of the most recent change for box-ticking purposes, not a relitigation of the earlier discussions.
I guess you would be opposed to honor
<base>
and lookup inside shadow trees if the document uri matches?
Yeah that breaks encapsulation.
The CSS Working Group just discussed [css-values] Clarify fragment URLs resolve against the current tree, not document tree
, and agreed to the following:
RESOLVED: ID-Fragment-only URLs use tree-scoped reference mechanics
RESOLVED: bring back text for WG review
Okay, new text committed as a result of the WG discussion - fragment-only URLs are now explicitly treated as tree-scoped references, with the set of IDs in the tree as the associated tree-scoped names.
This implies that x-foo::part(foo) { mask: url(#foo); }
will resolve to the element with id=foo in the light DOM, regardless of what IDs are used inside the shadow, while <div part=foo style="mask: url(#foo)">
inside the shadow will resolve to the element with id=foo in the shadow. (But if there is no such element, it'll walk up to the light and look for the ID there.)
For the question of what to do with Media Fragments and similar non-ID fragment syntaxes, I'm currently just treating them identically to anything else - I try to find an element with a matching ID and if it fails (as it almost certainly will) it fails as normal, and is treated the same as if #foo
wasn't in the document.
This probably needs some more work to make this good. In particular, this doesn't work properly with fragment directives - url(#foo:~:text=foo)
will search for an element with id="foo:~:text=foo"
, rather than stripping the directive. I've opened an issue (https://github.com/WICG/scroll-to-text-fragment/issues/198) to get an algo exposed for doing that easily.
Anything else the WG thinks is still wrong, or needs to be added?
If the intention of this special behavior is to apply this to ID fragments, then scope it to ID fragments. There are other types of fragment identifiers, scroll-to-text-fragment is only one, see e.g. https://www.w3.org/TR/media-frags/ for some others. In general URL fragments are an extension point. Even if we special-case some things, we need to define their generic behavior in a way that's going to work generically.
If the intention of this special behavior is to apply this to ID fragments, then scope it to ID fragments.
I would if I could. The problem is that as far as I can tell, there isn't a well-defined notion of "ID fragments".
The CSS Working Group just discussed [css-values] Clarify fragment URLs resolve against the current tree, not document tree
.
Agenda+ to review the latest spec text: https://drafts.csswg.org/css-values-4/#local-urls
The CSS Working Group just discussed [css-values] Clarify fragment URLs resolve against the current tree, not document tree
, and agreed to the following:
ACTION: fantasai ask ryosuke to review
RESOLVED: Accept edits
Right now, section 4.4.1.1. fragment URLs say that:
We text should be updated to refer to the current tree so that when the local url flag is set, the fragment is resolved against the current tree.