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

The CSS Working Group just discussed Ambiguities in handling url(), and agreed to the following resolutions:

```
RESOLVED: mask-image distinguishes element reference vs image reference via local vs external reference in url()
```

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

```
<astearns> topic: Ambiguities in handling url()
<astearns> https://github.com/w3c/csswg-drafts/issues/383
<leaverou> https://github.com/w3c/csswg-drafts/issues/383
<astearns> github issue: https://github.com/w3c/csswg-drafts/issues/383
<fantasai> Github topic: https://github.com/w3c/csswg-drafts/issues/383
<leaverou> relevant TPAC minutes where this was discussed: https://lists.w3.org/Archives/Public/www-style/2016Nov/0070.html
<fantasai> TabAtkins: Everybody remembers issue from awhile ago -- it's ambiguous whether an URL with a fragid is referencing an element in the SVG or a pant server /mask whatever
<fantasai> TabAtkins: Everything is bad, and it's been bad since 2012 when issue was first raised by roc.
<fantasai> TabAtkins: Going forward we wanted to rely on element() vs image() functions to make it clear
<fantasai> TabAtkins: But still need to figure out what to do with url() legacy
<fantasai> TabAtkins: Unclear whether that should be property-specific, language-specific, something else
<fantasai> TabAtkins: Looking at TPAC minutes
<fantasai> TabAtkins: Some proposals
<fantasai> TabAtkins: 1. Treat ambiguous cases as url reference into an SVG document, not treat as image and apply :target
<fantasai> TabAtkins: 2. Treat ambiguous cases as url, if it has a fragID treat as a reference, otherwise treat as an image
<fantasai> TabAtkins: 3. Treat ambiguous cases, load it twice -- first see if there's an appropriate reference, otherwise go back and reload as an image
<fantasai> fantasai: 4. Do something different per property
<fantasai> plinss: #3 follows Web architectural principles better. Shouldn't judge URL by its syntax.
<fantasai> s/syntax/syntax like in #2/
<fantasai> Florian: #1 and #4 also don't violate principle
<fantasai> plinss: Could be a PNG at the end of a URL. You don't know
<fantasai> leaverou: Why would an author use a fragID on a PNG?
<fantasai> plinss: To crop a section of the PNG
<fantasai> plinss: We made image() function to make this unambiguous
<fantasai> TabAtkins: On the other hand, implementatiosn really don't want to load things twice
<fantasai> TabAtkins: Chrome and FF seem to decide on reference vs image based on whether it's local fragment vs external reference
<fantasai> TabAtkins: Could probably just switch on that, and then later introduce element() vs image() functions
<fantasai> TabAtkins: Might need more info from birtles
<fantasai> fantasai: I'm okay with distinguishing based on local vs external reference
<fantasai> TabAtkins: No browser currently allows external SVG references
<fantasai> dbaron: Gecko does in some cases, maybe not in CSS.
<fantasai> leaverou: Should not assume they never allow external SVG references
<fantasai> TabAtkins: Yeah, just don't need to consider it wrt web-compat
<fantasai> jet: We do for mask
<astearns> s/mask/clip-path/
<fantasai> dbaron: Most ambiguous case is mask
<fantasai> dbaron: But I thought we did for clip-path, filter, and mask
<fantasai> TabAtkins: mask is the only one that's troublesome atm
<fantasai> TabAtkins: Everyone else can define per property
<fantasai> TabAtkins: If a property only takes images, or only takes clip paths, not ambiguous
<fantasai> TabAtkins: Didn't want to do per-property decision for ambiguous cases
<fantasai> fantasai: Some of these properties that are currently unambiguous, maybe become ambiguous in the future
<fantasai> fantasai: So in the future, would be per-property disambiguation
<fantasai> TabAtkins: So when you said you handle external mask references, is that just for mask property that only accepts external references?
<fantasai> dbaron: We parse the mask property into longhands, so we would do it on mask-image, becaue that's where it lives
<fantasai> TabAtkins: How do you split mask-image into the two different cases?
<fantasai> TabAtkins: afaict, you did it based on whether local or not
<fantasai> fantasai: I think fill/stroke has (or will have) ambiguous cases.
<fantasai> ...
<fantasai> TabAtkins: Right now element() and image() hav other features, which is why were kicked out to L4
<fantasai> leaverou: element somewhat impl in Firefo
<fantasai> TabAtkins: We could though define them as subset of the functionality, i.e. same as url() except without ambiguity
<fantasai> fantasai: fill currently takes a paint server reference, we'lre adding image references, so it will become ambiguous
<fantasai> leaverou: Option 3 is off the table?
<fantasai> TabAtkins: Yeah, because cost-prohibitive
<fantasai> leaverou: #2 is only a problem cuz web architecture?
<fantasai> plinss: blatant violation of web architecture
<fantasai> fantasai: what about local ref vs external reff?
<fantasai> plinss: Not so bad
<fantasai> astearns: Sound sto me that 1 is only viable option
<fantasai> Florian: Well, 1 and 3?
<fantasai> s/3/4/
<fantasai> Florian: We will have to define property by property going forward
<fantasai> Florian: We do #1 on currently-ambiguous cases, but will have to define property by property going forward
<fantasai> TabAtkins: E.g. fill/stroke previously unambiguous, becoming mbiguous with new fill-stroke spec
<fantasai> astearns: So in cases where it coudl be interpreted as either, it will be ?
<fantasai> TabAtkins: Alternately could make it local vs external, like mask-image
<fantasai> fantasai: For mask-image, what are the possible things we could actually do?
<fantasai> TabAtkins: depends on what FF is doing and if compat-required
<fantasai> TabAtkins: I think local vs external is def how Webkit/Blink does it, and it's how Gecko used to work
<fantasai> birtles: Still
<fantasai> fantasai: So sounds like we *have* to do mask-image that way.
<fantasai> fantasai: Should we resolve on local vs non-local?
<fantasai> leaverou: Makes sense now because external reference aren't possible
<fantasai> fantasai: but we will have unambiguous syntax for that
<fantasai> leaverou: but by adding a fragID, author made their intent clear
<fantasai> TabAtkins: No, they didn't, because e.g. might be using svg stacks where fragID is triggerng :target
<fantasai> plinss: Can use a media frag to pull a frame out of an MP4
<fantasai> leaverou: ok...
<birtles> fwiw the Firefox code I'm looking at is http://searchfox.org/mozilla-central/rev/214345204f1e7d97abb571b7992b6deedb5ff98f/layout/style/nsCSSDataBlock.cpp#64 which at least indicates we don't trigger an image load if it's a local reference
<leaverou> s/leaverou: ok.../leaverou: ok/
<fantasai> dbaron and birtles investigate Gecko code
<fantasai> astearns: First proposed rsolution is distinguish these cases on mask-image via local vs external reference
<fantasai> astearns: which matches implementations, as far as we can tell
<fantasai> astearns: any objections?
<fantasai> dbaron: I'm not sure if that's actually happening. Things are fancy here.
<fantasai> dbaron: not sure if it matters
<fantasai> RESOLVED: mask-image distinguishes element reference vs image reference via local vs external reference in url()
<dbaron> The point where we actually branch between the SVG vs. image-tiling case is in the function PaintMaskSurface in nsSVGIntegrationUtils.cpp...
<dbaron> And as far as I can tell that's just a function of whether a pointer is null, which is null as a function of whether we managed to find an SVG Mask Element...
<fantasai> TabAtkins: I'm betting we could apply local vs externa globally, on account of local hash bg images are broken right now anyway, unless your HTML is also a PNG
<fantasai> leaverou: what about hashes on data URL? If SVG was in a data URL, and has a hash?
<fantasai> TabAtkins: That's still an external URL as far as loading pipeline is concerned
<fantasai> leaverou: I suspect that's something I've used...
<dbaron> the thing that it's testing for null was set up in the constructor nsSVGMaskProperty::nsSVGMaskProperty(
<fantasai> astearns: For second istance?
<fantasai> fantasai: second instance is now, fill-stroke
<fantasai> astearns: Maybe wait until we have more info?
<fantasai> astearns: e.g. dbaron figuring out gecko code
<fantasai> xidorn: Person who implemented mask-image says we do check if target element is mask element after we load the file
<fantasai> fantasai: Question is, afte ryou check it and it fails the check, what do you do?
<fantasai> dbaron: I suspect we do two loads
<fantasai> plinss: Don't want to require impls to all do hardest least performant thing, but don't want to preclude doing it correctly
<fantasai> astearns: Seems we have t leave this one for now
<fantasai> dbaron: Anyone have a technique for making a file that's both a valid SVG and a valid PNG?
<fantasai> Florian: I don't but I know who would
<fantasai> dbaron: Might be able to test SVG as SVG
<fantasai> Florian: If you need, try p01 on twitter, he makes crazy demos
<fantasai> dbaron: I think we just need an SVG that's a circle and a mask that's a square
```
</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-295173229 using your GitHub account

Received on Wednesday, 19 April 2017 08:58:16 UTC