Re: [csswg-drafts] [css-values] Clarify fragment URLs resolve against the current tree, not document tree (#3320)

The CSS Working Group just discussed `[css-values] Clarify fragment URLs resolve against the current tree, not document tree`.

<details><summary>The full IRC log of that discussion</summary>
&lt;astearns> topic: [css-values] Clarify fragment URLs resolve against the current tree, not document tree<br>
&lt;astearns> github: https://github.com/w3c/csswg-drafts/issues/3320<br>
&lt;dandclark> fantasai: Short version of problem is there was resolution to change how fragment urls are handled when fragment url is changed.<br>
&lt;dandclark> fantasai: e.g. using rel tag. but most implementations don't follow that, so not sure if we want to keep. Need implementers to review.<br>
&lt;fantasai> s/rel tag/&lt;base href>/<br>
&lt;dandclark> fantasai: Different engines doing different things.<br>
&lt;dandclark> emilio: I think what FF and Blink do is consistent with other things. Like other specs, ??? and stuff that should behave consistently for base URI case.<br>
&lt;astearns> s/???/SVG/<br>
&lt;dandclark> emilio: Whatever we do should also check...is the WebKit behavior constent here?<br>
&lt;fantasai> https://www.w3.org/TR/css-values-4/#local-urls<br>
&lt;tantek> +1 emilio, what FF + Blink do seems both consistent and interoperable, can we resolve on that being what we want?<br>
&lt;dandclark> fantasai: Pasted link to what spec currently says.<br>
&lt;fantasai> fantasai: I'm not convinced this is what we want to do, and it's certainly not what's implemented.<br>
&lt;tantek> q?<br>
&lt;florian> q-<br>
&lt;dandclark> emilio: Resolving against ??? is a bit undefined I think. Also I'm pretty sure we don't use StyleSheet owner node.<br>
&lt;tantek> q+<br>
&lt;astearns> s/???/node tree/<br>
&lt;dandclark> emilio: I suspect blink does the same, so it's tricky<br>
&lt;dandclark> emilio: I guess that's the intention for ShadowDOM.<br>
&lt;astearns> ack tantek<br>
&lt;dandclark> tantek: I would flip question around. Are there objections/problems from web dev perspective to how it's implemented? If there are no problems, makes sense to resolve and move forward. Spec is behind, fix the spec accordingly.<br>
&lt;dandclark> fantasai: This is a change from L3 that was requested. Not convinced this is what we need to do.<br>
&lt;dandclark> tantek: I mean behind reality. THis has happened before.<br>
&lt;fantasai> I would say it differs from reality, it's not *behind* reality.<br>
&lt;dandclark> astearns: So the q is should resolve fragment against node tree or current tree?<br>
&lt;dandclark> emelio: The tree we're resolving against, is it correct? And are base URIs taken into account? I think they should be, agree w/ fantasai that it's weird they're not.<br>
&lt;dandclark> emilio: There's also trickiness in shadowDOM behavior.<br>
&lt;dandclark> emilio: Not sure we match with spec here.<br>
&lt;dandclark> s/emelio/emilio<br>
&lt;dandclark> astearns: I assume motivating bit is what we do with shadowDOM, given linked issues.<br>
&lt;dandclark> asteans: Don't know enough about this to have good idea of what direction to take.<br>
&lt;dandclark> fantasai: Might make sense to kick to f2f<br>
&lt;dandclark> tantek: To decide, is the methodology. Define from 1st principles or based on interoperable implementation behaviors. I'm OK with either approach but that's high level question to settle first.<br>
&lt;dandclark> astearns: Closing to take back up in a couple weeks. I will ping ??? to try to get more details.<br>
&lt;dbaron> s/???/ryosuke/<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-1317401796 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Wednesday, 16 November 2022 17:36:25 UTC