W3C home > Mailing lists > Public > www-style@w3.org > June 2014

[CSSWG] Minutes Seoul F2F 2014-05-21 Part IV: web-platform-tests and csswg-test github, annotate url() with "crossorigin" "integrty" etc.

From: Dael Jackson <daelcss@gmail.com>
Date: Fri, 13 Jun 2014 10:21:11 -0400
Message-ID: <CADhPm3uAT2mhG5OMaB_JshHB9Ki3bs4MpfZogt134LjuwF6nxQ@mail.gmail.com>
To: www-style@w3.org
web-platform-tests and csswg-test github

  - plh presented the interest in having tests to CSS submitted
       though web-platform.
  - There was some concern about conflicting interests where the
       working group tools were developed to get specs to REC
       whereas web-platform was just developed to create more tests.
       However, there was also support for more tests to make
       better specs.
  - No end decision was reached, but there was interest in having
       web-platform-tests be a subdirectory of CSS tests.

annotate url() with "crossorigin" "integrty" etc.

  - There was ample interest in being able to annotate url().
  - TabAtkins' believed he had a solution involving enhancing url()
       which he will investigate and bring back his findings to
       the group.


Agenda: http://wiki.csswg.org/planning/seoul-2014#agenda
Scribe: dael

web-platform-tests and csswg-test github

  plh: I don't know how familiar people are with testing we have and
       the differences between the two.
  plh: How much detail should I go into?
  plh: With web-platform-tests it contains test suits for around 60
       specs from 6 working groups. The goal is actually to make the
       web work. It might sound crazy, but that's the goal and
       there's input to make that work.
  plh: There's high activity on that at the moment. At the moment
       James Graham from Mozilla is doing fantastic work to get it
       to work on Firefox. My hope is by end of year we'd get
       results from browsers.
  plh: So, you put a test into the suite and overnight you get
  plh: That would be very useful for working groups to get the raw
       test results. That's the goal. The problem is it wants to
       cover CSS as well.
  plh: By running the tests, it's also web tests. And there's
       ongoing work to be able to write a webdriver test as well.
  plh: So there's a huge advantage to having CSS participate. The
       CSS test repo is a mirror of mercurial. I'd assume this group
       is more familiar with mercurial than me.

  plh: So there's discussion about how to get them to interact.
       There's 3 proposals.
  plh: First is to make a simple solution. Make the CSS repo a
       submodule of web-platform-test.
  plh: So if you want to make a pull request you make it on the CSS
       repo. On the pro side, it's easy, but on the con it's
       confusing because people can't pull requests from the same
       place. Right now web-platform is using a different review
       system than CSS.
  plh: The third option that can be argued the most is we have
       different requirements. web-repo placed the bar low to favor
       test submission.
  plh: The second solution is to have the repo as a subtree. The
       problem is you would have two systems and you could send pull
       requests to both.
  plh: We're used to dealing with one place and we'd have to look at
       two with different test requirements.
  plh: Third solution is to say we're not going to try and integrate.
  plh: People will send submitters to web-platform test and in order
       to satisfy the requirements it'll have to move to the
       repository by the same or a different person.
  plh: So it would be submit your test to the web-platform and then
       the CSS will re-ask.
  plh: CSS platform does have tools that the web-platform doesn't
       have. The whole system we have on ED is all on the CSS test
       repo and you wouldn't get that on web-platform until that's

  clilley: That was discussed this morning.
  plh: I'm talking about a bigger rewrite.
  plinss: I was going to clean up, but not fundamentally re-write.
  clilley: I misunderstood.

  plh: To finish, we don't have everyone in the room, but we can
       start by saying are there opinions? What to test contributors
       want to see?
  plh: At the end of the day with web-platform-test we can let
       people submit tests and merge into the CSS test repo.
       That's fine.

  plh: Do people have opinions? Do they care at the moment?
  zcorpan: My opinion is that people should be able to make a pull
           request to web-platform-tests for when they want to add
           CSS tests and not have to put in the meta data that the
           CSS WG requires for their tests.
  zcorpan: How the syncing works, I have less opinion.
  plinss: Without some fundamental metadata, we won't get use from
          the test.
  plinss: The fundamental dichotomy is that the stated goal of the
          web-platform is to get better tests, but they don't care
          about getting specs to REC and we do.
  zcorpan: There is some metadata needed to annotate which tests go
           to which section. You put it in a directory and it
           annotates it for a particular section.
  plinss: I don't care about what form the metadata is in, but I'm
          saying we need to to exist. And if you're promising our
          minimum of metadata we can work with that.
  zcorpan: Right.

  plinss: The biggest problem is tracking issues. Where are the bugs
          going to be filed and where are they tracked and if we're
          copying back how will people know where to look.
  hober: We already have that problem.
  plinss: But at least we have a system. There's even less
          information about where we'll track information for the
  plh: We have a tracking per WG and a system that's automatically...
  plh: I can tell you the number of tests and pull requests we have
       to each spec. You mentioned that it didn't care about getting
       to REC and you're right.
  plh: But WGs can use it to get to REC and that's good enough. If
       we can get test results from three or four browsers that's

  astearns: I think the most important thing is one place to submit
            for any web-platform-tests. So any one place that takes
            differences and reviews differences is a big thing.
  plh: If we do that there's a lot of work to be done. Most of the
       CSS tests are manual so they'll have to be run manually which
       takes time.
  plh: It may will be that we have an approach like with the presto
       where they have their of github and we're trying to over time
       move their tests to web-platform and than remove them from
       the original repository. We'll be successful when that's 0,
       but it'll take us a while.
  astearns: So. I'm much more concerned with getting test solutions
            than having a single place to track issues and reviews.
            I just want the tests.
  astearns: I'll accept multiple processes and the headaches to get
            bigger test suites.
  astearns: I thought we decided as long as a review happened, it
            didn't matter where. It just mattered that it was tracked
  astearns: There could be review in many places and we can deal
            with having the headache of having these multiple ways
            as long as we get more tests in the test suite.

  zcorpan: The multiple reviews thing is already an issue in
           web-platform without CSS.
  astearns: And it's an issue in CSS.
  plinss: I have a plan to sync our systems.
  astearns: And if you get to it great. If not that's fine.
  plinss: I don't know how to sync those three and another repo. It
          sounds like a nightmare, but maybe it's possible.
  plinss: Fundamentally from one aspect I don't care and don't want
          to worry about this stuff. If we had an all in one we can
          use I'd be happy, but we don't. The other systems out
          there don't meet our needs. They don't help use get the
          specs to REC.
  plinss: And they're not offering to help us with the needs beyond
          what they're acknowledged.
  astearns: But getting to REC means sufficient tests and I don't
            have any evidence that critic *or* shepherd help us get
            to REC.
  plinss: But what we have is multi-format test suites so we can run
          against things besides browsers. We accept tests from
          other sources and fold them into an area to generate the
          data to get us to REC. That's not from shepherd.
  plinss: I'm all for trying to blend, but I don't want the throw
          out the baby with the bathwater and make it harder to get
          specs done. If we can bring things together and get them
          in one place, but still keep going, that's great.
  plinss: I don't know what the right step is. If it's sub trees and
          pulling from different places or if it's submodules.
  astearns: If all tests were in same repository and we have our
            system for our tests and the tests in W3C and their
            tests do what they want, maybe the competition will move
  plh: And we tried to be highly modular and they're not likely to
       try and impose every bit of the system.
  plinss: The other problem is there's a lot of historical review
          data we would lose or have the track separately.
  plinss: I don't want to lose that information. Tests have to be
          good tests of they make our jobs harder. If the web-
          platform can live with being used in a subdirectory we can
          do that and maintain our own repo for as long as we need
          to. But I don't know if that will fly.
  plh: I think we've done as much as we can on this topic.
  plinss: There are questions about if putting all CSS in a
          subdirectory is good enough.
  plh: I don't have an answer. I think there are some people who
       don't like this approach.
  <Ms2ger> I don't think that improves the situation.
  <Ms2ger> My personal answer to that is "no"

annotate url() with "crossorigin" "integrty" etc.

  zcorpan: So yesterday Anne van Kesteren talked about an ability to
           to give attrributes to a url() in CSS.
  zcorpan: It doesn't have to be a url() function [which has crazy
           parsing rules]. I mean the functionality.
  zcorpan: In HTML you can do
        <link rel=stylesheet href=http://a/b crossorigin=anonymous>
  zcorpan: In this case you can read the stylesheet data in CSSOM
           but without crossorigin you can't read it.
  zcorpan: So today with @import you cannot annotate the url with
           the crossorigin. You can have a media query here, but
           the crossorigin piece is missing.
  zcorpan: So import stylesheets can't be read in CSSOM.
  zcorpan: What it's asking for is some way to spec a crossorigin.
  zcorpan: There's also a spec called sub-resource integrity which
           takes an integrity attr.
  zcorpan: And the user can compare the downloaded hash with the
           spec hash and they probably want to use this in CSS
           as well.
  <krit> zcorpan: Is that just about stylesheets or other resources
         like images as well?
  <astearns> http://w3c.github.io/webappsec/specs/subresourceintegrity/

  zcorpan: So how do we do it?
  zcorpan: You can't put anything inside url() but we can come up
           with some other function like
           newurl("...", crossorigin...);
  zcorpan: I don't have a concrete proposal for how to do this, but
           I wanted to see what people think.

  glazou: To be sure I understand, current behavior of linking, we
          can link to any stylesheet from anywhere. If this is going
          to be changed without crossorgin, you won't be able to
          reach the OM, right?
  dbaron: No, the issue you can't access without crossorigin.
  zcorpan: You should be able to opt-in to loading and accessing.
  glazou: This is a change.
  zcorpan: It's a new feature.

  plinss: I haven't read up on crossorigin, but I'm assuming it's
          more than having the attr that makes it accessible.
  zcorpan: Yeah.
  TabAtkins: It's relatively easy. There's already been a lot of
             work done.
  plinss: It'll depend on the response of the server.
  zcorpan: Yeah. If you try and link and spec and if the server
           doesn't support...
  plinss: So you're requiring that the browser does something?
  zcorpan: If the server doesn't support CORS you'll get an error.
  plinss: You don't get the stylesheet? Not just you don't get
  zcorpan: Yes. If you opt into "I want CORS" and it doesn't support
           it you get a network error.

  plh: One question if when you function you'll need to have some
       questions about lazyload.
  <hober> something like link(<url> <plist>?) (where <plist> is
          [<ident> <string>]+) e.g. link(http://a/b crossorigin
          "anonymous" integrity "6d8f296997bfd407d3c82bd950585200")
  hober: If you look at my IRC syntax and you accept arbitrary.
  plh: That would work.
  zcorpan: I think your(hober's) prop needs quotes for parsing, but
           is fine.
  <hober> so link(<url> <plist>?) (where <plist> is [<ident>
          <string>]+) e.g. link("http://a/b" crossorigin "anonymous"
          integrity "6d8f296997bfd407d3c82bd950585200")
  dbaron: I think this is fine if we come up with a good name for it.
  zcorpan: So we have link. Any other ideas?
  dbaron: Or href.
  <dbaron> ... because there's precedent, not because it's any good.

  fantasai: Are we using this for anything but @import?
  zcorpan: Yeah.
  fantasai: For images we can put in the image() function.
  hober: The generic case is just slightly worse than current syntax.
  <krit> what about a cors() function?
  <krit> cors(<url> | image, CORS arguments) ?

  TabAtkins: One possibility is we play with parsing for quoted
             strings; URLs can take arguments after.
  hober: So no new function?
  TabAtkins: You would have to use " or you're get an error.
  hober: I'm sympathetic to no new function, but I worry about if
         I'm an author I hear of this awesome thing, but I don't
         look at if I have to quote the URL.
  TabAtkins: So it's the same scenario if we add a new property
  plinss: And if you're really naive you don't check if the server
          supports CORS.
  dbaron: If you find a way to do TabAtkins proposal you make URLs
          with quotes return as tokens.
  <krit> people love url()!!!
  <krit> you cannot get rid of it
  TabAtkins: I think I can do this.
  TabAtkins: It'll consume space until it finds the quotation mark.
  dbaron: It's the URL without " token that's crazy, so this
          will work.
  TabAtkins: Yeah. I want to get into the code to make sure but at
             this point I'm certain I can do this quickly.
  zcorpan: I like the URL with quotes idea.
  fantasai: But you don't need multiple?
  TabAtkins: Everywhere a function can take a URL it can take a
             quoted string.
  fantasai: I don't know about that. In SVG it uses a hyphen
  hober: I love this idea of enhancing URL.
  <krit> what about image() ???

  <trackbot> ACTION-632 on TabAtkins - Figure out if enhancing url() works

  TabAtkins: We'd build the resource integrity stuff alongside.
  zcorpan: I don't expect the integrity right now.

  krit: You're just talking about URL, what about image?
  hober: Image takes the url() argument so it's the same thing.
  TabAtkins: Alternately we could also allow these changes
             directly in image function grammar.
  fantasai: How often would we use this for images?
  plinss: I think integrity would become popular for things like
          online banking
  fantasai: I imagine it would in the HTML, but the CSS?
  TabAtkins: We can always let you do it as URL and flatten it later
             if necessary.
  fantasai: Yes. I think it won't be used often for images.
  fantasai: Also, it's more closely tied to the network request
            rather than the image processing.
  <fantasai> so fits better in url() than flattened into image()

  plinss: So TabAtkins you'll come back to us.
  hober: If it doesn't work we can add the function.
Received on Friday, 13 June 2014 14:21:39 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:51:30 UTC