06:56
<zcorpan>
sigh. i want to demo incremental rendering and have problems with php flush thing not working :-(
07:00
<hsivonen>
<?php ob_flush(); flush(); ob_flush(); sleep(3); ?>
07:00
<hsivonen>
that works for me
07:13
<zcorpan>
doens't appear to work for me. http://simon.html5.org/sandbox/html/incremental-ajax-iframe/slow-load.php
07:14
<zcorpan>
i get chunked encoding but no incremental rendering
07:19
zcorpan
gives up
07:21
<annevk>
http://www.hixie.ch/tests/evil/page-loading/incremental/002.cgi?mime=text%2Fhtml&delay=1&repeats=100 doesn't work either for me
07:21
<annevk>
I wonder if browsers changed their rendering model maybe
07:22
<annevk>
actually, that one kinda does work
07:23
<annevk>
just wasn't waiting long enough
07:23
<annevk>
http://www.hixie.ch/tests/evil/page-loading/incremental/002.cgi?mime=text%2Fhtml&delay=1&repeats=20 makes it easier
07:31
<hsivonen>
argh. Opera on Linux is a pain to use with a non-QWERTY keyboard layout
07:31
<hsivonen>
it triggers keyboard shortcuts based on the hardware keycodes rather than the baked letters
07:32
<hsivonen>
just opening it for test cases is super-annoying, because ctrl-l and ctrl-v don’t work
07:32
<zcorpan>
annevk: a script with an alert doesn't run until the end so it's not just rendering
07:33
<hsivonen>
I guess this is what you get when you bypass the toolkits on Linux
07:33
<annevk>
I meant that in a broad way, but yeah, I should have said page loading
08:03
<[tm]>
hello friends
08:04
<[tm]>
back from my triumphant European tour 2012
08:04
<annevk>
mike[tm] 2012!!1!!
08:04
<[tm]>
heh
08:05
<[tm]>
hsivonen: planning to work on some validator bugs
08:06
<hsivonen>
[tm]: cool!
08:17
<jgraham>
[tm]: Did you sell t-shirts with the venues and dates on the back?
08:18
<annevk>
which reminds me, is that Docxs t-shirt made yet?
08:19
<jgraham>
Yeah, did you order one?
08:19
<annevk>
I thought I did
08:20
<jgraham>
OK, odinho is in charge
08:20
<jgraham>
Ask him
08:20
<odinho>
annevk: Yeah, I have one for you at my desk.
08:20
<odinho>
annevk: But you haven't been visiting me much lately :-(
08:21
<odinho>
09:32 < hsivonen> argh. Opera on Linux is a pain to use with a non-QWERTY keyboard layout <---- only next.
08:21
<odinho>
hsivonen: It's a very well known bug, I'm using dvorak myself, so I get totally tripped up. :]
08:23
<odinho>
hsivonen: You can use F8 instead of CTRL+L
08:23
<odinho>
hsivonen: Or if you just want to go to an URL, just middle-click in the middle of a page (not over a textarea), it will go to the url by itself.
08:23
<[tm]>
jgraham: yeah but I spent all the proceeds on hash in Amsterdam
08:42
<hsivonen>
odinho: good to know it’s known. thanks
09:26
[tm]
only just now discovers https://github.com/whatwg
09:54
<annevk>
[tm]: since all web developers appear to be on github, seemed nice to have the web standards there too
09:54
<danbri>
might as well move all websites there too
09:54
<annevk>
some do
09:59
<jgraham>
google.github.com
09:59
<[tm]>
annevk: everybody except Ms2ger
09:59
<annevk>
[tm]: he is too actually, and pushed some stuff to whatwg/dom already
09:59
<jgraham>
Eventually we should just remove the .github.com suffix and wire browsers to assume that all sites are github subdomains
09:59
<[tm]>
omg
09:59
<annevk>
[tm]: with hggit it works fine for him
09:59
<annevk>
or her
09:59
<jgraham>
"it"
10:00
<[tm]>
annevk: hell hath frozen over
10:00
<annevk>
had anyone confirmed gender yet?
10:00
<annevk>
"it" works :)
10:00
<[tm]>
Ms2ger is more of a "phenomenon"
10:00
<[tm]>
a force of nature
10:00
<annevk>
danbri: we actually host the specs elsewhere, e.g. http://xhr.spec.whatwg.org/
10:00
<jgraham>
annevk: I have never seen Ms2ger naked if that's what you're asking
10:00
<[tm]>
10:01
<annevk>
danbri: so when github goes bankrupt we just have to upload the repository elsewhere
10:01
<[tm]>
annevk: btw have you been looking at Chris Weber's tests?
10:01
<[tm]>
URL tests
10:02
<annevk>
it appears he just converted WebKit's tests to some weird XML format
10:02
<annevk>
as far as I can tell anyway
10:02
<annevk>
so I just used those from WebKit
10:03
<[tm]>
https://github.com/cweb/iri-tests
10:03
<[tm]>
annevk: I'm pretty sure he has a bunch of tests in addition to the WebKit ones
10:03
<annevk>
okay
10:03
<annevk>
http://wiki.whatwg.org/wiki/URL links to it already
10:04
<[tm]>
OK
10:05
<[tm]>
ah yeah some tests from Julian
10:05
<[tm]>
http://greenbytes.de/tech/tc/uris/ and http://greenbytes.de/tech/webdav/urldecomp.xml
10:06
<annevk>
so his tests don't include expected results
10:06
<[tm]>
eh?
10:06
<[tm]>
wow
10:06
<annevk>
might as well write tests from scratch then...
10:06
<annevk>
well, some do, some don't
10:08
<[tm]>
yeah lack of expected results makes stuff pretty useless
10:18
<annevk>
so for javascript: and data: and basically all non-hierarchical schemes you do not escape <>?# etc.
10:18
<annevk>
and you can only modify fragment
10:18
<annevk>
I guess that works
10:19
<annevk>
and the value of a javascript URL is then path[0] + fragment
10:20
<annevk>
otherwise javascript:alert('#1') would not work
10:20
<annevk>
and it does
10:39
<AryehGregor>
annevk, props for the easy-to-remember DOM spec URL.
10:39
<AryehGregor>
(even if I'm worried Microsoft will fork it in the W3C -- couldn't you have gone with a CG?)
10:45
<annevk>
we can still publish FSA through a CG
10:45
<annevk>
through the WHATCG
10:52
<annevk>
AryehGregor: also, I'm not a member of any CGs at the moment, I've not taken the time yet to read all the legal things around it
10:53
<[tm]>
annevk: might be worth moving over MIME-sniffing draft from https://github.com/abarth/websec to https://github.com/whatwg too
10:54
<annevk>
I'll let abarth decide on that
10:54
<annevk>
I guess I can add him to /whatwg as a first step
10:56
<annevk>
[tm]: you want to be a member too? since you were editing URL at some point?
10:57
<annevk>
[tm]: also, I was wondering if we could add a box to http://dvcs.w3.org/hg/url/raw-file/tip/Overview.html about it not being maintained
10:57
<[tm]>
annevk: yeah, I can add that
10:58
<[tm]>
and yeah please add me as a member and I'll copy over the current MIME sniff draft
10:58
<[tm]>
I am pretty sure abarth is not planning to work on that further
10:59
<annevk>
done
11:09
<annevk>
anyone from Gecko around that can tell me where Gecko's javascript URL code is located?
11:14
<[tm]>
annevk: gracias
11:14
<[tm]>
annevk: oh, btw, I rememer a while back on some list that abarth was explaining that
11:14
<annevk>
bz too I think
11:15
<[tm]>
annevk: abarth was explaining about some spec not dealing with IRIs but instead with just URIs
11:16
<[tm]>
because of failure of the RFCs to actually properly define how to get a URI from an IRI
11:17
<[tm]>
do you remember reading that? if so, which list?
11:17
<[tm]>
I been looking for it but can't remember where it was
11:18
<SimonSapin>
[tm]: this? http://tools.ietf.org/html/rfc3987#section-3.1
11:19
<annevk>
http://lists.w3.org/Archives/Public/public-whatwg-archive/2010Nov/0317.html is the one I was talking about
11:19
<annevk>
[tm]: dunno, but I know browsers have one URL code path
11:20
<annevk>
[tm]: and "IRI like" input gets converted to percent escaped stuff when needed
11:20
<annevk>
http://lists.w3.org/Archives/Public/public-whatwg-archive/2010Nov/0317.html is the one where bz explains some weird javascript: URL stuff
11:26
<annevk>
hmm
11:26
<annevk>
but it gets even weirder
11:27
<annevk>
e.g. javascript:alert('%e2%84') yields some weird character while in utf-8 it's bogus
11:27
<annevk>
%e2 is the start of a three-byte sequence
11:29
<Ms3ger>
Looks like I missed some interesting chatter earlier...
11:29
<Ms3ger>
Also, annevk, http://mxr.mozilla.org/mozilla-central/source/dom/src/jsurl/
11:30
Ms3ger
wanders off again
11:50
<[tm]>
annevk: thanks
11:50
<[tm]>
turns out http://lists.w3.org/Archives/Public/public-webappsec/2012Sep/thread.html#msg5 is what I was forgetting
11:50
<[tm]>
"Interaction of CSP and IRIs " thread with bz and abarth
11:51
<[tm]>
[[
11:51
<[tm]>
Converting IRIs to URIs is a big mess. It's something that needs to
11:51
<[tm]>
be solved for the whole platform. I tried to solve it a couple years
11:51
<[tm]>
ago, but gave up.
11:51
<[tm]>
]]
11:51
<[tm]>
et.c
11:54
<annevk>
ah yeah
11:54
<annevk>
the IDNA2008 vs IDNA2003 thing
11:54
<annevk>
UTS #46 attempted to solve that
11:55
<AryehGregor>
Is it testable whether an object's NativeBrand is "NativeError" vs. something else?
11:56
<annevk>
not looking forward to solving the IDNA problem
11:57
<annevk>
well, I can solve it, just superset IDNA2003 somehow or say IDNA2008 is the way, either way some group is going to yell
11:58
<annevk>
how the fuck the IETF could ever decided to break compatibility in domain names is beyond me
12:12
<[tm]>
annevk: btw and just FYI, http://trac.tools.ietf.org/wg/iri/trac/report/6
12:16
<AryehGregor>
annevk, comments welcome on: http://w3c-test.org/webapps/DOMCore/tests/approved/exceptions.html
12:16
<AryehGregor>
(which I just committed)
12:16
<AryehGregor>
I can't think of anything else to test regarding exception-throwing, TBH.
12:20
<[tm]>
SimonSapin: see abarth comments in http://lists.w3.org/Archives/Public/public-webappsec/2012Sep/0005.html thread
12:23
<annevk>
[tm]: is that still maintained?
12:24
<annevk>
[tm]: guess I could check some of those to see if they're addressed or not
12:26
<[tm]>
annevk: that's why I suggested it
12:26
<[tm]>
not sure if it's still maintained
12:26
<[tm]>
will ask Larry
12:27
<[tm]>
annevk: do you think it would be useful to try to encourage some new discussion on the public-iri list/
12:27
<[tm]>
e.g., post a link to the current URL draft and ask for feedback?
12:28
<annevk>
I don't really plan to subscribe
12:28
<annevk>
and the www-tag discussion was kinda pointless
12:29
<annevk>
given the experience of interacting with those people for the past six years I'm not too hopeful for novel contributions, but we can try I suppose
12:30
<[tm]>
annevk: it would be good to find some way if we can
12:30
<[tm]>
annevk: btw http://trac.tools.ietf.org/wg/iri/trac/report/1?asc=1&sort=ticket is better view maybe
12:30
<[tm]>
shows only the open issues
12:31
<[tm]>
37 open
12:31
<annevk>
[tm]: you think there's some gain there?
12:31
<annevk>
[tm]: I don't mind subscribing and posting if you think we should
12:31
<annevk>
[tm]: just wonder what the upside is
12:32
<[tm]>
well I am getting some complaint that we are ignoring use cases
12:32
<annevk>
jreschke will point out once again how he thinks this should really be on top of the existing specs somehow rather than replacing them
12:32
<[tm]>
for non-Web considerations
12:32
<annevk>
that this is really about error handling instead of a better approach to define URLs, etc.
12:32
<[tm]>
and non-browsers
12:33
<[tm]>
annevk: yeah
12:33
<annevk>
we're addressing the problems curl and such have
12:33
<[tm]>
OK
12:34
<annevk>
and this should help every consumer of HTML too...
12:34
<annevk>
or consumer of CSS
12:35
<annevk>
back later, tuna steak time
12:39
<SimonSapin>
We have a CSS issue on the definition of what’s in the url(foo) syntax, and how it should be interpreted
12:40
<SimonSapin>
(CSS escaping allows any unicode string)
12:40
<zcorpan>
SimonSapin: what's the issue?
12:41
<SimonSapin>
the spec previously said URI, it should say IRI or something else
12:41
<zcorpan>
clearly it should say URL :-)
12:42
<SimonSapin>
well, the name of the "value type" is <url> and the syntax is url(...)
12:46
<zcorpan>
the syntax is defined in http://dev.w3.org/csswg/css3-syntax/
12:46
<zcorpan>
the value type should be updated to reference http://url.spec.whatwg.org/
12:54
<annevk>
[tm]: so hey, I guess you should go out about now ;) but lets look into writing to public-iri next week or so
12:55
<annevk>
[tm]: I'm definitely open to all kinds of use cases, but my primary concern is what's important for http://platform.html5.org
12:56
<annevk>
SimonSapin: yeah, CSS should reference the URL Standard, it should just pass the string (collection of code points) to the parser and set the base URL appropriately and that's that
13:17
<[tm]>
annevk: OK
13:17
<[tm]>
I been talking to Larry already
13:17
<[tm]>
will talk to Martin in persdon if I can get him to make some time
13:17
<[tm]>
agreed about that use cases
13:18
<[tm]>
but I can understand others feeling like they're being blown off
13:18
<[tm]>
those the overstatement is tiresome
13:18
<[tm]>
sometimes
13:21
<zcorpan>
annevk: "Otherwise, set state to no scheme and start over (from the first code point in input)." why does this need to start over?
13:26
<[tm]>
annevk: wondering now if it might make sense for the URL spec to explicitly define some conformance classes
13:26
<[tm]>
if so I can take a shot at adding some language
13:26
<zcorpan>
though i guess it would be implemented by checking against /^[0-9a-zA-Z\+\-\.]*$/ so i guess it's fine
13:26
<[tm]>
e.g., based on subset of classes in the HTML spec
13:43
<SimonSapin>
annevk: the URL Standard, this one http://url.spec.whatwg.org/ ?
13:43
<Ms2ger>
Yep
13:57
<[tm]>
annevk: https://github.com/whatwg/mimesniff
13:57
<[tm]>
annevk: if you can set up http://mimesniff.spec.whatwg.org/ that'd be great
13:57
<[tm]>
oh
13:57
<[tm]>
cool
13:58
<[tm]>
I see it's already there
13:58
<[tm]>
automatic I guess
13:58
<[tm]>
nice
13:58
<[tm]>
ah no
13:58
<[tm]>
I guess it was already there before
14:00
<annevk>
yeah that was there before
14:00
<annevk>
[tm]: who is going to maintain whatwg/mimesniff?
14:00
<annevk>
[tm]: I can set up some kind of thing to make that work
14:03
<annevk>
need to coordinate with Hixie
14:04
<annevk>
SimonSapin: yup
14:05
<SimonSapin>
annevk: I wish I had this a few months ago :)
14:05
<annevk>
zcorpan: because you end up in "hierarchical" which does not reuse buffer
14:05
<annevk>
zcorpan: which means I need to reset buffer there I think
14:07
<annevk>
[tm]: the situation is a bit similar with DOM Events; it's easier to just write a better standard than get the people "in charge" to fix theirs
14:11
<annevk>
SimonSapin: ah, you are/were implementing a CSS parser?
14:12
<SimonSapin>
annevk: Yes. I’m making WeasyPrint (an UA with PDF output) and it’s dependency tinycss (CSS parser)
14:13
<annevk>
ah, in Python, sweet
14:13
<SimonSapin>
yes
14:13
<SimonSapin>
but weasyprint still has url-related bugs, so this new spec will be useful to me
14:14
<annevk>
it's not fully complete, but for http/https at least it should be pretty accurate
14:14
<annevk>
though I've yet to fully figure out IP addresses and host names, they're nasty
14:14
<annevk>
and then especially host names are nasty
15:00
<[tm]>
annevk: I can be responsible for whatever minimal maintenance it might need for now
15:01
<[tm]>
there are no open bugs against it as far as I know
15:01
<[tm]>
and it's fairly mature as far as I can tell
15:01
<annevk>
okay
15:02
<annevk>
so currently abarth owns mimesniff.spec.whatwg.org
15:02
<annevk>
I'll ask Hixie to change that to me so I can set up the syncing script
15:05
<annevk>
Never thought I would care about boring shit like copyright. I even feel slightly passionate about it
15:06
<karlcow>
ideally people would not sign at all their work
15:06
<SimonSapin>
slightly passionate :)
15:06
<karlcow>
but I guess it depends on the type of ideals the person has
15:07
<karlcow>
:)
15:28
<karlcow>
annevk: you have a date
15:58
<abarth>
annevk: thanks
16:33
<dglazkov>
good morning, Whatwg!
16:47
<smaug____>
error event handling is special only in onerror event handler, right?
16:51
<smaug____>
nm
17:32
<annevk>
Hixie: morning enough already?
18:08
<Hixie>
annevk: sup
18:08
Hixie
just realised he was working and hadn't yet checked irc and e-mail!
18:17
<annevk>
Hixie: can you change the user of mimesniff.spec.whatwg.org to be annevankesteren?
18:17
<Hixie>
abarth is handing it over to you?
18:17
Hixie
pokes abarth for confirmation
18:17
<abarth>
go for it
18:17
<Hixie>
thanks
18:17
<Hixie>
annevk: on it
18:17
<Hixie>
hm
18:17
<abarth>
annevk: thanks for taking up the cause
18:17
<Hixie>
this is going to nuke the directory, is that ok?
18:18
<Hixie>
or actually, i guess it won't
18:18
<Hixie>
it'll just move to pointing to an empty one
18:18
<annevk>
Hixie: (the complete story is that mike is going to do it and I will set up syncing between github and the spec)
18:18
<Hixie>
the old one is abarth's user will still be there
18:18
<Hixie>
annevk: nice
18:18
<annevk>
Hixie: yeah that's okay, it will be updated shortly
18:18
<Hixie>
k
18:18
<Hixie>
Please Stand By...
18:18
<annevk>
hopefully I can do it in ten minutes, otherwise it'll have to wait an hour
18:19
<Hixie>
oh sweet, dreamhost actually do support moving the files over
18:19
<annevk>
yeah I thought so
18:19
<Hixie>
abarth: you don't have anything secret in the directory, do you?
18:19
<Hixie>
abarth: if not, i'll just move it over
18:20
<Hixie>
annevk: ~/mimesniff.spec.whatwg.org/ ?
18:20
<annevk>
Hixie: yeah
18:20
<annevk>
just defaults
18:21
<Ms2ger>
I guess we should get parsing set up there too
18:22
<Hixie>
annevk: just in case abarth does have secret files there (e.g. svn password or something) I haven't copied the files over
18:22
<Hixie>
annevk: but it is otherwise done.
18:22
<annevk>
Hixie: sweet, I'll set up the sync script
18:22
<GPHemsley>
Is the WHATWG "official" MIME type for WAVE files "audio/wave"? Is this a willful violation of RFC 2361 (which specifies "audio/vnd.wave")? And where does that leave "audio/wav" and "audio/x-wav"?
18:22
<Hixie>
GPHemsley: the WHATWG "official" stance on MIME types in general is "sigh"
18:22
<GPHemsley>
:)
18:23
<GPHemsley>
s/official/canonical/
18:23
<annevk>
yeah, sanse quotes too :)
18:23
<annevk>
euh, sans*
18:23
<Hixie>
GPHemsley: the honest answer is we haven't fixed MIME types yet
18:23
<Hixie>
GPHemsley: it's on the roadmap, but probably not for this year
18:24
<GPHemsley>
I see
18:24
<Hixie>
GPHemsley: i expect to revamp the way registrations for everything is done at some point
18:24
<Hixie>
and that may affect mime types also
18:24
<GPHemsley>
what do you recommend in the meantime?
18:24
<annevk>
I have MIME in general as something I'd like to fix at some point
18:24
<Hixie>
for audio/wave, probably doesnt' matter, i'd assume it all gets sniffed anytway
18:24
<annevk>
at least define MIME type parsing and MIME type parameter parsing in more detail
18:25
<annevk>
because that's kind of a mess
18:25
<Hixie>
that too
18:25
<GPHemsley>
alright
18:25
<annevk>
http://mimesniff.spec.whatwg.org/ is up and running again
18:26
<annevk>
commits to https://github.com/whatwg/mimesniff will be propagated
18:27
<annevk>
thanks Hixie / abarth
18:27
<annevk>
and [tm] !
18:28
<Hixie>
Ms2ger: let me know if you do want me to set things up for you (or tell anne and have him ask me to set it up for him :-) )
18:28
<Ms2ger>
Having anne do it for me sounds good ;)
18:29
<annevk>
Ms2ger: ask Hixie for a URL and have him assign it to the annevankesteren account :p
18:29
<Ms2ger>
parsing?
18:29
<annevk>
Ms2ger: and make a github repo
18:29
<Hixie>
parsing.spec.whatwg.org?
18:29
<Ms2ger>
annevk, what did you use to convert the repo?
18:29
<annevk>
gotta catch a train
18:29
<Ms2ger>
See you, then :)
18:30
<annevk>
Ms2ger: the hggit stuff, I can do that for you if you want, later
18:30
<Hixie>
man, anne's getting jeff crashing his town to speak to him
18:30
<Hixie>
high roller
18:30
<Hixie>
domparsing.spec.whatwg.org?
18:30
<Hixie>
what spec are we talking about here?
18:31
<Ms2ger>
http://html5.org/specs/dom-parsing.html
18:32
<[tm]>
annevk: http://dvcs.w3.org/hg/url/raw-file/default/Overview.html
18:32
<Hixie>
so domparsing.spec ?
18:32
<Ms2ger>
That works
18:32
<Hixie>
[tm]: can you do that with html too? :-P
18:33
<[tm]>
heh
18:33
<Ms2ger>
[tm], and DOM4? :)
18:33
<[tm]>
my hit points are limited
18:34
<Hixie>
hah
18:35
<Hixie>
Ms2ger: please complete this sentence re that spec: "This specification defines "
18:36
<Hixie>
(for whatwg.org/specs)
18:36
<Ms2ger>
"DOM APIs related to parsing markup into DOM trees and serializing DOM trees into markup"? :)
18:36
<Hixie>
thanks
18:36
Ms2ger
is happy he wrote an abstract once
18:37
<Hixie>
:-)
18:37
<Hixie>
up to anne now
18:39
<[tm]>
this looks exciting: https://twitter.com/esdiscuss/
18:48
<Ms2ger>
annevk, everything set up
18:55
<Hixie>
"If the [script] element does not have a src attribute, and the element has been flagged as "parser-inserted", and [...] the parser that created the script is [...] an HTML parser whose script nesting level is zero [...]"
18:56
<Hixie>
how can that ever happen?
18:57
<Hixie>
i added that on 2012-08-28
18:57
<Hixie>
hmm
18:57
<Hixie>
that's only a month ago
18:59
<Hixie>
oh i think i meant "is 1"
18:59
<Hixie>
not zero
18:59
<Hixie>
(http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Aug/0231.html)
19:14
<Hixie>
annevk: re URLs: did you file a bug on updating the HTML spec to point to URL?
19:15
<Hixie>
annevk: and, is there any chance I can get you to define "URL" as a string, and use a slightly different term for the decomposed+absolute form? maybe "absolute URL"?
19:15
<Hixie>
annevk: (it would make merging way easier, and be more consistent with how people refer to URLs)
19:16
<annevk>
that would be kinda confusing with the URL object
19:17
<Hixie>
people think the value in href="foo.html" is a URL, I don't think we're going to convince them otherwise
19:17
<annevk>
you have a point there
19:18
<Hixie>
having the URL object represent an absolute URL is ok, i think. You can always _create_ a URL object from a relative one, right?
19:18
<Hixie>
it'll just resolve it first
19:18
<annevk>
you can if you provide a base URL
19:18
<Hixie>
oh it doesn't use the the script base URL? interesting
19:18
<annevk>
maybe it should fallback to that, didn't think of that
19:19
<Hixie>
didn't we define a Location.resolve() method at some point?
19:19
<annevk>
I hate the terminology minefield
19:19
<annevk>
Hixie: we removed it in favor of the URL constructor
19:19
<Hixie>
ah ok good
19:19
<Hixie>
i was about to suggest doing that
19:19
<Hixie>
ok so yeah, i'd say default to the script base URL or something
19:20
<Hixie>
but either way, i think it makes the name of hte URL object be fine
19:20
<Hixie>
even if we define URL as the string like in HTML today, and absolute URL as the decomposed thing that the algorithms use
19:22
<annevk>
Hixie: give it another two weeks or so and I'll file that bug; there's a conference here next week and I'm not sure how much time I have; I also want to try updating XMLHttpRequest first to use the new URL stuff to see how it works out
19:23
<annevk>
Ms2ger: you're ready to go btw
19:23
<Ms2ger>
Excellent, thanks :)
19:23
<annevk>
Ms2ger: do you want a redirect from http://html5.org/specs/dom-parsing.html or should I make it nice page like the one we have for ranges?
19:23
<Ms2ger>
A redirect, I think
19:23
<annevk>
kk
19:24
<Hixie>
annevk: lgtm
19:25
<annevk>
Hixie: if we call all strings URL I think we should reserve absolute URL for the form that is not relative, and use "parsed URL" or some such for the object
19:26
<annevk>
I'm not a big fan of that terminology personally though
19:26
<annevk>
having written a URL spec I can see why they went with relative reference and URI :)
19:28
<annevk>
Ms2ger: done
19:29
<Ms2ger>
Thanks
19:32
<Hixie>
annevk: "parsed URL" works for me. I'd just have to change "resulting absolute URL" throughout
19:32
<Hixie>
annevk: which is better than changing every instance of URL anywhere. :-)
19:32
<Hixie>
hsivonen: yt?
19:33
<Hixie>
hsivonen, abarth: https://www.w3.org/Bugs/Public/show_bug.cgi?id=17872
19:41
<abarth>
Hixie: is that a feature request or a compat issue?
19:42
<Hixie>
feature request
19:42
<Hixie>
it's asking for <form id=a></form> <fieldset form=a> <input> </fieldset> to associate the input with the form
19:42
<annevk>
abarth: so to your knowledge WebKit is going to stick with IDNA2003? or are there plans to implement UTS #46?
19:42
<annevk>
abarth: I'm not too interested in what the IETF thinks, I just want to define what everyone wants to converge towards
19:43
<abarth>
annevk: I believe it's a port specific decision
19:43
<annevk>
abarth: I saw Gecko might just go to IDNA2008 by adopting some library
19:43
<abarth>
annevk: Chrome doesn't have any plans to move off IDNA2003
19:43
<annevk>
abarth: gotta love that
19:44
<annevk>
abarth: ah okay, I found some Chromium bug where Mark Davies suggested otherwise, but maybe he was wrong; I guess he's not on Chrome to begin with
19:44
<annevk>
Davis*
19:45
<annevk>
-- http://code.google.com/p/chromium/issues/detail?id=114375
19:45
<abarth>
(looking)
19:46
<abarth>
annevk: jshin is the person who will make the final decision
19:46
<abarth>
you can just ask him directly
19:47
<annevk>
guess I can try that, haven't had much luck in the past when asking about encoding stuff
19:49
<abarth>
I would be very surprised if Chrome adopted IDNA2008
19:54
<annevk>
thus far I know Safari has no immediate plans (and has a list of sites that will break if they do); I know Gecko is waiting for relicensing of some Japanese DNS library they want to adopt that implements IDNA2008; Opera implements IDNA2008 and faces compatibility issues (presumably including those on Safari's private list), Opera's IDNA2008 implementation might not entirely match the spec, they do support IDNA2003 label-separator
19:54
<annevk>
s for instance; Chrome you just mentioned; no idea about Microsoft
19:57
<annevk>
http://blogs.msdn.com/b/michkap/archive/2012/09/27/10353657.aspx suggests Microsoft goes with IDNA2008 + UTS #46 for Windows 8
20:01
<annevk>
http://blogs.msdn.com/b/michkap/archive/2012/02/27/10273315.aspx looks like IDNs are a world of hurt
20:01
<annevk>
joy
20:08
<[tm]>
lovely
20:11
<annevk>
[tm]: http://mimesniff.spec.whatwg.org/#acknowledgements has an encoding issue
20:11
<annevk>
[tm]: lacks a comma, too
20:14
<[tm]>
annevk: thanks will fix it now
20:31
<zewt>
annevk: IDNs seem like a pretty broken idea
20:32
<zewt>
i mean, they simply Don't Work(tm) in plaintext, short of evil heuristics
20:32
<hober>
zewt: i dunno, poopla is pretty awesome.
20:33
<annevk>
hober: one of those blogs.msdn.com links above suggests poopla might be breaking the rules
20:33
<zewt>
<- shocked
20:38
<annevk>
I'm not really shocked that much, just annoyed that nobody figures it out in full detail
20:38
<annevk>
IDNA2003 was pretty complete, but still did not cover things such as underscores or semicolons in labels
20:39
<annevk>
the same thing happened with URL, in theory URLs were pretty restricted, but nobody implemented the restrictions and just looked at the separators
20:40
<annevk>
and then when that became widespread, nobody updated the definition
20:40
<annevk>
you'd think with a billion people online or so, there must be more than one person that cares about fixing those things
20:40
<TabAtkins>
Unrelated to URLs, KLINGON STYLE http://www.youtube.com/watch?v=CayMeza487M (from what I understand, a pretty close translation from Korean to Klingon).
20:43
<annevk>
haha
20:43
<annevk>
has the elevator scene and everything
20:43
<TabAtkins>
yup! the only major scene i see them missing is the fake-snowstorm
20:47
<[tm]>
annevk: I see Thomas Ford left Opera
20:49
<annevk>
[tm]: oh? haven't seen him in ages
20:50
<annevk>
https://twitter.com/thomasford doesn't say much
20:51
<annevk>
does say he's working for Soundrop, doh
20:51
<[tm]>
annevk: linkedin
20:51
<[tm]>
yah
20:51
<[tm]>
whatever that is
20:51
<[tm]>
famous?
20:51
<[tm]>
Hixie: IANA approved the registration for text/html
20:52
<[tm]>
but the sent back questions on application/microdata+json
20:52
<danbri_>
got a link for that, re application/microdata+json questions?
20:53
<[tm]>
danbri_: no, private mail unfortunately
20:53
<danbri_>
ok, thanks
20:53
<[tm]>
that seems to be the way they handle these
20:53
<[tm]>
text/html updates is at http://www.iana.org/assignments/media-types/text/index.html
20:53
<[tm]>
http://www.iana.org/assignments/media-types/text/html
20:54
danbri_
finds http://www.ietf.org/mail-archive/web/ietf-types/current/msg01722.html
20:54
<danbri_>
the json-ld comparison seems fair; they're in similar territory
20:55
<[tm]>
dude subsequently posted to whatwg about that
20:55
<[tm]>
lemme find the thread
20:56
<[tm]>
http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Aug/thread.html#msg73
20:56
danbri_
was reading http://www.ietf.org/mail-archive/web/ietf-types/current/msg01722.html
20:56
<[tm]>
http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Aug/thread.html#msg80
20:56
<annevk>
man, can't wait when IANA is fully replaced by wiki.whatwg.org or specs
20:57
<annevk>
for when, even
20:58
<annevk>
not like it matters http://www.iana.org/assignments/media-types/text/html exists now
20:59
<annevk>
[tm]: so no fucks were given about versioning or the DOCTYPE stuff from the RFC?
20:59
<annevk>
[tm]: so weird!
20:59
<[tm]>
matters for me personally because it's one less thing i'm supposed to have got done that I have now got done
20:59
<[tm]>
level cleared
20:59
<[tm]>
annevk: I just push the buttons
21:00
<annevk>
bit hit with the ladies
21:00
<annevk>
big*; damn it
21:01
<[tm]>
PSY of web standards
21:01
<[tm]>
gangham style
21:02
<annevk>
still surprised no fucks were given about any of the things fucks were going to be given over
21:03
<[tm]>
I'm just always happy to slip stuff under the radar whenever I can
21:03
<[tm]>
and prepare to fly the "Too late now!" flag as needed later
21:04
<[tm]>
hey, that worked for the IDN WG
21:05
<annevk>
oh hey, sorry, we fucked over the primary means of accessing your site, have a nice day now
21:07
<annevk>
prolly the same guys that deleted http://en.wikipedia.org/wiki/.yu
21:07
<annevk>
or http://en.wikipedia.org/wiki/.cs
21:08
<[tm]>
hmm what's e10s?
21:08
<[tm]>
https://bugzilla.mozilla.org/show_bug.cgi?id=770778
21:08
<[tm]>
also https://twitter.com/kripken/status/251754496361914369 looks like good news
21:09
<[tm]>
"Initial support for websockets in emscripten now in incoming branch (i.e., use the C sockets API, and it uses websockets)"
21:11
<annevk>
kinda, you'd have to rewrite the server software though
21:14
<[tm]>
oh
21:16
<[tm]>
also me finds https://wiki.mozilla.org/Electrolysis ( = e10s(