02:36
<MikeSmith>
https://twitter.com/sebmarkbage/status/435113501447573504 "I guess I'm curious if W3C specs are really efficiently policing diverging user level paradigms and even if it is. Is that important?"
02:37
<MikeSmith>
I wonder what "efficiently policing diverging user level paradigms" means
02:45
<nessy>
SamB: that's all good then :-)
08:36
<zcorpan>
annevk-cloud: http://lists.w3.org/Archives/Public/public-web-perf/2014Feb/0048.html shouldn't sendBeacon send a Referer?
08:37
<zcorpan>
annevk-cloud: "API referrer source" is different depending on global env
13:19
<MikeSmith>
weird, I get https://raw.github.com/slightlyoff/ServiceWorker/master/spec/service_worker/index.html as text/plain in desktop but rendered HTML on mobile
13:21
<MikeSmith>
hmm maybe because it redirects to https on desktop but not on mobile
13:30
<zcorpan>
MikeSmith: try https://rawgithub.com/slightlyoff/ServiceWorker/master/spec/service_worker/index.html
13:31
<zcorpan>
(don't know why the other url wouldn't be text/plain on mobile though)
13:31
<MikeSmith>
ah yeah
13:31
<MikeSmith>
thanks
13:47
<zcorpan>
https://critic.hoppipolla.co.uk/r/800 seems like a good example of "test is testing what it thinks it is testing"
13:48
<jgraham>
*isn't?
13:48
<zcorpan>
or maybe "The test fails when it's supposed to fail"
13:49
<zcorpan>
i mean they fail at it
13:49
<zcorpan>
http://testthewebforward.org/docs/review-checklist.html
13:51
<jgraham>
Yeah, I think I know what you mean :) But I think your original sentence needed an extra negative somewhere to be clear
14:08
<zcorpan>
what is our story for manual tests? https://critic.hoppipolla.co.uk/r/803
14:09
<gsnedders>
"Cry."
14:11
<jgraham>
Yep, the tears of gsnedders are like holy water to a vampire. Just a few drops on a manual test and it will fizz and dissolve into the æther.
14:12
<jgraham>
But actually the policy is to name them -manual and hope that in the future we can convert them to WebDriver tests
14:13
<wilhelm>
Deleting them sounds wrong, unless those features are tested automatically elsewhere.
14:14
<jgraham>
Yeah. I'm not sure if those specific tests are good tests, but it needs someone to decide that rather than just deleting them all
14:14
<jgraham>
(maybe foolip already did, I don't know)
14:53
<zcorpan>
stevef++ in https://www.w3.org/Bugs/Public/show_bug.cgi?id=24679
15:01
<foolip>
jgraham: most of the ones I removed say things like "passes if the audio is playing without sound heard" which can't be automated with any existing framework
15:02
<foolip>
but I'll close the review/PR anyway, since my assumption that manual tests should be nuked was wrong
15:04
<jgraham>
foolip: OK, thanks
15:05
<jgraham>
foolip: A PR to add -manual to the names of manual tests would be much appreciated
15:05
<foolip>
jgraham: will that now
15:12
<foolip>
jgraham: https://github.com/w3c/web-platform-tests/pull/646
15:16
<foolip>
zcorpan: about https://critic.hoppipolla.co.uk/showcomment?chain=2370 do you think it would be useful to have an obsolete.html or some such to collect tests for non-support of various features?
15:16
<zcorpan>
foolip: yeah. i think dom testsuite has a file called historical.html
15:17
<foolip>
zcorpan: ok, I'll start one of those for media then
15:20
<foolip>
zcorpan: whatwg.org/html#embedded-content-0 indicates to me that the -0 in html/semantics/embedded-content-0/ is not really useful
15:22
<zcorpan>
it should be http://www.whatwg.org/specs/web-apps/current-work/multipage/embedded-content-1.html#embedded-content-1
15:22
<zcorpan>
but with a stable id
15:23
<Ms2ger>
FileAPI has historical.html too
15:23
<foolip>
how could it be stable given that the -n is generated by anolis?
15:23
<foolip>
zcorpan: you mean ask hixie to make it stable?
15:23
<zcorpan>
foolip: yeah
15:24
<zcorpan>
Hixie: would you WONTFIX a bug asking you to set id="" to all sections in the spec, three levels deep?
15:24
<foolip>
zcorpan: https://www.w3.org/Bugs/Public/show_bug.cgi?id=24694
15:24
<zcorpan>
Hixie: web-platform-tests uses section id as basis for the directory structure so it's a problem that they are not stable
15:29
<gsnedders>
Pretty certain Hixie claims that that's no more of a problem than the fact that the tests become invalid because of oter spec changes
15:29
<jgraham>
Well
15:29
<jgraham>
It sort of is
15:31
<foolip>
given that these are scoped to directories, couldn't we just not include the -0 in the name?
15:39
<foolip>
zcorpan: historical.html for <video auto=muted> in https://critic.hoppipolla.co.uk/r/801
15:41
<zcorpan>
reviewed
15:45
<zcorpan>
foolip: how do you mean not include the -0?
15:47
<foolip>
zcorpan: I mean simply name the directory html/semantics/embedded-content/
15:47
<foolip>
but I guess let's see what Hixie says first
15:48
<zcorpan>
foolip: how would you know which section in the spec the tests map to?
15:48
<Ms2ger>
It has been claimed that the exact mapping to spec IDs is important
15:49
<zcorpan>
i thought the main reason to have this structure is to annotate the spec with links to the tests
15:55
<foolip>
ok, if there are scripts that rely on the IDs then I suppose there's no shortcuts
15:56
<jgraham>
At the very least darobin has a script that gets you the test directory given (something). Which I think probably relies on the ID
15:57
<darobin>
yeah, it's somewhere in the tools
15:58
<jgraham>
Of course no one else can run it because node ;)
16:07
<Hixie>
having spec links in tests imho is a bad idea, because specs test many things, so one link isn't going to help. also, that link will get stale, so it just causes unnecessary churn.
16:07
<Hixie>
but that's separate from the issue of stable IDs
16:07
<Hixie>
if there's a particular heading that needs a stable heading ID, file a bug
16:08
<Hixie>
i won't do it to all headings, but i will to specific ones
16:09
<Hixie>
in other news, it's come to my attention that chaals is mailing people privately telling them to post to public-html instead of whatwg.
16:09
<Hixie>
stay classy chaals.
16:15
<foolip>
Hixie: https://www.w3.org/Bugs/Public/show_bug.cgi?id=24694 is a specific one that would make me happy
16:16
<Hixie>
noted
16:19
<zcorpan>
Hixie: tests can have multiple spec links
16:20
<Hixie>
how many of them point to the "in body" parser insertion mode, the "navigate" section, the "html" element section, etc?
16:22
<jgraham>
Hixie: I think there is a certain extent to which the perfect is the enemy of the good here
16:22
<zcorpan>
Hixie: it's not useful to link to everything that a test happens to rely on, but it can be useful to point to things that a test is intended to be testing
16:23
<jgraham>
Although I am generally opposed to metadata, saying that a test [oh zcorpan just said it]
16:26
<Hixie>
in my experience, tests usually find bugs you're not intending to find.
16:27
<zcorpan>
so?
16:27
<Hixie>
*shrug*
16:27
<Hixie>
i find the link to be bad because it misleads people into thinking the section is relevant
16:28
<Hixie>
rather than having them try to find the section from first principles, which avoids them making the same mistake as the test writer
16:28
<Hixie>
but whatever
16:28
<Hixie>
you do as you like :-)
16:29
zcorpan
gotta go
16:31
<jgraham>
I think having a rough mapping of tests to spec sections is pretty useful to get a coarse view of which tests are *expected* to exercise a particular part of the spec, to find obvious gaps in the coverage, and to find tests that are likely invalid if a section undergoes a major rewrite or is removed. They are not useful as a tool for debugging a failing test
16:34
<gsnedders>
Though as opjsunit shows, we did end up with a testSiteRegressions_0.js file :)
16:47
<foolip>
jgraham: can you finish https://critic.hoppipolla.co.uk/r/801 so that I merge before sleep?
16:48
<jgraham>
foolip: Done. I assume you want to squash and merge?
16:49
<foolip>
jgraham: of course
16:50
<foolip>
jgraham: you can do https://critic.hoppipolla.co.uk/r/812 too if you like, or leave it to zcorpan :)
16:57
<jgraham>
foolip: I might leave that to zcorpan if you don't mind
17:37
<foolip>
jgraham: np
21:35
<Hixie>
http://www.whatwg.org/specs/web-apps/current-work/#overview-of-the-parsing-model vs http://www.whatwg.org/specs/web-apps/current-work/multipage/parsing.html#overview-of-the-parsing-model
21:35
<Hixie>
in chrome i get a different object entirely in the floating object...
21:35
<Hixie>
wtf
21:35
<Hixie>
the markup is identical
22:20
<scott_gonzalez>
smaug____: I talked to the jQuery team and the only case we know of for sync XHR is beforeunload.
22:20
<scott_gonzalez>
smaug____: Devs tend to use it for form validation as well, but that should really be handled async with event.preventDefault() in a submit event handler.
22:31
<smaug____>
scott_gonzalez: right
22:32
<smaug____>
scott_gonzalez: gecko now warns about sync xhr except when used in beforeunload/unload/pagehide event listeners
22:32
<scott_gonzalez>
That sounds reasonable.
22:32
<scott_gonzalez>
I guess you'll start warning in those once beacon lands?
22:33
<smaug____>
right
22:33
<smaug____>
hmm, did beacon land
22:33
<smaug____>
didn't
22:34
<smaug____>
ah, some test fixes still needed
22:34
smaug____
needs to also ask sicking about the stability of beacon
22:34
<smaug____>
scott_gonzalez: do you think jQuery could actually disable sync XHR at some point
22:35
<scott_gonzalez>
In some magical future, yes.
22:35
<scott_gonzalez>
I've already convinced the team to deprecate $.ajax in favor of separate APIs for each type of transport.
22:36
<scott_gonzalez>
So there would be $.xhr() and it would only support async XHR.
22:36
<scott_gonzalez>
The question is whether we can get to a point where we ship jQuery without $.ajax().
22:37
<scott_gonzalez>
Here's my proposal if you're interested: http://bugs.jquery.com/ticket/14509
23:41
<pdr>
w3.org is down. How will the web ever move forward now