| 00:06 | <tantek> | Dashiva - here is a short list of minor advantages to using XHTML rather than HTML: http://tantek.com/log/2003/01.html#L20030114t1345 |
| 00:09 | <Philip`> | JavaScript variable scoping is great fun |
| 00:11 | <Philip`> | Hixie: What does the fourth column in the http://www.whatwg.org/issues/data.html table mean? (It seems to lack a column heading) |
| 00:11 | <Hixie> | fixed |
| 00:12 | <Philip`> | Ah, indeed |
| 00:12 | <Philip`> | It'd be nice if Opera didn't display the entire table before the canvas |
| 00:13 | <Hixie> | it shouldn't display the table at all |
| 00:13 | <othermaciej> | tantek: that was a reasonable list of reasons at the time - I think nowadays most of them have been addressed by HTML5 or just general market changes |
| 00:14 | <Philip`> | Hixie: I think it just totally fails to implement canvas child nodes correctly |
| 00:15 | <tantek> | HTML5 certainly goes a long way towards addressing them, and certainly the web authoring community has made very good progress in better use of semantic (X)HTML. |
| 00:15 | <Philip`> | It parses <canvas> kind of like <script> or something |
| 00:16 | <tantek> | othermaciej, the reliable input to XML tools however is still a non-trivial advantage. For example, two very common microformats tools, X2V and Optimus, are both written in XSLT. |
| 00:16 | <Hixie> | Philip`: odd |
| 00:16 | <Hixie> | Philip`: file a bug |
| 00:16 | <tantek> | if parsing a page fails as XML, then the tools run tidy on the page to "clean it up" before retrying |
| 00:17 | <tantek> | since tidy is known to overly clean things up (e.g. strip elements with no contents, even if they have class and title attribute), it's still better to published well formed XML via XHTML. |
| 00:18 | <tantek> | also performance, as obviously trying once is faster than trying twice with a tidy clean step in the middle. |
| 00:20 | <othermaciej> | tantek: I think html5lib and such are making that advantage less and less relevant |
| 00:20 | <othermaciej> | but sure, it might not be deployed in all the right places yet |
| 00:22 | <tantek> | othermaciej, I tend to agree, over time the magnitude of the advantage is likely to decrease due to tools like html5lib. |
| 00:22 | <tantek> | and yes, for now and the near future however, I can say it still very much makes a difference. |
| 00:23 | <tantek> | frankly, it's turned out to make more of a difference (e.g. the microformats XSLT tools people wrote) than I expected it to when I wrote that blog post 6 years ago. |
| 00:24 | <syp_> | Hixie: is it safe to assume element.classList will need to be case insensitive in quirks mode? |
| 00:24 | <Hixie> | syp_: no |
| 00:24 | <othermaciej> | well - it's only an advantage for microformats XSLT tools in the case where people are using such tools on content they control |
| 00:24 | <Hixie> | syp_: it is not safe to assume that |
| 00:25 | <syp_> | hmm, ok |
| 00:25 | <Hixie> | syp_: it might be true, though; what does the spec say? |
| 00:25 | <othermaciej> | if tools like that need to be able to extract from anything on the web, then it's outright a bug in those tools that they use libtidy when faced with HTML instead of XHTML |
| 00:25 | <syp_> | Hixie: it doesn't say anything for the moment, so I guess it means case sensitive. |
| 00:25 | <tantek> | sure, they may switch to using html5lib instead of tidy over time |
| 00:25 | <Hixie> | syp_: k. That seems best. |
| 00:26 | <Hixie> | syp_: you can't be in quirks mode in a conforming doc anyway. |
| 00:26 | <tantek> | but even with that substitution, the performance difference will still exist. one process step vs. two process steps with a html5lib conversion in the middle. |
| 00:26 | <Hixie> | crap meeting gotta go |
| 00:26 | <tantek> | To be clear, I've never really had much hope for XML on the web. Extensibility and everyone making up their own vocabularies means less likelihood of communication (especially across time), not more. |
| 00:26 | <tantek> | Thus XML methodologies were kind of doomed from the start as far as an update to the basic communication format of the Web. Never mind the ridiculous "must fail" approach. |
| 00:26 | <syp_> | Hixie: ok thanks |
| 00:27 | <tantek> | s/ridiculous/impractical |
| 00:28 | <syp_> | Hixie: I saw some comments in the mailing list about that, and other parts of the spec where classes are handled in a case insensitive way, that's why I was wondering. |
| 00:28 | <othermaciej> | tantek: the downside risk to XHTML served as text/html is that there's no handy validator to tell you that your document is a correct chameleon document |
| 00:29 | <tantek> | othermaciej - the W3C validator does just fine. |
| 00:29 | <othermaciej> | so there's the risk of making something that will be misinterpreted depending on what tool is reading it |
| 00:29 | <othermaciej> | tantek: does it have a special "appendix C" mode? |
| 00:29 | <tantek> | it validates it as XHTML, even if served as text/html |
| 00:29 | <othermaciej> | validating as XHTML is not validating whether it means the same thing interpreted as HTML and XML |
| 00:30 | <tantek> | othermaciej - last I checked it hard *warnings* for Appendix C violations on XHTML 1.0 documents served as text/html. |
| 00:30 | <tantek> | s/hard/had |
| 00:30 | <othermaciej> | that's probably good enough |
| 00:30 | <tantek> | that's kind of what I figured too. |
| 00:31 | <othermaciej> | (only remaining risks would be to obscure script issues, but that's only an issue if serving to real browsers as both mime types, not so much to pure data processing tools) |
| 00:31 | <othermaciej> | I hope validator.nu gets a chameleon checking mode even though I bet hsivonen hates the idea of chameleon documents |
| 00:31 | <tantek> | agreed. and it's impractical to serve anything but text/html to browsers. |
| 00:32 | <tantek> | or rather, it's impractical to depend on "must fail" MIME types, e.g. serve application/xml(+*) to browsers. |
| 00:33 | <tantek> | othermaciej I for one like chameleon documents, and even code too. |
| 00:33 | <tantek> | see for example: http://tantek.pbworks.com/CassisProject |
| 00:34 | <tantek> | such chameleon documents/code typically have greater utility than either of the two single formats/languages on their own. |
| 00:36 | <othermaciej> | tantek: that's wild |
| 04:55 | <abii> | lol, no one uses hte #webapps channel? |
| 05:06 | <MikeSmith> | abii: what's the #webapps channel? |
| 05:06 | <abii> | MikeSmith: http://www.w3.org/2008/webapps/ |
| 07:23 | <gmaxwell> | I see that Till Halbach's dirac/theora/h264 comparison was mentioned. Beyond the point about it being old, three independent parties have been unable to reproduce his results using the same software versions. While H.264 and dirac numbers have good agreement, his theora numbers are ~15dB lower than anyone else gets (on Akiyo, for example). In spite of this he has been unwilling to check his measurements or post any notes on this point. T |
| 07:23 | <gmaxwell> | his is further supported by his example image: http://etill.net/projects/dirac_theora_evaluation/include/visual_comparison.png The sequence being original, dirac at 67kbit/sec, theora at 18kbit/sec, h264 at 17kbit/sec, while the charts theora is show as something like 10dB worse than the dirac which is clearly not the case from the example. ::shrugs:: Take that for what you will. |
| 07:26 | <gmaxwell> | As far as the prior comments about what I sent to youtube— The provided upload limits and supported formats constrained my choices. The MJPEG was the best I they appeared to accept, and anything larger would have interacted poorly with the upload size cap. The Theora and Youtube started from the same input. ::shrugs:: But if you're worried about points like this you've missed the point of the comparison, it was intended to be an ord |
| 07:26 | <gmaxwell> | er of magnitude kind of thing. A detailed comparison would require many kinds of input, etc. |
| 07:27 | <gmaxwell> | And would have been an enormous amount of work, which I can't justify spending my time on because the people I work with would never consider using H.264 in any case due to the licensing. |
| 07:27 | <gmaxwell> | Cheers. |
| 07:46 | <gsnedders> | jgraham: thoughts on weather? |
| 08:08 | <jgraham> | gsnedders: Just spoke to G+A decided it is too wet to risk |
| 08:08 | <jgraham> | takkaria: ^ |
| 08:24 | <gsnedders> | abii: #webapps on irc.w3.org:80 is used, though |
| 08:57 | gsnedders | waves at takkaria ? |
| 10:36 | <gsnedders> | Does DOMReady work in IE? I guess not |
| 11:28 | gsnedders | wonders if he leaves now when he'll get to jgraham's |
| 17:41 | <Dashiva> | Setting max-size on the total form seems problematic, or at least I can't think of a user friendly way to handle too big totals |
| 21:26 | <karlcow> | http://intertwingly.net/blog/2009/07/11/Vendor-Veto |
