01:11
Hixie
discovers Net::IMAP::Simple
01:11
Hixie
pokes at his IMAP mail box
01:13
<Hixie>
3741 e-mails in my whatwg folders
01:31
<Hixie>
the top five names still in my pile of e-mails to deal with are:
01:31
<Hixie>
Henri Sivonen (245)
01:31
<Hixie>
Jim Ley (144)
01:31
<Hixie>
Matthew Raymond (128)
01:31
<Hixie>
Anne van Kesteren (110)
01:31
<Hixie>
Lachlan Hunt (109)
01:32
<jruderman>
too bad you can't just off those people. kill one person and everyone thinks you're a murderer!
01:33
<Hixie>
what's amusing to me is that two of those five people haven't really posted much recently
01:38
<Hixie>
two most common subject lines:
01:38
<Hixie>
Re: [whatwg] Mathematics in HTML5 : 138
01:38
<Hixie>
Re: [whatwg] on codecs in a 'video' tag. : 74
01:38
<Hixie>
(remember that these are as yet unanswered e-mails, so they're heavily biased by what i've already replied to)
09:46
<zcorpan>
Philip`: did you implement microsyntaxes?
09:52
<hsivonen>
hmm. some Java APIs are like namespaces: can't remember them
10:23
<krijnh>
Why do spambots keep POSTing to 404 URIs :S
10:32
<virtuelv_>
krijnh: because they also keep POSTing to any URL they have decided
10:32
<virtuelv_>
I got 10000 POST requests to a document only strictly gettable
10:35
<krijnh>
Bah
12:39
<hsivonen>
hmm. I connected the Xalan serializer manually to Xalan and got ill-formed output (duplicate xmlns)
13:00
<Philip`>
zcorpan: I didn't - are you thinking of http://geoffers.no-ip.com/svn/php-html-5-direct/src/trunk/ ?
13:04
<zcorpan>
Philip`: hmm, perhaps
13:48
<zcorpan>
interesting that type="" is authorative on <embed> but ignored on <object>
13:51
<annevk>
I'd agree that the Web is interesting
13:51
<zcorpan>
is it required for compat?
13:58
<annevk>
zcorpan, maybe, at least when src= is not present
13:59
<annevk>
not sure it makes much sense trying to risk it for a useless element like <embed>
13:59
<zcorpan>
annevk: you lost me there
14:05
<zcorpan>
what happens with <param name="" value="foo">
14:07
<hsivonen>
I wonder what XHTML-to-XHTML XSLT transformations people tend to do
14:07
<hsivonen>
I now have only one real-world test case (DanC's task survey transformation)
14:07
<zcorpan>
(which is broken)
14:08
<hsivonen>
how?
14:08
<zcorpan>
it outputs elements in the null namespace
14:08
<zcorpan>
but works because it's served as text/html
14:08
<annevk>
zcorpan, <embed type> handling is required for compat when src= is not present (at least)
14:08
<hsivonen>
ooh. perhaps that's why I saw weirdness with Xalan
14:08
<annevk>
zcorpan, I'm not sure if changing browser behavior for <embed src type> is worth it
14:09
<hsivonen>
I already hacked a workaround that trashes xmlns attributes
14:09
<hsivonen>
but
14:09
<hsivonen>
with the hack, Xalan gives me sane namespaces scopes.
14:09
<hsivonen>
hmm.
14:09
<zcorpan>
annevk: ok. (i'm not suggesting to change it)
14:09
<hsivonen>
anyway, I am still interested in examples of non-broken XHTML-to-XHTML XSLT transformations
14:14
<hsivonen>
zcorpan: are you sure that DanC's transformation is broken?
14:14
<zcorpan>
yes
14:14
<zcorpan>
<xsl:template match='h:div[h:h3/h:a/@id="xbgbio"]/h:table'>
14:14
<zcorpan>
<ul>
14:14
<zcorpan>
no default namespace on the ul
14:14
<hsivonen>
oh, right that part
14:15
hsivonen
notes the non-use of id()
14:15
<hsivonen>
probably related to the IDness establishment probs
14:18
<hsivonen>
http://www.mnot.net/blog/2007/08/07/etags
14:57
<zcorpan>
<map ...><area><area .../> doesn't work in firefox
15:03
<annevk>
seems that only Firefox implies </address> at <table> and <ol>/<ul> ...
15:03
<zcorpan>
firefox implies </address>?
15:04
zcorpan
didn't know
15:04
<annevk>
I was wondering whether the <address> content model had legacy reasons
15:04
<annevk>
doesn't seem like it has in IE7 and O9
15:15
<zcorpan>
also div, address, dl, center...probably others too
15:15
<zcorpan>
blockquote
15:16
<zcorpan>
h1-h6
15:18
<zcorpan>
hr, li, menu, pre, fieldset, form
15:19
<zcorpan>
annevk: address does allow tables in address though
15:19
<zcorpan>
er
15:19
<zcorpan>
html5
15:19
<annevk>
sure
15:19
<annevk>
it would be silly otherwise
15:20
<zcorpan>
seems to be that Ben Boyle thought it didn't
15:21
<annevk>
oh, allowing it in the parser I meant
15:21
annevk
didn't check conformance
15:23
<Philip`>
Aha, I was wondering if Firefox treated anything else the same as <unknown> in terms of implying end tags, but couldn't think of any, but it looks like <address> is one
15:26
<zcorpan>
we should preserve wordings that makes readers smile! :)
15:33
<zcorpan>
hmm, ie doesn't support coords=default
15:34
<annevk>
yeah, known
15:35
<annevk>
I think IE parsing was not reverse engineered fully or something
15:36
<zcorpan>
parsing of what?
15:37
<zcorpan>
s/coords/shape/
15:38
<annevk>
coords, I believe it was not really a problem that IE didn't do shape=default
15:39
<zcorpan>
ok
15:39
zcorpan
needs to play more with image maps
15:39
<annevk>
I'd spend time on stuff that causes actual problems :)
15:39
<zcorpan>
such as
15:40
<annevk>
good question
15:40
<zcorpan>
seems we apply the areas in the wrong order
15:40
<annevk>
guess most of those sections are sort of covered, just awaiting implementation experience
15:40
<zcorpan>
yeah
15:40
<zcorpan>
i could write test cases for video
15:41
<zcorpan>
i've avoided that section so far
15:42
<annevk>
parsing of <meta http-equiv=refresh> ? :)
15:45
<zcorpan>
http://simon.html5.org/test/html/semantics/area/001.xht
15:45
<zcorpan>
yeah
15:45
<zcorpan>
or actually
15:45
<zcorpan>
http-equiv in general
15:45
<zcorpan>
it is implemented differently from what html5 says i think
15:45
<zcorpan>
browsers really treat the values as if they were http headers
15:46
<zcorpan>
and Refresh is supported as a real header
15:46
<annevk>
in some browsers, yes
15:46
<annevk>
the question is whether they can drop such support
15:46
<zcorpan>
in which browsers is that not so?
15:47
<annevk>
I thought Refresh was only supported by Gecko, actually
15:47
<zcorpan>
oh no
15:47
<zcorpan>
last time i checked i didn't find any browser not supporting it
15:47
<zcorpan>
but i might have done something wrong by then
15:47
<annevk>
interesting
15:48
Philip`
sees <meta http-equiv> used on more pages than <table>, but doesn't have any way to determine the attribute's values :-(
15:49
zcorpan
assumes content-type and content-language are the 2 top
16:42
<krijnh>
Perhaps set-cookie
16:48
<met_>
hsivonen: http://about.validator.nu/author/ from the footer gives 404
21:14
<gsnedders>
is there any content that relies on browsers treating HTTP headers ending in "CRLF as the value including the quote?
21:25
<gsnedders>
this is something browsers do unusually (for HTTP) consistently
22:45
<Hixie>
here's an example of a page that blatently shouldn't validate: http://gallery.mac.com/emily_parker#100335&bgcolor=black
22:46
<Hixie>
and not for the reasons the validator currently gives
22:46
<Hixie>
disable stylesheets on that page to see what i mean
22:47
<Hixie>
hsivonen: http://html5.validator.nu/?doc=http%3A%2F%2Fgallery.mac.com%2Femily_parker%23100335%26bgcolor%3Dblack ?
22:49
<gavin_>
wow
22:50
<Hixie>
hsivonen: btw i've added a form to validator.whatwg.org so that people can submit URIs from there instead of having one more page to go through
22:50
<Hixie>
hsivonen: let me know if that's a problem
22:54
<hsivonen>
Hixie: apparently & is not allowed in the fragment identifier so the IRI parser barfs
22:54
<hsivonen>
Hixie: the form on validator.whatwg.org is ok
22:55
<Hixie>
interesting about &
22:56
<Philip`>
Is <base target="_self"> meant to do anything at all useful? (If it does, I can't work out what it is, but TinyMCE appears to use it quite frequently)
23:01
<hsivonen>
Hixie: hmm. perhaps it isn't the IRI parser at all. but the HTTP lib doesn't like getting any fragment ids
23:01
<hsivonen>
I guess I should use the IRI lib to zap the fragment id
23:03
<Hixie>
yeah you shouldn't send fragids over the wire
23:03
<Hixie>
maybe the http lib just doesn't know to drop them :-)
23:04
<Hixie>
Philip`: it probably creates a new window called _self and then targets that a lot - unless something first did window.name = "_self_ ?