02:50
<GPHemsley>
annevk-cloud: Hmm, looks like the distinction got lost in translation: https://github.com/whatwg/mimesniff/commit/24098021f526233ad5ba7f69eaf387b696b7032a#diff-1feda49b40370635faef8b655f144f64L1601
02:54
<annevk>
And nobody noticed for over a year :/
03:11
<foolip>
jgraham: https://github.com/w3c/web-platform-tests/pull/531#issuecomment-32817873
03:14
<foolip>
jgraham: the final word on video mimesniff is TBD in https://www.w3.org/Bugs/Public/show_bug.cgi?id=11984
03:16
<GPHemsley>
annevk: You will find that to be the case in many problems with the mimesniff spec.
03:16
<GPHemsley>
Though it appears to be experiencing a renaissance.
03:18
<GPHemsley>
annevk: BTW, I commented more extensively on the relevant bug.
03:19
<annevk>
That's not really the relevant bug, but okay
03:20
<annevk>
I recommend going through the specification relative to the original specification again to make sure there are no other mistakes like this
03:26
<GPHemsley>
annevk: Is there a more relevant bug?
03:27
<GPHemsley>
annevk: Also, mimesniff is pretty far down on my list of priorities at the moment. If people raise specific issues, I'm happy to look into them, but I don't have time to re-audit the spec right now.
05:18
<foolip>
anyone know if Denis Ah-Kang (deniak) is on IRC?
05:25
<heycam>
foolip, he is denis on irc.w3.org:6667
05:26
<foolip>
heycam: thanks!
06:22
<MikeSmith>
foolip: Denis is around on the #testing channel when he's online
06:22
<MikeSmith>
on irc.w3.org as heycam mentioned
06:23
<MikeSmith>
Reunion Island time
08:51
Ms2ger
sees a webkit contribution to wptserve o/
09:02
<Ms2ger>
MikeSmith, you should give https://github.com/foolip access to w-p-t
09:22
<Ms2ger>
jgraham, what's up with https://critic.hoppipolla.co.uk/r/239?
09:25
<MikeSmith>
foolip: you got push access to w-p-t now
09:25
<Ms2ger>
Ta
09:28
<MikeSmith>
Ms2ger: thank you
09:28
<MikeSmith>
so is http-equiv="Content-Style-Type" in the spec now?
09:28
<MikeSmith>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24341
09:29
<MikeSmith>
eh is Content-Style-Type even an acutal header name
09:30
<Ms2ger>
Rings a vague bell
09:30
<MikeSmith>
yeah I see it around now
09:30
<Ms2ger>
'inline styles ignored using Content-Style-Type of "text/ccs"'
09:33
<MikeSmith>
yeah but why do people use this
09:33
<MikeSmith>
they think it has some effect?
09:33
<hsivonen>
MikeSmith: because in the future, CSS might go away and we might use XSLT in style attributes
09:33
<hsivonen>
MikeSmith: so better declare CSS
09:33
<hsivonen>
MikeSmith: as if the default could ever change
09:34
<hsivonen>
also, good luck introducing another styling language for the Web
09:34
hsivonen
waves at Dart and VBScript over in the <script> land
09:34
<MikeSmith>
heh
09:36
<MikeSmith>
maybe we should remove the HTML4 spec from the web and just make its URL redirect
09:37
<MikeSmith>
http://www.w3.org/TR/REC-html40/present/styles.html#default-style
09:37
<hsivonen>
MikeSmith: whoa. a normative requirement in HTML4.
09:37
<MikeSmith>
yeah, a rare normative requirement
09:38
<MikeSmith>
and unsurprisingly a bad misguided one
09:38
<hsivonen>
MikeSmith: and the User Agent side is only a "should" but the author side is "must"
09:38
<hsivonen>
totally backwards
09:39
<MikeSmith>
yeah. and there's not one sentence in that whole section that's right, as far as matching reality
09:45
<MikeSmith>
in other news I see there was a recent message from ArtB saying that there's no plan to implement Server-Sent Events support in IE
09:45
<MikeSmith>
I guess I had assumed they already supported it
09:46
<MikeSmith>
kinda sucks for anybody who might want to actually develop something using it
09:47
<MikeSmith>
I guess they probably would argue that developers should just use WebSocket instead
09:48
<foolip>
MikeSmith: thanks! what are the ground rules for merging PRs? is anything with an accepted review OK to merge, even if you are the author or reviewer?
09:49
<foolip>
hsivonen: I'm happy to see you're going ahead with Big5 in Gecko
09:51
<hsivonen>
foolip: well, I'm seeing if emk wants to go ahead. if not, I might get to it once I've dealt with goals for this quarter, first
09:52
<Ms2ger>
MikeSmith, but does dbaron's desk implement that requirement?
09:52
<foolip>
hsivonen: good luck in any event, now that the discussion part seems to be over
09:58
<odinho>
wtf, no sse? Well ok, it'll just never work in IE then. :)
09:58
<odinho>
I use SSE all over the place.
09:59
<Ms2ger>
foolip, a big thanks for the work you've been doing, btw
09:59
<Ms2ger>
Can I send you chocolate? :)
10:00
<odinho>
foolip: Yeah, you can merge as long as reviewed.
10:01
<MikeSmith>
foolip: the rules for w-p-t are to do what jgraham and Ms2ger say
10:02
<Ms2ger>
I say: feel free to merge anything that's accepted in critic
10:02
<MikeSmith>
foolip: but as far as I know it's OK for you to merge your own PR if it's been reviewed by others and accepte
10:02
<odinho>
And jgraham has already said that, so yea.
10:02
<Ms2ger>
jgraham / zcorpan: feel like reviewing https://critic.hoppipolla.co.uk/r/30 ? :)
10:09
<darobin>
oh wow
10:09
<darobin>
http-equiv="Content-Style-Type" is a must for authors but a should for authoring tools, and style@type is required anyway
10:09
<darobin>
that's just... wow
10:16
<zcorpan>
darobin: according to which spec?
10:17
<Ms2ger>
HTML4, I guess
10:17
<darobin>
zcorpan: I was reading the scrollback and looking at HTML4 http://www.w3.org/TR/REC-html40/present/styles.html
10:18
<Ms2ger>
darobin, you should write w3c html5 in that style... Clearly the easiest way to get to rec
10:18
<darobin>
Ms2ger: yeah, man, that would be awesome
10:18
<darobin>
I could be done by the end of the week
10:18
<Ms2ger>
And then do some test reviews :)
10:19
<darobin>
make sure that the assertions aren't testable — that makes the test writing process much simpler
10:19
<darobin>
who needs reviews? if you make the spec vague enough the tests are *obviously* right
10:19
<Ms2ger>
Well, you're done with the w3c tests immediately, so you can move on to the whatwg tests
10:20
<darobin>
now you're making it sound like work
10:21
<Ms2ger>
Yeah, but look at the amount of work I saved you. Surely you can do some in return :)
10:22
<darobin>
Ms2ger: I dunno, are you familiar with the free rider problem in game theory? :)
10:22
<Ms2ger>
I wouldn't dare to suggest you are one
10:23
<darobin>
sweet Ms2ger
10:27
<karlcow>
darobin: http://lists.w3.org/Archives/Public/www-archive/2014Jan/0007.html
10:28
<karlcow>
mail from the past
10:28
<darobin>
karlcow: oh man, that's priceless! thanks :)
10:29
<darobin>
"Conforming user agents must correctly map to ISO 10646 all characters in any character encodings that they recognize (or they must behave as if they did)."
10:30
<zcorpan>
i had forgotten how fun it is to decrypt RSA (the <video> RSA, not that other thing)
10:45
<foolip>
zcorpan: yeah I had some proper nostalgia looking at these tests again
10:52
<foolip>
Ms2ger: will plh magically see r=plh?
10:53
<Ms2ger>
How so?
10:53
<Ms2ger>
He mentioned those changes were okay on github
10:54
<MikeSmith>
in Critic you can assign people to review particular PRs right?
10:54
<Ms2ger>
Yeah
10:54
<MikeSmith>
or even parts of them
10:55
<foolip>
Ms2ger: oh, I thought it meant you wanted him to review the rest
10:56
<Ms2ger>
Well, that would be nice of him, but I don't expect it :)
10:58
<foolip>
Ms2ger: will you?
10:58
<Ms2ger>
Not right now
11:09
<MikeSmith>
Ms2ger: http://lists.w3.org/Archives/Public/public-web-perf/2014Jan/0027.html
11:09
<MikeSmith>
TR strikes again
11:10
<MikeSmith>
dunno if you added that to the wiki already
11:10
<MikeSmith>
if not I will
11:14
<MikeSmith>
oh but in this case the guy was reviewing a Rec
11:14
<Ms2ger>
At least he didn't punch anybody in the face
11:19
<jgraham>
Ms2ger: Not sure what's up with that review. I guess you mean the missing PR? I can fix that
11:19
<Ms2ger>
Yeah
11:19
<jgraham>
Although I don't know which one it is
11:19
<jgraham>
(I could look, but maybe you already did)
11:21
<Ms2ger>
jgraham, https://github.com/w3c/web-platform-tests/pull/238
11:22
Ms2ger
lunches
11:26
<jgraham>
Ms2ger: Fixed
11:26
<jgraham>
Looks like it got dropped and a new review was created
11:29
<Ms2ger>
jgraham, thanks
13:02
<sangwhan>
Silly question, if window.close() is implemented as a asynchronous function - what kind of side effects could that have? (Can't think of any, except for some strange scripts that run code after window.close() is called getting cut off - not sure if that's a really valid use case)
13:15
<jgraham>
Ms2ger: Shall I merge?
13:16
Ms2ger
looks
13:16
<Ms2ger>
I'll squash and merge
13:17
<jgraham>
OK
13:17
<jgraham>
Thanks
13:17
<Ms2ger>
And thank you!
13:23
<jgraham>
Ms2ger: Fancy looking at https://critic.hoppipolla.co.uk/r/268 while you are there? Looks like the submitter deleted their repo, but I don't know if there's anything we can salvage
13:24
<Ms2ger>
Possibly, yes
13:24
<Ms2ger>
I'll get to it eventually :)
13:26
<Ms2ger>
zcorpan, I assume I can ignore https://critic.hoppipolla.co.uk/r/307? :)
13:27
<jgraham>
Ms2ger: Sure, no particular rush
13:27
<jgraham>
I just get an email once an hour telling me it couldn't update the branch ;)
13:27
<Ms2ger>
Heh
13:27
jgraham
"solves" that by disabling tracking
13:28
<jgraham>
BTW if anyone has a review that they think I am the right person for, now is a good time
13:30
<Ms2ger>
There's actually something else I wanted to ask you... Is it possible to make an existing review track another repo, for the testtwf people who went missing in the months it took to get their PRs reviewed?
13:31
<jgraham>
Pretty sure it's possible, not sure there is UI for it
13:31
<zcorpan>
Ms2ger: yeah
13:32
<Ms2ger>
Alright, I'll look at pulling some of those into the w3c repo, then
13:32
<jgraham>
Ms2ger: You can click "they will review this" and stop getting email, if you like
13:33
Ms2ger
tries that
13:33
<jgraham>
Or maybe you still get email, but you are a watcher not a reviewer
13:34
<jgraham>
Ah, you probably have to click "Exclude me, please" to stop getting email
13:35
<zcorpan>
it should say "shut up!"
13:35
Ms2ger
tries that too
13:38
<jgraham>
zcorpan: Tell jl :p
13:39
<jgraham>
zcorpan: You will take https://critic.hoppipolla.co.uk/r/604 ?
13:39
<zcorpan>
jgraham: yes
13:39
<jgraham>
zcorpan: Great, thanks
13:47
<Ms2ger>
jgraham, if you're still looking, https://critic.hoppipolla.co.uk/r/608 :)
13:49
<jgraham>
Ms2ger: Did we decide anything about ArtB's readme files?
13:50
<jgraham>
https://critic.hoppipolla.co.uk/r/293 should be closed one way or another
13:51
<Ms2ger>
I think I asked for a link to the whatwg spec in another review
13:51
<Ms2ger>
Either that or I dreamed about ArtB
13:54
<jgraham>
Ms2ger: Hmm
13:55
<jgraham>
Anyway, other review done
13:55
<Ms2ger>
Thanks
13:55
Ms2ger
creates another
13:57
<jgraham>
Ms2ger: You are the ideal reviewer for https://critic.hoppipolla.co.uk/r/523 btw :)
13:59
<Ms2ger>
I even want to do it
13:59
<Ms2ger>
But not right now
13:59
<gsnedders>
You mean you have something better to do?
14:00
<Ms2ger>
Well, yes
14:00
<Ms2ger>
I'd kinda like to pass my next exam
14:01
<Ms2ger>
jgraham, https://critic.hoppipolla.co.uk/r/609
14:02
<Ms2ger>
With that done I'm pretty happy to start merging the other FileAPI PRs, I think
14:07
<gsnedders>
Ms2ger: People always told me exams weren't important!
14:07
<Ms2ger>
They're important in the sense that I'll have more time for useful work this summer if I pass it now :)
14:07
<darobin_>
gsnedders: maybe they're medical exams
14:07
<darobin_>
Ms2ger: you have a job, why the exams? :)
14:08
<Ms2ger>
Nah, I have a hobby
14:09
Ms2ger
moves back to the lovely world of the halting problem
14:13
<gsnedders>
Ms2ger: Have you solved it yet?
14:15
<jgraham>
darobin_: Don't set him down that road, lest he go all Swedish on us
14:15
<jgraham>
(half of Sweden seem to have a job and be 2 courses away from finishing their degree. And have been like that for a decade)
14:16
<darobin_>
jgraham: oh, I didn't know that — guess that makes me swedish :)
14:17
<MikeSmith>
q+ to say that OASIS WGs are all self-run
14:17
<jgraham>
MikeSmith: It's OK you can just say it :)
14:17
<MikeSmith>
q+ to say there is no process at OASIS, and no oversight -- they have nothing like team contacts
14:17
<MikeSmith>
oops
14:17
<gsnedders>
jgraham: Which arguably shows degrees are not considered important in Sweden
14:20
<jgraham>
gsnedders: I think s/Sweden/Opera/ in both our sentences to reflect sample bias.
14:21
<jgraham>
And I'm not sure it does show that
14:46
<Ms2ger>
jgraham, also Finland, from my sample of {smaug}
14:48
Ms2ger
grumbles
14:49
<Ms2ger>
With all those reviews being done, we're still at 126 open PRs
14:49
<jgraham>
Ms2ger: Can you put your script somewhere?
14:49
<jgraham>
Even just as a gist
14:49
<Ms2ger>
Yes
14:49
<jgraham>
or pastebin
14:50
Ms2ger
looks for the link he gave plh
14:51
<Ms2ger>
https://gist.github.com/Ms2ger/8440074
14:51
<jgraham>
Ms2ger: Thanks
14:51
<Ms2ger>
(You still need to fill in your own key)
14:52
<jgraham>
You don't want everyone to use yours?! ;)
14:52
<Ms2ger>
I don't think I'd like that :)
15:02
<Ms2ger>
125!
15:02
<Ms2ger>
(Same as 26 December and 17 January)
15:05
<Ms2ger>
A final useless statistic: merge one more PR and we're at the lowest level this year
15:06
<Ms2ger>
Really final: 7 more and we're at the lowest after the last testtwf
15:10
<MikeSmith>
I have one open that I'll try to finish
15:10
<MikeSmith>
Media Source Extensions interface tests
15:11
<MikeSmith>
which plh made review comments on already
15:33
<sangwhan>
MikeSmith: These are just sanity checks if the interface/members exist for MSE, right?
16:15
<DavidBruant>
darobin_ yo
16:15
<darobin_>
hi DavidBruant!
16:15
<DavidBruant>
so we were saying iframe@sandbox tests
16:15
darobin_
is in a meeting, but Ms2ger can reply :)
16:15
<annevk-cloud>
Whoa, a rare DavidBruant appears
16:16
<DavidBruant>
so I want to add tests about iframe@sandbox
16:16
<Ms2ger>
Ha
16:16
<Ms2ger>
I think I've seen some
16:17
<Ms2ger>
https://critic.hoppipolla.co.uk/r/160
16:17
<DavidBruant>
on Twitter, darobin_ suggested to put them in https://github.com/w3c/web-platform-tests/tree/master/html/semantics/embedded-content-0/the-iframe-element
16:17
<Ms2ger>
Want to review those?
16:17
<DavidBruant>
I've seen a bunch a submissions from Microsoft as well
16:18
<DavidBruant>
I have particular things in mind like code.google.com/p/chromium/issues/detail?id=277084
16:18
<DavidBruant>
oops
16:18
<Ms2ger>
I haven't, but feel free to review those too :)
16:18
<DavidBruant>
I meant https://bugzilla.mozilla.org/show_bug.cgi?id=907892
16:19
<DavidBruant>
I'm also looking at everything that could get in the way of https://bugzilla.mozilla.org/show_bug.cgi?id=961689
16:19
<DavidBruant>
I think named accessed will be such a thing
16:20
<Ms2ger>
Feel free to submit extra tests too, but I'd really like those reviewed :)
16:21
<DavidBruant>
I'm worried that sandboxing doesn't change anything to the result of http://people.mozilla.org/~bholley/testcases/cross-origin-named-window/test.html
16:22
<DavidBruant>
And I felt that given I'm spending the time looking into this issue, I'd rather make web-platform-tests from the get go
16:23
<jgraham>
DavidBruant: ++
16:24
<DavidBruant>
I'll look into reviewing the tests you're referring to ('cause sandboxed iframes are AWESOME), but later...
16:24
<Ms2ger>
DavidBruant++
16:25
<DavidBruant>
... I need to get the existing test running first *cough cough*
16:25
<DavidBruant>
(for whatever reason, I fail to generate the MANIFEST.json file)
16:25
<jgraham>
DavidBruant: How are you trying to generate it?
16:26
<DavidBruant>
Ms2ger should the review happen on the critic thing or github?
16:26
<DavidBruant>
jgraham python tools/scripts/manifest.py MANIFEST.json
16:26
<Ms2ger>
I prefer on critic
16:26
<jgraham>
DavidBruant: Preferably critic, but github if you really don't like learning better tools
16:26
<jgraham>
DavidBruant: That looks sensible. What is happening?
16:26
<DavidBruant>
I get this message "INFO:Web platform tests:Working directory not clean, adding local changes", but I'm not sure why or what to do
16:27
<DavidBruant>
"if you really don't like learning better tools" :-D
16:27
<DavidBruant>
ok, I'll do critic
16:30
<jgraham>
DavidBruant: Ah, right, yeah, the error message there isn't very clear
16:30
<jgraham>
If you have changes in your git it won't write the manifest file at the moment
16:30
<jgraham>
s/git/working tree/
16:31
<DavidBruant>
hmm... git status gives me "modified: tools/pywebsocket (untracked content)"
16:31
<DavidBruant>
not sure I did that...
16:31
<jgraham>
Hmm
16:31
<MikeSmith>
sangwhan: yeah specifically they test whether the implementation of the interface/members conforms to the WebIDL definition for the interface in the spec
16:32
<jgraham>
try seeing what git status in that directory gives
16:33
<DavidBruant>
jgraham a bunch of src/mod_pywebsocket untracked files
16:33
<DavidBruant>
was that all generated via python serve.py?
16:34
DavidBruant
knows nothing about python and feels helpless :-/
16:34
<MikeSmith>
sosangwhan: I wouldn't call them "sanity checks". they're conformance checks
16:36
<annevk>
DavidBruant: it's like JavaScript really, without all the braces
16:36
<DavidBruant>
:-)
16:37
<DavidBruant>
It all looks related to the pywebsocket submodule?
16:38
<jgraham>
DavidBruant: That seems very odd. No idea why there should be files there
16:38
<jgraham>
try reset --hard?
16:43
<Ms2ger>
jgraham, they're all .pyc's
16:44
<DavidBruant>
Obviously now python serve.py doesnt work cause "ImportError: No module named mod_pywebsocket"
16:44
<DavidBruant>
:-p
16:46
<jgraham>
Hmm, if pyc files aren't in the gitignore that seems problematic
16:47
<jgraham>
DavidBruant: It is hard to work out what state your repo is in, but maybe from the top level directory try git submodule update --recursive
16:47
<DavidBruant>
yep
16:47
<DavidBruant>
I have the tests running now :-) Thanks for the help
16:47
<Ms2ger>
jgraham, what's up with https://critic.hoppipolla.co.uk/r/15?
16:47
<dglazkov>
good morning, Whatwg!
16:48
<arunranga>
annevk, is the idea of taking a reference during the parsing URL steps the correct approach to https://www.w3.org/Bugs/Public/show_bug.cgi?id=17765 ?
16:48
<DavidBruant>
I'll file an issue to w3c/web-platform-tests with the relevant parts of our chat
16:49
<Ms2ger>
dglazkov, hey, had time to look at those tests already?
16:49
<dglazkov>
Ms2ger: no, I was holidaying.
16:49
<annevk>
The other idea I had was that after parse, you check the table, and then if the identifier is not in the table, you return the URL "blob:invalid" or some such. Of course, that means that if you parse the URL again things will fail, but I guess that's the same with your approach, no?
16:49
<annevk>
arunranga: what do you think of that?
16:50
<annevk>
arunranga: well, I guess the UA would be required to keep additional state around anyway.
16:51
<jgraham>
DavidBruant: Excellent
16:51
<arunranga>
annevk, by "after parse" do you mean, fetch? One of my concerns is that since fetch happens asynchronously, it may have an invalidated ref but the one held during parse might be valid.
16:51
<dglazkov>
also critic is scary. It sends me email and tells me to do stuff. I worry for my safety
16:51
<Ms2ger>
:D
16:51
<DavidBruant>
jgraham how can I easily run one test ?
16:52
<Ms2ger>
dglazkov, you don't want to know what happens if you don't do those reviews... :)
16:52
<dglazkov>
8-{
16:52
<jgraham>
DavidBruant: --include /url/of/test.html
16:52
<DavidBruant>
jgraham on serve.py?
16:53
<annevk>
arunranga: no I meant at the end of URL parsing, before the URL parser returns, sorry
16:53
<jgraham>
DavidBruant: Oh, sorry, no, I was thinking of my test runner
16:53
<jgraham>
DavidBruant: Which you presumably don't have :)
16:53
<annevk>
arunranga: I agree it needs to happen either during parsing or as a wrapper for parsing
16:53
<jgraham>
DavidBruant: How are you running > 1 test?
16:53
<DavidBruant>
jgraham, I thing the "Run tests under path" will be enough
16:53
<annevk>
arunranga: the main architecture problem I see is that people are used to pass URLs around as strings
16:54
<DavidBruant>
I'll pick the right directory and run the few tests there
16:54
<annevk>
arunranga: and this would require URLs to be passed around as objects
16:54
<arunranga>
annevk, in general, I'm wondering if there are cases where something is not in the Blob URL Store owing to a synchronous URL.revokeObjectURL or a global script cleanup steps (where the list is purged) but it is still something that parse holds.
16:54
<DavidBruant>
jgraham, I use http://web-platform.test:8000/tools/runner/index.html
16:54
<DavidBruant>
(locally of course)
16:54
<arunranga>
annevk, yes, that's the problem.
16:54
<DavidBruant>
As suggested at https://github.com/w3c/web-platform-tests#test-runner
16:56
<jgraham>
DavidBruant: Right, then enter the path in the little box
16:56
<DavidBruant>
yeah, I'll do that. Thanks :-)
16:57
<jgraham>
(or, if it is just one test, just load the URL)
17:02
<DavidBruant>
Filed https://github.com/w3c/web-platform-tests/issues/544
17:08
<jgraham>
Ms2ger: I don't know, what is up with that PR?
17:11
<Ms2ger>
jgraham, is anything going to happen with it?
17:13
<jgraham>
Ms2ger: I don't know
17:15
<jgraham>
I am still not happy about having random commented out code
17:15
<jgraham>
But I generally don't care too much about the default testharnessreport.js
17:26
<Ms2ger>
gsnedders, that's not a lot of tabs...
17:26
Ms2ger
is at 500
17:39
<gsnedders>
Ms2ger: Pretty certain bratell still has you beat.
17:39
<Ms2ger>
That's plausible
17:44
<Ms2ger>
arunranga, around?
17:44
<arunranga>
Hi ms2ger!
17:44
<Ms2ger>
I'm looking at the spec for Blob.close()
17:44
<Ms2ger>
It says "This must be [a] non-idempotent operation"
17:45
<arunranga>
I think we should define a "Closed State" on Blobs.
17:45
<Ms2ger>
Explain? :)
17:45
<arunranga>
This was taken from Transferable's close
17:46
<Ms2ger>
I see
17:46
<Ms2ger>
Hixie, explain
17:47
<arunranga>
A separate bug was filed on separating the transferable close from Blob's close. Explanation: it shouldn't be there, and should be fixed in https://www.w3.org/Bugs/Public/show_bug.cgi?id=24339
17:47
<Ms2ger>
Yeah, that would probably be better
17:56
<Ms2ger>
arunranga, do you know if anybody implements close yet?
17:59
<Ms2ger>
arunranga, feel free to review https://github.com/w3c/web-platform-tests/pull/545 :)
18:00
<arunranga>
Ms2ger, nobody (yet) implements close
18:00
<arunranga>
Ms2ger, great :)
18:05
<gsnedders>
Man, I always forget how horrible implementing the tokenizer is.
18:06
<Ms2ger>
That's probably the first time that sentence has been uttered
18:06
<jgraham>
Yeah, seriously, how did you forget?
18:06
<jgraham>
But mostly it's just dull
18:12
<gsnedders>
jgraham: It's the dullness that makes it horrible. I forgot because I tried to block out the memory.
18:12
<gsnedders>
(I maintain my prior position of hating zcorpan for introducing all the script states)
18:52
<Hixie>
Ms2ger: here now (not sure what you wanted me to explain)
18:52
<Hixie>
gsnedders: yeah, i recommend mechanical translation of some sort :-)
18:53
<Ms2ger>
Oh no, you're actually right
18:53
<Ms2ger>
I think
18:53
<Ms2ger>
So it's only Arun who doesn't know what idempotent means
18:55
<jamesr__>
"middle endian" ?
18:56
<gsnedders>
Hixie: Sadly doesn't work that easily in this case (I can't have shared state!).
18:56
<jgraham>
What's a hobbit's favourite byte order?
18:57
<jensnockert_>
Little endian?
18:58
<jensnockert_>
Oh, wait… I failed.
19:07
<Hixie>
jamesr__: it does exist... sadly
19:07
<Hixie>
jamesr__: http://en.wikipedia.org/wiki/Endianness#Middle-endian
19:07
<Hixie>
jamesr__: apparently the PDP-11 was middle-endian for 32 bit values
19:08
<Hixie>
and "The ARM architecture can also produce this format when writing a 32-bit word to an address 2 bytes from a 32-bit word alignment", which sounds awful
19:08
<jensnockert_>
The Wii has a similar endian sometimes.
19:09
<jensnockert_>
(http://wiibrew.org/wiki/Reversed_Little_Endian)
19:10
<Hixie>
gsnedders: how do you mean?
19:10
<Hixie>
gsnedders: i meant mechanically convert teh HTML spec text to your implementation
19:11
<gsnedders>
Hixie: The spec text uses shared state (say, the temporary buffer). This complicates things with an implementation that cannot use shared state (because the language doesn't allow it).
19:11
<Hixie>
jensnockert_: man, that's messed up
19:11
<Hixie>
gsnedders: ah, right
19:12
<jensnockert_>
Nintendo is well-known for silly hardware stuff.
19:12
<gsnedders>
Hixie: So, basically there's no simple 1:1 mapping to do a mechanical convertion. So yay ALL THE SCRIPT STATES!
19:12
gsnedders
glares at zcorpan
19:12
gsnedders
notes this was more effective when they originally got added to the spec, sharing an office with zcorpan
19:13
jgraham
notes http://xkcd.com/1319/ which is relevant to "just automate it"
19:14
<Hixie>
gsnedders: well, at least you can convert the states and switch statements, even if the bodies aren't as easy
19:15
<Hixie>
jgraham: that diagram is misleading. it fails to take into account how much more fun writing the automation is than the original task. :-)
19:17
<jgraham>
Hixie: True, but I don't think the graph claims to represent happiness, only effort
19:18
<Hixie>
right, that's why it's misleading, not wrong :-)
19:18
<Hixie>
the "effort" spent on the task is implied to be uninteresting (otherwise why would you want to get rid of it), and the result is depicted as "worse" because there's more total effort spent and no free time left.
19:19
<Hixie>
but the efforts are qualitatively different
19:19
<jsbell>
Until you end up maintaining the automated tool for other users and it ceases to be shiny
19:19
<jgraham>
But both may be worse than free time that you could in theory use to do your highest-reward activity
19:20
jgraham
notes that real life is not really like economics in this way
19:20
<Hixie>
jsbell: i think the implication here is you never get to that state, since if you did, that would imply the tool worked enough to get rid of the original task :-)
19:24
<SimonSapin>
http://www.w3.org/TR/CSS21/syndata.html#charset talks about "2143 endianness" for UTF-32…
19:25
<Hixie>
UTF-32 on the web is dead, that should just be dropped.
19:25
<Hixie>
HTML and the Encoding spec just say MUST NOT support UTF-32, iirc
19:26
<Hixie>
actually HTML just discourages it
19:26
<Hixie>
i guess we reserve MUST NOT for the ones with truly bad results like CESU-8, UTF-7, BOCU-1 and SCSU.
19:26
<gsnedders>
The Encoding spec, as I read it, enumerates everything you MUST support, and everything else MUST NOT be supported, implicitly.
19:27
<SimonSapin>
yes, that chapter is made obsolete by http://dev.w3.org/csswg/css-syntax/ , but I’d still like to get rid of the encoding nonsense in CSS2
19:28
<Hixie>
SimonSapin++
19:34
<Ms2ger>
SimonSapin, probably not worth it
19:44
<Hixie>
does 'z-index' has an official maximum value these days?
19:56
<JonathanNeal>
Hixie: depends if the browser supports higher than 32-bit values?
19:56
<Hixie>
that's unfortunate
19:56
<Hixie>
but likely true
19:56
<JonathanNeal>
http://css-tricks.com/rational-z-index-values/ "I was seeing z-index: 1.62909e+07"
19:57
<JonathanNeal>
Also http://www.puidokas.com/max-z-index/
19:59
<bholley>
Hixie: yt?
20:00
<bholley>
Hixie: just wanted to check if bug 20701 was on your list
20:01
<bholley>
Hixie: seems like we should act while we have travis' attention ;-)
20:01
<arunranga>
Ms2ger, sorry, got disconnected before.
20:01
<arunranga>
Ms2ger may actually leave "non-idempotent" in because it's right.
20:02
<Ms2ger>
arunranga, is it? Explain :)
20:02
<Hixie>
bholley: yeah.
20:03
<arunranga>
You can't do the same operation again. It's a one time only. You can't reactivate a closed (0 bytes) resource.
20:03
<Hixie>
bholley: to your first point in comment 124, consider prose like "As mentioned earlier, each browsing context has a WindowProxy object. This object is unusual in that all operations that would be performed on it must be performed on the Window object of the browsing context's active document instead."
20:04
<Hixie>
bholley: on the overall point of needing a summary, i vote you write it up this time :-)
20:04
<Hixie>
bholley: if implementations are on board, btw, doesn't matter how hard it is for me to spec it, i'll deal
20:04
<Ms2ger>
arunranga, okay, what do you think "idempotent" means?
20:05
<arunranga>
You get the same result upon the same operation.
20:05
<bholley>
Hixie: can you at least put it on some kind of wiki-ish thing where we can iterate on it?
20:06
<arunranga>
But https://www.w3.org/Bugs/Public/show_bug.cgi?id=24339 is still a bug.
20:06
<arunranga>
And much of it has to be redone.
20:07
<Ms2ger>
So blob.close(); blob.close()
20:07
<Ms2ger>
What happens on the second call?
20:07
bholley
lunches
20:07
<Hixie>
bholley: travis said he preferred the bug. i kinda do too (the history is more obvious that way)
20:08
<Hixie>
bholley: we can iterate on the bug fine. it's not like final spec text is being iterated here, it's just a description of what needs doing.
20:08
<bholley>
Hixie: I don't think he really said that, but the bug is fine by me
20:09
<Hixie>
if you want to put it on a wiki it's fine too, feel free to copy and paste my text :-)
20:10
<bholley>
Hixie: I'll take a crack at it after lunch
20:10
<bholley>
Hixie: is there a w3 or whatwg wiki somewhere?
20:10
<arunranga>
It should throw, just as reading on a closed blob throws. So it probably shouldn't say non-idempotent, which I think is your point?
20:11
<arunranga>
The intent is to not allow re-opening a closed blob.
20:11
<bholley>
eh, I'll just use an etherpad
20:12
<Hixie>
bholley: wiki.whatwg.org
20:12
<Hixie>
bholley: if you don't have an account there let me know i'll create one
20:12
<bholley>
Hixie: yeah, but looks like getting an account on that is a pain
20:12
<Hixie>
bholley: etherpad works too
20:12
bholley
really lunches
20:12
<Hixie>
it's not a pain, just give me your e-mail address
20:12
<bholley>
Hixie: bobbyholley⊙gc
20:13
<Hixie>
done
20:13
<Hixie>
oh hey, the wiki got better
20:13
<Hixie>
nice
20:13
<Hixie>
account creation page is nicer, anyway
20:15
Hixie
finds two e-mails in this inbox back to back: one from dreamhost saying his machine had to be rebooted due to memory usage issues, and one from the google webmaster tools saying his site was down.
20:42
<tbsaunde>
Hixie: is there a more recent discussion of the canvas draw focus ring stuff than http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2013-October/040974.html ?
21:29
<Hixie>
tbsaunde: iirc there's a bug about it?
21:30
<Hixie>
tbsaunde: wait, october. yes, there's definitely more recent stuff on the whatwg list about ot
21:30
<Hixie>
it
21:31
<Hixie>
tbsaunde: e.g. http://lists.w3.org/Archives/Public/public-whatwg-archive/2014Jan/0033.html
21:31
Hixie
doesn't really understand what's going on with that API
21:31
<Hixie>
it seems to have been coopted for a different purpose than it was intended for
21:32
Ms2ger
never quite figured out what it was intended for
21:34
<Hixie>
drawing a focus ring, and optionally telling the AT that it should move its focus/magnifier to that part of the canvas
21:37
<Hixie>
Ms2ger: can you elaborate on https://www.w3.org/Bugs/Public/show_bug.cgi?id=24327 ?
21:37
<Ms2ger>
Hixie, follow the link and look for "img"
21:39
<Hixie>
yes?
21:39
<Hixie>
why would <img> be listed there?
21:40
<Ms2ger>
Because...
21:40
<Ms2ger>
http://www.whatwg.org/specs/web-apps/current-work/multipage/embedded-content-1.html#the-img-element links to http://www.whatwg.org/specs/web-apps/current-work/multipage/the-map-element.html#attr-dim-width
21:40
<Hixie>
oh you're complaining that #attr-dim-width links to #dimRendering in "User agent requirements: User agents are expected to use these attributes as hints for the rendering.
21:40
<Hixie>
" ?
21:41
<Ms2ger>
Yep
21:41
<Hixie>
hmm
21:41
<Ms2ger>
And that afaict, img width="" doesn't actually do anything per spec
21:42
<Hixie>
i wonder why it's not listed there
21:42
<Hixie>
huh
21:43
<Streusel>
has dc.title & dc.description been added yet?
21:43
<Hixie>
Ms2ger: it's there in r2757...
21:43
<Hixie>
Ms2ger: and that lasts til at least r7000
21:44
<Ms2ger>
Heh
21:45
<Hixie>
was removed in r7614...
21:45
<Hixie>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=17630
21:45
<Hixie>
i guess it was a mistake
21:46
<Hixie>
very odd
21:46
<Ms2ger>
I suspected it would be
21:47
<Hixie>
k, fix should be in soon
21:48
<Ms2ger>
Thanks
21:49
<Ms2ger>
Hixie, btw, the diff that removed it might have been easier to read if you hadn't also changed the line length in the same commit :)
21:49
<Hixie>
yeah, i've stopped doing that
21:49
<Hixie>
now i mark the paragraph as CLEANUP when i make changes
21:50
<Hixie>
and later go back and reflow the paragraphs
21:50
<Ms2ger>
Good :)
21:52
<tbsaunde>
Hixie: k, thanks, that API seems to have some issues imho
21:53
<Hixie>
tbsaunde: what are the issues?
21:54
<tbsaunde>
Hixie: my biggest one is that the element and its related accessible object already have bounds so makingthe focus ring its bounds seems really wrong
21:55
<tbsaunde>
in layout terms it seems like laying out a page, and then picking up the one elmeent and putting it someplace possible different from where it was without adjusting any of the other elements
21:55
<tbsaunde>
but it looks like you already got that in the mail you linked (reading now)
21:56
<Hixie>
tbsaunde: you mean bounds from addHitRegion()? the drawFocusRing() API doesn't set any bounds, it just does a one-time move of the magnification.
21:59
<tbsaunde>
Hixie: from the spec it seems like the path on the canvas is used as the bounds of the accessible object for the element passed to it, or did I read the wrong spec?
21:59
<Hixie>
tbsaunde: what in the spec makes you interpret it that way? a lot of people have interpreted it that way, but that wasn't what i intended.
22:01
<tbsaunde>
Hixie: its certainly what cabanier wants to do in gecko, looking up the spec again now
22:01
<Hixie>
yes, rik has all kinds of (imho crazy) ideas about what the API should do, that have little to do with what i specced.
22:02
<Hixie>
that's what i was referring to above when i said "it seems to have been coopted for a different purpose than it was intended for"
22:05
<tbsaunde>
Hixie: yeah, still haven't gotten through the mail :(
22:05
<tbsaunde>
I'd expect the language that would make you think that behavior is correct is Inform the user that the focus is at the location given by the intended path.
22:05
<cabanier>
tbsaunde: you should talk to roc
22:05
<cabanier>
tbsaunde: these are no my crazy ideas
22:06
<cabanier>
tbsaunde: this is how it already is implemented in chrome
22:06
<cabanier>
tbsaunde: and I had nothing to do with that
22:07
<tbsaunde>
I haven't rad chrome's code, but that sounds crazy
22:07
<cabanier>
what sounds crazy?
22:07
<Hixie>
tbsaunde: i don't see how "Inform the user that the focus is at the location given by the intended path" implies anything to do with setting anything persistent
22:08
<Hixie>
tbsaunde: in particular, it certainly doesn't seem to imply anything about the element
22:10
<tbsaunde>
Hixie: so, I guess I read the spec wrong or something, but fwiw I think the logic people are using is "the way you notify accessibility of where focus is is by focusing an accessible object, which they seem to think you should get from the element passed in and then since your saying the focus is at a point you make that accessible object be at that point
22:10
<Hixie>
tbsaunde: yeah... that's not a good way to read specs. :-) specs say what they mean, one shouldn't read between the lines.
22:10
<Hixie>
tbsaunde: at least, my specs do
22:11
<Hixie>
tbsaunde: there _is_ an API to actually set the bounds of specific elements, the addHitRegion() API
22:11
<Hixie>
tbsaunde: but that's an entirely different thing
22:13
<tbsaunde>
Hixie: yeah, this seems a lot more reasonable :-)
22:15
<Hixie>
tbsaunde: do you have any suggestion for how i can rewrite the "inform the user..." text to be less misleading?
22:35
<tbsaunde>
Hixie: I want to spend some time thinking about the hit region stuff, and actually understanding how this works then I'll try
22:35
<Hixie>
tbsaunde: cool, thanks
22:35
<tbsaunde>
sorry I was confused
22:35
<tbsaunde>
np
22:44
<Hixie>
tbsaunde: given the recent discussions about this, i'm equally confused, so no apology needed!
22:45
<Hixie>
tbsaunde: not that one ever needs to apologise for being confused after reading a spec, it's basically always the spec writer's fault :-)
22:47
<tbsaunde>
heh
23:11
<tbsaunde>
Hixie: oh, so I think another think that helped confuse me is this at the end of the scrollPathIntoView() description " "Inform the user", as used in this section, could mean calling a system accessibility API, which would notify assistive technologies such as magnification tools. To properly drive magnification based on a focus change,
23:11
<tbsaunde>
a system accessibility API driving a screen magnifier needs the bounds for the newly focused object. The methods above are intended to enable this by allowing the user agent to report the bounding box of the path used
23:11
<tbsaunde>
to render the focus ring as the bounds of the element element passed as an argument, if that element is focused, and the bounding box of the area to which the user agent is scrolling as the bounding box of the current
23:11
<tbsaunde>
selection." which since the inform ... isn't explained for the draw*FocusRing() methods so I assumed it applied to both
23:12
<tbsaunde>
that said it seems wrong for the scrollIntoView method too
23:12
<Hixie>
that text is kinda confusing, yeah
23:12
<Hixie>
that'll teach me to have non-normative text...
23:13
<Hixie>
every time i try to explain things, people rely more on the non-normative text than the normative text. d'oh.
23:13
<tbsaunde>
especially since all the accessibility APIs are stateful here
23:14
<Hixie>
yeah
23:14
<Hixie>
it might be that the right solution is just to make these methods not tell the ATs anything
23:14
<tbsaunde>
what did you actually mean? I can't see what happens on screen but I'd assume the focus ring *is* the notification that that thing is focused
23:14
<Hixie>
and tell authors to use addHitRegion() only
23:15
<Hixie>
tbsaunde: what i originally meant was that you'd call drawSystemFocusRing() with a focused element, and the magnification would move, end of story
23:16
<cabanier>
Hixie: in our last exchange I stated this:
23:16
<cabanier>
> Informing the user is an imperative action, not an indirect action
23:16
<cabanier>
> involving caching state over multiple frames.
23:16
<cabanier>
If that is the case, we should drop focus ring support. There's no point to just draw rings.
23:17
<tbsaunde>
Hixie: yeah, still thinking, but it seemslike the right thing to do is have the fall back content / hit regions set up and then have draw focus ring not tell the AT anything
23:17
<tbsaunde>
(other than fire a focus event on the accessible that is getting focused of course
23:17
<Hixie>
cabanier: right (though of course we still want to draw focus rings in general, separate from ATs)
23:17
<cabanier>
Hixie: why?
23:18
<cabanier>
Hixie: the API as currently implemented by chrome is quite useful according to the a11y people
23:18
<Hixie>
tbsaunde: yeah. the problem there is that most authors aren't going to bother to use addHitRegion(), i'd guess... i wonder how many authors would use draw*FocusRing() but not addHitRegion(), maybe the number of people who want system focus rings is so low that actually all the people who'd do it half right with focus rings will just do it entirely right with hit regions, dunno.
23:18
<cabanier>
Hixie: It is a bit wonky
23:18
<Hixie>
cabanier: why what?
23:19
<cabanier>
why would you still want an API for focus rings if all it does is draw focus
23:19
<Hixie>
cabanier: i've not seen anyone say that the API is actually useful, do you have a pointer for where that's discussed?
23:19
<Hixie>
cabanier: so you can draw the focus ring?
23:19
<Hixie>
cabanier: how else would you draw one?
23:20
<cabanier>
Hixie: the author can draw it. There's nothing magical going on
23:20
<tbsaunde>
Hixie: yeah, that's a valid concern, but I'm not really sure how we make draw*FocusRing() work usefully
23:21
<Hixie>
cabanier: how do you draw a native-looking focus ring? i don't follow.
23:21
<Hixie>
tbsaunde: yeah
23:21
<cabanier>
Hixie: I agree that the there's a high barrier for addHitRegion so it won't see much adoption
23:21
<Hixie>
cabanier: why do you think the barrier is high?
23:22
<cabanier>
Hixie: because the author would have to make sure that the region DOM is in sync with what's on the page
23:23
<Hixie>
cabanier: do you think the barrier to using draw*FocusRing() is significantly lower? (notwithstanding the fact that that API doesn't actually work well for ATs)
23:23
<Hixie>
cabanier: it seems like it'd be nearly the same code
23:24
<cabanier>
Hixie: you'd have to keep track of the id and add/remove regions
23:24
<cabanier>
Hixie: with draw*Ring, that all happens behind the scenes
23:26
<Hixie>
cabanier: no, the regions get removed automatically with addHitRegion()
23:27
<tbsaunde>
Hixie: I wonder if we can make hit regions simpler? why can't we nuke the label / control / role stuff, and just always have them point at a element that is a child (or inderct child) of the <canvas> ?
23:27
<Hixie>
cabanier: you just have to call x.addHitRegion({ control: element }); whenever you draw the path for the control
23:28
<Hixie>
tbsaunde: simpler for whom? implementors or authors?
23:28
<Hixie>
cabanier: (if you remove a control entirely, but are calling clearRect() regularly, then you don't even have to worry about the control being removed, unlike the mess that would result from the focus ring stuff being repurposed in this way)
23:28
<tbsaunde>
I was thinking it would be simpler for authors since it would just be one consistant way of doing things
23:29
<Hixie>
tbsaunde: well, there's several kinds of authors. Some will have a backing DOM, but others won't (what would the backing DOM be for a game?)
23:29
<Hixie>
tbsaunde: as specced, it lets you put labels all over the canvas, without having to worry about having <span>s for each such label
23:29
<Hixie>
tbsaunde: think e.g. of a chart, how would you design a functional backing DOM for it?
23:29
<tbsaunde>
not really clear other than a bunch of divs, but what would be the a11y story there anyway?
23:30
<Hixie>
well it depends on the user
23:30
<Hixie>
but e.g. an entirely blind users on a tablet could use tactile feedback to feel their way around the canvas, with addHitRegion() roles and labels
23:30
<tbsaunde>
that seems reasonable
23:31
<Hixie>
a user with low sight but enough sight to see the image, who just need magnification, could jump from label to label and see that zoomed in
23:31
<Hixie>
a user who cannot read but can rely on speech synthesis could walk around the canvas using a mouse, and have the labels read out
23:31
<tbsaunde>
on the other hand since you only get a couple types of form control or (label, role) your kind of restricted
23:32
<Hixie>
what kind of stuff are you imagining that can't be done?
23:33
<Hixie>
tbsaunde: (btw, i changed that paragraph you quoted to hopefully be less confusing)
23:33
<tbsaunde>
well, you wouldn't get accessible states, so if you wanted to have editable text I'm not sure how you'd mark it as editable
23:34
<Hixie>
as far as editable text goes, i refer you to http://www.whatwg.org/html#best-practices
23:34
<Hixie>
uh http://www.whatwg.org/specs/web-apps/current-work/#best-practices
23:35
<Hixie>
ah, http://www.whatwg.org/html#best-practices does work
23:36
<tbsaunde>
Hixie: fair, I could probably think of other stuff but its kind of corner casey
23:39
<Hixie>
i mean, there's always things that can't be done, but that's true regardless of whether you're using canvas or not.
23:39
<Hixie>
if there's things that can't be done that could easily be supported, we can always improve the API.
23:40
<tbsaunde>
Hixie: so, as an implementor of this virtual dom tree how do I handle order of children? / is there a way to insert a child before another?
23:40
<Hixie>
you mean the addHitRegion() one?
23:40
<Hixie>
it's unordered. or rather, it's ordered by visual order.
23:42
<tbsaunde>
yeah, visual order makes sense