Re: [csswg-drafts] [css-images][css-masking][paint] Ambiguities in handling url()

The CSS Working Group just discussed `Update on URL function discussions`, and agreed to the following resolutions:

* `RESOLVED: Should treat ambiguous cases, load it twice -- first see if there's an appropriate reference, otherwise go back and reload as an image`
* `RESOLVED: Implementations should treat 1ambiguous cases, load it twice -- first see if there's an appropriate reference, otherwise go back and reload as an image`
* `RESOLVED: For ambiguous cases, UAs SHOULD first see if there's an appropriate reference, otherwise go back and reload as an image`

<details><summary>The full IRC log of that discussion</summary>

```
<Rossen> Topic: Update on URL function discussions
<myles> plinss: url() - do they resolve to images or elements?
<myles> plinss: we had 4 options
<dbaron> https://dbaron.org/css/test/2017/mask-url
<myles> plinss: David looks into what Firefox does. But our resolution is contrary to that. We want to revisit to allow Firefox
<myles> dbaron: Firefox treats mask image with a URL. If it has a hash, we will look for a ref in it, whether its local or remote
<plinss> present+
<myles> dbaron: so, there are some cases where we will try to load it twice. If there is no hash, we don't attempt to look for a mask element, and load it as an image. If it's purely a local ref, we don't' attempt to load it as an image - we will only find a mask URL. But if it has a hash in the middle, we'll load it both ways.
<myles> fantasai: This is an optimization of loading twice in general
<myles> fantasai: a local reference is not going to be an image
<myles> dino: why not?
<myles> dino: it could be an SVG image, or a SVG root, or a canvas
<myles> dbaron: we dont' want infinite recursion
<myles> TabAtkins: pointing to canvases isn't allowed at all anywhere
<myles> dino: Someone might do it
<myles> dino: We could point as an image element in the document and using it as a mask
<myles> leaverou: that's not allowed
<myles> ChrisL: this is imaginary
<myles> dbaron: the mask property used to point to a mask element but we extended it to point to image
<myles> dbaron: when we do this, we ignore the other masking properties like mask-repeat, etc.
<myles> ChrisL: this is according to the spec, rights?
<myles> dbaron: i think so
<myles> leaverou: So, it's possible to have the Firefox implementation from the spec?
<myles> leaverou: We all agree that this is the most reasonable choice
<myles> Rossen: Can someone summarize what is going on?
<myles> plinss: You should know what's going on
<myles> leaverou: Hey tab, please type in the options again
<plinss> https://log.csswg.org/irc.w3.org/css/2017-04-19/#e796988
<leaverou> 1. Treat ambiguous cases as url reference into an SVG document, not treat as image and apply :target
<leaverou> 2. Treat ambiguous cases as url, if it has a fragID treat as a reference, otherwise treat as an image
<leaverou> 3. Treat ambiguous cases, load it twice -- first see if there's an appropriate reference, otherwise go back and reload as an image
<leaverou> 4. Do something different per property
<myles> leaverou: ❤️
<myles> dino: what does "ambiguous" mean?
<myles> plinss: if the property can handle both an element and an image, and the URL could be either
<myles> plinss: can we resolve to make this decision on whether it's a local or external URL?
<myles> myles: Firefox does 3, right?
<myles> leaverou: Basically. With some extra optimizations
<myles> plinss: Architecture says that you can only interpret what a fragment means until you get a content-type from the response
<myles> dbaron: The case where Firefox doesn't do the right thing is when there is a base URL and a url(#foo)
<myles> dbaron: This is probably not the only case where this occurs
<myles> dbaron: like <a href="#foo"> scrolls within the current document
<myles> TabAtkins: CSS always treats a #url as a reference into the local document
<myles> plinss: That is a separate issue and an architectural violation
<myles> plinss: At the end of the day, I'm okay with browsers not handling everything exactly b/c of optimizations. What I'm not okay with is the spec stating you must violate architectural principles and Gecko must stop doing what it's doing
<myles> Rossen: Other thoughts?
<myles> Rossen: Proposed resolution: a mixture of #2 and #3
<myles> fantasai: By choosing to follow Moz behavior, you are deciding tha ta local reference will always be an element reference and not an image reference. Which is fine, but we should be explicit.
<myles> fantasai: We always have our image() and element() functions which can make the distinction
<myles> ChrisL: so you're not losing anything
<myles> TabAtkins: We know the content type of the current resource, so we can interpret the hash correctly
<myles> TabAtkins: I need confirmation from our loading people that this is implementable
<myles> TabAtkins: we will try
<myles> plinss: I'm okay with "should" or "must (but we know you won't)"
<myles> Rossen: "should" please.
<myles> Rossen: Proposed resolution: Option #3 with "should"
<myles> TabAtkins: 👍
<myles> TabAtkins: (summarizes proposed resolution)
<leaverou> RESOLVED: Should treat ambiguous cases, load it twice -- first see if there's an appropriate reference, otherwise go back and reload as an image
<myles> RESOLVED: Implementations should treat 1ambiguous cases, load it twice -- first see if there's an appropriate reference, otherwise go back and reload as an image
<dbaron> Github issue: https://github.com/w3c/csswg-drafts/issues/383
<leaverou> RESOLVED: For ambiguous cases, UAs SHOULD first see if there's an appropriate reference, otherwise go back and reload as an image
<myles> Thanks leaverou
<myles> Rossen: RESOLVED: Let's stop resolving
```
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/383#issuecomment-295987911 using your GitHub account

Received on Friday, 21 April 2017 00:37:07 UTC