01:35
<MikeSmith>
how do I check whether http://w3c-test.org/testrunner/2dcontext/fill-and-stroke-styles/2d.pattern.repeat.nullsuffix.html is passing or not?
01:35
<MikeSmith>
(manual test)
01:51
<MikeSmith>
hmm I see it's not actually a manual test; it passes automaticaly at http://philip.html5.org/tests/canvas/suite/tests/2d.pattern.repeat.nullsuffix.html
01:52
<MikeSmith>
so what's different..
01:54
<Philip`>
MikeSmith: It probably should be calling _assert_throws, not assert_throws
01:55
<Philip`>
because (per http://w3c-test.org/common/canvas-tests.js) that's what sets _asserted = true
01:55
<MikeSmith>
hey Philip`
01:55
<MikeSmith>
ah
01:55
<Philip`>
and _asserted is what the thing uses to tell if any assertions actually ran (because if there were none, it assumes the test requires manual verification)
01:56
<MikeSmith>
Philip`: voila http://w3c-test.org/testrunner/2dcontext/fill-and-stroke-styles/2d.pattern.repeat.nullsuffix.html
01:56
<MikeSmith>
thanks
01:57
<Philip`>
That test only really existed to annoy Opera developers though, and now their browser is dead so it doesn't matter much
01:59
<MikeSmith>
Philip`: well I got a bunch of tests with that problem actually
02:00
<Philip`>
That was the goal of every one of the tests that has a \0 in it
02:01
<MikeSmith>
ok
02:01
<Philip`>
I hope nobody at Opera actually spent any time trying to fix that bug
02:03
<MikeSmith>
Philip`: should we just drop those test from the test suite?
02:05
<Philip`>
MikeSmith: No, because it finds real spec violations in real implementations, so it's exactly the kind of thing a thorough test suite should be testing
02:05
<MikeSmith>
ok
02:05
<Philip`>
But you shouldn't expect anyone to get a 100% pass rate, because the cost/benefit is totally not worthwhile
02:09
<MikeSmith>
ok
02:10
<MikeSmith>
Philip`: btw you have any idea why http://w3c-test.org/testrunner/2dcontext/fill-and-stroke-styles/2d.pattern.image.incomplete.immediate.html is failing?
02:12
<Philip`>
MikeSmith: I assume you're testing in a browser that considers the image to be loaded as soon as img.src was set (at least when the image was in cache), but (if I was reading the spec correctly, and if it hasn't changed since then) the image shouldn't be loaded until after the script has returned
02:14
Philip`
goes to sleep
02:25
<MikeSmith>
Philip`: I'm testing in Firefox and IE and Chrome ..
02:25
<MikeSmith>
nn
02:25
<MikeSmith>
(oh I guess you didn't meant that sleep literally)
02:27
<MikeSmith>
http://w3c-test.org/testrunner/2dcontext/fill-and-stroke-styles/2d.pattern.image.incomplete.emptysrc.html seems to failing in the same way maybe (except in IE)
02:27
<MikeSmith>
anyway
11:07
<MikeSmith>
http://w3c-test.org/testrunner/2dcontext/failures.html
11:12
<jgraham>
Those UA strings are super-easy to read
11:13
<MikeSmith>
jgraham: I guess I should trim them down
11:13
<jgraham>
MikeSmith: Might be interesting to cross-check against http://hoppipolla.co.uk/410/results.html
11:13
MikeSmith
looks
11:13
<jgraham>
Although if you fixed some tests recently I haven't run with the newe tests yet
11:14
<MikeSmith>
I haven't checked in any fixes
11:15
<jgraham>
You have local fixes?
11:15
<MikeSmith>
yeah the only changes I made were locally and then only to change some assert* to _assert
11:16
<MikeSmith>
jgraham: so I see fill-and-stroke-styles/2d.pattern.image.incomplete.immediate.html is failing at http://hoppipolla.co.uk/410/results.html too
11:16
<MikeSmith>
what UA are those results for?
11:17
<MikeSmith>
Gecko?
11:17
<jgraham>
MikeSmith: Yeah, some recentish nightly
11:18
<MikeSmith>
from what I've checked at http://hoppipolla.co.uk/410/results.html it does seem the results pretty much match
11:18
<MikeSmith>
except for the _assert* change, which fixed some of them in all UAs
11:19
<MikeSmith>
and which fixed some in Gecko only but not in Trident or Blink
11:20
<jgraham>
That's encouraging :)
11:20
<jgraham>
A PR for the _assert change would be nice btw :)
11:20
<jgraham>
Also
11:21
<jgraham>
Jasper: The latest canvas tests are at http://w3c-test.org/web-platform-tests/master, not under html/
11:21
<jgraham>
and the repo is at https://github.com/w3c/web-platform-tests
11:21
<jgraham>
Contributions via pull requests are welcome
11:22
<MikeSmith>
I'd make a PR for the changes but last I talked to Ms2ger he suggested changes should be made to the test sources from Philip` and we regenerate the WPT versions
11:23
<MikeSmith>
and the problem with that is, Robin changed the WPT directory structure, which broke Ms2ger's script
11:23
<MikeSmith>
jgraham: I'm curious about http://w3c-test.org/testrunner/2dcontext/failures.html#gecko-passes
11:32
<jgraham>
Sigh
11:32
<jgraham>
I might have to fix the script then
11:32
<jgraham>
But I don't know where it is
11:33
<MikeSmith>
jgraham: it's in the repo
11:33
<MikeSmith>
right?
11:33
<MikeSmith>
https://github.com/w3c/web-platform-tests/tree/master/2dcontext/tools
11:38
<jgraham>
Probably
11:38
<jgraham>
I don't really remember what I knew about these tests and what I knew wasn't all that much
11:40
<MikeSmith>
jgraham: still I reckon that's way more than I know. I just been pushing buttons to make that report which I promised plh two months ago I'd do
11:41
<MikeSmith>
anyway, very glad at least to have Ms2ger's test runner. That makes the basis grunt work automatic.
11:43
<zcorpan>
Philip`: i think \0 was fixed in some places but not everywhere, and yes, developers were annoyed. i was annoying them with such tests as well. :-)
11:43
<jgraham>
Well they always said that it wasn't worth the time to fix in general
11:44
<jgraham>
So it's not like you killed Presto by making us fix null bugs rather than implement features
11:52
<zcorpan>
right
12:08
<gsnedders>
It was basically fixed for new APIs, not old, and occasionally when some real site hit NULL-truncation in old APIs, but that was rare.
14:11
<zcorpan>
i wonder if the custom element guys have discussed with the SVG WG about SVG not introducing new elements with dashes in the name
14:15
hsivonen
sure hopes so
14:16
<jgraham>
They probably couldn't think of a humourous thread title for it
14:16
<zcorpan>
All your dashed names are belong to us.
14:19
<MikeSmith>
heh
14:21
<MikeSmith>
I don't remember anybody asking whether the rest of the everybody figured reserving dash exclusively for web components was a good idea
14:22
<MikeSmith>
or, say, maybe even asking Hixie_
14:26
<zcorpan>
filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=23256
14:27
<zcorpan>
hmm, html suggests x-vendor-foo as element name for vendor extensions
14:28
<zcorpan>
but maybe browsers are moving away from prefixing stuff in general anyway
14:28
<zcorpan>
or maybe that was attributes, not elements
14:35
<zewt>
prefixing elements sounds even more of a pain in the ass to authors than prefixing css (which is more of a pain in the ass than prefixing APIs)
15:37
<Hixie_>
MikeSmith: i think it was partially my idea, as a way to get rid of the ugly x- prefixes :-)
16:32
<TabAtkins>
zcorpan: Yes, SVG isn't going to make any elements with dashes in their name.
17:51
<Hixie_>
people who care about multipart/form-data, please see https://www.w3.org/Bugs/Public/show_bug.cgi?id=16909
22:02
<zewt>
nothing quite as futuristic as sites rejecting a form because i didn't put dashes in my phone number
22:37
<heycam>
zcorpan, yeah the only reason dashes are in the names of some elements is that they were reflecting CSS at-rules (like font-face) in elements
22:37
<heycam>
zcorpan, and that was a bad idea :)
22:40
<zcorpan>
missing-glyph is an at-rule? :-)
22:40
<heycam>
zcorpan, you got me there!
22:40
zcorpan
-> sleep