W3C home > Mailing lists > Public > www-style@w3.org > November 2016

[CSSWG] Minutes Lisbon F2F 2016-09-19 Part II: url() as image or SVG reference [css-values]

From: Dael Jackson <daelcss@gmail.com>
Date: Tue, 15 Nov 2016 20:56:26 -0500
Message-ID: <CADhPm3vYucUwUdYiqC4rE_rqLRr1mKnMnPDwXT+TD19XM6gVEg@mail.gmail.com>
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

This archive was generated by hypermail 2.3.1 : Wednesday, 16 November 2016 01:57:29 UTC