04:26
<othermaciej>
so what's the story with EventSource and server-sent events these days?
04:29
<Hixie>
it's stable
04:29
<Hixie>
not aware of any outstanding issues
08:49
<hsivonen>
http://lists.w3.org/Archives/Member/tag/2009May/0066.html
08:55
<Hixie>
http://lists.w3.org/Archives/Public/public-xhtml2/2009May/0024.html
08:59
<hsivonen>
context: http://lists.w3.org/Archives/Member/tag/2009May/0051.html
09:21
<hsivonen>
http://lists.w3.org/Archives/Member/w3c-ac-forum/2009AprJun/0112.html
09:28
<Hixie>
there's a perception that wg groups fail to meet their deadlines because they always do, because the timetables the w3c put forward are wildly unrealistic, because they consider realistic timetables to be too likely to turn people away
09:37
mhausenblas
seldom agrees with Hixie, but 'they consider realistic timetables to be too likely to turn people away' deserves a +1 ;)
09:39
<Hixie>
when the htmlwg was chartered, i said what the html5 timetable was
09:39
<Hixie>
last call in oct 2009, etc
09:39
<othermaciej>
which was clearly unreasonable, to anyone who had any understanding of the matter
09:40
<othermaciej>
at this point I am not sure if we will get to Last Call this decade, given Sam's way of talking about it...
09:40
<Hixie>
they said that was never going to work and instead used this: http://www.w3.org/2007/03/HTML-WG-charter#deliverables
09:40
<Hixie>
last call june 2008, CR by sept last year
09:41
<Hixie>
whatwg's html5 will reach LC in oct 2009
09:41
<Hixie>
i can't speak as to the w3c's :-)
09:59
<zcorpan>
"Add a <code title="">type</code> attribute whose value is the string "<code title="">text/html</code>" to <var title="">x</var>"
09:59
<zcorpan>
Hixie: ^ that seems unnecessary and might be incorrect
10:00
<Hixie>
i thought i removed the type attribute in the case where it was wrong
10:01
<zcorpan>
hmm the next step inserts another <link rel="alternate">
10:01
<Hixie>
oooops
10:01
<Hixie>
looks like i have an extra one
10:02
<zcorpan>
isn't type="" optional anyway?
10:02
<Hixie>
yeah but seems good to include it if you know it
10:03
<Hixie>
ok removed the extra one
10:03
<Hixie>
bed time now
10:04
<Hixie>
uh
10:04
<Hixie>
hsivonen:
10:04
<Hixie>
Possible conformance errors:
10:04
<Hixie>
"Stream length exceeds limit.": non-document-error io: http://www.whatwg.org/specs/web-apps/current-work/source-validation
13:40
gsnedders
sighs
13:40
<gsnedders>
Splitting out the input stream from the tokenizer in PHP html5lib is a lot of work
14:30
gsnedders
finds a fairly major bug
14:30
<gsnedders>
Though actually with only CDATA and RCDATA elements having ASCII names it isn't actually a bug that can ever be hit
14:31
<annevk4>
that doesn't like you discovered a bug then :)
14:34
gsnedders
wonders whether he should change the tokenizer to allow R?CDATA elements to have non-ASCII names, but seeming it's an anti-optimization, decides against it
15:44
<Philip`>
gsnedders: Why do you want to split it out?
15:45
<gsnedders>
Philip`: To have multiple different InputStream classes, esp. one for files
15:48
<Philip`>
gsnedders: Ah
15:55
<gsnedders>
Huh… line 751 tokenizer.py
15:55
<gsnedders>
Will that not match D followed by any permutation of the characters OTYPE (with repetition allowed)?
15:56
<gsnedders>
s/O/OC/
15:57
<Philip`>
gsnedders: No
15:58
<gsnedders>
Oh, duh.
15:58
gsnedders
realizes how dumb that was
15:58
<Philip`>
gsnedders: It loops with expected=('o', 'O') first and checks the next character against that, etc
15:58
<gsnedders>
Exactly.
16:04
<gsnedders>
The difficulty of doing this is mainly because the PHP impl assumes it is a string so it has look-ahead and look-behind for the entire input data.
16:08
<Philip`>
I don't think the Python version ever did that, but it did assume it could arbitrarily consume and unconsume characters whenever it fancied
16:12
<takkaria>
yeah, if you can optimise your tokeniser never to use look-behind, that can give you good performance benefits
16:19
<gsnedders>
We need to look-behind per spec, but we can't look behind in, e.g., an http file resource.
16:23
gsnedders
finally makes it to the final method
16:30
<Philip`>
gsnedders: Why do we need to use look-behind per spec?
16:30
<gsnedders>
Oh, no, we don't.
16:30
<gsnedders>
It's just both PHP and Python impl consume too much :P
16:30
<Philip`>
It needs look-ahead, which I guess would look like look-behind from a different perspective
16:30
<gsnedders>
Yeah, indeed.
16:35
<gsnedders>
The Python deviates from the spec quite a lot when consuming an entity.
16:38
<Philip`>
The spec isn't written a way that can be efficiently implemented
16:38
<Philip`>
*in
21:04
<hsivonen>
"Gregory: What I need to do is to proselytize the use of RDFa for accessibility"
21:04
<hsivonen>
http://www.w3.org/2009/05/13-xhtml-minutes.html
21:14
<Dashiva>
"Gregory: I would like to a DTD for XHTML 1.1+RDFa+Aria... +role"
21:15
<Dashiva>
DTD proliferation :)
21:18
<Philip`>
Sounds like a scalability problem for the W3C, if the number of DTDs they have to host is exponential in the number of technologies they specify
21:21
<gsnedders>
It's factorial, not exponential.
21:22
<gsnedders>
Stop trying to paint the W3C in good light :P
21:22
<Philip`>
I'm pretty sure it's exponential
21:23
<Philip`>
If you have n technologies, then for each technology you can decide to either add it to the DTD or not
21:23
<Philip`>
which means you have a choice between 2 values, n times
21:23
<Philip`>
which results in 2^n possible choices
21:24
<gsnedders>
Permutations
21:24
<gsnedders>
You have the number of permutations of specs you have.
21:25
<Philip`>
No you don't
21:25
<Philip`>
Order doesn't matter
21:25
<gsnedders>
Ah, true.
21:26
<gsnedders>
Duh.
21:26
<Philip`>
And it's not combinations (nCr) either, because r is not restricted to a single value
21:26
<gsnedders>
Yeah, true.
21:27
<Philip`>
(Obviously it wouldn't be exactly 2^n, because nobody's going to want the DTD that contains zero technologies)
21:27
<Philip`>
(but it'll be O(2^n))
21:32
<gsnedders>
2^n-1, no?
21:33
<Philip`>
Nooooo!
21:33
<Philip`>
Constants are ugly
21:33
<gsnedders>
:D
21:33
<Philip`>
Just call it O(2^n) :-p
21:38
<Dashiva>
Order matters if UAs do string matching
21:39
<Dashiva>
Poor code :(
21:41
<Philip`>
They can use a canonical ordering
21:41
<gsnedders>
\sum_{r=1}^{n} nPr then
21:41
<gsnedders>
Ow.
21:41
<Philip`>
so that there aren't multiple orderings of the same set of technologies
21:45
<Dashiva>
What about when users start writing the doctype names by hand?
21:45
<Philip`>
Throw a fatal error if they didn't use the canonical ordering
22:23
<Hixie>
i am baffled
22:24
<Hixie>
when i said last call was october 2009 in 2006, html5 was accused of glacial progress
22:24
<Hixie>
when i say last call is october 2009 in 2009, html5 is accused of going too fast
22:25
<gsnedders>
Logic? Peh.
22:25
gsnedders
throws it out
22:28
<inimino>
that's only baffling if it's the same people making both sets of accusations
22:34
<gsnedders>
http://www.ietf.org/internet-drafts/draft-sneddon-atom-export-01.txt — feedback welcome.
22:37
gsnedders
wonders what to do about IRI for atom:category@scheme
22:40
<Philip`>
gsnedders: It would be nice if the abstract said what it was actually about
22:40
<Philip`>
(In particular, what it's meant to be exporting, and from where)
22:41
<hober>
gsnedders: sounds like a description of the backing store I use for my blog :)
22:45
gsnedders
makes another tweet probably nobody will understand