00:03
<Hixie_>
jamesr__: back
00:03
<Hixie_>
jamesr__: you still around?
00:04
<Hixie_>
gsnedders is gone, bummer.
00:04
<Hixie_>
there can be many event loops. they run in parallel. for example, if you have firefox and chrome both running on your machine, you'll have at least two event loops.
00:04
<Hixie_>
also each worker has its own event loop.
00:04
<Hixie_>
multiprocess event loops have one loop per process.
00:04
<Hixie_>
etc
00:06
<Hixie_>
gsnedders: see logs
00:52
<leo_33>
in your opinion why would a headhunter continue sending you info about a job after a job interview?
00:55
<jamesr__>
Hixie_: i'm around, but not for super long
00:55
<jamesr__>
Hixie_: i got distracted by finding a 3-month old crash bug in our parser
00:55
<leo_33>
in your opinion why would a headhunter continue sending you info about a job after a job interview?
00:57
<jamesr__>
Hixie_: if you had <script>document.write('<link ...><script src=...><\/script>');</script>, wouldn't the nesting level be non-zero when parsing the inner </script>, thus bypassing that section of the algorithm?
01:20
<Hixie_>
jamesr__: hm.
01:20
<Hixie_>
jamesr__: no
01:21
<Hixie_>
jamesr__: it's 1 while the document.write() runs, but the inner script doesn't execute until the outer script has ended, when it's zero again.
08:01
<hallvors>
jgraham: yt? time for a testharness.js question?
08:08
<darobin>
hallvors: you're doing it wrong
08:08
<darobin>
jgraham: hey man! We've got some cookies over here!
08:08
<hallvors>
:)
08:09
<Ms2ger>
What's up?
08:11
<hallvors>
Ms2ger: well, busy responding to you in bug 918764 :)
08:11
<hallvors>
I'm also curious what the best way to use testharness.js's assert_throws() for a TypeError is
08:12
<Ms2ger>
assert_throws(new TypeError(), fn)
08:12
<hallvors>
assert_throws("TypeError", ... doesn't work
08:12
<hallvors>
OK
08:12
<Ms2ger>
It's a bit strange :)
08:12
<hallvors>
I was trying to decide between new TypeError() and passing in {name:'TypeError' ..
08:13
<hallvors>
It's strange mainly because it's somewhat inconsistent with the assert_throws("FooError" style for the DOM exceptions..
08:14
<zcorpan>
Hixie_: http://www.whatwg.org/specs/web-apps/current-work/multipage/fragment-links.js seems broken
08:14
<hallvors>
I would prefer adding more known strings so that us poor test authors don't have to figure out what syntax to use for the error we're after..
08:15
<hallvors>
ah, zcorpan - perhaps I should have bothered you and not James about this ;-)
08:17
<hallvors>
anyway Ms2ger, if you have a moment please reply in bug 918764 - thx :)
08:17
<zcorpan>
hallvors: if you can construct the real thing, do that, if not (DOMException), use a custom object
08:18
<zcorpan>
or a string for DOMException...
08:18
<zcorpan>
not super obvious, i agree
08:19
<zcorpan>
Philip`: do you know anything about why http://www.whatwg.org/specs/web-apps/current-work/multipage/fragment-links.js is broken?
08:19
<Ms2ger>
Don't the docs say all that, though?
08:20
<zcorpan>
yeah
08:23
<Philip`>
zcorpan: It worked when I last looked at it, so someone must have changed something in the past five years
08:24
<zcorpan>
helpful!
08:24
<zcorpan>
xref relies on it in html.py so now i can't generate html-differences
08:26
<Philip`>
zcorpan: The file looks truncated, so I guess either the upload was incomplete or the script aborted halfway through
08:26
<Philip`>
zcorpan: but I don't know where the script is run now, or how to see what errors it might have emitted
08:26
<hsivonen>
I wonder if these seriously bad idea encodings are truly needed for email
08:26
<hsivonen>
UTF-7 and its friends
08:26
<zcorpan>
yeah failed upload seems plausible, i'll wait a bit and see if it fixes itself
08:28
<zcorpan>
hsivonen: maybe first step towards making them not truly needed is to identify clients that send utf-7 by default, and second clients that support sending utf-7
08:29
<zcorpan>
although i can imagine the problem isn't just with clients but with scripts that send email (like newsletters)
08:31
<hsivonen>
encodings are fractally wrong
08:31
<hsivonen>
every time I try to fix a bug, I find another bug that I should fix
08:32
<zcorpan>
http://programmers.stackexchange.com/questions/163930/how-relevant-is-utf-7-when-it-comes-to-parsing-emails
08:34
<hsivonen>
oh programmers.stackexchange is for conceptual questions and StackOverflow for non-conceptual ones?
08:35
<hsivonen>
Developing a browser engine would be easier if it wasn't used for email also.
08:35
<zcorpan>
so hotmail bounces is utf-7 (unless they've changed it), that's something users actually get
08:36
<hsivonen>
sad
08:39
<darobin>
maybe it'd help if we added the list of errors from http://www.ecma-international.org/ecma-262/5.1/#sec-15.11 to testharness?
08:40
<Ms2ger>
gsnedders, merge https://github.com/html5lib/html5lib-tests/pull/4 already :)
08:41
<zcorpan>
Hixie_: is fragment-links.js regenned every commit?
08:46
<Philip`>
zcorpan: It's generated by http://html5.googlecode.com/svn/trunk/spec-splitter/spec-splitter.py which ought to be run every commit
08:47
<zcorpan>
ok
08:49
<zcorpan>
the multipage version is up to date so that part still works
08:55
<hsivonen>
\o/ Thunderbird always sends UTF-8 to the HTML parser, so I can rip out support for mail-only encodings out of the parser
08:55
<Ms2ger>
\o/
10:05
<hsivonen>
annevk: do you happen to already have test cases for the replacement encoding?
10:08
<jgraham>
hallvors: Sorry, missed the question earlier. Did you sort things out?
10:08
<hsivonen>
annevk: can you remind me why the spec doesn't map UTF-7 and HZ to the replacement encoding?
10:08
<jgraham>
We could probably add support for assert_throws("TypeError", function(){})
10:38
<aleray>
hi, I'm having problems with html5lib and lxml.etree. I don't know exactly what happens but I get a "'unicode' object has no attribute 'tag'" AttributeError. I wrote my own serializer to tranform HTML into ConText (LaTex-like language). I have a bunch of database entries that have some fields with HTML in them. It seems to happen when the fragment of HTML I pass in is text only (not enclosed by any tag). Any Idea?
10:38
<aleray>
http://dpaste.com/1394167/
11:06
<aleray>
ok more info: http://dpaste.com/1394200/
11:07
<aleray>
I somehow end up with a tree that contains a unicode object, and not an Element
11:47
<jgraham>
aleray: Do you have a small testcase that demonstrates the problem?
11:57
<aleray>
jgraham, trying to make on
11:57
<aleray>
one
11:57
<aleray>
just a moment
12:06
<aleray>
jgraham, here it is: http://dpaste.com/1394268/
12:09
<aleray>
jgraham, works when I remove the the unicode entities
12:17
<aleray>
jgraham, seems to be caused by lxmletree.py
12:18
<jgraham>
aleray: That seems like a bug in html5lib. Can you file an issue on github?
12:18
<aleray>
jgraham, yes
12:18
<jgraham>
Oh, unless you have time towork out what's wrong and fix it, in which case an issue and a PR would be great ;)
12:18
<aleray>
the FragmentWrapper.isstring method doesn't play nice with unicode
12:18
<aleray>
jgraham, I can try, but I'm always a mess with unicode stuff :)
12:19
<jgraham>
Ah, you could be right
12:20
<jgraham>
the isstring attribute looks quite python 3 ish
12:20
<jgraham>
gsnedders: &
12:20
<jgraham>
s/&/^/
12:20
<aleray>
jgraham, basically: "self.isstring = isinstance(obj, str) or isinstance(obj, bytes)" should be valid for unicode type
12:22
<jgraham>
self.isstring = isinstance(obj, six.string_types)
12:23
<jgraham>
Perhaps
12:29
<aleray>
jgraham, here is the relevant part of the thing: http://dpaste.com/1394290/
12:31
<aleray>
sl I guess it should become "self.isstring = isinstance(obj, str) or isinstance(obj, bytes) or isinstance(obj, six.text_type)"
13:18
<annevk>
hsivonen: no tests, a bunch of encodings are not listed yet because I wanted to see if this was the direction we were heading
13:20
<annevk>
hsivonen: looking for the bug...
13:21
<annevk>
hsivonen: per https://www.w3.org/Bugs/Public/show_bug.cgi?id=21057 you thought utf-7 and utf-32 might be relying on fallback
13:21
<annevk>
hsivonen: I think hz-gb-2312 is still in use
13:34
<aleray>
here we go: https://github.com/html5lib/html5lib-python/issues/115
13:35
<jgraham>
aleray: Thatnks
13:35
<jgraham>
*Thanks
13:35
<aleray>
jgraham, happy to help :) I'm quite in love with html5lib. I didn't wrtie any test I don't know exactly how it should be done
14:13
<Ms2ger>
Hrm, idlharness doesn't seem to like variadic arguments
14:20
<darobin>
Ms2ger: is this from an existing IDL?
14:20
<Ms2ger>
DOMTokenList
14:21
<Ms2ger>
annevk, r? https://critic.hoppipolla.co.uk/r/288
14:22
<annevk>
r+
14:23
<Ms2ger>
Ta
14:31
<jgraham>
gsnedders: I think the point is that in this case lxml gives unicode on py2
14:32
<jgraham>
zcorpan: I think I accidentially fixed the bug that caused reviews to not get closed on critic
14:32
<zcorpan>
jgraham: nice
14:32
<jgraham>
In other news, I now have pywebsockets tests running on localhost :)
14:33
<zcorpan>
jgraham: i guess it won't close the reviews currently open with a closed PR though?
14:33
<jgraham>
Well I mean pywebsockets-based tests for the websockets api
14:33
<jgraham>
zcorpan: No
15:27
<jgraham>
hallvors: So you are working on XMLHttpRequest tests, right? :)
15:28
Ms2ger
sees outstanding xhr reviews
15:28
<hallvors>
jgraham: yes. A little bit :)
15:28
<hallvors>
Found some issues during a Gecko test run, will fix them
15:29
<jgraham>
hallvors: You don't have some hidden desire to rewrite the PHP in python so that we can run them in automation, do you?
15:29
<hallvors>
Those PHP files are pretty simple, no?
15:29
<hallvors>
should be easy enough
15:30
<hallvors>
(aka "famous last words" I guess :-))
15:30
<jgraham>
I don't know, I just know that they are taking up a lot of my screen :)
15:30
<jgraham>
I haven't really looked
15:32
<hallvors>
well, some of them might be tricky if they try to do corner case stuff. On the other hand, some of those corner cases might be easier to trigger in a less hacky language ;-)
15:32
<hallvors>
although I think supporting PHP in whatever test framework you're aiming for might lower the bar to participation ;-)
15:33
hallvors
thinks PHP is a great language for beginners because of the excellent docs, and is prepared for being flamed & lynched for saying so
15:35
jgraham
wonders where these excellent docs are, only found the slightly rubbish built-in ones
15:35
<jgraham>
:p
15:36
<annevk>
if you know how PHP works, it's pretty great for small stuff, otherwise many pitfalls
15:45
<zewt>
probably python's biggest flaw is that its syntax sucks for php-style templating
16:11
<gsnedders>
jgraham: WTF. It shouldn't ever, I believe.
16:11
<gsnedders>
jgraham: Well, will look later.
16:12
Ms2ger
pokes gsnedders about that PR
16:13
<gsnedders>
Ms2ger: Which?
16:13
<Ms2ger>
https://github.com/html5lib/html5lib-tests/pull/4
16:28
<jgraham>
So, should I consider the possibility of browsers sending multiple headers with the same name?
16:39
<gsnedders>
Ms2ger: Oh, okay. Then sure.
20:20
<gsnedders>
Ms2ger: if you read logs, dealt with that PR
20:27
<gsnedders>
Ms2ger: If you deal with https://github.com/html5lib/html5lib-tests/pull/21 we're even. ;P
20:39
<Hixie_>
oh man
20:39
<Hixie_>
setting up a new event loop is gonna suck
20:40
<Hixie_>
(a per-tab event loop for session history, independent of the event loops of any actual tabs)
20:40
<Hixie_>
(er, of any actual browsing contexts)
20:45
<gsnedders>
Who deals with parser stuff at WebKit nowadays?
20:58
<zcorpan>
heycam|away: "The following extended attribute is applicable to dictionaries: [Constructor]." is that right?
22:01
<Hixie_>
tantek: microformats just honours dir="" transparently, right? there's no special magic?
22:06
<tantek>
Hixie - that's right
22:07
<tantek>
did someone raise an issue about dir?
22:07
<Hixie_>
only tangentially. not an issue on microformats.
22:44
<annevk>
I could also change *|*:fullscreen::backdrop to ::backdrop...
22:44
<annevk>
I don't think you'd be able to observe the difference
22:44
<Hixie_>
too late :-)
22:44
<Hixie_>
well, not too late i guess
22:44
<Hixie_>
but i've taken care of it
22:44
<Hixie_>
for <dialog>
22:45
<Hixie_>
i originally thought it was just defined to cover the background
22:45
<Hixie_>
that's why i hadn't positioned it
22:45
<Hixie_>
but it's fine
22:46
<annevk>
fair enough, no need to touch both specs at this point indeed