01:51
<Benvie>
JonathanNeal: http://www.html5doctor.com
09:09
<jgraham>
Anyone on mozirc fancy asking jlebar to share his test cases?
09:10
<jgraham>
(also is it me or is he devaluing the brand of evil.com; using it in examples that are not really sites doing evil-evil things, just somewhat complex / unpleasant)
09:12
<jgraham>
(althopugh I guess there is actually a security bug in the second example)
09:12
<jgraham>
(but only because of firefox having a broken implementation)
09:58
<annevk>
Hixie: ping
12:29
<annevk>
so thus far I thought no browser other than Chrome unescaped
12:29
<annevk>
but apparently for certain sequences they do?
12:29
<annevk>
e.g. http://example.com/foo/%2e./%2e%2e/.%2e/%2e.bar
12:30
<annevk>
becomes http://example.com/%2e.bar in Gecko
12:34
<annevk>
hmm only Chrome and Gecko it seems
13:37
<annevk>
given e.g. /test/test
13:37
<annevk>
would you rather have .dirs = ["test"] and .filename = "test"
13:37
<annevk>
or .path = ["test", "test"]
13:38
<annevk>
/test/test/ would be .path = ["test", "test", ""]
13:38
<annevk>
could still have filename as returning .path[-1]
13:38
<annevk>
the .path thing seems somewhat more elegant
13:41
<darobin>
all of the above
13:52
<smaug____>
jgraham: who @Opera might have something to say about Filesystem API ?
13:53
<zewt>
people who post "list etiquette" posts to mailing lists i suppose didn't learn the "don't be condescending" item of list etiquette
13:54
<zewt>
annevk: usually "/test/test" and "/test/test/" are equivalent--there are exceptions but having them parse differently would be strange
13:55
<annevk>
zewt: they're usually different
13:55
<annevk>
e.g. replace test with test.html
13:55
<zewt>
i guess if it's for urls and not filename paths (which is what it looked like you meant) you'd want them distinguishable
13:57
<zewt>
hard to do anything "nice" when you don't actually know if the last element is a filename or directory element
13:58
<zewt>
i'd lean towards just .path too
14:03
<zewt>
presumably you'd want to distinguish having a path, eg. [""] (http://foo.com/) with not having a path at all (http://foo.com, []); seems like that would also be awkward with .filename (need to allow it to be null or something)
14:09
<annevk>
actually there will always be a slash there
14:09
<annevk>
so you don't need that
14:12
<zcorpan>
annevk: are you adding more url decomposition idl attributes?
14:13
<annevk>
zcorpan: maybe
14:13
<annevk>
zcorpan: this is mostly the internal API for my parser for now
14:13
<annevk>
zcorpan: to easily implement "." and ".." segments
14:13
<annevk>
for hierarchical URLs
14:13
<zcorpan>
ok
14:13
<annevk>
but some of it might be cool to expose
14:14
<zcorpan>
i don't see much point if we have ability to resolve a url to another
14:15
<zcorpan>
do popular javascript libraries have stuff in this area?
14:47
<annevk>
I was planning to look into that at some point
14:47
<annevk>
abarth did add .filename
15:07
<annevk>
https://github.com/annevk/url/blob/master/url.js is my code
15:16
<annevk>
note: does not do host/ip mess
15:27
<niloy>
why dont browsers provide api to list all listeners attached to a DOM node?
15:28
<annevk>
search public-webapps archives or www-dom
15:28
<niloy>
search on google?
15:30
<annevk>
I don't really care where you do it
15:33
<annevk>
ah
15:34
<annevk>
my URL parser also does not deal with encoding for query
15:34
<annevk>
that's kinda hard to support in JavaScript
15:34
<annevk>
without implementing all the encodings that is :)
15:40
<Ms2ger>
annevk, jsbell's encoder thing ;)
15:40
<annevk>
Ms2ger: yeah indeed, but since this parser is mostly for research purposes I don't really see the point
15:40
<annevk>
Ms2ger: but if you want to make it work, be my guest
15:41
<Ms2ger>
Heh
15:41
<annevk>
next step is rewriting this JavaScript into English
15:41
<annevk>
and then I guess I'll have another look at host/IP
15:44
<jgraham>
I see being on holiday didn't cheep Ms2ger up any :)
15:44
<jgraham>
*cheer
15:45
<Ms2ger>
Hmm? :)
15:45
<jgraham>
public-webapps
15:47
<Ms2ger>
Ah, always a cheery place
16:07
<annevk>
heh
16:24
<Ms2ger>
jgraham, though I don't know how you expected me to be cheery after wading through my email backlog ;)
16:53
<smaug____>
Ms2ger: that is why holiday isn't good for health
16:54
<smaug____>
reading the emails after holiday sucks all the energy
16:57
<Ms2ger>
Should've gone for a sauna instead
16:58
smaug____
is waiting for sauna to be ready :)
17:28
<annevk>
just mark email as read :)
18:12
<annevk>
rwaldron: thanks, seems I forgot a comma before IDNAToASCII
18:13
<annevk>
rwaldron: not too concerned about the global URL object; this is just a research thingie for now
18:25
<Hixie>
annevk: pong
19:06
<jgraham>
Dammit I forgot to reply to smaug
20:05
<annevk>
Hixie: dealt with it already; wiki account issue
20:05
<annevk>
or at least, I hope it is okay this time around
21:38
<Hixie>
can anyone think of ways to cause a document to fire more than one unload event?
21:38
<Hixie>
other than starting a navigation while running unload
21:39
<Hixie>
we've already killed running document.open() during unload
21:42
<Hixie>
back() eventually fires unload, but it does so on a task so i don't think you can have that one happen after another
21:43
<Hixie>
ok so to block the double unload from navigation i just need to detect if we're going back while navigating, and if so, not do the unload dance