00:00
<Jero>
yeah, i noticed, thanks
00:00
<Jero>
i saw it on your slides i mean :p
00:01
<Jero>
are there a lot of implementations you know of? or just the 3 you listed on your presentation?
00:03
<zcorpan_>
http://waffle.wootest.net/2007/05/16/ruby-the-same-token/
00:03
<zcorpan_>
not sure where he has the source of that
00:04
<zcorpan_>
but those are the ones i know of
00:06
<Jero>
hmm, that's not a lot
00:08
<zcorpan_>
would be cool to have it implemented in a browser, that would surely find bugs in the spec :)
00:09
<Jero>
indeed
00:10
<zcorpan_>
esp if it's used for quirks mode
00:11
<Jero>
but html5lib could be used to download a collection of pages to parse it, right?
00:11
<zcorpan_>
sure
00:12
<zcorpan_>
or at least the parsing bit :)
00:12
<Jero>
or do you mean that you want to actually see how those websites are displayed?
00:12
<Jero>
ah ok :p
00:12
<Jero>
yeah, for that it'll become a bit hard with just html5lib
00:13
<zcorpan_>
i mean to have a downloadable build of firefox that has a real html5 parser, to see how many people compain about their sites broke in the new firefox
00:13
<zcorpan_>
just using firefox as an example
00:14
<zcorpan_>
for instance, we might find that the parsing spec actually has to take <script><!--</script>--></script> into account
00:15
<Jero>
yeah, having a Firefox build with an html5 parser would be awesome
00:15
<zcorpan_>
or actually, firefox already doesn't do that for standards mode. let's see if there are any bug reports on that
00:21
<zcorpan_>
hmm, the <script><!--</script>--></script> might include some reparsing stories currently. what do you do with <script><!--</script>x</script>EOF ?
00:21
<zcorpan_>
(or just <script><!--</script>x EOF)
00:24
<zcorpan_>
https://bugzilla.mozilla.org/show_bug.cgi?id=311128
00:25
<Jero>
hmm, i wish i couldn't test what ph5p does with that, but I've added 1000 lines of untested code today, so i need to get rid of all the syntax errors first :p
00:33
<zcorpan_>
there are some dups of document.write('</script>'); not working in mozilla, even though it's only in standards mode
00:33
<Jero>
yup, it's annoying
00:34
<zcorpan_>
that suggests to me that trying to remove support for pseudo-comments in quirks mode won't work
00:34
<zcorpan_>
and we will have to spec it
00:34
<Jero>
yeah, i think you're right
01:03
<Jero>
hey i got to go
01:03
<Jero>
see ya
09:41
<MikeSmith>
playing around with setting up a Venus-based aggregator
09:42
<MikeSmith>
question: What's a reasonable time interval for running the script that checks for updates to blogs?
09:42
<MikeSmith>
every 30 minutes? once an hour?
09:43
<annevk>
hourly and please do check for 304 and such :)
09:44
<annevk>
I guess Sam has support for that...
09:48
<annevk>
What is actually the reason for not allowing both block and inline in the same element?
09:48
<annevk>
Besides that it doesn't look good
09:55
<MikeSmith>
annevk - where are block and inline in the same element prohibited
09:55
<MikeSmith>
(and I'm just using Venus off-the-shelf so I hope Sam does have it set up for 304s and such)
09:56
<hsivonen>
MikeSmith: pretty much everything that used to be %Flow is now bimorphic
09:58
<hsivonen>
annevk: what's your take on my editor-related conformance/bimorphic idea? http://intertwingly.net/blog/2007/05/08/Dont-Break-The-Web#c1178698369
09:58
<hsivonen>
I'd be *very* interested in hearing Hixie's design rationale, though.
09:59
<annevk>
me too
10:00
<annevk>
See http://www.456bereastreet.com/archive/200705/use_only_blocklevel_elements_in_blockquotes/#comment57
10:05
<annevk>
hsivonen, why don't you support file upload?
10:05
<annevk>
your validator
10:18
<mpt>
"Fundamentally, I believe that the current state (where HTML is functionally a subset of XHTML, but operationally, HTML is more robust than XHTML) is unstable."
10:20
<othermaciej>
XHTML is functional?
10:21
<mpt>
You know that's not what he means
10:23
<othermaciej>
I don't know who you're quoting or what the context is
10:23
<othermaciej>
I was just trying to make a snide remark
10:23
<mpt>
Sam Ruby, http://intertwingly.net/blog/2007/05/08/Dont-Break-The-Web#c1179440845
10:23
<mpt>
and I agree
10:24
<mpt>
That XHTML but not HTML can have lists inside paragraphs is unfortunately unavoidable. That XHTML but not HTML can have MathML or SVG is just ... wrong.
10:25
<othermaciej>
we definitely need a way to embed other languages in non-X HTML
10:25
<hsivonen>
annevk: the reason why I don't have file upload is that I had prioritized my thesis. And now I am prioritizing the parser.
10:25
<othermaciej>
SVG probably matters more than MathML to be honest
10:25
<annevk>
That's definitely the wrong way to go around things, hsivonen. You should priortize around my needs :)
10:26
<mpt>
othermaciej, agreed
10:26
<annevk>
I'm still not quite convinced that embedding SVG inside HTML (or XHTML for that matter) is a good idea
10:26
<mpt>
In the meantime, there will be a lot of <canvas> used where SVG would be more useful-in-the-long-term
10:26
<hsivonen>
annevk: out of curiosity, why do you need file upload? don't you have your stuff on an HTTP server somewhere?
10:27
<mpt>
(or some less crackful vector format, I'm not choosing SVG specifically)
10:27
<hsivonen>
annevk: Lachy wanted data: URIs which are easier UI-wise ;-)
10:29
<hsivonen>
annevk: I really think we need to put aside theoretical purity regarding SVG being presentational and figure out how to achieve feature parity with the XML serialization here
10:29
<annevk>
hsivonen, my XML5 spec is not uploaded somewhere so far
10:30
<hsivonen>
annevk: FWIW, when upload happens, raw POST is likely to happen before form-based upload
10:31
<hsivonen>
(Since raw POST is again UI-neutral)
10:31
<othermaciej>
annevk: well, the other option is to replicate enough useful vector graphics features in HTML+CSS
10:32
<hsivonen>
I haven't figured out yet how to do file uploads at the same server URI while keeping the UI clean even without JavaScript toggles
10:33
<hsivonen>
annevk: anyway, part of my procrastination is that I want to get the UI Right and I want to get the server side Right and I'm not yet sure how to get the UI Right.
10:34
<hsivonen>
annevk: I try hard to avoid adding to the form widgetry in the UI
10:35
<hsivonen>
annevk: with file upload reality says I can't trust Content-Type. would you like me to sniff or to force you to pick the parsing mode manually?
10:36
<hsivonen>
(with raw POST I'm going to respect the Content-Type and make setting it your problem)
10:40
<annevk>
othermaciej, yeah, I've seen propposals to that effect
10:40
<annevk>
hsivonen, with file upload sniffing the file extensions seems like a bettter solution
10:41
<hsivonen>
annevk: would it be useful to you if I implemented raw POST that you could POST a local file to without form encoding using the tool of your choice (curl, your own Python script, whatever)?
10:41
<hsivonen>
annevk: ok
10:41
hsivonen
looks up man curl
10:42
annevk
was joking with the prioritizing above
10:42
annevk
could use curl given the site provides example usage :)
10:48
hsivonen
wonders if it is legal to have a query string in a POST URI
10:48
<hsivonen>
(as far as HTTP goes regardless of browsers)
11:03
<hsivonen>
MikeSmith: I finally managed to get an N800. :-)
11:06
<annevk>
othermaciej, another thing is XBL
11:06
<annevk>
that helps with integrating as well and doesn't pollute semantics
11:06
<annevk>
hsivonen, afaik query strings are just part of a URI (as opposed to fragment identifiers, which are special)
11:07
<hsivonen>
annevk: ok. excellent. we'll see if the servlet API thinks so too
11:16
<MikeSmith>
hsivonen - great to hear you got an N800
11:16
<MikeSmith>
can you get me one too? and/or an N95?
11:17
<hsivonen>
sorry, it was hard enough to get this one
11:18
<kfish>
hi hsivonen, maikmerten, MikeSmith
11:18
<hsivonen>
kfish: hi
11:19
<maikmerten>
hi
11:20
<hendry>
hsivonen: what is the main browser on the N800? the webkit "Web" ?
11:20
<hsivonen>
hendry: Opera 8.6 engine with Nokia UI.
11:22
<hsivonen>
hendry: the UI is in SVN. the engine seems to come as a binary from Opera Software, so it is hard for even Nokia to offer the new engine for the old hardware revision
11:24
<MikeSmith>
kfish - hei. got to catch a train from Kanagawa back to Tokyo. back on around 10pm JST
11:24
<hsivonen>
hendry: Minomo should be available though. it's been a while since I've tried Minimo for Maemo, so I don't know if it is now even usable
11:24
<kfish>
MikeSmith, cool, l8r
11:36
<hendry>
hsivonen: have you used the Webkit "Web" one?
11:37
<hendry>
i wonder if it has a better name..
11:39
<hsivonen>
hendry: I've tried the S60 port. I have not tried the Gtk port. And I can't get anyone who works on Maemo to say anything about the Gtk port.
11:40
<hsivonen>
hendry: it looks like the Gtk port is dead
11:40
<hsivonen>
hendry: but no one knows or dares to speculate
11:41
<hsivonen>
hendry: besides, it looks like the Gtk port was a research center thing and not a product thing
11:41
<hendry>
i built minimo ages ago
11:41
<hendry>
and I have not seen much 'movement'
11:42
<hendry>
I find the Webkit one more interesting
11:42
<hendry>
as I like it on my E65 for one
11:42
<hendry>
And I my flat mate Andrei wrote it :)
20:10
<Jero>
For those who care: I've updated my parser http://jero.net/lab/ph5p/ to a real parser, instead of implementing only a small part of it
20:10
<Jero>
though it's still needs some work, not every phase of the tree construction process has been implemented, only from the initial phase until the in body insertion mode
20:11
<Jero>
all modes from in table to after frameset still need to implemented
20:11
zcorpan_
looks
20:11
<Jero>
I've also grabbed the tests from html5lib and tested them: http://jero.net/lab/ph5p/tests.html
20:12
<Jero>
green: pass; red: sux; black: could not be tested because some of its elements are not yet implemented
20:12
<zcorpan_>
what is the output, html5?
20:13
annevk
notes that http://wiki.whatwg.org/wiki/Example_simple is non-conforming
20:13
<Jero>
the output is a DOMDocument class
20:13
<Jero>
it's a native PHP class
20:13
<zcorpan_>
i mean in the "output" textarea
20:13
<zcorpan_>
annevk: yeah, probably also inappropriate use of <address>
20:14
<Jero>
the output is html5
20:14
<zcorpan_>
Jero: where do the linebreaks come from?
20:15
<Jero>
are you testing the code Anne linked to?
20:15
<Jero>
hmm, and that domdocument class also inserts its own linebreaks
20:16
<Jero>
"<p>h<p>m<p>m" outputs:
20:16
<Jero>
<html>
20:16
<Jero>
<head></head>
20:16
<Jero>
<body>
20:16
<Jero>
<p>h</p>
20:16
<Jero>
<p>m</p>
20:16
<Jero>
<p>m</p>
20:16
<Jero>
</body>
20:16
<Jero>
</html>
20:17
<annevk>
Maybe we should come up with some alternative arguments for the headers= debate. 1) They are supported. 2) Who is going to use them? 3) They are not used right now, who says they will be used in the future? 4) Don't we have a better solution? 5) We do. Defined algorithms and using scope= in case that doesn't work.
20:17
<zcorpan_>
Jero: right, it should output <html><head></head><body><p>h</p><p>m</p><p>m</p></body></html>
20:17
<zcorpan_>
no line breaks
20:17
<Jero>
yeah i know
20:18
<Jero>
i'm looking into it right now
20:18
<zcorpan_>
k
20:18
<zcorpan_>
Jero: noticed that you don't parse / in tags correctly too
20:19
<Jero>
oh yeah, you're right
20:21
<Jero>
i've added it to the tests (3rd entry)
20:26
zcorpan_
fixed http://wiki.whatwg.org/wiki/Example_simple
20:30
<zcorpan_>
Jero: you move <style> to HEAD, which you shouldn't, and the contents of STYLE are moved to the BODY, which they shouldn't
20:30
<Jero>
i know, the implementation of style and script elements is messed up at the moment
20:30
<Jero>
that's why all tests with either of the two elements always fail
20:30
<zcorpan_>
ok
20:31
<zcorpan_>
oh, seems like <style> is parsed as an empty element by ph5p
20:57
<Jero>
well, i got to go
20:57
<Jero>
thanks for your input!
20:57
<Jero>
i'll try to get some improvements up tomorrow
20:57
<Jero>
later
20:57
<zcorpan_>
cya