- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 31 Jul 2019 16:42:14 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `Ambiguities in handling url()`, and agreed to the following: * `RESOLVED: treat fragment only URLs as only elements, never images` * `RESOLVED: Change requirements from 'should' to 'must'` * `RESOLVED: Add the edits in https://drafts.csswg.org/css-images-3/#ambiguous-urls` <details><summary>The full IRC log of that discussion</summary> <dael> Topic: Ambiguities in handling url()<br> <fantasai> it says "fallback rendering"<br> <dael> github: https://github.com/w3c/csswg-drafts/issues/383<br> <fantasai> Because what the fallback is varies, not all images are replaced elements<br> <TabAtkins> https://github.com/w3c/csswg-drafts/issues/383#issuecomment-513416574<br> <dael> TabAtkins: This comment has the questions ^<br> <fantasai> some of them are in 'content' or 'list-style' or 'background-image'<br> <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.<br> <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<br> <dael> TabAtkins: Want to request review of text as written.<br> <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.<br> <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.<br> <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.<br> <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.<br> <dael> TabAtkins: Same use case. But talking about an SVG pointing to itself with a fragment. Not pointing to something else.<br> <dael> nigel: Is the same where fragment pointing to defines contents of image to display<br> <dael> fremy: But then you're pointing to element in same document with an ID. BUt not loading entire document<br> <tantek> right it's an IDREF<br> <dael> TabAtkins: If pointing to a thing inside it's an element reference. Not loading whole file again to render as image.<br> <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<br> <dael> TabAtkins: Fine b/c not ambig URL<br> <dael> AmeliaBR: That's not an ambig situation nor a realistic use case for ambig references<br> <dael> TabAtkins: THat's something that takes an image not an image or reference. That's cool and not relevant here<br> <AmeliaBR> s/weird thigns with SVG/weird things with SVG views/<br> <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.<br> <tantek> what if the element is a picture element or has multiple srcs etc<br> <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<br> <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<br> <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<br> <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<br> <tantek> or what if the subresource it points to defines *multiple* images?<br> <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?<br> <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.<br> <dael> nigel: Will you go around circles forever doing that?<br> <dael> TabAtkins: Not sure what's circular<br> <dael> nigel: What I heard was try and load it, try and go there, find it's not right, try again<br> <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"<br> <fantasai> If you wanted to use such an image as a mask-image<br> <fantasai> You can't.<br> <fantasai> Because we try to load it as a <mask> element, and it fails.<br> <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<br> <dael> nigel: Okay, I'm with you<br> <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.<br> <dael> fantasai: Have image for that but no one implt<br> <fantasai> s/image/image()/<br> <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.<br> <dael> Rossen_: You're fine with resolution?<br> <dael> TabAtkins: I am, yeah<br> <dael> Rossen_: Any other comments? Or try to resolve<br> <dael> Rossen_: Objections to the proposed resolution?<br> <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.<br> <dael> Rossen_: What's the actual resolution text?<br> <AmeliaBR> The edited text: https://drafts.csswg.org/css-images-3/#ambiguous-urls<br> <dael> TabAtkins: Does the text added look fine? Should match previous resolution<br> <dael> Rossen_: Do the others hinge on this? If people need to review edits might have to move on.<br> <dael> fantasai: I don't know if the sub issues need extra time. Can resolve on those and then edit main text<br> <dael> Rossen_: Let's do sub issues<br> <dael> TabAtkins: On the asummption that this text is good, do we want to treat fragment only URLs as only references, never images<br> <dael> s/references/elements<br> <dael> Rossen_: Objections?<br> <dael> RESOLVED: treat fragment only URLs as only elements, never images<br> <dael> fantasai: Resolved on using should, do we change that to a must? Not sure what you would do if disagree witht he should<br> <dael> Rossen_: Objectiosn to change from should to must?<br> <dael> RESOLVED: Change requirements from 'should' to 'must'<br> <dael> Rossen_: Are those the sub issues?<br> <dael> TabAtkins: That's it<br> <dael> Rossen_: Back to main one. Do people need more time? Fine if you do. Otherwise we can resolve<br> <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<br> <dael> TabAtkins: That would be general css is stateless and things reflect current true<br> <dael> AmeliaBR: Okay. Consistent with rest of resolution and no special fallbacks in that case<br> <dael> Rossen_: Great.<br> <fantasai> s/true/truth/<br> <dael> Rossen_: Do people need more time to review? Otherwise I'll call to resolve.<br> <dael> Rossen_: Objection to adding the edits in https://drafts.csswg.org/css-images-3/#ambiguous-urls ?<br> <Rossen_> https://drafts.csswg.org/css-images-3/#ambiguous-urls<br> <dael> RESOLVED: Add the edits in https://drafts.csswg.org/css-images-3/#ambiguous-urls<br> </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-516927986 using your GitHub account
Received on Wednesday, 31 July 2019 16:42:16 UTC