[css-images][css-masking][paint] Ambiguities in handling url() #383
Comments
|
FYI: I wrote up detailed URL-handling rules for SVG 2 as part of the overhaul of use-element handling. I tried to be consistent with CSS/FX specs (particularly Masking) to the extent that they had any guidance, but if you're adding new guidance you may want to review that section and make sure we're still consistent. Key parts that are relevant to CSS:
I was only focusing on I like the idea of using functions to clarify which way you want to interpret the reference. I'm slightly concerned about confusion with the other use of I'm not too keen on having different rules for CSS-defined properties vs SVG-defined properties. That just seems like grounds for confusion. I realize there is a theoretical backwards-compatibility issue when allowing SVG paint servers as a CSS image type (a URL that would formerly be interpretted as an SVG image with :target styles now being interpretted as a paint server reference), but I think it is exceedingly rare in practice that :target styles are tied to a paint server element. The bigger concern would be whether there are substantial performance impacts from parsing the document to identify the element before deciding to treat it as an image: i.e., can implementations switch from "effects" mode to "image" mode without repeating the basic parsing & DOM construction? |
|
Hmm, so yeah, that's rather inconsistent with our earlier plans for CSS. :/ This is gonna need some discussion. |
|
(removing label because this is already on the TPAC agenda) |
|
This is a big, long-term-strategy issue, so I appreciate that you're giving it extra thought. But FYI, we're aiming to get SVG 2 published as CR before TPAC, so requests to change anything normative will be a bit of a pain after that. (Oh, and I won't be at TPAC myself, but do ping me if you have any questions about the SVG side.) |
|
After TPAC discussion:
Extra detail: it looks like Chrome and Firefox do the split based on "local fragment" vs "otherwise". This means that external links, frag or no, are treated as image. Need more detail. /cc @birtles |
|
Re which properties currently have image-vs-element ambiguities: Marker does not accept a plain image type, so there's no ambiguity there. Ambiguous URL properties I've noted that are currently supported in at least some browsers are In other words, |
|
By the way, one other detail I clarified in the SVG linking spec is that element references can be in any document that can be parsed as a DOM. I.e., you can link to an element in an HTML doc, not only an SVG doc. This is of course already supported in all the browsers for same-document references, but it was not defined for external references. That shouldn't add too much confusion on this issue, but it means that in some cases there won't be a valid image interpretation of a file if the element reference interpretation fails. |
|
Minutes from TPAC discussion on this issue: https://lists.w3.org/Archives/Public/www-style/2016Nov/0070.html |
|
The CSS Working Group just discussed Ambiguities in handling url(), and agreed to the following resolutions: The full IRC log of that discussion |
|
We're also gonna go ahead and use local/external as the determiner for the now-ambiguous fill/stroke properties. And we might be able to do it globally:
|
|
We didn't actually resolve on anything except mask-image. |
|
Wait, does this mean that you won't be able to use SVG mask elements in an external file? That is tragic. I'm pretty sure it's supported in at least Firefox, maybe Edge.
|
|
And for fill & stroke, again references to another file are currently only supported in Firefox, old Presto, and Edge under certain possibly accidental conditions. But I was really hoping that a consistent model with CSS URL references would lead to browsers fixing that. It seriously limits the ability to create re-usable assets for inline SVG icons if you need to copy & paste (or PHP include, or whatever) your gradients into every page of the website. |
|
The CSS Working Group just discussed
The full IRC log of that discussion |
|
The last resolution is the actual one |
That would be "RESOLVED: Let's stop resolving" ?
So, does this mean that my URL-resolution algorithm from SVG 2 is still valid? Although, now I read it again I realize that I should have been more clear that there are two cases for what to do if a target element can't be located, depending on whether it is a same-file vs different file references.
|
|
I thought I mentioned this on www-style a few years ago but I can't find it now: I had come to the conclusion that the way to resolve this issue was to unify the image-loading path with the element-reference path, basically by eliminating the latter. You would use the image-loading path, and if you happened to load an SVG image and the fragment reference points to the right kind of element, you would use that instead of rendering the image. (Document self-references would continue to be special-cased.) This depends on the browser being able to "punch through" the image-loading-and-rendering abstraction to access the underlying image's DOM, but I guess that's not a problem in practice. This would mean that "external resource documents" are subjected to the constraints of SVG image documents, e.g. they can't contain external references of their own. That seems like an insignificant loss in practice, unless Web-compat issues have developed. |
|
@Krit You'll need to update css-masking with something like the following: |
|
OK, Agenda+ to confirm a few things
|
|
@fantasai I clearly should register @Krit :P The change to masking looks fine to me. |
|
The reasoning was because browsers might not be able to "back out" of the resource-loading path to treat it as an image, and vice versa. |
|
@tabatkins So now it is up to the UA to reload or reuse/reinterpret the resource depending on the UAs own requirements? Also, agree with @rocallahan that we should load an element reference document with the same restrictions as an |
Yeah.
That's now tracked by #4152. It's a more general issue than just ambiguous URLs. |
|
The CSS Working Group just discussed
The full IRC log of that discussion<dael> Topic: Ambiguities in handling url()<fantasai> it says "fallback rendering" <dael> github: https://github.com//issues/383 <fantasai> Because what the fallback is varies, not all images are replaced elements <TabAtkins> https://github.com//issues/383#issuecomment-513416574 <dael> TabAtkins: This comment has the questions ^ <fantasai> some of them are in 'content' or 'list-style' or 'background-image' <dael> TabAtkins: This is handling the cases where like in mask-image a URL might be an element in a doc or a doc as an image. Defined ambig image URL that can be used in this situation. <dael> TabAtkins: Defined from the discussion where conclusion was load both ways. Check for an element to be reference and if there isn't load it as an image <dael> TabAtkins: Want to request review of text as written. <dael> TabAtkins: Specific questions: resolution didn't call out fragment-only URLs. Loading those as an image is just the same document. I suspect they should always be element references. <dael> TabAtkins: We resolved with should rather then must. I wrote as a must b/c didn't seem to have a good reason to diverge. Wanted to confirm if it is a should or a must. <dael> TabAtkins: Fragment only URL. Does it make sense for it to ever try and load as an image? Else will spec they're reference only. <dael> nigel: Strange use case, TTML. Images can be referenced by fragment URL. I'm not convinced this is same use case. Words sound similar. <dael> TabAtkins: Same use case. But talking about an SVG pointing to itself with a fragment. Not pointing to something else. <dael> nigel: Is the same where fragment pointing to defines contents of image to display <dael> fremy: But then you're pointing to element in same document with an ID. BUt not loading entire document <tantek> right it's an IDREF <dael> TabAtkins: If pointing to a thing inside it's an element reference. Not loading whole file again to render as image. <dael> AmeliaBR: IN that case it is being used as an element reference. The only case where you have a hash reference and doing weird thigns with SVG. I have in SVG an example where I call out that if you use a hash only URL in a property that only expects full files you will get correct doc as a full image file <dael> TabAtkins: Fine b/c not ambig URL <dael> AmeliaBR: That's not an ambig situation nor a realistic use case for ambig references <dael> TabAtkins: THat's something that takes an image not an image or reference. That's cool and not relevant here <AmeliaBR> s/weird thigns with SVG/weird things with SVG views/ <dael> fantasai: I think nigel case needs to calle dout more carefully. You are pulling out a refereance to an element, but for mask image a reference is pointing to an element. nigel case you're pulling out the element but then using as an image type, not a mask-eleemnt type. Treated as an image. Element reference we're pulling out of document. <tantek> what if the element is a picture element or has multiple srcs etc <dael> TabAtkins: Seems fine. It's reasonable to have element reference for an image denotated by elements pointing to. THis is different then loading whole file as an image <dael> fantasai: For mask-image an image type you treat as an image and use alpha to turn into mask. mask-element is an element. referring to an image you can't use as a mask-eleemnt <dael> TabAtkins: Right. mask-element...mask-image defines it must be a mask. nigel use case in TTML would define the reference element can be whatever image defining element is. Use cases define what's a valid reference element. here's no ambiguity there <dael> AmeliaBR: What talking about now is if element you reference is not valid in property making reference what do you do. Always relative to context of the reference as to if the element is valid <tantek> or what if the subresource it points to defines *multiple* images? <dael> nigel: If the URL used to point to image but sub-resource in document isn't defining an image. In that case what should you display. Is that it? <dael> TabAtkins: Yes and the text is you just load the whole document as an image. Hopefully it's a SVG and it works. If not you wrote bad CSS. <dael> nigel: Will you go around circles forever doing that? <dael> TabAtkins: Not sure what's circular <dael> nigel: What I heard was try and load it, try and go there, find it's not right, try again <fantasai> I still think it's wrong. Nigel's case is "in TTML, you can refer to an <image> using a fragment URL to an element in the TTML document" <fantasai> If you wanted to use such an image as a mask-image <fantasai> You can't. <fantasai> Because we try to load it as a <mask> element, and it fails. <dael> TabAtkins: Trya nd load as a document, look and see it's type expected, then go back and load the whole thing as an image. Different state that does not trigger same rendering. And this is why fragment only which refers to same document we think should not try and fallback because that produces the circularity <dael> nigel: Okay, I'm with you <dael> smfr: I don't like the double load. Can we resolve this with a new function like URL but lets author state what they'd like. <dael> fantasai: Have image for that but no one implt <fantasai> s/image/image()/ <dael> TabAtkins: We did have that, but this is the resolution we came up with instead. Works fine with FF. DOn't know with the rest of stuff. <dael> Rossen_: You're fine with resolution? <dael> TabAtkins: I am, yeah <dael> Rossen_: Any other comments? Or try to resolve <dael> Rossen_: Objections to the proposed resolution? <AmeliaBR> Re TTML maybe wanting to use image references in mask: if there is demand for that, we can always add that to mask-image as a valid type of element reference. <dael> Rossen_: What's the actual resolution text? <AmeliaBR> The edited text: https://drafts.csswg.org/css-images-3/#ambiguous-urls <dael> TabAtkins: Does the text added look fine? Should match previous resolution <dael> Rossen_: Do the others hinge on this? If people need to review edits might have to move on. <dael> fantasai: I don't know if the sub issues need extra time. Can resolve on those and then edit main text <dael> Rossen_: Let's do sub issues <dael> TabAtkins: On the asummption that this text is good, do we want to treat fragment only URLs as only references, never images <dael> s/references/elements <dael> Rossen_: Objections? <dael> RESOLVED: treat fragment only URLs as only elements, never images <dael> fantasai: Resolved on using should, do we change that to a must? Not sure what you would do if disagree witht he should <dael> Rossen_: Objectiosn to change from should to must? <dael> RESOLVED: Change requirements from 'should' to 'must' <dael> Rossen_: Are those the sub issues? <dael> TabAtkins: That's it <dael> Rossen_: Back to main one. Do people need more time? Fine if you do. Otherwise we can resolve <dael> AmeliaBR: I looked through comments. Once case that doesn't disagree but maybe needs callout in spec. When you do ahve a same file hash only URL we're not causing any reload or fallback but there is a chance the hash might be invalid to start and valid later because DOM is mutated and an ID appears <dael> TabAtkins: That would be general css is stateless and things reflect current true <dael> AmeliaBR: Okay. Consistent with rest of resolution and no special fallbacks in that case <dael> Rossen_: Great. <fantasai> s/true/truth/ <dael> Rossen_: Do people need more time to review? Otherwise I'll call to resolve. <dael> Rossen_: Objection to adding the edits in https://drafts.csswg.org/css-images-3/#ambiguous-urls ? <Rossen_> https://drafts.csswg.org/css-images-3/#ambiguous-urls <dael> RESOLVED: Add the edits in https://drafts.csswg.org/css-images-3/#ambiguous-urls |
Back in 2012, roc raised this issue about an ambiguity in handling url()s that might refer to an image or an SVG element reference: https://lists.w3.org/Archives/Public/www-svg/2012Oct/0019.html In particular, giving a url like "mask-image: url(foo.svg#bar)", do we load that as an SVG image with a fragment of #bar, or do we load it as an SVG document and retrieve the
id=barelement (which might be a<mask>element)? This also infects all CSS-<image>-taking properties, if we let CSS refer to SVG paint servers.There was a lot of discussion and seemingly consensus, but nothing ever got formally decided, and several of the affected specs (Images, Masking, etc) weren't edited to take this into account. Let's fix that! The conclusion seemed to be:
image(), and the element interpretation by loading it aselement().This means that
background-imagecan only refer to a paint server by usingelement("foo.svg#bar"), whilemask-imagecan only use an SVG Stack by usingimage("foo.svg#bar").It also means that in our new attempt to define
fillandstrokefor CSS, it'll default fragment urls to being element references, as that's their current behavior in SVG.Let's please put this 4-year-old issue to rest - I can do the edits to the necessary specs.
The text was updated successfully, but these errors were encountered: