- From: Dael Jackson <daelcss@gmail.com>
- Date: Fri, 13 Jun 2014 10:21:11 -0400
- 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.
==== FULL MINUTES BELOW ======
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
results.
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
written.
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
tests.
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
great.
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
faster.
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
access?
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
though.
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