| 00:30 | <heycam> | anyone know if there's a flattened dtd for mathml somewhere? |
| 00:32 | <Dashiva> | Aren't there programs for creating those? |
| 00:33 | <heycam> | probably. i don't use dtds enough to know though. |
| 00:33 | <heycam> | maybe i can just substitute in for the <!ENTITY> bits and hope it works |
| 05:47 | <Hixie> | Lachy_: where are you these days, geographically? |
| 09:07 | <hsivonen> | It seems to me that when parsing as UTF-16 tentatively, one might as well do it confidently always, because there's no way to get a reasonable reason to revise the guess. |
| 09:07 | <Hixie> | yeah i considered changing the spec to say that instead |
| 09:07 | <Hixie> | i believe it's equivalent to what the spec says now, actually |
| 09:08 | <Hixie> | but i couldn't find a good way to say it -- it turns out i'd have to poke things in way more places than the way the spec does now |
| 09:08 | <hsivonen> | UTF-16 is such a mistake |
| 09:08 | <hsivonen> | is the series of learning experiences that affect a lot of people |
| 09:09 | <jgraham> | hsivonen: Nice explaination of web-scale btw |
| 09:09 | <hsivonen> | jgraham: thanks |
| 09:10 | <Hixie> | not as bad a mistake as UTF-32 and UTF-7! (though they, like UTF-16, both have their place in practice) |
| 09:10 | <Hixie> | if othermaciej was here i'd say he should take the text of http://www.w3.org/mid/4B6CB076-271A-4E9E-AAF8-891C8F4B4A72⊙if and put it in the design principles |
| 09:33 | <hsivonen> | I wish there were some kind of submarine patent craziness 101 that people were required to read before entering a codec debate |
| 09:34 | <Hixie> | and i wish there were no patents, but... |
| 09:34 | <Hixie> | Philip`: yt? |
| 09:35 | <hsivonen> | Hixie: that, too, preferably |
| 09:37 | <franksalim> | how did the patent issues with img play out? |
| 09:37 | <franksalim> | i know about gif |
| 09:37 | <franksalim> | aren't there a lot of image formats that we largely avoid due to patent concerns? |
| 09:37 | <Hixie> | png and jpeg didn't have patent issues that i know of |
| 09:37 | <hsivonen> | franksalim: IIRC, Netscape's lawyers figured that the patents didn't cover decode and Netscape continued shipping decode |
| 09:38 | <hsivonen> | franksalim: IIRC, about boxes in Microsoft software suggest that MS took a license but they also shipped encode in some of their products. |
| 09:38 | <hsivonen> | franksalim: all IIRC and IANAL |
| 09:39 | <franksalim> | hsivonen, pretty much nobody is a lawyer (PMNIAL) |
| 09:39 | <hsivonen> | Hixie: there was the Forgent thing about JPEG, but Forgent went after digital camera manufacturers and not against all kinds of software |
| 09:40 | <Hixie> | dannyb who was posting on whatwg recently is a lawyer, fwiw |
| 09:40 | <Hixie> | expert on software licenses |
| 09:40 | <hsivonen> | franksalim: some software (IIRC, Ghostscript and GIMP) shipped an encoder that didn't compress but produced a bitstream that was readable with an LZW decoder |
| 09:40 | <jgraham> | On an entirely different topic, the requirement that the <caption> be the first child of <table> is non-obvious to the point of uselessness, I guess |
| 09:43 | jgraham | is sad that Google think that H.264 decoding is more valuable than patent licenses not being required to read web content |
| 09:44 | <jgraham> | At the very least it makes new entrants to the browser market not backed up by some big company less likely |
| 09:44 | <Hixie> | google supports theora |
| 09:44 | <Hixie> | or rather, chrome does |
| 09:44 | <jgraham> | Hixie: Sure |
| 09:45 | <jgraham> | It's not clear if that's enough |
| 09:45 | <hsivonen> | jgraham: I'm eager to see how Opera plays this |
| 09:45 | <jgraham> | hsivonen: me too :) |
| 09:46 | <jgraham> | Actually I'm interested to see what happens with youtube. Because if they start doing HTML5+H.264 then it puts significant pressure on everyone else to but patent licenses |
| 09:47 | <jgraham> | *buy |
| 09:47 | <Hixie> | youtube is already doing 264 for flash 10 and iphone and apple tv, iirc |
| 09:47 | <hsivonen> | indeed, YouTube weilds a lot of power so let's hope they follow "Don't be Evil" |
| 09:48 | Hixie | tries to understand http://www.w3.org/Submission/2008/SUBM-ccREL-20080501/#SECTION00071000000000000000 and fails |
| 09:48 | hsivonen | tried doing some back-of-the-envelope calculations on how much H.264 is going to cost YouTube when the grace period runs out, but I probably misunderstood things |
| 09:53 | <annevk2> | http://torrentfreak.com/pirate-party-wins-and-enters-the-european-parliament-090607/ is cool |
| 09:54 | <Hixie> | indeed |
| 09:57 | hsivonen | expects the Ogg controversy Wikipedia page to grow in whatwg list references in due course :-/ |
| 10:00 | <archtech> | Sorry for the OT, but anyone using LaTeX here? Is the syntax for ` and ' turning into quotes getting in the way? |
| 10:00 | <annevk2> | "I'm not so sure. YouTube is very popular despite the fact that its video clips resemble the transmission from the moon landing in 1969." :) |
| 10:01 | hsivonen | disagrees with howcome's characterization of JPEG2000 |
| 10:02 | <hsivonen> | JPEG2000 is pretty sad as a whole |
| 10:03 | <hsivonen> | but it's nice that JPEG2000 shows how good the old JPEG is after all these years |
| 10:06 | <hsivonen> | JBIG, for all its patent flaws, at least improves more upon CCITT Group 4 than JPEG2000 improves over JPEG |
| 10:08 | <jgraham> | http://james.html5.org/table_descriptions/ has been updated a little. If someone could look over that and tell me if I have done anything silly I will email public-html about it |
| 10:12 | <hsivonen> | http://twitter.com/summary must be enjoying HTML5 tweets |
| 10:31 | <hsivonen> | maikmerten: yeah, the unsigned ActiveX control gets blocked for me, too, in IE8 on XP SP3 on Parallels |
| 10:32 | <maikmerten> | maikmerten, according to some chatting in the videolan irc channel there's a chance VLC will get a signed control soon |
| 10:32 | <hsivonen> | maikmerten: cool |
| 10:32 | hsivonen | has no idea how much the signing process costs |
| 10:33 | <Hixie> | how on earth do i express <div about="x"><img src="x">...</div> in RDFa without repeating "x" |
| 10:33 | <Hixie> | where ... is a bunch of property/value pairs that hang on the about="x" bit |
| 10:33 | <hsivonen> | maikmerten: Are there releases (deployable binaries with corresponding source drops) for the wikimedia version of cortado? |
| 10:34 | <hsivonen> | I've only found the svn repo and noticed wikimedia's own binary deployment |
| 10:34 | <maikmerten> | hsivonen, vastly outdated ones only. Xiph.org currently is in the process of taking over development http://www.theora.org/cortado/ |
| 10:34 | <hsivonen> | maikmerten: ok |
| 10:34 | <maikmerten> | hsivonen, we hope to have releases available "soon" |
| 10:35 | <hsivonen> | maikmerten: great! |
| 10:35 | <maikmerten> | hsivonen, Xiph.org also provides a signed version of Cortado at http://theora.org/cortado.jar. You can directly embed this applet without having a local copy. |
| 10:35 | <hsivonen> | cool |
| 10:35 | <maikmerten> | that thingie is signed with a Xiph.org certificate, though |
| 10:35 | <maikmerten> | *not* by a "real" CA |
| 10:36 | <hsivonen> | maikmerten: is it a cost thing or a principle thing? |
| 10:36 | <maikmerten> | hsivonen, definately not a principle thing |
| 10:36 | <maikmerten> | hsivonen, it may be the cost or the effort to get through a proper CA |
| 10:38 | <hsivonen> | maikmerten: donated. (btw, xiph would have benefited from making the amount of donation editable :-) |
| 10:39 | <maikmerten> | (on a side note: I *did* see the latest wave of codec/patent/FUD/not-FUD discussion on the list but currently think I should only join into the fun if I have something constructive to say.) |
| 10:39 | <maikmerten> | hsivonen, thanks! |
| 10:43 | <maikmerten> | (I still remember embarassing myself by doing way-over-the-top stupid posts discussing with Apple representatives. Happens in a heated discussion, I guess, but doesn't help the cause) |
| 10:44 | <maikmerten> | I forwared your donation feedback to xiphmont and also asked for more status on Xiph.org's CA status |
| 10:49 | <maikmerten> | hsivonen, can you elaborate on your donation-amount problem? xiphmont appears surprised - there should be a way to adjust the amount. |
| 10:52 | <maikmerten> | hsivonen, ah, apparently a "theora donation" is a fixed item at $10.00 - now, that's suboptimal |
| 10:52 | <maikmerten> | (when clicking the donta-button on theora.org) |
| 10:52 | <maikmerten> | *donate |
| 10:53 | <maikmerten> | when clicking the button on xiph.org/donate/ I get to homepage-thingie on paypal... hmmmm.... broken? |
| 11:03 | <annevk2> | yeah, I got the same on xiph.org |
| 11:03 | <annevk2> | it asked me to login but I don't have a PayPal account and normally you can pay without having an account |
| 11:19 | <Hixie> | ok bed time |
| 11:19 | <Hixie> | nn |
| 11:20 | <annevk2> | g'night! |
| 11:24 | <hsivonen> | maik|lunch: yeah, the issue was the when clicking the donation button on the cortado page, the amount was fixed to $10 |
| 11:29 | <zcorpan> | Hixie: NETWORK_NO_SOURCE is inconsistently marked up (sometimes with <code> sometimes not) |
| 11:46 | <annevk2> | the ways in which some people use "IMHO" make it a completely useless initialism in practice :/ |
| 11:54 | <annevk2> | wow, Xbox Project Natal looks pretty cool |
| 11:56 | <Rik|work> | annevk2: but pretty vaporware for the moment |
| 12:05 | <annevk2> | yeah |
| 12:06 | <jgraham> | hsivonen: It is worth noting that many users don't change default settings even if they could improve their user experience by doing so |
| 12:06 | <jgraham> | Even expert users |
| 12:06 | <hsivonen> | jgraham: which way do the defaults on summary reading go? |
| 12:07 | <jgraham> | hsivonen: I think "on" but I'm not sure |
| 12:09 | <hsivonen> | it would be helpful if screen reader users and vendors (if they've done usability studies) participated in these threads |
| 12:34 | <maikmerten> | hsivonen, donations should be fixed once the webpage mirrors catch up |
| 12:34 | <maikmerten> | hsivonen, thanks for the catch |
| 12:34 | <maikmerten> | (and for the donation, of course) |
| 12:35 | <hsivonen> | maikmerten: OK. thanks. I'll make another attempt later |
| 12:47 | jgraham | wonders if he should explicitly point out that the <details> proposal has more or less no new conformance requirements relative to <details> |
| 12:47 | <annevk2> | it seems a bit complicated to me |
| 12:48 | <jgraham> | annevk2: It is the best I can manage that takes account of the positions of both "sides" |
| 12:49 | <jgraham> | But if yoou can think of something less complex... |
| 12:49 | <annevk2> | http://www.zeldman.com/2009/06/08/not-safe-for-work-tag-in-html-5/ lol |
| 12:50 | <annevk2> | it's all over twitter too |
| 12:50 | <Dashiva> | I can't wait for the "We must allow users to encode which kind of work it's not safe for" talk to start |
| 12:51 | <jgraham> | (well "just use <caption>" is less complex but doesn't account for the argument that @summary is needed because authors don't want to burden all users with information that only a small constituency require) |
| 12:52 | <zcorpan> | <details><legend>Not safe for work</legend><img src=badkitten.jpg></details> |
| 12:52 | <Dashiva> | That tiny minority that supply summary info, and that tiny minority of those who actually supply non-universal summary info, wouldn't they be competent enough to use a hidden block of text linked with ARIA? |
| 12:53 | <jgraham> | Dashiva: They're not competent enough to use @summary |
| 12:54 | <Dashiva> | Then what's the problem? |
| 12:54 | <jgraham> | I never understand Zeldman when he starts talking in the first person plural. Does he have multiple personality disorder or does he think he's the Queen? |
| 12:54 | <Dashiva> | I hear kings do it too |
| 12:57 | <jgraham> | (also if <caption> allowed flow content children, being able to use <details> would just fall out naturally so there would be no problem except documenting the best-practice) |
| 13:12 | <jgraham> | Things I hate about javascript number 0156: The difference between undefined meaning "no property" and undefined meaning "a property with the value undefined" |
| 13:14 | <Dashiva> | Meet the in operator |
| 13:15 | <annevk2> | I want to post a short follow-up post on the video thing |
| 13:15 | <annevk2> | Chrome can distribute FFmpeg because its patent license that it may or may not have covers the Chrome product and not the library, right? |
| 13:15 | <jgraham> | Dashiva: I know /how/ to tell. But it is still stupid and unintuitive (this is based on debugging code where someone else got this wrong) |
| 13:17 | <Dashiva> | jgraham: Wouldn't you say that code treating the two differently is a bug, though? |
| 13:18 | <jgraham> | Dashiva: In that case the ECMAScript spec is really buggy |
| 13:18 | <jgraham> | (see e.g. Array.prototype.sort) |
| 13:21 | <Dashiva> | The part about undefined values coming before missing indexes? |
| 13:21 | <jgraham> | Yes |
| 13:21 | <Dashiva> | That's invisible to code that doesn't separate the two, though |
| 13:21 | <jgraham> | In general array methods behave rather differently with undefined and missing values |
| 13:22 | <jgraham> | (this is not the only area of the spec that is differnt of course) |
| 14:14 | <hsivonen> | oh. the chrome/ffmpeg/lgpl thing hit slashdot yesterday |
| 15:22 | <hsivonen> | hmm. If nearly all non-calendar tables on Philip's list are layout tables and JAWS detects them as layout tables, I could understand how users hear none of the whole pile Philip had and instead hear summaries only on .gov sites |
| 15:23 | <hsivonen> | that seems like a huge waste ratio :-/ |
| 15:24 | <hsivonen> | Hixie: maybe you should put a JAWS-compatible summary suppression algorithm in the spec |
| 15:26 | <jgraham> | hsivonen: AFAIK we haven't got as far as reverse engineering how JAWS (or others) detect layout tables |
| 15:26 | <jgraham> | Nor is there any evidence that they have reached a maximum of efficiency to the point at which the algorithm should be standardised |
| 15:27 | <jgraham> | well, that didn't quite make sense but you see what I mean, maybe |
| 15:27 | <hsivonen> | ok, but today's back-and-forth may actually have teased out a reasonable explanation that reconciles the data with the claims that users aren't burdened with accessispam |
| 15:28 | <jgraham> | That JAWS and others have layout-table-detecting algorithms that cause @summary to be supressed? I thought we already knew that |
| 15:29 | <jgraham> | We don't know what the efficiency of those algorithms is |
| 15:29 | <hsivonen> | what I didn't realize before is how predominantly the summaries are used on layout tables outside .gov |
| 15:30 | <hsivonen> | what does it say about the success of an accessibility feature that the leading screen reader has code to suppress it? |
| 15:31 | <jgraham> | (there was a machine-learning based paper that claimed something like 95% although I can't remember quite what that referred to) |
| 15:32 | <jgraham> | (clearly it can't be "right in 95% of all cases because you cn do rather better than that just by saying all tables are layout tables) |
| 15:33 | <jgraham> | s/s/s"/ |
| 15:33 | <hsivonen> | anyway, I can buy the argument that summary should be 'in', because .gov sites may manage to use it right and that abuse by others is suppressed by algorithms |
| 15:34 | <hsivonen> | but then why does the .gov guide recommend <caption> |
| 15:34 | <hsivonen> | and can we have @summary for .gov without having all these other people write summaries only to be suppressed? |
| 15:36 | <hsivonen> | I wonder what kind of effect would a validator that whined about non-empty summary on tables that JAWS would consider layout tables would have |
| 15:36 | <hsivonen> | minus one 'would' |
| 15:38 | <jgraham> | hsivonen: It is worth noting that the data was not so conclusive about .gov managing to use @summary right |
| 15:38 | <hsivonen> | jgraham: that, too |
| 15:39 | <jgraham> | I don't think we should be keeping heavily abused features just because some small subset of people might get them right sometimes and the bad effects of people getting them wrong can be mitigated by significant client side effort |
| 15:40 | <jgraham> | Not least because it makes developing clients significantly harder; to compete with JAWS you have to reverse engineer its table heuristics |
| 15:40 | <jgraham> | or build better ones |
| 15:40 | <jgraham> | or offer a worse user experience |
| 15:40 | <hsivonen> | jgraham: unless HTML5 saves prospective developers the cost by having a canned explanation of what JAWS does |
| 15:41 | <jgraham> | hsivonen: Since FS have no interest in giving that to us we would have to reverse engineer it. But that sort of thing should not be codified in the spec |
| 15:41 | <jgraham> | It would be an intersting and useful excersie though |
| 15:42 | <jgraham> | although if they have used e.g. machine learning the algorithm could be rather complex to pin down |
| 15:42 | <Dashiva> | "Structure is nothing if it is all you got. Skeletons spook people if they try to walk around on their own. I really wonder why XML does not." |
| 15:54 | <webben> | jgraham: "should not be codified in the spec" ... why not? |
| 15:54 | <webben> | Seems like an important area of interoperable consumption of the web corpus. |
| 16:02 | <jgraham> | webben: Because it seems like a UI issue |
| 16:02 | <jgraham> | (sort of) |
| 16:05 | <jgraham> | and because making a dejure method of categorising tables into layout and non-layout unnecessarily freezes the state of the art |
| 16:05 | <hsivonen> | jgraham: I disagree. I think it's a semantic issue for answering "what's the summary if any of this table" |
| 16:07 | <webben> | jgraham: I don't think it's a UI issue. If one wants to allow conforming UAs to implement even better algorithms, it could always be a suggested algorithm. |
| 16:08 | <webben> | that lowers the bar to creating a UA, while still allowing evolution of better heuristics. |
| 16:15 | <jgraham> | I am not opposed to an informative algorithm, perhaps in a seperate document. I would be very worried about defining semantic issues based on things that have a certian known failure rate and no manual override |
| 17:39 | <annevk42> | gsnedders, "all other specs"? mwaha |
| 17:39 | <gsnedders> | :P |
| 17:39 | <gsnedders> | all the other specs, I meant |
| 17:39 | <gsnedders> | And I said that! |
| 17:40 | <gsnedders> | There is a difference between "all other" and "all the other" :P |
| 17:41 | <annevk42> | still, CORS, Selectors API, various CSS specs, ... |
| 17:41 | <gsnedders> | the is the definite article, hence it doesn't apply to absolutely all. |
| 17:42 | <annevk42> | maybe I'm being dense, but it's not clear to me how "the" includes XMLHttpRequest, but not those |
| 17:42 | <annevk42> | but it also does not really matter and I have to go :) |
| 17:42 | jgraham | onders what is being discussed |
| 17:42 | <jgraham> | *wonders |
| 17:42 | <gsnedders> | Nuances of English :) |
| 17:43 | <jgraham> | damn double-u |
| 17:43 | <jgraham> | if it was spelt uuonders I could get it right |
| 17:45 | <gsnedders> | jgraham: See -archive, though |
| 18:24 | <gsnedders> | Does anyway have a test suite for XML serializers, apart from giving Philip` access to it? :P |
| 19:18 | <hsivonen> | scary. google's page optimization docs mention netscape 4.04 |
| 19:36 | <gsnedders> | Uh, xml-names doesn't define what a valid value for an xmlns actually is, apart from saying it must be a URI reference (whatever that is) or an empty string. |
| 19:37 | <ezyang> | I'm pretty sure anything for xmlns is fair game. |
| 19:37 | <ezyang> | I've used urns for xmlns before. |
| 19:37 | <gsnedders> | Yes, but what's a URI? |
| 19:38 | <ezyang> | Uniform Resource Identifier |
| 19:38 | <gsnedders> | What RFC3986 says? What RFC 2396 says? |
| 19:38 | <ezyang> | See RFC 3986 |
| 19:38 | <ezyang> | 3986 supercedes 2396 |
| 19:39 | gsnedders | finally finds a reference in the spec saying what a URI is. |
| 19:39 | <gsnedders> | (I mean what the XML namespaces spec means by "URI", I don't care about what RFC obsoletes what :P) |
| 19:39 | <ezyang> | jaja |
| 19:40 | <gsnedders> | (I mean, if I wanted to throw fatal errors on invalid namespace names, then it'd be better that it's behaviour was constant and didn't depend on what RFC I chose to implement, as there should hopefully be a static reference in the spec.) |
| 19:41 | <gsnedders> | Oh, more fun: xml-names first ed. references RFC 2396 and second edition RFC 3986 |
| 19:41 | gsnedders | wonders which to be compatible with |
| 19:41 | <ezyang> | That makes sense |
| 19:41 | <ezyang> | 3986 is mostly a strict superset of 2396, so you should use that |
| 19:41 | <gsnedders> | The problem is it means a document using namespaces may throw parse errors if it implements the first edition. |
| 19:42 | <ezyang> | Unlikely. |
| 19:42 | <gsnedders> | But possible. Bear in mind the big issue of XML 1.0 Fifth edition. |
| 19:43 | <gsnedders> | (i.e., a document valid under that can be not even well-formed according to another XML 1.0 processor, because it implements an earlier edition) |
| 19:43 | gsnedders | wonders how to implement URI validation |
| 19:43 | <ezyang> | I'm pretty sure they only sanity check URIs, and don't do an in-depth check. |
| 19:44 | <gsnedders> | Processors normally do not checking :) |
| 19:44 | <gsnedders> | For a serializer, it ought to be impossible to output anything that isn't conforming, though |
| 19:44 | <ezyang> | btw, you should read "D.2. Modifications" |
| 19:45 | gsnedders | thought from memory there were actual changes |
| 19:47 | <gsnedders> | Is it true that any string that matches unreserved / reserved _and_ where any "%" are followed by 2HEXDIG will match URI-reference? |
| 19:47 | <jgraham> | gsnedders: I feel you are being over-analytic somewhere |
| 19:48 | <gsnedders> | That's untrue. |
| 19:48 | gsnedders | wonders if he can do this without implementing a full URI parser |
| 19:49 | <jgraham> | gsnedders: Really, worrying that a document may implement(?) an absolete RFC is over-analysing something |
| 19:49 | <gsnedders> | :P |
| 19:49 | <gsnedders> | OK, but now I've moved on from that! |
| 19:54 | <hsivonen> | gsnedders: serializers should target 4th ed for compat |
| 19:54 | <gsnedders> | hsivonen: Indeed. |
| 19:54 | <gsnedders> | hsivonen: And what edition of xml-names? |
| 19:54 | <gsnedders> | (Or does that not matter?) |
| 19:55 | <hsivonen> | gsnedders: 1.0 |
| 19:55 | <hsivonen> | edition, dunno |
| 19:55 | <gsnedders> | hsivonen: first or second edition, though? |
| 19:56 | gsnedders | sighs |
| 19:57 | <gsnedders> | I'm subclassing PHP's built-in XMLWriter to fix the fact it can output non well-formed XML (this is a "bogus" bug). This is gonna be a big subclass. :( |
| 19:58 | <ezyang> | Oh, if this is PHP, HTML Purifier has RFC-compliant code for parsing URIs |
| 19:58 | <gsnedders> | LGPL though |
| 19:58 | <ezyang> | HTML Purifier is LGPL? |
| 19:59 | <gsnedders> | Is it not? |
| 19:59 | <ezyang> | Yep, it is. What do you need to license it as? |
| 20:00 | <gsnedders> | Ideally MIT |
| 20:01 | <gsnedders> | But it needs to at least be includable within an Apache product. |
| 20:02 | <gsnedders> | Also: URI parsing isn't the hard part. Validation is. |
| 20:02 | <ezyang> | Sure. |
| 20:02 | <ezyang> | But I thought you just wanted to freak out when the URI wasn't compliant |
| 20:04 | <gsnedders> | Yeah. |
| 20:04 | <gsnedders> | But that means validating it :P |
| 20:04 | <gsnedders> | (Or using a needlessly complex parser) |
| 20:10 | myakura | is installing Safari 4 |
| 20:39 | <jwalden> | man, this chrome/ffmpeg thread is like the gift that keeps on giving |
| 20:50 | <jgraham> | jwalden: You get odd gifts |
| 20:57 | <jwalden> | what can I say, my needs are few :-) |
| 21:22 | <gsnedders> | The XMLWriter extension really is useless :( |
| 21:25 | <sayrer> | gsnedders, is that php? |
| 21:25 | <gsnedders> | sayrer: yeah |
| 21:26 | <gsnedders> | (And yes, I know PHP is all useless :D) |
| 21:26 | <sayrer> | oh, it is what it is :) |
| 21:26 | <sayrer> | gsnedders, is there a genx wrapper? that's always been pretty good |
| 21:26 | gsnedders | wonders how much he would lose by making BetterXMLWriter not a subclass XMLWriter |
| 21:27 | <sayrer> | after all, any bozo can generate well-formed xml |
| 21:27 | <gsnedders> | I mean, I re-implement so much… |
| 21:27 | <gsnedders> | sayrer: That would have to be a non-standard extension, which makes it virtually impossible to rely upon for shippable code |
| 21:27 | <sayrer> | oh, I see. I didn't realize there were "standard extensions" |
| 21:28 | <gsnedders> | Oh, sure. More or less anything useful is in an extension. And, naturally, it can be disabled. |
| 21:28 | <sayrer> | what are you writing, btw? |
| 21:29 | <gsnedders> | A subclass of XMLWriter that can be relied upon to always output XML. |
| 21:29 | <sayrer> | XMLForSeriousWriter? |
| 21:29 | <gsnedders> | BetterXMLWriter. |
| 21:29 | <sayrer> | ActuallyXMLWriter? |
| 21:30 | <sayrer> | I have been using Venus for some stuff lately |
| 21:30 | gsnedders | finds startPI actually works! |
| 21:30 | <gsnedders> | Like, actually does enough sanitization to be usable. |
| 21:30 | <sayrer> | I have to say... it's the first time I've actually derived value from an XML publishing pipeline |
| 21:33 | <gsnedders> | Awesome. U+FFFF is allowed as an element name. |
| 21:33 | <gsnedders> | And when you use U+FFFF as a namespace URI you get ï¿¿ |
| 21:33 | <gsnedders> | (EF BF BF is U+FFFF in UTF-8) |
| 21:34 | <sayrer> | There’s just no nice way to say this: Anyone who can’t make a syndication feed that’s well-formed XML is an incompetent fool |
| 21:34 | <sayrer> | quote unquote |
| 21:34 | <sayrer> | :) |
| 21:34 | gsnedders | gets the quote :) |
| 21:35 | <gsnedders> | I mean, it's hardly as if WP can be made to produce a feed that isn't XML well-formed… |
| 21:36 | <sayrer> | I that is my second favorite XML quote ever |
| 21:36 | <gsnedders> | (This is, of course, a bug that has been open for 16 months, but has existed since before it was called WP :P) |
| 21:36 | <gsnedders> | sayrer: What's your favourite? |
| 21:36 | <jgraham> | I asume we are expected to ask what your favourite XML quote is |
| 21:36 | <jgraham> | Oh gsnedders already said that |
| 21:36 | <gsnedders> | jgraham: You're slow. |
| 21:37 | <jgraham> | Well that's no surprise to anyone |
| 21:37 | <sayrer> | No doubt I can write a routine to parse this, but look at how deep they went to re-invent, XML itself wasn't good enough for them, for some reason (I'd love to hear the reason). Who did this travesty? Let's find a tree and string them up. Now. |
| 21:39 | <gsnedders> | Ah, Dave Winer. That makes the quote seem quite mild and calm. |
| 21:39 | gsnedders | wonders what the hell XMLWriter is doing here |
| 21:39 | <gsnedders> | XMLWriter::writePI('a', "\xEF\xBF\xBF") |
| 21:39 | <gsnedders> | <?a Ôø\BF?> |
| 21:40 | <gsnedders> | Ô is U+00D4 and ø is U+00F8 |
| 21:41 | <jgraham> | gsnedders: You do realise that using a language without proper unicode support in 2009 is just silly, right? |
| 21:41 | gsnedders | points to the first point of his rant on PHP's problems |
| 21:41 | <jgraham> | (or at least the ability to invent unicode support in a reasonably performant manner) |
| 21:42 | gsnedders | watches jgraham get confused by gsnedders pointing at an unpublished draft :P |
| 21:42 | <jgraham> | gsnedders: Don't rant, boycott :) |
| 21:43 | <gsnedders> | jgraham: If you want the state of XML to get better on the web you need to get it working in PHP. Sad reality. |
| 21:44 | <jgraham> | gsnedders: I'm not that concerned with the state of XML on the web |
| 21:44 | gsnedders | grumbles, finding more ways to break XMLWriter |
| 21:44 | <jgraham> | It hasn't worked very well so far, it will continue to not work very well in the future |
| 21:44 | <sayrer> | it might be more effective to get genx in the php distribution |
| 21:45 | <gsnedders> | sayrer: Should I point out WP supports versions of PHP shipped over six years ago? |
| 21:46 | <sayrer> | first you fix the ones actually hosted on wordpress.com |
| 21:46 | <sayrer> | then you get the ones that actually update for bug fixes and perf |
| 21:46 | <sayrer> | and the others die out |
| 21:46 | <sayrer> | it will take a while, I agree |
| 21:49 | <gsnedders> | Even getting WP to use a broken XML serializer would probably help |
| 21:58 | <jgraham> | gsnedders: Did you implement the comment-end-bang stuff in php-html5lib? |
| 21:59 | <ezyang> | I did. |
| 21:59 | <gsnedders> | jgraham: No. |
| 22:01 | <jgraham> | ezyang: Yeh I just noticed on hg log :) So, where do the two parse errors for <!----!a--> come from? |
| 22:02 | <ezyang> | first parse error is from !, second parse error is from a |
| 22:02 | <jgraham> | It seems like the tests assume a in comment end bang state is a parse error but that's not what the spec says |
| 22:02 | <ezyang> | Unless Hixie, like, changed it. |
| 22:02 | <ezyang> | Oh? |
| 22:03 | <ezyang> | "Parse error. Switch to the comment end bang state." |
| 22:03 | <jgraham> | Right |
| 22:03 | <ezyang> | (the parse error results when you transition into the state, not in the actual state) |
| 22:03 | <jgraham> | then why does the a give a second parse error? |
| 22:04 | <jgraham> | s/a/"a"/ |
| 22:04 | <ezyang> | oh ho, that's not right |
| 22:05 | <ezyang> | I can fix that, or you can? |
| 22:05 | <ezyang> | (I have the html5lib-php fix, anyway) |
| 22:05 | <jgraham> | You can if you like |
| 22:07 | <sayrer> | olliej: congrats on Safari 4 (I hate the codecs, but I know you guys don't have much to do with that choice) |
| 22:08 | <olliej> | sayrer: we had those in S3.1 :D |
| 22:08 | <annevk42> | http://twitter.com/daringfireball/status/2078539734 |
| 22:08 | <sayrer> | it's much nicer than the beta |
| 22:08 | <olliej> | sayrer: but omg i wih there was some sane codec solution |
| 22:08 | <olliej> | sayrer: or failing that |
| 22:08 | <olliej> | sayrer: people would stop arguing about chrome specifics in the whatwg list |
| 22:08 | <ezyang> | Pushed. |
| 22:08 | <sayrer> | well, I think the argument is healthy |
| 22:08 | <sayrer> | easy to skip |
| 22:10 | <annevk42> | just filter on chrome + ffmpeg if you don't care about it |
| 22:10 | <jgraham> | ezyang: Thanks |
| 22:11 | <jgraham> | olliej: We could get people to diss apple too, if you like :) |
| 22:12 | <olliej> | jgraham: they already do |
| 22:12 | <ezyang> | jgraham: I think it would be generally useful for people do adopt the SPEC convention |
| 22:12 | <olliej> | jgraham: and then they claim that chrome has actually implemented stuff |
| 22:13 | <sayrer> | olliej? |
| 22:14 | jgraham | wonders what a SPEC convention is |
| 22:14 | <olliej> | sayrer: oh google acting like (and convincing people that) they are responsible for significant amounts of the browser feature set |
| 22:14 | <sayrer> | oh I see |
| 22:14 | <olliej> | sayrer: which i also take to be bitching about apple :D |
| 22:14 | <ezyang> | jgraham: Oh yeah... |
| 22:15 | <sayrer> | don't you think that's how open source goes? |
| 22:15 | <olliej> | sayrer: what, bitching about apple? |
| 22:15 | <sayrer> | no, claiming you have a feature |
| 22:15 | <sayrer> | since you just import an open source library |
| 22:15 | <olliej> | sayrer: ah right |
| 22:15 | <sayrer> | sort of like we claim we have ogg |
| 22:15 | <ezyang> | jgraham: It's putting a SPEC file in the root of your project directory, and setting it's contents to be 1234, where that's the last revision of HTML5 that you've checked the library against. |
| 22:15 | <sayrer> | but we didn't write the ogg libraries |
| 22:16 | <jgraham> | ezyang: Tha would be hard to do since I will often miss things that aren't covered by tests |
| 22:16 | <olliej> | sayrer: but yes, there's a difference between claiming support for ogg, and claiming to have added support for video/audio/appcache/etc when all you did was pickup existing or enabled from a standard trunk build |
| 22:16 | <sayrer> | what is the difference? |
| 22:17 | <jgraham> | Although it would be helpful to know what the last revision I looked at was |
| 22:17 | <sayrer> | like, what could they say that would be ok? |
| 22:17 | <olliej> | sayrer: eg. compare "Firefox now supports ogg" to "Flock has now added support for html5" |
| 22:17 | <sayrer> | hmm. I can understand that they want people to know <audio> will work in Chrome |
| 22:17 | <olliej> | (Flock is that geco/firefox based social browser?" |
| 22:17 | <sayrer> | how do they say that the right way? |
| 22:18 | <jgraham> | ezyang: <a a=a<> should have a parse error, right? (< in attribute value, unquoted, state) |
| 22:18 | <olliej> | sayrer: enabled would be preferable -- i would prefer "we have now updated to a new version of webkit that provides ..." |
| 22:18 | <ezyang> | jgraham: That's fine; but you really don't want to be re-scanning the spec every time something changes |
| 22:18 | <olliej> | sayrer: but anyway, this isn't relevant to the channel |
| 22:19 | <jgraham> | olliej: See /topic |
| 22:19 | <olliej> | sayrer: this started with me just wishing people would continue arguing about whether google is legally allowed to do what they're doing |
| 22:19 | <sayrer> | this channel is pretty wide open :) |
| 22:19 | <ezyang> | jgraham: Umm, that's a new test, I think it needs a parse error |
| 22:19 | <sayrer> | or so I hear |
| 22:19 | <olliej> | errr |
| 22:19 | <olliej> | s/continue/stop |
| 22:19 | <ezyang> | Whatever it says there is what I think it should be, since I wrot ethe test |
| 22:19 | <olliej> | subtle difference there :D |
| 22:19 | <ezyang> | *wrote the |
| 22:19 | <sayrer> | haha |
| 22:20 | <olliej> | sayrer: i have JSON.stringify implemented now |
| 22:20 | <olliej> | sayrer: not yet landed (Waiting for review) |
| 22:20 | <sayrer> | cool... mostly the same as mine? |
| 22:20 | <jgraham> | ezyang: I think there should be a parse error but the test disagrees |
| 22:20 | <sayrer> | I know I have a few deviations |
| 22:20 | <sayrer> | stupid spec changes every meeting |
| 22:20 | <jgraham> | I guess ECMA don't believe in testsuites? |
| 22:21 | <sayrer> | actually |
| 22:21 | <sayrer> | Microsoft donated the beginnings of one |
| 22:21 | <sayrer> | at the last meeting |
| 22:21 | <jgraham> | Awesome |
| 22:21 | <sayrer> | host on their codeplex site |
| 22:21 | <sayrer> | (like google code or sourceforge) |
| 22:21 | <sayrer> | it's dual licensed BSD / MSPL |
| 22:21 | <jgraham> | But there is no interoperable implementations requirement like with W3C? |
| 22:22 | <sayrer> | there is an agreement in the group |
| 22:22 | <jgraham> | sayrer: Do you have a pointer? |
| 22:22 | <olliej> | sayrer: mostly the spec/json2.js behaviour |
| 22:22 | <ezyang> | Ok, spec agrees with what you say. Checking code. |
| 22:22 | <sayrer> | olliej: I'm sure you'll find json2.js changes over time with no changelog |
| 22:22 | <sayrer> | I certainly have :) |
| 22:23 | <olliej> | sayrer: hehe |
| 22:23 | <olliej> | sayrer: i've tried to go for "sane" |
| 22:23 | <Philip`> | Hixie: I'm not here (and will be similarly not here for the next week, so if it can't wait then now is as good a time as any) |
| 22:23 | <olliej> | sayrer: in most cases the issues i pointed out should never matter |
| 22:23 | <sayrer> | yeah, I was pretty happy about hat |
| 22:23 | <sayrer> | that |
| 22:23 | <sayrer> | clearly edge cases |
| 22:23 | <olliej> | sayrer: yeah |
| 22:23 | <olliej> | sayrer: i was happy with that :D |
| 22:24 | <ezyang> | I think the test is right. |
| 22:24 | <sayrer> | jgraham: I think there is a message on the es-discuss list |
| 22:24 | <olliej> | jgraham: both mozilla and webkit have fairly substantial js test suites as well |
| 22:24 | <ezyang> | Hu, no. |
| 22:24 | <sayrer> | olliej: I think we're going to try and upstream to microsoft's for es5 |
| 22:25 | <sayrer> | and have hg pull it in |
| 22:25 | <olliej> | sayrer: righto |
| 22:25 | <sayrer> | I'm going to donate my JSON tests at least |
| 22:25 | <jgraham> | olliej: I am aware of the mozilla testsuite. It is nice but not always a test of the spec :) |
| 22:26 | <olliej> | sayrer: cool |
| 22:26 | <sayrer> | there are a few that test mozilla-specific extensions like scripted iterators that I will have to remove |
| 22:26 | <ezyang> | Oh hey, the test fails for my impl too |
| 22:26 | <ezyang> | Yep, that should have a parse error |
| 22:26 | <ezyang> | Wow, how'd I miss that? |
| 22:26 | <ezyang> | Can you fix that? |
| 22:27 | <annevk42> | hmm, nothing in the keynote was not predicted by daringfireball |
| 22:27 | <annevk42> | no fun |
| 22:27 | <jgraham> | ezyang: Sure |
| 22:43 | <Philip`> | sayrer: I guess you mean genx as in http://lists.w3.org/Archives/Public/www-archive/2009Mar/0060.html ? :-) |
| 22:44 | <sayrer> | Philip`: class |
| 22:44 | <sayrer> | who did this XML travesty? It's not even JSON! |