- From: Dael Jackson <daelcss@gmail.com>
- Date: Tue, 15 Nov 2016 20:56:26 -0500
- To: www-style@w3.org
=========================================
These are the official CSSWG minutes.
Unless you're correcting the minutes,
Please respond by starting a new thread
with an appropriate subject line.
=========================================
url() as image or SVG reference [css-values]
--------------------------------------------
- TabAtkins requested that the group resolve the discrepancy
between how CSS and SVG handle urls with a fragment.
There are various backwards- and forwards-compatibility
and architectural considerations involved
- TabAtkins came up with three alternative proposals:
1. For ambiguous cases, always treat url() as ref.
2. For ambiguous cases, introspect on URL; treat fragment as
ref, no-frag as image.
3. For ambiguous cases, load as document and see if it's
pointing to a valid ref; if not, load as image.
However,
1. has web-compat problems
2. breaks Web architecture assumptions
3. is expensive and given implementation's loading pipelines
====== FULL MINUTES BELOW =======
Agenda: https://wiki.csswg.org/planning/tpac-2016#agenda
Scribe: gregwhitworth
url() as image or SVG reference
-------------------------------
<astearns> https://github.com/w3c/csswg-drafts/issues/383
TabAtkins: So, trying to get this issue resolved on a call.
TabAtkins: 4 years ago Roc tried to resolve a url that points to a
frag ref in an SVG document.
TabAtkins: You might want to refer to it as a particular object or
an image.
TabAtkins: There wasn't a firm conclusion.
TabAtkins: But the consensus seemed to be that urls with a
fragment refer to a resource in the document, if not it
is an image.
TabAtkins: This allows you to cover most issues, but this causes a
small difference between CSS and SVG.
TabAtkins: I would like to resolve on anything, and I'll do
whatever spec work.
TabAtkins: Amelia said that SVG is thinking about doing some smart
stuff where it tries to resolve as a resource and then
fall back as image.
TabAtkins: The reason why we didn't want to do this was because we
have different paths based on what is being loaded.
dbaron: There may be some slight web compatibility issues, eg: svg
mask
TabAtkins: Yes mask would be expecting to look for a reference.
TabAtkins: Not entirely sure how much, but I'm sure there probably
are some.
Florian: In that case could you utilize the element() for
unambiguous issues?
TabAtkins: Don't worry about that.
dbaron: Though we do have an element function that does a
different thing for background-image.
dbaron: Is the CSS different than the moz version?
fantasai: Yes.
Florian: Yeah that's the one I was referring to.
TabAtkins: That only exists in Firefox.
<dbaron> so what background: -moz-element() does could be
background: element-image() or something like that
zcorpan: What do browsers do?
TabAtkins: Similar to what I stated, background-image refers to
image and mask refers to object reference.
TabAtkins: The mask spec is very badly defined on this matter as
they want to refer to them as either.
TabAtkins: Ideally we should match up the attribute and the
property.
tantek: Are there any tests?
TabAtkins: I didn't link to any here, but I could possibly dig
some up.
<tantek> could have test cases linked directly from
https://github.com/w3c/csswg-drafts/issues/383 ?
tantek: Yeah, could please put those in the actual GitHub issue.
TabAtkins: The complication is that, unless we changed more
recently we'll fail things that are external documents.
TabAtkins: At least we didn't do back in the day
TabAtkins: from css.
dino: I think it should be ok, I think if it's within SVG where
there becomes a problem.
shepazu: This is defined in SVG 2 in profiles
<shepazu> SVG 2 processing modes (security, etc.):
https://www.w3.org/TR/SVG2/conform.html#processing-modes
astearns: Can we make a decision today?
TabAtkins: If anyone is fine to resolve that's great, but if we
want to wait until later that's fine too.
Rossen: Are there any issues in SVG?
TabAtkins: They need to match with what we do.
Rossen: That's why I'm asking they're trying to CR SVG2
TabAtkins: Agreed, we need to get them as consistent as possible
and ASAP.
tantek: The folks that are looking at this, did they look at the
cursor properties?
TabAtkins: The cursor should be taking it as an image because it
can't take an external resource.
TabAtkins: That's the problem, everything in CSS refers to it as
an image, SVG where it can refers to a resource.
plinss: There is an architectural problem here that has bugged me,
we shouldn't do anything different only if there is a
fragment in the url.
tantek: If it's SVG you'll only know that if you go fetch it.
TabAtkins: Yeah, I think distinguishing it based on a fragment is
ok.
plinss: It could be anything.
plinss: Once you know what's there and it's a valid resource then.
plinss: I prefer the SVG approach.
plinss: Theoretically a sub resource of a PNG could grab another
image.
TabAtkins: Being able to re-interpret a document as an image if it
isn't the right type of reference.
TabAtkins: In our loading pipelines, how reasonable is that?
Florian: That wouldn't matter to a css prop that only takes an
image.
TabAtkins: Of course, only ones - like mask.
zcorpan: I don't really like that behavior, I'd prefer it to just
fail, makes it obvious to the author.
TabAtkins: If we don't do the fallback and we don't want to assume
anything in the URL then.
<TabAtkins> If prop takes <image>, treat it as image. If prop
takes <ref>, treat it as ref. If prop takes both,
treat it as ref; override with image() if you want.
<andrey-rybka> i agree with that
TabAtkins: I'm happy with that.
dbaron: So a prop takes both, basically makes mask, clip-path, etc.
dbaron: So if it takes both, treat it as a reference?
TabAtkins: Yes load it as a document and search for the reference.
dbaron: So you're saying that we should load all external
resources as an svg?
dbaron: People use mask today pointing to the PNG.
dbaron: Quite a lot.
dbaron: This will probably break a lot of stuff.
TabAtkins: That's what I was worried about.
TabAtkins: Probably similar to what Roc.
TabAtkins: <use> is just fine as it only takes ref()
Rossen: What about marker?
Rossen: It's not as used, but it should be similar.
TabAtkins: Assume it's a ref if it could be a ref or image.
Florian: Without a fallback?
TabAtkins: Yes, there is no fallback.
astearns: Restates his idea of the proposal.
<TabAtkins> 1. For ambiguous cases, always treat url() as ref.
<TabAtkins> 2. For ambiguous cases, introspect on URL; treat
fragment as ref, no-frag as image.
<TabAtkins> 3. For ambiguous cases, load as document and see if
it's pointing to a valid ref; if not, load as image.
<zcorpan> (1) is not web-compatible per dbaron. (3) is expensive
in impl because different loading pipelines
<astearns> 1 probably has web-compat problems, 2 breaks
architecture assumptions, 3 is expensive
fantasai: Here's an issue, if we take a prop that only allows an
image, and extend it to, e.g. handle paint servers, a
prop that wasn't ambiguous becomes ambiguous.
Florian: [lists all of the problems]
shane: Use a random page generator.
shane: Maybe implement all three.
leaverou: 2 seems the most obvious to authors.
fantasai: The image function isn't implemented by anyone yet.
Florian: Option 3 is stated that it's incompatible with how
browser's are implemented but is that still true.
<leaverou> fwiw, after Tab's comment re:SVG stacks, I'm leaning
towards 3 being least surprising for authors
TabAtkins: Do we still have a difference between loading something
as an image and an SVG image?
espreh: Yes, SVG is super weird.
TabAtkins: The option we're discussing [catches @esprehn up]
esprehn: I'd support the hash.
astearns: Even if the url redirects to a url with a fragment?
esprehn: This has to be determined early in the pipeline.
Florian: And it sounds author hostile.
dbaron: ok, I did find the gecko code to determine which loading
path.
dbaron: It gets the URL
dbaron: skips any chars that are control chars or space, and if
the first char found is a hash then it loads it as a
reference.
<dbaron> http://searchfox.org/mozilla-central/rev/f6c298b36db67a7109079c0dd7755f329c1d58e2/layout/style/nsCSSValue.cpp#31
TabAtkins: So it's only doing local matches?
dbaron: I believe so
TabAtkins: So everything else would be treated as an image.
dbaron: I'm not exactly sure, it seems odd that we don't support
external ref for masking.
astearns: I'm hearing a lot of implementers wanting option 2,
authors want option 3, and it seems SVG wants option 3.
dbaron: That's hard.
TabAtkins: The point of three is that you have the double load.
ChrisL: When you say load, do you actually go fetch it again?
TabAtkins: I believe it does?
dbaron: I think if they have the correct cache headers you could.
plinss: This double loading sounds like a red herring.
shane: It's only a red herring if you don't want consistency.
plinss: Seems like something you could change.
dbaron: There are benefits also to modularity and security
consistencies to take into consideration.
plinss: With exception to security issue, that seems like an
implementation detail.
plinss: I should be able to pass an html document to a background
image and it renders it as an image.
<birtles> background reading
http://robert.ocallahan.org/2012/10/impending-doom-for-svg-stacks-sort-of.html
Florian: Should we maybe remove the ambiguous definitions and make
them explicit?
zcorpan: If we were to start over we wouldn't have the ambiguous
issues.
<tantek> yes there are CSP implications
<tantek> CSP img-src vs media-src vs child-src
fantasai: So hold on, the issue we're discussing - didn't dbaron
say that FF loads based on local vs non-local URL?
That's less more straightforward than switching based on
fragment/no-fragment.
dbaron: The local ref thing might be for something different.
dbaron: Actually ignore my code.
dbaron: It's somehow related.
dbaron: There are areas where url:#foo is relative to the document
and not relative to the CSS.
<dbaron> ok, I'm not sure whether this code is actually relevant
<dbaron> yeah, we do support remote references -- I think the
current gecko test is just "does the URL have a ref"
TabAtkins: There is no way to resolve the fragment in CSS.
<TabAtkins> https://drafts.csswg.org/css-values/#local-urls
fantasai: We resolved on the local urls is relative to itself.
TabAtkins: That's not what the spec says.
fantasai: What did you do to the spec?
TabAtkins: What I just said.
fantasai: We had a discussion and we said we're not doing that.
<SimonSapin> https://lists.w3.org/Archives/Public/www-style/2016Jun/0026.html
"Minutes Telecon 2016-06-08"
<SimonSapin> OK to have fragment-only URLs always refer to the
host document?
<SimonSapin> ------------------------------------------------------
<SimonSapin> There were strong objections to this approach so
TabAtkins will re-write with a different approach.
<fantasai> Tab misread his spec, see
https://hg.csswg.org/drafts/rev/6e9ea5a746c3
* TabAtkins can't read their own spec, clearly we need a note
clarifying regardless.
<fantasai> needs to raise an issue against css-values
<fantasai> Alright, issues against
https://drafts.csswg.org/css-values-3/#local-urls
<fantasai> 1. Clarify so that TabAtkins isn't confused by his own
spec ;)
<fantasai> 2. Clarify whether computed value is "#foo" or
"baseURL#foo"
<fantasai> 3. Spec says url(#foo) is treated as same-document, but
what if it's in an HTML doc with a <base href>
pointing elsewhere?
<fantasai> 4. Round-tripping is broken for inherited local URLs
afaict
Florian: Since we only have this problem when there is an
ambiguity, then we only have to deal with it with legacy
stuff since we won't design future CSS to be ambiguous.
Do you, plinss accept option number 2?
plinss: I'm not excited about it, I know we have warts but I don't
want to people to point to this as precedent
tantek: The TAG is ok with this?
plinss: Saying I'm ok with this - is an overstatement, if we're
going to have this stupid behavior then we should
deprecate the url() for these properties that have
ambiguity.
astearns: The only option that I can think of is to go look at the
data and then fetch what is correct, but that has an
issue because we want to define what browsers actually
do.
tantek: I'm with plinss on this - this feels bad.
TabAtkins: esprehn pointed out that we don't know how mask loading
actually works, so we'd prefer a simple option.
TabAtkins: I'd prefer option 2 and make adjustments as necessary
and bind ourselves from doing it again.
tantek: Detail the back compat issues.
TabAtkins: That's what we're doing, we know that mask has the
problem.
tantek: If the homework is done then we're willing to take the
suggested proposals to ensure that ALL ambiguous issues
are covered by our proposal.
tantek: If there isn't an issue, then you just cut the ambiguity.
TabAtkins: That sounds reasonable, I'm happy to look into this.
TabAtkins: I think mask falls into this, we'll need to provide
some special casing.
TabAtkins: Let's resolve on not introducing no <image> or
<reference> ambiguity.
zcorpan: Does this apply to SVG WG too?
<birtles> from roc's article, "For example, for security reasons
external resource documents for paint servers are
required to be same-origin with the main document --- in
Gecko, at least, and we think the security reasons are
good enough to require the same behavior in every
browser."
<birtles> not sure fill/stroke actually do support loading images,
https://svgwg.org/svg2-draft/painting.html#SpecifyingFillPaint ?
Received on Wednesday, 16 November 2016 01:57:29 UTC