- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 30 Nov 2022 16:07:32 +0000
- To: public-css-archive@w3.org
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` <details><summary>The full IRC log of that discussion</summary> <emeyer> TabAtkins: Brought up a few weeks ago and wasn’t inroduced properly<br> <emeyer> …Several years ago, we discussed behavior of fragment-only URLs and how they react to the <base> element or Navigation API, chaning page URL, etc.<br> <emeyer> …They’re necessary for SVG references, and if they can be shifted, that can break things<br> <emeyer> …Fragment URLs are supposed to be special, if y ou write a fragment-only URL in they’re always resolved against the current document, regardless of URL situation<br> <emeyer> …Browsers were in several places at the time, but we decided this was a good place to go<br> <emeyer> …The question arose how this works in Shadow trees. Are fragment-only URLs resovled against the current document, or are they resolved against the tree they appear in?<br> <emeyer> …Web Components group thought it was most reasonable to resolve inside the current tree, I agreed<br> <Rossen_> q?<br> <emeyer> …Question is: is this okay that fragment URLs resolve against the current tree? Is the spec text okay or do I need to fix it up?<br> <emeyer> emilio: The current tree means the tree of the stylesheet that specified the URL, right?<br> <emeyer> TabAtkins: Yes.<br> <emeyer> emilio: That may be tricky with SVG <use> elements, which sucks<br> <emeyer> …Seems the most sensible, but it isn’t the current behavior of anyone<br> <heycam> q+<br> <emeyer> TabAtkins: No other behavior allows SVGs with references to work inside of a shadow tree at all<br> <PaulG> would this apply to text-selection fragments as well?<br> <emeyer> emilio: The tree of the stytlesheet makes more sense<br> <Rossen_> ack heycam<br> <TabAtkins> Essentially, treating fragment-only URLs as being tree-scoped<br> <PaulG> q+<br> <JakeA> q+<br> <emeyer> heycam: I can understand using this proposal<br> <Rossen_> ack PaulG<br> <emeyer> PaulG: Does this apply to text-fragment URLs, and is a web component has CSS and it uses fragment URLs, can that leak to other shadow DOMs and the parent document?<br> <heycam> q+<br> <emeyer> TabAtkins: For the first, the spec assumes only IDs exist, and I’ll clarify that this only applies to fragment URLs and doesn’t apply to other things like text-fragment<br> <fantasai> There's also #xywh= fragments etc. to worry about ...<br> <emeyer> PaulG: It sounds like will process such that CSS in a component could detect IDs in other trees<br> <emeyer> TabAtkins: Nope, the opposite<br> <TabAtkins> TabAtkins: If the stylesheet is in the shadow, it'll only see IDs in the shadow; if it's in the light, it'll only see IDs in the light.<br> <emeyer> JakeA: This wouldn’t change the scope of ARIA things like aria-describedby, yes?<br> <emeyer> TabAtkins: This is just about the CSS url() function<br> <emeyer> …This is why we need raw element references so we can reference across trees<br> <Rossen_> ack JakeA<br> <Rossen_> ack heycam<br> <emeyer> heycam: 1. It might be weird with the stylesheet relative thing when you look at computed style, now you have a state behind the computed value not represented by that style<br> <emeyer> …2. Have we considered an alternative approach where we change the way IDs get resolved by looking up the tree?<br> <emeyer> TabAtkins: 1. Yes, this does introduce state not expressed in the text. This is how we handle tree-scope references already and explicitly resolved to do it that way.<br> <emeyer> …If you set font family, it remembers the tree it was set in. If you read computed style in a shadow, you read it and set it back to the inline style, it will change that reference<br> <emeyer> …2. Automaticlly searching up trees is how tree scope works today<br> <Rossen_> q<br> <emeyer> …assuming i use the same behavior, you look up the tree and if you don’t find anything, you can maybe find things in the light<br> <emeyer> heycam: Ah, that’s different from how I was understanding things.<br> <fantasai> I think the spec doesn't currently express this nuance<br> <emeyer> TabAtkins: There’s still state. If you use a ::part, it will search in the light DOM, not the shadow<br> <emeyer> …If you explicitly inherit, that will capture the original tree it was set on. If it inherits into a shadow tree, it will still search the light tree.<br> <Rossen_> ack fantasai<br> <Zakim> fantasai, you wanted to ask about base URLs again; and also non-ID fragment references<br> <emeyer> fantasai: We’re binding the fragment to a tree, and inherting that binding. Need to make that clear in the spec.<br> <emeyer> …Also that it doesn’t just look in its own tree, it looks up trees.<br> <fantasai> ACTION: TabAtkins to clarify above<br> <emeyer> TabAtkins: I need to use tree-scoped references explicitly.<br> <emeyer> fantasai: In this text to handle ID fragments, you hadn’t considered other fragments. Wht do we anticipate what happens there?<br> <emeyer> TabAtkins: I don’t know, haven’t thought about it in detail. For ID references, we get this behavior, the rest are undefined.<br> <emeyer> fantasai: We have to define those<br> <fantasai> <!DOCTYPE html><br> <fantasai> <base href="http://example.com/"><br> <fantasai> ...<br> <fantasai> <a href="#anchor" style="background-image: url(#image)">link</a><br> <emeyer> …Other question: with base URLs, there’s an example (see above) which is resolved against one document and an image resolving against a different document<br> <emeyer> …Firefox and WebKit don’t handle this<br> <emeyer> …Do we actually want to change this behavior to something I think authors will find more confusing?<br> <emeyer> TabAtkins: This is based in an older decision and didn’t want to re-litigate it<br> <emeyer> fantasai: Do we want to keep going in this direction?<br> <emeyer> TabAtkins: We have to, or else SVGs in shadow DOMs will break and can’t be fixed<br> <Rossen_> q?<br> <emeyer> fantasai: Can’t you put a base in a component and have it resolve against that?<br> <emeyer> TabAtkins: Probably not. <base> is terrible old HTML we should discourage<br> <emeyer> fantasai: I do want confirmation from browsers that they still want this to be where we go<br> <fantasai> tescase: capable of resolving to IDs visible in the topmost light DOM) or if the<br> <emeyer> emilio: It seems okay from my point of view<br> <emeyer> heycam: I think it’s fine as well<br> <fantasai> testcase: https://www.software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cbase%20href%3D%22https%3A%2F%2Fxanthir.com%2Fpony%22%3E%0A%3Ca%20href%3D%22%23linky%22%20style%3D%22background%3A%20url(%23foo)%3B%20font-size%3A%202em%22%3Etest%3C%2Fa%3E%0A<br> <Rossen_> q?<br> <fantasai> s/tescase: capable of resolving to IDs visible in the topmost light DOM) or if the//<br> <TabAtkins> proposed resolution: ID-Fragment-only URLs use tree-scoped reference mechanics<br> <emeyer> RESOLVED: ID-Fragment-only URLs use tree-scoped reference mechanics<br> <fantasai> RESOLVED: bring back text for WG review<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3320#issuecomment-1332400370 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 30 November 2022 16:07:34 UTC