08:52
<zcorpan>
jgraham: hmm. seems like the introduction of transferrable changed the semantics of postMessage(string, '*', []) such that the event.data is an object rather than a string...
08:54
<jgraham>
zcorpan: Oh, so we have lots more updating to do?
08:54
<jgraham>
I started looking at your latest batch of changes
08:55
<zcorpan>
maybe. i don't like the current situation with almost identical tests, maybe i should just kill the "with ports" ones and add a few tests that do more interesting things with ports and transferables
08:56
<zcorpan>
i just don't understand where the object comes from, in the spec
09:05
<zcorpan>
jgraham: wait, does testharness send message events to the test case?
09:06
<zcorpan>
argh!
09:06
<jgraham>
zcorpan: Er, yeah, as of recently it does :(
09:06
<zcorpan>
why
09:06
<zcorpan>
and can i disable it
09:06
<jgraham>
tobie needed it. I dont remember why
09:06
<jgraham>
I should have thought of this at the time :(
09:06
<zcorpan>
it should be opt-in
09:07
<jgraham>
Well, the problem is that it's for running the tests in a harness
09:07
<jgraham>
Making it opt-in doesn't make sense
09:07
<zcorpan>
ah
09:07
<jgraham>
(at least I think that's why)
09:08
<zcorpan>
sigh
09:09
<jgraham>
Sorry
09:09
<zcorpan>
it just shouldn't send the events to the page itself
09:09
<zcorpan>
it can send events to parents and openers, fine
09:09
<tobie>
hey
09:11
<jgraham>
tobie: http://krijnhoetmer.nl/irc-logs/whatwg/20130313#l-251
09:11
<tobie>
yes, just went through the logs
09:11
<tobie>
have to go back through the code.
09:11
<zcorpan>
forEach_windows i guess
09:12
<jgraham>
YEah, it is possible to stop it sending events to the test window itself. I just wonder if anything depends on that
09:12
<jgraham>
I think we might have to and fix the dependencies
09:12
<jgraham>
This is way too much of a sharp edge
09:12
<zcorpan>
s/cache = [[self, true]];/cache = [];/ ?
09:13
<jgraham>
No, we can't change it there
09:14
<jgraham>
The callbacks on the same window should still work
09:15
<jgraham>
I think the right fix is s/if(supports_post_message(w))/if(supports_post_message(w) && w !== self)/g
09:15
<tobie>
yes
09:15
<tobie>
in all three places.
09:15
<zcorpan>
yeah
09:15
<zcorpan>
tobie: can you fix it?
09:16
<tobie>
sure. Is the canonical repo still the hg one?
09:16
<jgraham>
No, it's the github one
09:16
<jgraham>
I think
09:16
<tobie>
the testharness one?
09:16
<tobie>
or the html suite one?
09:16
<zcorpan>
the testharness one
09:16
<jgraham>
The testharness os gets synced to /resources/ on w3c-test.org
09:17
<jgraham>
And it is the canonical testharness.js repo. as far as I'm concerned
09:17
<jgraham>
It's the one hooked up to critic, for example ;)
09:17
<zcorpan>
should we kill the other testharnesses?
09:18
<tobie>
yes please.
09:19
<tobie>
w !== self or w !== window? (I can't remember the difference between the two)
09:19
<jgraham>
self === window
09:20
<jgraham>
Gotta love the DOM
09:21
<tobie>
is it always the case?
09:21
<tobie>
isn't self different within frames or something?
09:21
<jgraham>
http://www.whatwg.org/specs/web-apps/current-work/multipage/browsers.html#dom-self
09:21
<tobie>
Man, I'm getting rusty.
09:33
<tobie>
zcorpan: sorry, weird rebasing issues.
09:38
<tobie>
jgraham, zcorpan: https://github.com/w3c/testharness.js/pull/12/files
09:39
<tobie>
Turns out these weren't weird rebasing issues, but that the PR was automatically done against jgraham's repo (not uptodate) rather than mine.
09:39
<tobie>
s/mine/w3c's/
09:39
<zcorpan>
tobie: thanks
09:40
<tobie>
yet another sign we should probably clarify what the canonical repo is.
09:41
<jgraham>
yeah, apparently I need to email github or something to get testharness.js root to be the W3C copy
09:41
<tobie>
(jgraham you'll need to update your repo, delete W3C's and then transfer yours). Will probably break a number of things in the process.
09:41
<jgraham>
It would be nice if they had UI for it
09:41
<tobie>
they do.
09:41
<tobie>
In admin tools.
09:41
<jgraham>
odinho claimed that an email would be enough
09:42
<tobie>
I doubt it given they have UI for it.
09:42
<tobie>
but who knows.
09:42
<jgraham>
They have UI to solve a different problem
09:42
<jgraham>
AFAICT
09:43
<zcorpan>
now my test passes
09:43
<tobie>
zcorpan: awesome.
09:43
<odinho>
I claimed and it was correct :-)
09:43
<jgraham>
odinho: Who do I mail?
09:44
<odinho>
I did it for another project. T'was easy. support⊙gc
09:44
<odinho>
tobie: No UI for changing roots :-)
09:45
<odinho>
tobie: Although you can hack around it like you suggest. But hacky hacky.
09:45
<tobie>
yeah, hacky. hacky.
09:45
<tobie>
But you're both right. The problem is a different one.
09:46
<tobie>
And changing root is the way to go about it.
09:46
<jgraham>
OK, email sent
09:51
<tobie>
Nice.
09:52
annevk
hopes Fake Alex wakes up soon
09:57
<jgraham>
And real Alex stays asleep?
10:06
<zcorpan>
wonder what to do with data: and same-origin. should we change the spec there?
10:06
<zcorpan>
chrome's behavior is kinda annoying
10:07
<jgraham>
Chrome's behaviour is super-annoying
10:07
<jgraham>
They should really fix that
10:13
<annevk>
zcorpan: http://html5.org/temp/fetch.html treats data as same-origin
10:13
<annevk>
zcorpan: about/blob too
10:13
<zcorpan>
jgraham: i think i'm done now (if you were waiting for things to settle before reviewing)
10:13
<jgraham>
zcorpan: OK
10:13
<zcorpan>
annevk: ok
10:13
<jgraham>
I was reviewing something else
10:13
<annevk>
zcorpan: I expect all specs to use that algorithm eventually so the same type of URLs work in similar places
10:14
<jgraham>
And feeling vaugely bad about doing so much code review :(
10:14
<jgraham>
https://github.com/w3c/testharness.js <- spot the difference
10:14
<zcorpan>
jgraham: heh. you should delegate more :-)
10:14
<zcorpan>
nice!
10:30
<tobie>
wow. That was fast.
10:38
<zcorpan>
ok next up is workers
10:41
<jgraham>
tobie: Did you just do something to the branch you created for the fixpostmessage pr?
10:41
<odinho>
Cool. :-)
10:41
<tobie>
jgraham: yes, deleted it. why?
10:42
<jgraham>
tobie: OK. Critic tried to update the branch and gave me an error message
10:43
<tobie>
Update on my repo?
10:43
<jgraham>
No, update in its local repo
10:43
<tobie>
oh.
10:43
<jgraham>
Probably just need to teach it to stop tracking branches that don't exist upstream anymore
10:44
<jgraham>
(it might even already do that after a while)
11:18
<annevk>
Man, "referrer source" is such a pain
11:32
<annevk>
SimonSapin: so I think what I need from http://simonsapin.github.com/data-urls/ is that it either returns failure or a MIME type and data
11:33
<SimonSapin>
annevk: makes sense
11:33
<SimonSapin>
Returning a "response" with a Content-Type header is not a thing?
11:34
<annevk>
SimonSapin: that's what I'm building out of that
11:34
<SimonSapin>
MIME type, with parameters
11:34
<annevk>
SimonSapin: refresh http://html5.org/temp/fetch.html
11:34
<SimonSapin>
I think we already had that discussion … (what is called a mime type)
11:35
<annevk>
yeah including parameters
11:35
<annevk>
whatever you want to call that
11:36
<SimonSapin>
I don’t really care how it’s called, as long as it’s defined somewhere
11:37
<annevk>
agreed :-)
11:37
<annevk>
I think GPHemsley is defining MIME type terminology
11:37
<darobin>
we could just call them GPHemsleys then
11:38
<annevk>
SimonSapin: in any event, the second instance of "data" (including quotes) on that page invokes your algorithm
11:38
<annevk>
SimonSapin: it's not entirely correct yet as it should probably queue a bunch of a tasks rather than simply returning the response
11:39
<SimonSapin>
well, what I have for data: at this point is more a list of issues than an algorithm :)
11:42
<SimonSapin>
annevk: for now I suppose you can write "… whose value is the MIME type and parameters returned from …"
11:43
<annevk>
k
11:45
<darobin>
mmm, we'd said web-platform-tests for the new repo name, right? tobie?
11:45
<darobin>
jgraham? --^
11:45
<annevk>
why not "tests"?
11:45
<darobin>
please let's not bikeshed AGAIN
11:47
<jgraham>
darobin: yes
11:47
<darobin>
ok, ta jgraham
11:47
<jgraham>
zcorpan: Did you delete your html-testsuite repository on github?
11:47
<darobin>
if you want to bikeshed with annevk, you have about 90 seconds before something happens
11:47
<zcorpan>
jgraham: yeah. was that a bad thing?
11:47
<SimonSapin>
annevk: in data: the MIME type + parameters is an unparsed string of text, data is a byte string
11:48
<jgraham>
zcorpan: yes :)
11:48
<zcorpan>
lunch, bbiab
11:48
<annevk>
SimonSapin: MIME type should prolly be a byte sequence too
11:48
<jgraham>
zcorpan: Apart from anything else, I don't know where the commits in https://github.com/w3c/html-testsuite/pull/36 live now
11:48
<annevk>
I wish we had some easy way of annotating bytes vs strings
11:49
<annevk>
is Content-Type vs "Content-Type" too subtle?
11:49
<annevk>
(that's what I'm kinda using now)
11:53
<jgraham>
darobin: So, any idea where those commtis *do* live?
11:53
<jgraham>
*commits
11:54
<darobin>
jgraham: commits in a PR from a repo that's been deleted?
11:54
<jgraham>
Yeah
11:54
<jgraham>
If I fetch the html-testsuite repo I don't see them at least
11:54
<jgraham>
But I don't know if fetch gets everything or only reachable commits
11:54
<darobin>
jgraham: first, run git checkout -b zcorpan-master master
11:55
<darobin>
then curl https://github.com/w3c/web-platform-tests/pull/36.patch | git am
11:55
<darobin>
that's the only way to get at them now I think
11:55
<darobin>
it's a miracle they still exist
11:56
<darobin>
rename accomplished
11:57
<darobin>
I guess I should set up a new auto-clone
11:58
<jgraham>
That doesn't make much sense
11:58
<darobin>
jgraham: what doesn't?
11:59
<jgraham>
The patch being the only source of the commits
11:59
<darobin>
I don't know man, I see them in the UI for sure
11:59
<darobin>
but I don't see them anwhere!
11:59
<darobin>
I mean I don't know where they would be
11:59
<jgraham>
If that was true, I don't understand why https://github.com/w3c/web-platform-tests/commit/9ad57834d3d4871e083bcbf202dac74240242ab0 would work
12:00
<darobin>
oh wait
12:00
<jgraham>
Unless the github UI is doing something super-weird it feels like the commit should still exist
12:01
<darobin>
jgraham: can you checkout a branch called 9ad57834d3?
12:01
<darobin>
or somehow track it
12:01
<darobin>
because it's what the UI shows for the branch name
12:02
<darobin>
jgraham: otherwise you can use plumbing commands to get at the commits
12:02
<darobin>
I *guess* you can merge them
12:03
<jgraham>
darobin: Right, you can, in theory, see the commit in git log
12:03
<jgraham>
But that particular commit doesn't seem to be in my clone
12:03
<darobin>
weird
12:03
<jgraham>
And I don't know for sure how to tell if it is in the remote without shell access
12:03
<darobin>
I don't know how PRs are handled tbh
12:04
<jgraham>
git fetch origin {sha1} seems like a good bet
12:04
<darobin>
worth a shot
12:04
<jgraham>
It doesn't work :)
12:04
<jgraham>
fatal: Couldn't find remote ref 9ad57834d3
12:05
<jgraham>
So maybe that ref really doesn't get pulled into the local repo.
12:05
<jgraham>
and we are just seeing cached data
12:06
<darobin>
this is weird
12:06
<darobin>
clearly the GH UI is designed to handle this as gracefully as it can
12:07
<darobin>
because it offers the "grab a patch" option when normally it would tell you how to get at the commits
12:07
<jgraham>
(I can get at the commits via critic fwiw, so they aren't gone in any meaningful sense)
12:07
<darobin>
yeah they're in GH too
12:07
<darobin>
I just don't know in what repo they're stored :) it's bizarre
12:08
<zcorpan>
jgraham: sorry about that. should i do a new pull request?
12:08
<jgraham>
zcorpan: No, but you could recreate the original repo and readd the commits with the same branch name ;)
12:09
<jgraham>
In other news, I wonder how to teach critic that the repo name/url changed
12:09
jgraham
thinks the answer is pain + SQL
12:11
<zcorpan>
jgraham: how do i do that?
12:12
<darobin>
SQL!
12:12
darobin
shudders
12:13
<SimonSapin>
annevk: URLs are text, right? (Not bytes.) We have no encoding information for extracting a MIME type from a data: URL
12:13
<SimonSapin>
just use utf-8, maybe?
12:14
<SimonSapin>
is non-ASCII ever relevant in MIME types or parameters?
12:14
<annevk>
SimonSapin: once parsed URLs are text representing bytes
12:14
<SimonSapin>
text representing bytes, what does that mean?
12:15
<annevk>
SimonSapin: a string where all code points are in the range 0-127 and everything else has a %XX escape
12:15
<annevk>
iirc
12:15
<jgraham>
zcorpan: Well I donno really what the easiest way is.
12:15
<SimonSapin>
annevk: so, for data:, should I percent-decode the whole thing before doing anything else?
12:16
<zcorpan>
from my perspective, the easiest thing is to throw away the current pull request and do it all over again. that i know how to do
12:16
<jgraham>
Go for it
12:16
<zcorpan>
ok
12:16
<annevk>
SimonSapin: I think the most logical think would be to first tokenize the start until you get to the data part
12:16
<annevk>
SimonSapin: and then decode the data part using the encoding you found in the MIME type
12:16
<SimonSapin>
annevk: well, %2C or %3B might not be special as , or ; are …
12:17
jgraham
does the simple part of the repo move
12:17
<annevk>
SimonSapin: yeah, therefore you prolly want to tokenize, not decode
12:17
<annevk>
SimonSapin: I suspect different implementations do different things here and they probably hacked something together rather than did a proper job
12:18
<SimonSapin>
I’ll prolly need a lot of testing before we can decide if , or ; can be %-encoded
12:18
<darobin>
a beer to whoever can make sense of https://www.w3.org/Bugs/Public/show_bug.cgi?id=20993#c7 for me
12:19
<SimonSapin>
annevk: anyway, we’ll figure this out later
12:22
<annevk>
darobin: sounds like he wants a restriction on the DOCTYPE in XHTML similar to how <meta charset> has a restriction when used in XHTML
12:22
<annevk>
darobin: with a lot of distraction
12:22
<darobin>
annevk: yeah, I sort of get some of the idea, but there's an awful lot of distraction so I'm a bit lost tbh
12:24
<annevk>
darobin: he wants nothing but <!DOCTYPE html> allowed or some such, sounds like a polyboat argument
12:25
<jgraham>
darobin: I was going to read it just to disrupt the global beer economy a little, but then I realised it wasn't worth it
12:26
<darobin>
annevk: close, but that's not enough of an explanation for me to act on it, so no beer (well, beer, but not for that)
12:26
<darobin>
jgraham: it's a lot of effot
12:26
<darobin>
effort
12:27
<darobin>
also, if it's a polygloat thing why not do it in the polygoat?
12:27
<annevk>
darobin: the only relevant sentence is
12:27
<annevk>
"I only want a rule which promotes a HTML5-friendly DOCTYPE if and when a DOCTYPE use used."
12:27
<annevk>
and then you have to do s/use /is /
12:28
<annevk>
which is basically also what the subject of the bug is
12:28
<annevk>
reasonable responses include:
12:28
<annevk>
XHTML: mahahahaha
12:29
<annevk>
o_O *shrug*
12:29
<annevk>
o_O fixed
12:29
<darobin>
I almost went with "huhwah?"
12:31
<SteveF>
wiseguys https://twitter.com/w3cmemes/status/311816660707328000 ;-)
12:32
<SteveF>
what twat said that?...
12:33
<darobin>
tee hee :)
12:35
<darobin>
"I accidentally the repository." -- zcorpan :-)
12:37
<SteveF>
if i ever find out whose behind those damn W3C memes...
12:43
<annevk>
http://lists.w3.org/Archives/Public/public-html/2013Mar/0088.html o_O
12:45
<SteveF>
annevk: hmm odd you just post that link and a w3c meme about it appears on twitter
12:45
<annevk>
yeah I got it from there
12:45
<annevk>
I don't read public-html
12:45
<SteveF>
;-)
12:46
<SteveF>
your'e missing out on soo much
12:46
<darobin>
so much love!
12:46
<SteveF>
love to spare!
12:47
<SteveF>
even html-wg IRC is a groovy place to be these days
12:48
<SteveF>
not as groovy as whatwg irc of course
12:50
<SteveF>
HTML WG is sorta like darobin's 'field of dreams'
12:54
<zcorpan>
jgraham: https://github.com/w3c/web-platform-tests/pull/37
13:06
<SimonSapin>
annevk: better? https://github.com/SimonSapin/data-urls/commit/ce8046bd#diff-1 http://simonsapin.github.com/data-urls/
13:08
<jgraham>
zcorpan: Nice. Critic doesn't seem happy after the move though :(
13:09
<zcorpan>
jgraham: the move being html-testsuite -> web-platform-tests ?
13:10
<jgraham>
Yeah
13:26
<zcorpan>
memes on a roll
13:51
<annevk>
SimonSapin: cool
13:51
<annevk>
SimonSapin: fwiw, a parsed URL's scheme is normalized already so you don't have to do case-insensitively match against it
13:51
<annevk>
s/do//
13:53
<SimonSapin>
annevk: does it include the colon?
13:53
<annevk>
SimonSapin: doesn't actually
13:57
<zcorpan>
are any of these available in workers these days (per spec)? CanvasRenderingContext2D CanvasGradient CanvasPattern TextMetrics
13:59
zcorpan
gotta go, will read the logs
14:02
<SimonSapin>
annevk: fixed
14:05
<annevk>
cool
15:00
<darobin>
ah, crap, no zcorpan
15:00
<darobin>
oh "will read the logs", good
15:00
<darobin>
zcorpan: since you were interested in this, you might want to look at http://library.2017.im/app/refs/
15:00
<darobin>
it's not the real deployment, so you can break stuff and all
15:01
<darobin>
(you'll need to sign up to make it do anything at all)
15:05
<jgraham>
2017.im?
15:05
<jgraham>
Nothing like years in the hostname
15:06
<darobin>
who said it's a year :)
15:06
<jgraham>
I just did
15:06
<darobin>
oh
15:06
<darobin>
fait point that
15:07
<annevk>
o_O
15:07
<annevk>
http://www.w3.org/TR/xforms/sliceE.html fail
15:07
<annevk>
(is linked from Web Forms 2.0)
15:07
<darobin>
I guess XForms has some Living Slices
15:35
<jgraham>
Horray!
15:35
<jgraham>
I Was missing the FORMAT COMPLAINT
15:35
<jgraham>
*FORMAL
15:35
<jgraham>
Sigh
15:35
<jgraham>
But I also misss the FORMAT COMPLAINT
15:36
<jgraham>
I think I will go and find some 5.25" floppies
15:36
<annevk>
there's a new one?
15:38
<jgraham>
So, anyone care to take bets on who will post the AXIOMATIC PROOF that EME isn't solely a vehicle for DRM?
15:40
<zewt>
heh apparently webkit sometimes runs async xhr synchronously :(
15:41
<jgraham>
In an observable way, other than timing?
15:41
<zewt>
unless my test is brain farted, yeah (one sec)
15:41
<jgraham>
Or so you mean sometimes as in "data URLs"?
15:41
<zewt>
nope, http
15:42
<zewt>
(uh, one sec, my server is being stupid)
15:43
<annevk>
Anyone know an easy way to test HTTP auth on DreamHost? Apparently PHP running under CGI makes this annoying
15:43
<zewt>
oh (unrelated), apparently webkit will pop up a password prompt if an xhr request needs credentials (?!)
15:46
<zewt>
happens when testing on the local network, but not with my remote server, so possibly latency-related; going to play with cache headers to see if I can make it more deterministic
15:46
<dglazkov>
good morning, Whatwg!
15:47
<zewt>
but FWIW http://zewt.org/~glenn/test-webkit-weird-async-xhr.html locally I get c1: 2, 3, 4, Starting c2, c2: 2, 3, 4, Started c2 (as if the second xhr was sync)
15:48
<zewt>
(chrome)
15:57
<tantek>
good morning, dglazkov
15:57
<annevk>
zewt: password prompt is per spec
15:58
<annevk>
zewt: or a SHOULD per spec, as reportedly that was required by some sites, dunno if that's still true
15:59
<annevk>
zewt: sounds weird
16:00
<zewt>
isn't that one of those things that's so catastrophic to security that it trumps web compat?
16:01
<zewt>
can't seem to repro the webkit weirdness when not on the local network, hmm
16:02
<GPHemsley>
https://hacks.mozilla.org/2013/03/font-inspector-and-elements-firefox-development-highlights/
16:02
<GPHemsley>
links to the W3C spec for <time> but the WHATWG spec for <data>
16:02
GPHemsley
scratches his head.
16:04
<annevk>
zewt: dunno
16:12
<SimonSapin1>
Simon Pieters is sometimes zcorpan on IRC
16:12
<SimonSapin>
eh, wrong channel
16:16
<annevk>
SimonSapin: so... data: URL parsing needs to be async and queue tasks and spin the event loop
16:16
<annevk>
SimonSapin: just like the HTML parser
16:16
<annevk>
SimonSapin: I'm sorry
16:17
<SimonSapin>
oh
16:17
<SimonSapin>
I have no idea how that works :p
16:17
<SimonSapin>
annevk: is it useful to write in spec how to decode the data incrementally?
16:18
<annevk>
It might be enough to say that it happens that way
16:18
<zewt>
... when does URL parsing spin the event loop? that's terrible
16:19
<SimonSapin>
annevk: I mean, if a data: URL is many mega-bytes large, browsers may want to decode incrementally. Is this only an implementation detail or does the spec need to reflect it?
16:20
<SimonSapin>
In particular, does a partially decoded body trigger an event or something?
16:20
<annevk>
SimonSapin: it matters when you load it through XHR or when it contains a <script> and you load it from the address bar
16:20
<zewt>
having xhr.open() spin the event loop sounds a bit catastrophic
16:21
<zewt>
unless I'm misunderstanding (which I'm hoping for :)
16:21
<jgraham>
data uris should be just like any other network data
16:22
<annevk>
yeah, there's a difference between URL parsing and obtaining data
16:24
<jgraham>
So I'm confused. Presumably parsing urls doesn't spin the event loop? But parsing the resulting data might
16:25
<jgraham>
For example data:text/html,<script defer src=slow-loading-script>
16:26
<zewt>
also, you do need to parse a base64 url in advance, since eg. xhr.open("GET", "data:text/html;base64,illegal_string") throws an exception
16:27
<zewt>
so you can't just stash the URL and parse it incrementally
16:29
<annevk>
that it throws an exception is a bug
16:29
<zewt>
it throws in both chrome and firefox, so i don't think it is
16:29
<annevk>
Chrome doesn't support data URLs
16:29
<annevk>
it'll throw either way
17:04
<MikeSmith>
annevk: public-whatwg-bugs sounds fine
17:04
<MikeSmith>
I will get it set up
17:04
<MikeSmith>
but not today
17:04
<MikeSmith>
probably this weekend
17:04
<MikeSmith>
Nao and I care sightseeing in Chicago today and tomorrow
17:05
<annevk>
saw on Twitter, go have fun :)
17:05
<MikeSmith>
thanks
17:50
<matjas>
has there even been a browser that executed <script>s in .innerHTML?
17:50
<matjas>
“IE used to execute <script defer> when inserted via innerHTML, but that was fixed.” says nzakas; anyone know which IE version(s)?
18:30
<annevk>
GPHemsley: given that MIME types are not always in the right group I don't really see the point
18:30
<annevk>
GPHemsley: and sometimes they're in the same group but with wildly different semantics (e.g. image/svg+xml)
18:35
<zewt>
it's not like the "type/subtype" scheme of mime types is for anything but human consumption
19:03
<zcorpan_>
so now i'm an editor of cssom, cssom view and cssom values
19:03
<Ms2ger>
Enjoy
19:03
<zcorpan_>
to my surprise, cssom values is public domain
19:03
<Hixie>
not sure whether "sorry" or "congratulations" is more appropriate
19:04
<zcorpan_>
Hixie: either way, thanks :-)
19:14
<zcorpan_>
interesting how glenn took material from cssom (document license) and pasted into a new spec cssom values (public domain)
19:18
<annevk>
wait what? he copied my work and put it under CC0?!
19:19
<annevk>
zcorpan_: good luck, that stuff is a) hard and b) without fixing the underlying model, extra hard
19:20
<zcorpan_>
annevk: he took your work which was CC0, changed it to the document license, then moved some of it to a new spec with CC0
19:20
<annevk>
zcorpan_: I had changed CSSOM too? interesting
19:23
<zcorpan_>
hmmm. maybe it was glenn who changed from document license to CC0, then changed it back at some point? https://dvcs.w3.org/hg/cssom/rev/74784effb4e3
19:23
<Ms2ger>
No, I'm pretty sure annevk did
19:24
<annevk>
zcorpan_: that seems to indicate more that he moved away from Anolis
19:25
<annevk>
zcorpan_: I think Ms2ger is right and I had a split setup, CC0 for editor drafts and W3C for TR/
19:25
<Ms2ger>
You did TR/ for CSSOM?
19:26
<annevk>
Seems kinda pointless that Glenn would put a bunch of effort into migrating to his own publishing system and then leave all the bugs in the spec...
19:26
<annevk>
Ms2ger: It seems I did, back in 2011
19:26
<Ms2ger>
I dunno, maybe he had fun doing it?
19:26
<zcorpan_>
i guess this is the wrong place https://dvcs.w3.org/hg/cssom/
19:26
<Ms2ger>
And maybe it was easier than actual work?
19:26
<Ms2ger>
zcorpan_, yes
19:26
<annevk>
In fact, it seems thus far nobody updated my TR/ drafts from cssom and cssom-view
19:26
<Ms2ger>
https://dvcs.w3.org/hg/csswg/
19:27
<zewt>
can i petition for him to pick a new name
19:27
<annevk>
Hopefully the CSS WG has realized it should be more careful with people doing actual work
19:28
<Ms2ger>
Bwahahahahahahaha
19:39
<jgraham>
zcorpan_: Gosh, I'm sorry. How did that happen?
19:40
<zcorpan_>
i volunteered
19:41
<zewt>
man. there's no api for anything related to next/previous focusable element and doing it by hand is a pain
19:41
<jgraham>
Hmm, now I'm wondering if brucel infected you with mind worms masquerading as the common cols
19:41
<jgraham>
*cold
19:49
<jgraham>
( I guess I should maybe say that I am actually very happy that you are going to take care of those specs)
19:49
<jgraham>
(I'm glad that I don't have to :)
19:53
<jamesr>
zcorpan_, good luck!
19:54
<zcorpan_>
jamesr: thanks
19:54
<jamesr>
zcorpan_, have any plan of attack?
20:00
<annevk>
oh lol
20:00
<annevk>
cssom-values does not even mention me
20:01
<zcorpan_>
jamesr: http://www.w3.org/mid/op.wtweynahidj3kv⊙sl
20:03
<zcorpan_>
annevk: filed a bug
20:04
<jamesr>
zcorpan_, d'oh, will have to remember my w3c credentials
20:04
<zcorpan_>
jamesr: first i want to try to get the specs under CC0
20:09
<zcorpan_>
seems like i've pushed a hot button already
20:18
<jgraham>
Well really what were you expecting
20:21
<zcorpan_>
heh yeah i'm not surprised
20:22
<annevk>
So are you co-editor?
20:22
<zcorpan_>
yes
20:22
<annevk>
ouch
20:24
<zcorpan_>
annevk: glenn's now added you under acks for values
20:25
<annevk>
ta
20:25
<annevk>
have fun making it all work
20:26
<annevk>
In my experience what you want is tight integration with the rest of CSS, but I'm not sure how realistic all that is
20:27
<SimonSapin>
zcorpan_: I genuinely curious and don’t want to imply it’s not, but why is it useful or important to have a public domain copy?
20:27
<annevk>
Especially with the CSS WG prioritizing organization over solving problems
20:28
<Ms2ger>
SimonSapin, say you want to quote the spec in the source code of a FOSS project
20:28
<SimonSapin>
Ms2ger: that’s not allowed with the W3C license?
20:28
<annevk>
SimonSapin: http://annevankesteren.nl/2012/11/copyright
20:28
<Ms2ger>
SimonSapin, would you say that the W3C document license allows that?
20:28
<SimonSapin>
I don’t know
20:28
<SimonSapin>
Let me look at the details …
20:28
<zcorpan_>
SimonSapin: several reasons. first, it lets people use the text in books and software etc. second, if the people maintaining the spec go "nuts" and screw things up, someone else can take the ball and maintain it somewhere else.
20:29
<zcorpan_>
without having to rewrite it all from scratch
20:34
<annevk>
zcorpan_: should maybe write a new post simply stating that
20:35
<SimonSapin>
annevk: yes, http://annevankesteren.nl/2012/11/copyright looks mostly about ideology. Writing the practical reasons/consequences would help
20:37
<SimonSapin>
I generally agree with you all, but I’m still judging how bad the situation is
20:37
<SimonSapin>
and honestly I don’t want to care about licenses
20:38
<zewt>
also other general reuse (eg. if somebody's speccing a canvas-like API for Python, a normative dependency on HTML and a delta spec is probably a really bad approach)
20:40
<GPHemsley>
annevk: That depends on what you believe the semantics are for an image, I suppose.
20:40
<Ms2ger>
I dunno if someone speccing a canvas-like API for anything is something to be encouraged ;)
20:40
<GPHemsley>
annevk: But zewt makes a valid point.
20:40
<jgraham>
As usual glazou misses the point
20:40
<jgraham>
As usual I can't say how because he does it in Member space
20:41
<zewt>
Ms2ger: at an API level, perhaps not, but the careful definitions of how to draw paths and so on may well have other uses
20:41
<GPHemsley>
annevk: Though perhaps not an altogether important one. I'd be interested in hearing your arguments against defining terminology for the various parts.
20:41
<annevk>
GPHemsley: there's no processing that I know of that looks at individual parts
20:42
<GPHemsley>
annevk: So do you believe the mimesniff spec is mistaken in doing so?
20:45
<annevk>
GPHemsley: yeah and it contains bugs therefore too
20:45
<annevk>
GPHemsley: e.g. "If the supplied media type is an image type supported by the user agent, let matched-type be the result of executing the image type pattern matching algorithm with the resource header as the byte sequence to be matched. "
20:45
<annevk>
GPHemsley: is wrong, because image types is defined as wider than the actual supported set
20:46
<annevk>
actually, never mind
20:46
<annevk>
although it does not help either
20:47
<jamesr>
zcorpan_, so a big problem in CSS specs is it's impossible to figure out where the hell anything is
20:48
<jamesr>
a lot's supposed to be in one of om/view/values
20:48
<GPHemsley>
annevk: If there's something you think can be clarified or improved, please file a bug so I don't lose track of it. :)
20:48
<jamesr>
but please cross-ref stuff in a sane way
20:51
<SimonSapin>
zcorpan_: we recently resolved to move CSSPageRule to css3-page. Do you think that’s a good idea?
20:53
<SimonSapin>
zcorpan_: also, CSSPageRule needs to get at least a cssRules property of type CSSRuleList to expose the page-margin rules. The issue with that is, it doesn’t preserve the position of at-rules compared to declaration. It’s not significant in @page, but it could be in future at-rules that mix declarations and at-rules.
20:53
<zcorpan_>
SimonSapin: dunno. having the interface in the same spec that defines the feature seems sane on the face of it
20:54
<zcorpan_>
SimonSapin: but then a lot of cssom should also move to other specs, no?
20:54
<SimonSapin>
probably
20:58
<SimonSapin>
zcorpan_: it’s already been done for fonts and conditional rules, at least
20:59
<zcorpan_>
SimonSapin: ok
20:59
<SimonSapin>
… although that’s not visible in http://dev.w3.org/csswg/cssom/#the-cssfontfacerule-interface or http://dev.w3.org/csswg/cssom/#the-cssmediarule-interface
21:06
<annevk>
(I pushed for that, fwiw)
21:07
<annevk>
it's what HTML and SVG and URL and ... are doing too
21:19
<zcorpan_>
thanks SimonSapin
21:20
<SimonSapin>
annevk: what is "that" you pushed for? Moving OM for specific at-rules to their respective spec?
21:20
<annevk>
yeah
21:20
<SimonSapin>
oh, here come the off-list arguments
21:25
<annevk>
:/
21:26
<annevk>
I should not have gotten internet before a proper desk, this is no good
21:29
<zcorpan_>
annevk: new place?
21:29
<annevk>
zcorpan_: I moved to the UK a while back
21:30
<zcorpan_>
yeah. you noticed now you're missing a desk? :-)
21:31
<annevk>
well now I've internet at home that's somewhat reasonable, so yes :-)
21:31
<annevk>
been trying to find some kind of second hand victorian desk but it seems like I need to settle for something else
21:32
<zcorpan_>
i'd like to get a standing desk of some sort at home
22:05
<dcheng>
Question... if the spec defines an attribute to return a DOMString[], it would be incorrect to return null if it's empty right?
22:05
<annevk>
dcheng: yes
23:12
<Hixie>
hsivonen: ping on https://www.w3.org/Bugs/Public/show_bug.cgi?id=17869