| 00:05 | <ezyang> | +6 passes, to 90 passes! |
| 00:06 | <gsnedders> | And how many failures? |
| 00:08 | <ezyang> | 279 failures, although I know one fix that will get rid of a lot of them. I'm currently squishing exceptions |
| 00:15 | <gsnedders> | Is all your work in Parser.php then? |
| 00:15 | <ezyang> | TreeConstructer.php |
| 00:15 | <gsnedders> | Ah, that's what it's called. |
| 00:15 | <ezyang> | in the php-tb branch. I'll be merging it back in before pushing |
| 00:15 | Hixie | writes a sentence of garbled english that he can't work out how to make real english |
| 00:15 | <gsnedders> | Can I change the tokenizer to an iterator? |
| 00:16 | <Hixie> | this doesn't bode well |
| 00:16 | <gsnedders> | Hixie: en-gb-x-hixie isn't real English anyway! :P |
| 00:16 | <Hixie> | this sentence is not en-gb-x-hixie either |
| 00:16 | <ezyang> | What would the output of the tokenizer be? |
| 00:16 | <ezyang> | (as an iterator) |
| 00:16 | <gsnedders> | ezyang: Tokens :P |
| 00:16 | <ezyang> | Uhh, ok |
| 00:16 | <ezyang> | So, problem |
| 00:17 | <gsnedders> | So, solution. |
| 00:17 | <ezyang> | Tree construction needs to be able to pass info back to the tokenizer |
| 00:17 | <ezyang> | coroutines would be ideal, but we don't have those in PHP |
| 00:17 | <Hixie> | can someone translate this to english?: |
| 00:17 | <Hixie> | Whenever a Document d is added to the worker's Documents, the user agent must, for each port in the list of the worker's ports that is entangled with a second port p whose owner is a WorkerGlobalScope object whose list of the worker's Documents does not contain d, add d to q's WorkerGlobalScope owner's list of the worker's Documents. |
| 00:18 | <gsnedders> | foreach($tokinzer as $token) { if ($token['type'] === HTML5_Tokenizer::STARTTAG) $tokenizer->content_model=HTML5_Tokenizer::PCDATA; } |
| 00:18 | <gsnedders> | ezyang: ^^ |
| 00:18 | <gsnedders> | Hixie: Oh dear… |
| 00:19 | <ezyang> | That's not sufficient, but sure, if you want to move the twiddling there |
| 00:19 | gsnedders | is too tired to do such things, so time for me to go read Anna Karenina for five hours, get up at 1pm tomorrow, do no more work… |
| 00:19 | <ezyang> | I think it's pseudocode time |
| 00:19 | <gsnedders> | I <3 study leave. |
| 00:19 | <ezyang> | That would be ok. |
| 00:19 | <gsnedders> | ezyang: I'll speak with you when I'm sanely awake. |
| 00:20 | <ezyang> | Savvy |
| 00:25 | <ezyang> | WHOO! zero exceptions |
| 00:26 | <ezyang> | And fixing those bumped up passes to 103 |
| 00:26 | <ezyang> | I think its pushin' time |
| 00:27 | <ezyang> | Time to fix the text blobbing problem |
| 00:31 | <ezyang> | Bumped up to 117 passes |
| 00:36 | <Hixie> | public-html has been strangely silent today |
| 00:36 | <Hixie> | did i address all of larry's concerns? surely not. |
| 00:36 | <Hixie> | and leif never responded to my last e-mail to him, i wonder if i actually managed to explain what he was asking about |
| 00:38 | <annevk2> | Hixie, that worker Document stuff, is that about my question? |
| 00:38 | <Hixie> | no |
| 00:38 | <Hixie> | though i should fix that at the same tim,e |
| 00:38 | <Hixie> | time |
| 00:46 | <ezyang> | Ok, that's probably enough html5lib hacking for today |
| 00:48 | <annevk2> | supercool that you're doing this btw |
| 00:51 | <Philip`> | No it isn't - it'll remove a reason for PHP programmers to migrate to a proper language, like Python :-p |
| 00:52 | <ezyang> | annevk2: Thanks! |
| 00:53 | <ezyang> | Python is still a bitch to get set up for web applications. I do most of my scripting in it these days though |
| 01:11 | <Philip`> | http://dev.opera.com/articles/view/opera-ua-string-changes/ |
| 01:12 | <Philip`> | The web would be much simpler if there weren't User-Agents strings |
| 01:12 | <ezyang> | Sometimes you have to use the user-agent string, since the browser lies about what it supports via feature detection |
| 01:43 | <ezyang> | mmmmmmm |
| 01:43 | <ezyang> | (got tugged back into debugging the brushfires) |
| 02:15 | <ezyang> | So what does the specification *mean* when it says "if it wasn't ignored" |
| 02:16 | <ezyang> | Oh, it's explicitly spelled out. savvy |
| 02:17 | <jcranmer> | ezyang: "if the moon is currently waxing, and Saturn is in conjunction with Jupiter" |
| 02:43 | <ezyang> | Quirks mode go boom |
| 03:21 | <othermaciej> | Hixie: well Google totally loves HTML5 it seems |
| 03:34 | <ezyang> | "Pop all the nodes from the bottom of the stack of open elements, from the current node up to the root html element." Does this mean that the stack is empty afterwards? |
| 03:34 | <ezyang> | Or does it just contain the html node? |
| 04:45 | <Hixie> | ezyang: wow, that text is confusing. send mail in and i'll fix it. it should say "up to and excluding" the html element. |
| 04:46 | <othermaciej> | Hixie: I think my demo of HTML5 video was sexier than Vic's, too bad I probably can't post it publicly |
| 04:46 | <othermaciej> | but I have to show you sometime |
| 04:47 | <ezyang> | Awesome, thanks! |
| 04:48 | <ezyang> | Umm... does html5 take unsubscribed emails? I unsubscribed because there was too much stuff I didn't care about and I hadn't gotten Sup to filter mailing lists |
| 04:48 | <Hixie> | othermaciej: i am shocked, shocked i tell you, that an apple demo was slicker than a google demo. :-P |
| 04:48 | <Hixie> | ezyang: you can just mail me directly (ian⊙hc) |
| 04:48 | <othermaciej> | my slides were very pretty too, but not many people showed up to my session |
| 04:49 | <othermaciej> | Hixie: I did post my offline demo though: http://webkit.org/demos/calendar/Calendar.html |
| 04:49 | <othermaciej> | (uses AppCache, SQLStorate, LocalStorage, online/offline events) |
| 04:50 | <Hixie> | othermaciej: that demo will be even more compelling once browsers do the vEvent drag-and-drop stuff |
| 04:50 | <Hixie> | othermaciej: and you can just drag from one calendar to another and have the event carry through |
| 04:50 | <Hixie> | wouldn't even be that hard to do, on the js side |
| 04:50 | <othermaciej> | that would be cool |
| 04:50 | <ezyang> | Sent! |
| 04:50 | <Hixie> | it's technically a requirement of html5 now :-) |
| 04:50 | <Hixie> | ezyang: thanks! |
| 04:51 | <othermaciej> | I did like the YouTube video demo, though really only cause of the domain where it is hosted |
| 04:51 | <othermaciej> | not so much intrinsic slickness |
| 04:51 | <ezyang> | Hmmm... why am I getting two <html> nodes in my documents... |
| 04:53 | <ezyang> | Ouch, the DOM is coming preloaded with an HTML element |
| 04:55 | <ezyang> | Holy crap, that caused 66 cases to start passing |
| 04:55 | <Hixie> | othermaciej: yeah, people from apple and mozilla have been asking for months now for me to convince the youtube guys to do that, and it's been killing me that i couldn't just say "they've already done it, just wait" |
| 04:56 | <othermaciej> | I didn't know Apple was pushing for it, I thought we were gonna make such a demo ourselves |
| 04:57 | <Hixie> | i don't think it was a corporate position, but i have received private requests to that effect |
| 04:57 | <othermaciej> | it's pretty cool |
| 04:57 | <Hixie> | we really need to figure out the codec issue |
| 04:57 | <othermaciej> | it's funny that I chose to highlight similar browser features in my WebKit talk to what apparently was highlighted in the keynote |
| 04:58 | <othermaciej> | (I demoed video, canvas, offline stuff) |
| 04:58 | <Hixie> | i'm surprised offline was demoed anywhere |
| 04:58 | <othermaciej> | only thing I showed that Google didn't highlight was CSS animation |
| 04:58 | <Hixie> | it's so hard to demo in a compelling fashion |
| 04:58 | <othermaciej> | Hixie: that's why I have the network indicator in my demo |
| 04:58 | <Hixie> | oh they took out the animation demo? |
| 04:58 | <othermaciej> | I pulled the network cable, quit and relaunched |
| 04:59 | <othermaciej> | I don't think there was one - if there was I hadn't heard |
| 04:59 | <Hixie> | one of the early versions of the keynote i saw had the video being rotated by css animation stuff |
| 04:59 | <Hixie> | maybe it wasn't reliably enough or something |
| 04:59 | <othermaciej> | I would have demo'd workers too but olliej ran out of time to multithread my fluid dynamics demo |
| 04:59 | <othermaciej> | (solves navier-stokes equations in realtime and draws results to canvas) |
| 05:00 | <Hixie> | nice |
| 05:06 | <othermaciej> | you know, one convenient thing about everything being in one spec prior to the recent splitting was that you could use HTML5 as a shorthand for "next generation of Web standards" |
| 05:06 | <othermaciej> | now you have to be mildly ignorant to do so |
| 05:06 | <othermaciej> | http://www.webdesignerhelp.co.uk/index.php/2009/05/5-fantastic-features-of-html-5/ |
| 05:07 | <othermaciej> | Hixie: anyway I dunno what to do about codecs |
| 05:07 | <othermaciej> | I should look up when the patents on a plausible H.264 baseline expire |
| 05:10 | <Hixie> | i say we co-opt the term Web 5.0 |
| 05:10 | <othermaciej> | ES 5 conveniently renumbered themselves! |
| 05:11 | <ezyang> | Hmm... when I get around to throwing out ~1/2 of my HTML Purifier codebase to use the html5lib parser, I'll be at version 5.0! |
| 05:11 | <ezyang> | All of the stars are conveniently aligned. |
| 05:14 | <ezyang> | "Remove node from the stack of open elements. " If node isn't the current node, do I excise it from the stack? |
| 05:16 | <ezyang> | That wouldn't make any sense at all. |
| 05:16 | <ezyang> | So I guess I'm supposed to pop the stack until I get to the node |
| 05:29 | <ezyang> | Houston, I think I see an error in the test-case |
| 05:29 | <mpilgrim> | there was a bit in the keynote where vic showed the rotated video demo |
| 05:30 | <mpilgrim> | he specifically pointed out that once video was in the DOM, you could do fun stuff with it, including CSS animations and styling |
| 05:30 | <othermaciej> | that's cool |
| 05:30 | <mpilgrim> | ("in the DOM" instead of "in plugin prison") |
| 05:31 | <othermaciej> | I guess it must have looked like I planned my stuff based on Google's conference agenda but I seriously had no idea |
| 05:31 | <mpilgrim> | but yeah, you had to look really closely to notice that he was switching between two different computers and three different browsers in order to demo this stuff |
| 05:31 | <mpilgrim> | the rotating video was a firefox demo (with ogg theora video) |
| 05:32 | <mpilgrim> | the youtube html5 demo only works in safari 4 and (apparently) a nightly build of chrome/chromium that i don't have |
| 05:32 | <mpilgrim> | and on and on |
| 05:32 | <othermaciej> | video is in chromium nightlies now? |
| 05:32 | <othermaciej> | like actually working? |
| 05:32 | <othermaciej> | that would be sweet if so, I hadn't heard |
| 05:32 | <mpilgrim> | http://codereview.chromium.org/115625 |
| 05:33 | <mpilgrim> | i could be misremembering, he may have shown the youtube demo in safari 4 |
| 05:33 | <mpilgrim> | he did NOT make any mention of the fact that he kept switching browsers (and OSes) |
| 05:33 | <Hixie> | ezyang: it means excise |
| 05:34 | <othermaciej> | that checkin would add codecs but presumably you would need something more to actually use them |
| 05:34 | <mpilgrim> | that's all i know :( |
| 05:34 | <othermaciej> | yeah, the bleeding edge of the Open Web platform can be sharp |
| 05:34 | Hixie | runs his recent chromium build to find out |
| 05:34 | <ezyang> | Oh, really! |
| 05:34 | <othermaciej> | I did all my demos in Safari cause I am lazy |
| 05:34 | <Hixie> | doesn't work on the mac chromium builds |
| 05:35 | <Hixie> | dunno about windows |
| 05:35 | <ezyang> | So, that means that <form><div></form><div> results in two nested divs inside of <form>, and nothing outside? |
| 05:35 | <mpilgrim> | i have windows right now |
| 05:35 | <mpilgrim> | where can i get nightly builds? |
| 05:35 | <Hixie> | i build them from svn |
| 05:35 | <Hixie> | ezyang: nested ones, yeah |
| 05:35 | <ezyang> | Wow. That's weird. |
| 05:35 | <mpilgrim> | nm, i found it |
| 05:35 | Hixie | points to the topic |
| 05:36 | <ezyang> | :-) |
| 05:36 | <mpilgrim> | wow, my hotel wireless doesn't completely suck |
| 05:37 | <ezyang> | mpilgrim: Congratulations! A million travelers would love to be in your hotel right now :-P |
| 05:37 | <mpilgrim> | getting sustained 115 kB/s down |
| 05:37 | <ezyang> | Maybe that should get a note. |
| 05:42 | <ezyang> | Huh. Google Code's authorization will randomly fail. |
| 05:45 | <mpilgrim> | it's official: i'm on crack |
| 05:45 | <mpilgrim> | chromium nightly does not play youtube html5 video |
| 05:45 | <mpilgrim> | nor wikimedia commons videos (theora) |
| 05:46 | <mpilgrim> | still, someone is obviously working on it |
| 05:46 | <mpilgrim> | if it's really built on top of ffmpeg, that would be exciting |
| 05:46 | <mpilgrim> | (to me anyway) |
| 05:46 | <othermaciej> | I've definitely heard that folks are working on it |
| 05:46 | <othermaciej> | what would be specifically exciting about ffmpeg being involved? |
| 05:46 | <mpilgrim> | broad codec support |
| 05:46 | <mpilgrim> | on all platforms |
| 05:47 | <mpilgrim> | including linux, which i run on my primary home workstation |
| 05:48 | <mpilgrim> | for posterity, i tested chromium 3.0.183.0 (r17063) |
| 05:49 | <mpilgrim> | on windows |
| 05:49 | <othermaciej> | Chromium is up to 3 already? |
| 05:49 | <mpilgrim> | from http://build.chromium.org/buildbot/snapshots/chromium-rel-xp/17063/ |
| 05:49 | <mpilgrim> | that's what it says in the about box |
| 05:49 | <othermaciej> | at this rate it will have a higher version number than Opera by next year |
| 05:49 | <mpilgrim> | lol |
| 05:56 | <Hixie> | othermaciej: let's not get crazy here, don't forget opera is also releasing browsers! |
| 05:57 | <othermaciej> | Hixie: Opera only consumes 2/3 of a major version number a year though |
| 05:58 | <othermaciej> | Chrome is on track to 3 major versions per year or more |
| 05:58 | <Hixie> | true |
| 05:58 | <Hixie> | i wonder how long they'll keep it up |
| 05:58 | <othermaciej> | probably until their number is big enough to sound comparable to other browsers |
| 05:59 | <Hixie> | firefox and safari are at 3 |
| 05:59 | <Hixie> | so that shouldn't take leng |
| 05:59 | <Hixie> | lon7g |
| 05:59 | <Hixie> | long |
| 06:00 | <othermaciej> | I mean, I dunno if they really want to hit IE / Opera level numbers |
| 06:00 | <Hixie> | oh, well, catching up to IE wouldn't take long at this rate |
| 06:00 | <Hixie> | given the average time between IE releases |
| 06:01 | <othermaciej> | heh |
| 06:01 | <mpilgrim> | everybody gives us shit for keeping products in perpetual beta |
| 06:01 | <mpilgrim> | then we release 2 stable versions in < 1 year, and people give us shit for that instead |
| 06:02 | <mpilgrim> | i think i can see the common factor here |
| 06:02 | <mpilgrim> | ;) |
| 06:02 | <Hixie> | hah |
| 06:04 | <othermaciej> | I would argue GMail has more right to claim to be a non-beta than Chrome 2 |
| 06:05 | <ezyang> | Foster parenting is so convoluted |
| 06:09 | <Hixie> | foster parenting has nothing on the AAA |
| 06:10 | <ezyang> | AAA? |
| 06:11 | <mpilgrim> | "HTML 5 is an appluadable initiative, however it is doomed to fail. One only needs to look at the features in Silverlight (particularly silverlight 3) to see that the level of features offered by HTML 5 is not enought to meet the needs of future RICH applications." |
| 06:11 | <mpilgrim> | http://radar.oreilly.com/2009/05/google-bets-big-on-html-5.html#comment-2060516 |
| 06:13 | <othermaciej> | Stop HTML5! Keep Web applications poor! |
| 06:13 | <Hixie> | i saw that comment earlier |
| 06:13 | <othermaciej> | why you gotta be so jealous of *Rich* internet applications, HTML? |
| 06:13 | <Hixie> | it's an accurate comment if you assume (as the author does) that the goal is to replace native platforms |
| 06:14 | <Hixie> | but the spec explicitly says that that is not the goal |
| 06:14 | <Hixie> | mozilla and opera explicitly said, as did microsoft and sun and redhat, at the famous workshop, that doing that a non-starter with a standards-based approach |
| 06:14 | <Hixie> | specs don't move fast enough |
| 06:15 | <Hixie> | interoperable platforms are doomed to always be inferior to the cutting edge proprietary ones |
| 06:15 | <Hixie> | however that misses the entire point |
| 06:15 | <Hixie> | which is that they _can_ be good enough |
| 06:15 | <Hixie> | and we can make the web much better |
| 06:15 | <othermaciej> | If the commentor thinks "do more stuff than Silverlight" is the goal then he's probably right that HTML5 will fail on those terms |
| 06:16 | <othermaciej> | but I'm happy with how we're doing on "enable Web developers to do more cool stuff" |
| 06:16 | <Hixie> | yup |
| 06:16 | <Hixie> | html5 is also doomed to fail if the goal is to cure cancer |
| 06:19 | <weinig> | Hixie: with that attitude it is! |
| 06:20 | <othermaciej> | hmm validator.nu doesn't like the sizes attribute on this: |
| 06:20 | <othermaciej> | <link rel="icon" href="surfin-safari.icns" sizes="32x32 128x128 512x512"> |
| 06:20 | <othermaciej> | I can't figure out what if anything is wrong |
| 06:21 | <othermaciej> | is that actually a bad value or is it a validator bug? |
| 06:22 | <othermaciej> | it looks conforming to me.... |
| 06:23 | <roc> | I wonder how Google is going to address its patent licensing obligations if they distribute ffmpeg under the LGPL |
| 06:27 | <mpilgrim> | i know i've beat on rubys in the (recent) past |
| 06:28 | <othermaciej> | beat on him about what? |
| 06:28 | <mpilgrim> | but i must give him credit for his stewardship of the rdfa discussion |
| 06:28 | <othermaciej> | he's been fine on that |
| 06:28 | <othermaciej> | I am no fan of his stewardship of the title discussion, in that he started a title discussion |
| 06:29 | <mpilgrim> | are these people for real? http://lists.w3.org/Archives/Public/public-html/2009May/0436.html |
| 06:29 | <othermaciej> | though it has been uphill from there, now that he and Larry have expressed their actual issues with the spec |
| 06:29 | <mpilgrim> | actual_issues++ |
| 06:29 | <othermaciej> | sideshow_proxy_discussions-- |
| 06:30 | <mpilgrim> | "if I have a document that is HTML5 with RDFa and parse it, and a similar document that is XHTML + RDFa and parse it, would you expect *exactly* the same triples to be emitted?" |
| 06:30 | <mpilgrim> | words fail me |
| 06:31 | <othermaciej> | you would kind of expect people interested in semantic markup to want it to work robustly |
| 06:31 | <mpilgrim> | also, http://lists.w3.org/Archives/Public/public-html/2009May/0269.html |
| 06:31 | <mpilgrim> | i think shane is laboring under the misapprehension that he has done the hard part and is about 99% done |
| 06:32 | <othermaciej> | well, he's writing a spec to tack onto HTML4 |
| 06:32 | <mpilgrim> | and all he has to do with RDFa is "dumb it down" for HTML, drop the "X" from the title, and declare victory |
| 06:32 | <mpilgrim> | dude, you're about 1% done |
| 06:32 | <othermaciej> | so HTML4-level quality is not surprising as an outcome |
| 06:32 | <mpilgrim> | and it was the easy 1% |
| 06:32 | <othermaciej> | I would say he's 99% done, and now he has to do the other 99% |
| 06:33 | <mpilgrim> | RDFa-in-XHTML is an interesting theoretical exercise |
| 06:34 | <mpilgrim> | a toy language in an academic's sandbox |
| 06:34 | <billyjackass> | othermaciej: the cause of the sizes thing is a bug in validator.nu, from code I added. I'll fix it. |
| 06:34 | <othermaciej> | MikeSmith: thanks! |
| 06:34 | <MikeSmith> | thanks for catching it |
| 06:35 | <othermaciej> | my only other validator issue is use of proprietary <input type="search"> attributes |
| 06:36 | <mpilgrim> | anyway, rubys has been good at knocking some sense into them so far |
| 06:36 | <othermaciej> | I wonder if we implement enough of Web Forms 2 to replace that all with standards ones |
| 06:36 | <othermaciej> | mpilgrim: he's knocking, but I suspect there is nobody home |
| 06:36 | <mpilgrim> | i hope he can manage to get them to understand the magnitude of the task ahead of them |
| 06:37 | <othermaciej> | it would have been far easier to consider these issues when designing RDFa in the first place... |
| 06:37 | <othermaciej> | but of course, They Weren't Chartered to do That(tm) |
| 06:37 | <mpilgrim> | i can't fault them for that, really |
| 06:37 | <mpilgrim> | they were told XHTML was the future |
| 06:37 | <mpilgrim> | been there, done that |
| 06:38 | <mpilgrim> | not everybody got the memo in 2003 |
| 06:38 | <othermaciej> | I thought flying cars were the future |
| 06:40 | <mpilgrim> | http://www.threadless.com/product/63/Damn_Scientists ! |
| 06:41 | <mpilgrim> | where is my jetpack, dammit! |
| 06:42 | <mpilgrim> | man, this is awesome in retrospect: http://ln.hixie.ch/?start=1037595583&count=1 |
| 06:42 | <mpilgrim> | and http://diveintomark.org/archives/2002/11/21/a_warning_to_others |
| 06:44 | <mpilgrim> | "New XHTML version 1.1! Now more hostile than ever!" |
| 06:44 | <mpilgrim> | good times |
| 06:45 | <hsivonen> | othermaciej: validator bug most likely |
| 06:45 | <ezyang> | XHTML 1.1 was nice enough to give us the modularization though... |
| 06:45 | <othermaciej> | hsivonen: MikeSmith said it was and said he'll fix it |
| 06:46 | <Hixie> | i wonder if the rdfa guys have noticed that the issues they're battling with are non-issues in the microdata proposal... |
| 06:47 | <othermaciej> | I don't know that they are battling those issues so much as trying to sweep them under the carpet |
| 06:47 | <othermaciej> | I think the goal is more to show that RDFa is already perfect than to fix it |
| 06:47 | <mpilgrim> | MICRODATA IS TEH SUCK! |
| 06:48 | <mpilgrim> | U STOLE OUR ATTRIBUTEZ! |
| 06:48 | <othermaciej> | whoah, Hixie used the phrase "in the pre-XHTML2 world" |
| 06:48 | <Hixie> | it's ok, i gave them back |
| 06:48 | <othermaciej> | and it doesn't look like he was being at all sarcastic |
| 06:48 | <Hixie> | othermaciej: you think that's bad. see http://ln.hixie.ch/?start=1042630901&count=1 |
| 06:49 | <hsivonen> | mpilgrim: http://lists.w3.org/Archives/Public/public-html/2009May/0301.html is interesting |
| 06:49 | <mpilgrim> | BUT STILL! WE MUST BRING IT UP AT EVERY OPPORTUNITY! IN CASE IT HAPPENS AGAIN! |
| 06:49 | <othermaciej> | "Personally, I think XHTML2 is shaping up to be a great specification." - Ian Hickson |
| 06:49 | <mpilgrim> | REMEMBER THE @PROPERTY! |
| 06:49 | <othermaciej> | I should twitter that |
| 06:49 | <Hixie> | i started work on html5 8 months later |
| 06:50 | <Hixie> | it's amazing when you realise that in 6 years since then xhtml2 has hardly changed at all |
| 06:50 | <mpilgrim> | not true, it grew roles and states |
| 06:50 | <othermaciej> | what made you grow disenchanted so quickly? |
| 06:51 | <Hixie> | othermaciej: xforms |
| 06:51 | <roc> | and can we bottle it and sell it? |
| 06:51 | <Hixie> | as you will recall :-) |
| 06:51 | <othermaciej> | was it really not obvious before that, that starting with a clean slate of purity was a bad idea? |
| 06:51 | <Hixie> | i guess not |
| 06:51 | <othermaciej> | still, it is good to know you can change your mind even on major questions of strategy when presented with the evidence |
| 06:52 | <othermaciej> | in the nascent days of Safari I initially thought we should base it on Gecko |
| 06:52 | <othermaciej> | as long as we are bringing up regrettable past beliefs |
| 06:53 | <mpilgrim> | on the subject of embarassing quotes, i like this one: http://lists.w3.org/Archives/Public/www-html/2003Jan/0277.html |
| 06:54 | <Hixie> | it's interesting to note that the end of the blog post does acknowledge that a boil-the-oceans strategy will take a long time |
| 06:55 | <othermaciej> | so long, it's infinite! |
| 06:56 | <Hixie> | nah, if the technology is good enough, you can do it |
| 06:56 | <Hixie> | e.g. mac os 9 to mac os x |
| 06:56 | <Hixie> | or the iphone |
| 06:56 | <Hixie> | or windows to linux |
| 06:56 | <Hixie> | etc |
| 06:57 | <Hixie> | mpilgrim: i still don't think we should have the style="" attribute. |
| 06:57 | <othermaciej> | OS X had to build a lot of bridges |
| 06:57 | <othermaciej> | from the original total-ocean-boiling strategy |
| 06:57 | <Hixie> | yes, you need to build a lot of bridges to do it |
| 06:57 | <othermaciej> | (Classic and Carbon were not part of the original plan) |
| 06:57 | <Hixie> | it's far more work than the xhtml2 wg are even remotely considering |
| 06:57 | <Hixie> | also xhtml2 isn't enough of an improvement (any more) |
| 06:57 | <Hixie> | (if it ever was) |
| 06:58 | <mpilgrim> | http://www.zeldman.com/daily/0103c.shtml#inatwist "Nevertheless, we get the feeling that XHTML 2’s most ardent supporters think ordinary designers and developers are bad and stupid and backward and intractable, and that only brute force can deliver the semantic web." |
| 06:58 | <othermaciej> | Apple also had the advantage of having a totally vendor-controlled ecosystem |
| 06:58 | <othermaciej> | zeldman beats Hixie! |
| 06:58 | <mpilgrim> | funny, i still get that feeling |
| 06:59 | <mpilgrim> | zeldman wrote that over 6 years ago |
| 07:00 | <Hixie> | that was written around the same time as my blog post |
| 07:00 | <Hixie> | probably as part of the same "blogosphere meme" |
| 07:01 | <hsivonen> | might be interesting to look up my ancient XHTML2 technical feedback to see if it has been addressed |
| 07:01 | <hsivonen> | nah |
| 07:01 | <hsivonen> | I'll spend my day doing perf profiling instead |
| 07:02 | <Hixie> | hsivonen: the wg finally got back to me today on some feedback i sent on xhtml1 in 2003 |
| 07:03 | <ezyang> | Question: Why doesn't the whitespace in ><div><table><a>foo</a> <tr><td>bar</td> </tr></table></div> get foster parented? |
| 07:03 | <ezyang> | (erm, ignore that stray >) |
| 07:03 | <ezyang> | Doesn't <a>foo</a> trigger the taint? |
| 07:03 | <Hixie> | in the spec, you mean? |
| 07:04 | <ezyang> | This example comes from html5lib test suite |
| 07:04 | <ezyang> | I'm trying to decide if I've done something boneheaded before changing the test |
| 07:05 | <hsivonen> | Hixie: cool. better late than never |
| 07:05 | <hsivonen> | Hixie: had you already fixed it in XHTML5? |
| 07:05 | <Hixie> | ezyang: looks like a bug in the test to me |
| 07:05 | <ezyang> | awesome |
| 07:06 | <Hixie> | hsivonen: the feedback was basically "don't allow text/html to be used for xhtml", so yes, we fixed that years ago |
| 07:06 | <hsivonen> | ezyang: the test was updated when I thought Hixie would do WebKit-style taintless tables |
| 07:06 | <ezyang> | Oh? |
| 07:06 | <Hixie> | hsivonen: their response was "we split xhtml appendix c into a separate note", and my further response was to ask for the editor's draft so i could check their new wording |
| 07:06 | <ezyang> | Well, is Hixie going to do taintless tables? |
| 07:06 | <hsivonen> | ezyang: not at the moment. I need to convince him some more |
| 07:07 | <Hixie> | iirc i came up with some reason why it wasn't a good idea |
| 07:07 | <ezyang> | Heh, ok. |
| 07:08 | <hsivonen> | it's certainly possible to construct cases where it's a bad idea not to have taint |
| 07:09 | <hsivonen> | but WebKit seems to get away with not having taint, so... |
| 07:09 | <ezyang> | I see; you want to keep things simple. |
| 07:10 | <ezyang> | Well, it's nice to know that it's intentional. I hate it when I implement parts of the spec and the number of passing tests goes down :-) |
| 07:10 | <hsivonen> | Hixie: so far, I haven't seen real-world issues |
| 07:10 | <ezyang> | Hmmm... I suppose I should check how many tests the python implementation has passing and check that |
| 07:11 | <ezyang> | This means the lower bound to fails is at least 1... possibly more |
| 07:11 | <hsivonen> | Hixie: I've seen one reftest fail bus so mildly that users wouldn't have noticed if it had been in the wild |
| 07:11 | <hsivonen> | s7bus/but/ |
| 07:12 | <othermaciej> | I love this old Hixie blog post |
| 07:12 | <othermaciej> | every line is a treasure |
| 07:14 | <hsivonen> | mpilgrim: it seems that HTML5 is hostile in some ways like XHTML 1.1 |
| 07:14 | <othermaciej> | actually, some of these things would be great to fix if they were practically fixable |
| 07:14 | <othermaciej> | like lists in paragraphs |
| 07:14 | <hsivonen> | mpilgrim: e.g. name=foo being non-conforming |
| 07:15 | <hsivonen> | mpilgrim: whoa! you've had a FOAF profile! |
| 07:16 | <hsivonen> | mpilgrim: what made you not have one any longer? |
| 07:16 | <mpilgrim> | i did, when they were all the rage |
| 07:17 | <mpilgrim> | i had a blogroll and an rss feed once too |
| 07:17 | <mpilgrim> | i believe if you go back far enough, i had a scriptingNews feed |
| 07:17 | <mpilgrim> | (betcha don't even know what that is) |
| 07:17 | <hsivonen> | mpilgrim: I think I've seen something about that |
| 07:18 | ezyang | lost another four test-cases... argh |
| 07:18 | hsivonen | remembers seeing a YSoD on diveintomark around the time of that post |
| 07:19 | <ezyang> | Ok, the test-case is almost definitely wrong |
| 07:20 | <ezyang> | Oh wait, my diff is being wonky |
| 07:22 | <ezyang> | No, this is most certainly bogus |
| 07:22 | <ezyang> | The test case wants me to have <input> be a child of <table> |
| 07:23 | <hsivonen> | ezyang: not "hidden"? |
| 07:23 | <ezyang> | Ooh, good point. |
| 07:25 | <ezyang> | Whoo, converted into passes |
| 07:29 | <Hixie> | othermaciej_: pretty much everything in that list is either something we've done (e.g. cite="" is now on <section> and <article>, we have <section>/<h1>, we allow <a href=""> around blocks, etc) or things we want to do but can't (e.g. replace <br> with <l>, have href="" everywhere, have <h> instead of <h1>, etc) |
| 07:29 | <ezyang> | hsivonen: How good is our <frameset> coverage? |
| 07:32 | <ezyang> | 'A start tag whose tag name is "frameset"' in mode "in body" seems to be a dead zone |
| 07:32 | <mpilgrim> | hixie: you say xhtml 2 hasn't changed, but it has an <img> element now! |
| 07:32 | <Hixie> | it's true, it has regressed in some ways |
| 07:33 | <Hixie> | :-P |
| 07:33 | <mpilgrim> | http://microformats.org/discuss/mail/microformats-discuss/2005-October/001783.html "<img> was reintroduced to XHTML 2, no doubt after a vigorous and healthy debate in which all parties treated each other with mutual respect. But now it has a different content model than <img> in XHTML 1 and HTML 4, which just goes to show that mutual respect is for chumps." |
| 07:34 | <mpilgrim> | the bit about the content model is still true, AFAICT: http://www.w3.org/TR/xhtml2/mod-image.html |
| 07:36 | <Hixie> | yes |
| 07:37 | <mpilgrim> | ironically, i actually like the idea of using the content inside <img></img> as fallback |
| 07:38 | <mpilgrim> | bummer about the whole legacy content thing |
| 07:40 | <zcorpan> | how annoying - opera's UA string *was* pretty good |
| 07:40 | <Hixie> | mpilgrim: oh there are lots of things that suck in html that i'd do differently if we could |
| 07:49 | <Mrmil> | Hi, can <time> be used this way? <time>May 28 2009 08:48:44</time> I remember there was some fuss about this. I know it's useless without the datetime attribute but I don't have to use everywhere, do I? :) |
| 07:51 | <Hixie> | Mrmil: either you have to have the attribute or the contents have to be YYYY-MM-DDTHH:MM.ssZ |
| 07:53 | <Mrmil> | Mmm, okey. The spec says something else though: http://www.whatwg.org/specs/web-apps/current-work/multipage/text-level-semantics.html#the-time-element - The time element is not necessary for encoding dates or times. In the following snippet, the time is encoded using time, so that it can be restyled (e.g. using XBL2) to match local conventions, while the year is not marked up at all, since marking it up would not be particularly useful. |
| 07:53 | <Mrmil> | <p>I usually have a snack at <time>16:00</time>.</p> |
| 07:58 | <Hixie> | Mrmil: oh, i misspoke. it's actually either YYYY-MM-DDTHH:MM:SS.ssZ or YYYY-MM-DD or HH:MM:SS.ss |
| 07:58 | <Hixie> | and the :SS.ss part is optional |
| 08:00 | <Mrmil> | Hixie: Oh okey. Does it mean the example with <time>16:00</time> is wrong? |
| 08:01 | <Hixie> | no, HH:MM is a valid syntax (since the :SS.ss part is optional) |
| 08:01 | <Mrmil> | right, now I mislooked. Ok, thanks |
| 08:04 | <ezyang> | "<body><frameset><frame></frameset>" This wouldn't result in <body> getting replaced with <frameset>, would it? |
| 08:06 | <ezyang> | because <body> sets the frame-ok flag to false, and then frameset doesn't get to do the wibbly-wobbly timey wimey stuff |
| 08:07 | <hsivonen> | ezyang: frameset test coverage is very, very bad |
| 08:08 | <ezyang> | Well, I've had about a 50/50 chance of detecting bad tests tonight, so it could be just me |
| 08:09 | <ezyang> | hsivonen: Should I go ahead and "fix" the test, or send mail to html5lib-discuss and wait for an ack? |
| 08:09 | <hsivonen> | ezyang: Also, it would be great to have tests for trying to enter 'in foreign' when the tree builder is already in 'in foreign' |
| 08:10 | <ezyang> | oh ho ho, I haven't even implemented that yet. |
| 08:10 | <hsivonen> | ezyang: you mean the tain thing? |
| 08:10 | <ezyang> | no, the frame-ok one I just mentioned |
| 08:10 | <hsivonen> | ezyang: yes, please fix |
| 08:12 | <ezyang> | Hmm... I'm probably going to get the errors wrong |
| 08:13 | <ezyang> | Can I add a comment to .dat files? |
| 08:14 | <zcorpan> | Hixie: "xHTML2" - http://ln.hixie.ch/?start=1042630901&count=1 - typo or intentional lowercase x? |
| 08:14 | <Hixie> | typo |
| 08:14 | <Hixie> | happens in several posts from back then |
| 08:14 | <Hixie> | i assume it was a typo, anyway |
| 08:14 | <Hixie> | maybe i was making some crazy subtle point that i now forget |
| 08:14 | <Hixie> | there's a lot of that in my blog entries |
| 08:15 | <zcorpan> | i always get confused about what people mean when people write "xHTML" |
| 08:17 | <Mrmil> | That means they don't know whether they use HTML or XHTML :) |
| 08:21 | <hsivonen> | Usually "xHTML" is signal for "I don't want to upset the XHTML2 WG by calling the XML serialization of HTML5 XHTML." |
| 08:21 | <hsivonen> | ezyang: I think there aren't comments |
| 08:22 | <hsivonen> | ezyang: also, the format is very brittle in my harness, so please avoid reordering fields |
| 08:22 | <hsivonen> | (I have a streaming impl.) |
| 08:23 | <hsivonen> | How often should I tell Shark to sample if I leave it running for an hour? |
| 08:23 | <hsivonen> | so that I don't get too much data |
| 08:33 | <zcorpan> | hsivonen: maybe in the contexts you see "xHTML", but i'm sure lots of instances of "xHTML" i've seen the author has no idea about HTML5 or the XHTML2 WG |
| 08:40 | <hsivonen> | zcorpan: that's possibel |
| 08:40 | <Hixie> | crap |
| 08:40 | <hsivonen> | zcorpan: did Opera change its UA string again? |
| 08:40 | Hixie | realises a flaw in his recent checkin |
| 08:40 | <Dashiva> | hsivonen: Issues with two-digit version numbers |
| 08:41 | <hsivonen> | Dashiva: yay |
| 08:41 | <zcorpan> | hsivonen: Opera/9.80 ... Version/10.00 |
| 08:41 | <hsivonen> | UA sniffing FTW! |
| 08:41 | <Dashiva> | I suggested just converging towards 10 with an ever-inreasing number of 9.9999... |
| 08:42 | <hsivonen> | zcorpan: does it also contain substrings "Gecko" and "WebKit" now that you aren't hard-line about version? |
| 08:42 | <zcorpan> | hsivonen: no |
| 08:43 | <zcorpan> | hsivonen: http://dev.opera.com/articles/view/opera-ua-string-changes/ |
| 08:45 | <zcorpan> | maybe we should change name and start over from version 1 |
| 08:46 | <Dashiva> | Ballett/1.0 |
| 08:46 | <Dashiva> | -t |
| 08:46 | <zcorpan> | (or version 4 or 5 or whatever the web sniffers require to work) |
| 08:47 | <hsivonen> | my recent UA string annoyances have been with major sites sniffing for Firefox and blocking or semiblocking Minefield |
| 08:47 | <Philip`> | What if you changed the version number to 19.00, so that people who use /(\d)\.\d\d/ to find the version number will not think it's an old version? |
| 08:48 | <olliej> | Philip`: i believe safari 2.0.4 was detected as netscape 4 by a number of sites |
| 08:48 | <Dashiva> | Philip`: It's usually the first character after Opera/ |
| 08:48 | <zcorpan> | Philip`: i think some pages use /\/(\d)/ |
| 08:48 | <Dashiva> | So we could go with 90, 91, etc |
| 08:49 | <Philip`> | It'd be much easier if the UA string was structured data, like JSON perhaps, so people didn't have to use regexps |
| 08:49 | mpilgrim | recalls that windows 95 identified itself to applications as "major version 3, minor version 95", for compatibility with stupid windows 3.1 apps |
| 08:50 | <hsivonen> | mpilgrim: I recall reading Windows 7 doing something similar |
| 08:50 | <mpilgrim> | see, we're just replicating the native application experience! |
| 08:51 | <zcorpan> | Maybe we should use Mozilla/5.0 (actually Opera/10.00 and not Gecko/Firefox/WebKit/Safari) Presto/2.2.15 |
| 08:51 | <Philip`> | http://blogs.msdn.com/oldnewthing/archive/2004/02/13/72476.aspx |
| 08:52 | <mpilgrim> | oldnewthing++ |
| 08:53 | <mpilgrim> | must sleep now. "big surprise" coming in tomorrow's keynote |
| 08:53 | <mpilgrim> | i hear all google i/o attendees are getting their own personal robot |
| 08:54 | <Hixie> | dude |
| 08:54 | <Hixie> | nda! |
| 08:55 | <Philip`> | Is it a 30-foot dinosaur robot that eats cars? |
| 08:55 | <mpilgrim> | no, it's one of these: http://www.ftrain.com/robot_exclusion_protocol.html |
| 08:55 | <Dashiva> | Does it destroy humanity? |
| 08:55 | <Philip`> | If not, it hardly seems worth bothering |
| 08:59 | <hsivonen> | what was the right OS X incantation to do a resource fork-safe copy of a directory in such a way that symlinks get replaced with concrete copies? |
| 09:04 | <Mrmil> | Is it normal to release a new version of a software when the development hasn't been finished yet? I just love to fix things 3 times rather than once. |
| 09:09 | <hsivonen> | Mrmil: software development is never finished |
| 09:11 | <Mrmil> | hsivonen: talk about fighting with entropy |
| 09:12 | <Dashiva> | It's not even entropy, it's a malicious agent |
| 09:29 | <MikeSmith> | hsivonen: so <link rel="icon" href="surfin-safari.icns" sizes="32x32"> validates, but <link rel="icon" href="surfin-safari.icns" sizes="32x32 64x64"> does not |
| 09:29 | <MikeSmith> | it's not actually allowing a list, only a single token |
| 09:31 | <MikeSmith> | the schema defines the value of sizes as 'list { xsd:string { pattern = "[1-9][0-9]*x[1-9][0-9]*" }' |
| 09:34 | <MikeSmith> | maybe a jing bug? |
| 09:38 | <roc> | the best way to do version checking is to only provide an API that does IsVersionGreaterThanOrEqualTo(version) |
| 09:41 | <annevk42> | actually, I'm speccing sync XHR to not have any side effects either |
| 09:41 | <annevk42> | I mean, that scripts cannot run |
| 09:42 | <Dashiva> | roc: What's the datatype of version? |
| 09:43 | <roc> | I don't think it matters too much |
| 09:44 | <roc> | a single int into which you pack major/minor is probably OK |
| 09:45 | <Hixie> | annevk42: if sync xhr has no network-based side-effects, it's a pretty useless networking api :-P |
| 09:46 | <annevk42> | meh, I mean that when send() is invoked the event loop is taken out of the loop |
| 09:46 | <annevk42> | until all is done |
| 09:46 | <annevk42> | (or exception is thrown, blah) |
| 09:46 | <annevk42> | I'm working on defining this in terms of the event loop |
| 09:47 | <annevk42> | It's been very annoying so far though also interesting |
| 09:49 | <Hixie> | annevk42: sounds exactly like what implementors have said about it :-) |
| 09:55 | <roc> | no, I think it's only annoying |
| 09:58 | <annevk42> | I wonder if we could've done it a bit more abstractly |
| 09:58 | <annevk42> | Like "run the following steps synchronously" and "queue a task for these steps and run them whenever what is running runs to completion" |
| 10:02 | <ap> | annevk42: defining abstract expectations would be more desirable than describing algorithms in pseudo-code, in my opinion |
| 10:03 | <ap> | annevk42: one often cannot even compare the pseudo-code with actual implementation - e.g. if the actual implementation of event loop is closed source |
| 10:04 | <annevk42> | it also seems mightily hard to write tests against |
| 10:04 | <jgraham> | My rather biased view is that making it easy to write tests is more important than having the spec map closely onto the implementation |
| 10:05 | othermaciej | fails at sleeping again |
| 10:05 | <annevk42> | othermaciej, I have a similar issue |
| 10:05 | <annevk42> | (though today it was because I was woken up early by someone coming by to fix something) |
| 10:06 | <othermaciej> | annevk42: are you in a time zone where you are supposed to be asleep? |
| 10:06 | <roc> | I don't think anyone's arguing that writing psuedo-code algorithms is good because it maps closely to implementations |
| 10:06 | <annevk42> | othermaciej, not anymore :) |
| 10:06 | <othermaciej> | sometimes pseudo-code can define things more unambiguously |
| 10:06 | <othermaciej> | but it can also be hard to figure out what the consequences are for a practical implementation |
| 10:06 | <othermaciej> | Workers is an example of where this goes bad IMO |
| 10:06 | <annevk42> | <input iprof>: http://bulknews.typepad.com/blog/2009/05/another-way-to-autofill-your-profile-in-html-forms.html |
| 10:07 | <othermaciej> | it's very breezy about concurrency isues |
| 10:07 | <othermaciej> | and as a result ends up requiring crazy things for practical implementations |
| 10:07 | <othermaciej> | (of course, that's not in the HTML5 spec as such) |
| 10:08 | zcorpan | finds http://www.w3.org/2009/04/video-player.xhtml |
| 10:08 | <roc> | to be fair, writing specs for things involving concurrency is very hard no matter how you do it |
| 10:08 | <othermaciej> | that is true |
| 10:09 | <othermaciej> | it's very easy to require things that are unimplementable or unbelievably hard to implement |
| 10:09 | <othermaciej> | it's also easy to state requirements that are unsound and end up having race conditions |
| 10:09 | <zcorpan> | i wonder who wrote the video-player.xhtml demo |
| 10:09 | <roc> | it's pretty cool |
| 10:10 | <Philip`> | http://lists.w3.org/Archives/Public/public-pfwg-comments/2009AprJun/0085.html |
| 10:10 | <zcorpan> | thanks Philip` |
| 10:10 | Philip` | thanks Google |
| 10:11 | <roc> | I'm glad they're enjoying the video element, I just hope they don't ask us to implement DFXP |
| 10:13 | <othermaciej> | video-player.xhtml is indeed neat |
| 10:13 | <othermaciej> | what is DFXP? |
| 10:13 | <Hixie> | annevk42: "whenever what is running runs to completion" doesn't work because it doesn't define ordering of async events |
| 10:14 | <Hixie> | annevk42: and we can't just say that that things fire in the order the fire, because certain things get priority (hence the multiple task sources) |
| 10:14 | <MikeSmith> | roc: btw, do you know if there's been any new news about the 'Accelerated 3D on the Web' work at Khronos? |
| 10:15 | <Hixie> | othermaciej: btw i just made a number of changes to workers to hopefully reduce that (though that wasn't the main goal of the changes, the main goal was reducing cross-thread reachability tests) |
| 10:17 | <zcorpan> | "This will never work on Internet Explorer" - http://www.dailymotion.com/openvideodemo |
| 10:17 | <roc> | othermaciej: W3C Timed Text, some giant bloated thing IIRC |
| 10:17 | <roc> | MikeSmith: there may be, but I'm not involved |
| 10:22 | <annevk42> | Hixie, but the priority is up to the UA |
| 10:23 | <annevk42> | Hixie, so we could just say they go in a bucket or some such |
| 10:23 | <Hixie> | annevk42: no, because some things have to happen in order |
| 10:23 | <Hixie> | relative to each other |
| 10:23 | <Hixie> | but not necessarily relative to others |
| 10:24 | <annevk42> | hmm yeah |
| 10:24 | <Hixie> | also, we have to define that inactive documents don't run their tasks |
| 10:24 | <Hixie> | and we have to define when the storage mutex is released |
| 10:24 | <Hixie> | and we have to define when rendering happens relative to task processing |
| 10:25 | <Hixie> | i just don't know how to do all this without using algorithms |
| 10:25 | <annevk42> | we should write this list down somewhere |
| 10:25 | <Hixie> | it's all already specified :-) |
| 10:25 | <annevk42> | I'll make a wiki page |
| 10:25 | <Hixie> | i have just been reading straight out of the html5 event loop description |
| 10:25 | <annevk42> | a definition is not a list of requirements |
| 10:26 | <Hixie> | the spec already meets these requirements as far as i can tell |
| 10:26 | <annevk42> | sure, but this is easier to understand than the spec :) |
| 10:29 | <annevk42> | hmm nm |
| 10:29 | <annevk42> | writing it down doesn't make it look like anything useful |
| 10:34 | <Hixie> | annevk42: just saying "we must define when bla happens" isn't useful, indeed :-) |
| 10:34 | <Hixie> | (at least, not once we've defined it) |
| 10:34 | <Hixie> | i mean, you probably could come up with some complicated non-algorithmic description |
| 10:34 | <Hixie> | but it'd almost certainly be far less clear |
| 10:34 | <Hixie> | i haven't been able to come up with clear non-algorithmic descriptions for these things |
| 10:35 | <annevk42> | "Google Chrome now supports the video tag." |
| 10:36 | <annevk42> | I was hoping for more information than that :) |
| 10:37 | <othermaciej_> | last I heard, it did not work when markpilgrim tried it |
| 10:37 | zcorpan | adds the mentioned demos to the spec's annotation box for <video> |
| 10:38 | <othermaciej_> | and I don't see any code in the public WebKit tree for a chromium back end for <video> |
| 10:41 | <annevk42> | othermaciej_, http://googlechromereleases.blogspot.com/2009/05/dev-channel-release-301822.html |
| 10:41 | <annevk42> | othermaciej_, seems they use FFmpeg |
| 10:49 | <othermaciej> | I wonder if their video stuff is just not submitted yet |
| 10:49 | <annevk42> | It's also not in the actual release notes: http://sites.google.com/a/chromium.org/dev/getting-involved/dev-channel/release-notes/301822 |
| 10:50 | <annevk42> | oh, but something is in: http://sites.google.com/a/chromium.org/dev/getting-involved/dev-channel/release-notes/201800 |
| 10:52 | <annevk42> | Hixie, do you know anything about license story and if there's more info somewhere about <video> and Chomium/Chrome? |
| 10:54 | <othermaciej> | hmm I see only the faintest trace of a Chromium media engine in the WebKit tree |
| 10:55 | <othermaciej> | will have to ask some Chromium folks when they are around |
| 11:00 | <hsivonen> | MikeSmith: on the surface, the sizes thing sure looks like a Jing bug |
| 11:01 | <hsivonen> | MikeSmith: oops. I think you need to have a quantifier for the datatype |
| 11:01 | <hsivonen> | MikeSmith: so not a Jing bug |
| 11:06 | <annevk42> | http://www.ffmpeg.org/legal.html makes it look very dodgy |
| 11:06 | <annevk42> | guess the next question is whether MPEG-LA is in contact with Google |
| 11:08 | <roc> | this is something I am very curious about |
| 11:09 | <hsivonen> | MikeSmith: fix being deployed |
| 11:09 | <hsivonen> | annevk42: MPEG-LA deal would explain use on server without ever distributing it, but the case of distributing it is interesting |
| 11:10 | <hsivonen> | annevk42: (L)GPL considered |
| 11:10 | <hsivonen> | annevk42: I can see how they could wiggle around Apache License 2 for Android |
| 11:11 | <annevk42> | so what exactly is the deal with the licenses? they're not compatible? |
| 11:13 | <jgraham> | Isn't the problem just that the LGPL bits have to remain open source yet there will be a patent licensing fee associated with distributing them. Which causes interesting issues |
| 11:14 | <hsivonen> | annevk42: see section 11 of http://www.gnu.org/licenses/old-licenses/lgpl-2.1.html |
| 11:16 | <roc> | if Google has arranged H.264 patent licensing for all users of ffmpeg, that would be a neat solution to the codec problem |
| 11:17 | <annevk42> | hsivonen, wow |
| 11:19 | <jgraham> | roc: I'm not sure how that would work without making the ffmpeg patents worthless |
| 11:19 | <roc> | you mean the H.264 patents |
| 11:19 | <roc> | but yes |
| 11:19 | <Mrmil> | Doesn anybody know how to make HTML 5 work in IE? Bruce Lawson pointed out this script http://remysharp.com/2009/01/07/html5-enabling-script/ but I thought I'd ask here to make sure. |
| 11:19 | <roc> | it's hard to see the MPEG LA agreeing to that |
| 11:19 | <jgraham> | yeah I did mean that |
| 11:21 | <roc> | there are possible alternatives, like Google isn't actually using ffmpeg's H.264 implementation, but it's useless to speculate. We should just wait and see |
| 11:21 | <annevk42> | so this basically means all browsers can ship FFmpeg if Google is shipping a complete version |
| 11:21 | <annevk42> | fascinating |
| 11:22 | <annevk42> | (quite brutal license terms too) |
| 11:22 | <jgraham> | It it fun to speculate wildly. Maybe we can start a rumour that Google bought all the patents |
| 11:22 | <zcorpan> | then google will sue microsoft when they ship <video> support in IE11 |
| 11:23 | <othermaciej> | Hixie: is this one of the changes you made for Worker lifecycle? |
| 11:23 | <othermaciej> | "User agents must either act as if MessagePort objects have a strong reference to their entangled MessagePort object or as if each MessagePort object's owner has a strong reference to the MessagePort object." |
| 11:23 | <roc> | Maybe they replaced the MPEG LA board with Cyclons |
| 11:23 | <othermaciej> | (I failed to notice the second clause initially and was writing a reply.) |
| 11:24 | <jgraham> | If someone would only twwitter one or more of these things as the "big Keynote announcement"... |
| 11:28 | <annevk42> | zcorpan, how could Google do that? |
| 11:31 | <zcorpan> | annevk42: no idea, just wild speculation |
| 11:39 | <MikeSmith> | hsivonen: thanks |
| 11:39 | zcorpan | wonders whether gsnedders' outliner should be added to http://validator.whatwg.org/ |
| 11:40 | <MikeSmith> | I didn't realize list{} could even have a quantifier |
| 11:40 | <jgraham> | Having an outliner as part of validator.nu would rock |
| 11:40 | <MikeSmith> | oh |
| 11:41 | <MikeSmith> | hsivonen: sorry, I was confused |
| 11:41 | <MikeSmith> | I see the quantifier is on the pattern |
| 11:41 | <zcorpan> | jgraham: yes |
| 11:42 | <MikeSmith> | hsivonen: I thought list{} by itself meant "one or more" |
| 11:43 | <zcorpan> | maybe RELAX NG should be changed to match expectations better |
| 11:44 | <zcorpan> | send feedback to OASIS |
| 11:44 | <MikeSmith> | heh |
| 11:45 | <MikeSmith> | zcorpan: (assuming you meant that sarcastically) |
| 11:45 | <annevk42> | hmm, http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/ffmpeg/README.chromium |
| 11:46 | <annevk42> | "Example configure flags suitable for Chromium (Ogg+Theora+Vorbis)" |
| 11:46 | <zcorpan> | MikeSmith: i wasn't sarcastic |
| 11:46 | <MikeSmith> | oh |
| 11:46 | <zcorpan> | MikeSmith: relax ng is intended to be free of surprises like these |
| 11:47 | <zcorpan> | see http://www.imc.org/ietf-xml-use/mail-archive/msg00217.html |
| 11:48 | <MikeSmith> | I see. well, OASIS has not had anything to do with RELAX NG for a long time. And had next to nothing to do with it to begin with. James just picked OASIS for convenience, because he needed somewhere |
| 11:48 | <MikeSmith> | and taking it to W3C did not seem to be an option |
| 11:48 | <zcorpan> | MikeSmith: ok, send feedback to James :) |
| 11:48 | <MikeSmith> | I was actually on the RELAXNG TC when it was formed |
| 11:49 | <MikeSmith> | zcorpan: its home is at ISO now, fwiw |
| 11:49 | <zcorpan> | MikeSmith: as well as OASIS, i think? |
| 11:49 | <MikeSmith> | nominally |
| 11:49 | <MikeSmith> | only |
| 11:51 | <zcorpan> | http://www.imc.org/ietf-xml-use/mail-archive/msg00247.html |
| 12:02 | <hsivonen> | haha. the ISO version is more than "a little" harder to read |
| 12:02 | <hsivonen> | the ISO version is only suitable as a reference for people who already know what the spec says |
| 12:03 | <myakura> | should the W3C version of HTML5 be a little harder, too? |
| 12:03 | <itpastorn> | This discussion might be of interest: http://www.sitepoint.com/blogs/2009/05/26/html-5-now-or-never/ |
| 12:05 | <hsivonen> | myakura: it's not impossible that that's what's going to happen :-/ |
| 12:05 | <myakura> | hsivonen: yeah :( |
| 12:05 | <hsivonen> | myakura: oh, and it already lacks the scripted readability features |
| 12:05 | <hsivonen> | myakura: so we are already there :-( |
| 12:06 | <zcorpan> | would be nice with a sitepoint book about canvas (and svg, too, probably, so that people don't use canvas for cases where svg is more appropriate) |
| 12:08 | <zcorpan> | "SVG still doesn’t feel like it has arrived on today’s web, especially in mobile browsers; on the other hand, canvas is already available in a handful of mobile and most desktop browsers" |
| 12:08 | <zcorpan> | seems not quite correct - i think a number of mobiles gained support for svg before canvas and desktop browsers were implementing svg at the same time as canvas |
| 12:09 | <hsivonen> | Aren't both SVG and canvas in Fennec, Mobile Safari and Opera Mini? |
| 12:09 | <hsivonen> | zcorpan: which mobile browser that is suitable for browsing the Web had SVG before <canvas>? |
| 12:09 | <annevk42> | itpastorn, lots of FUD there |
| 12:10 | <zcorpan> | hsivonen: not sure if there was any that was suitable for browsing the web |
| 12:10 | <annevk42> | e.g. "Anything can happen before HTML5 becomes a stable candidate recommendation." -- clearly that's true, but for a lot of things it's highly unlikely |
| 12:11 | <zcorpan> | hsivonen: maybe at one point opera had a partial svg implementation but no canvas :) |
| 12:11 | <annevk42> | when did we add <canvas>? |
| 12:11 | <annevk42> | we had SVG in Opera 8 |
| 12:12 | <hsivonen> | annevk42: I'm pretty sure you didn't on mobile |
| 12:12 | hsivonen | launches Opera 8.65 on S60 |
| 12:12 | <zcorpan> | annevk2: i think <canvas> was opera 9 |
| 12:13 | roc | wonders why on earth someone from Nokia is building Firefox for the Playstation 3 |
| 12:13 | <annevk42> | prolly because the default browser is crap |
| 12:13 | <hsivonen> | roc: why not? the default browser isn't nice |
| 12:14 | <hsivonen> | annevk42: no SVG in Opera 8.65 on S60r3.1 on intertwingly.net |
| 12:14 | <roc> | what is the default browser? |
| 12:14 | <hsivonen> | annevk42: I do see the SVG in Mini |
| 12:14 | <hsivonen> | roc: NetFront, I assume |
| 12:14 | <jgraham> | Hehe those sitepoint comments are funny |
| 12:14 | <jgraham> | Now is a _good_ time for a HTML5 book |
| 12:14 | <annevk42> | mkay, might be that it was not good enough for mobiles yet |
| 12:15 | <jgraham> | It is no more subject to change than, say, Rails and there is a whole book _industry_ built around that |
| 12:16 | <jgraham> | Plus whoever wites a good book now gets to influence how people think about HTML 5 in the future |
| 12:16 | <hsivonen> | annevk42: it could also be that Opera 8.65 sends headers that lead to me getting the wrong mime type |
| 12:16 | <othermaciej> | the parts of HTML 5 that are already widely implemented probably won't change very much |
| 12:16 | <zcorpan> | "Microformats have a low barrier to entry, build on existing semantics and offer far more useful opportunities today, in 2009, than HTML 5." - i wonder what those useful opportunities are |
| 12:16 | <othermaciej> | although it's not until they are widely used that it moves from "unlikely" to "near impossible" |
| 12:17 | <othermaciej> | I think only <canvas> is past that threshold of use |
| 12:17 | <roc> | I think localStorage is further ahead actually |
| 12:17 | <roc> | at least it has IE8 support |
| 12:17 | <jgraham> | Doing a book about the features like <canvas>, databases, video, storage, etc. seems quite reasonable |
| 12:18 | <hsivonen> | annevk42: SVG not supported even by navigating directly to the tiger |
| 12:18 | jgraham | likes Shelly's comment "It exists whether you’re using HTML5 or not.", without mentioning that the same is true of every other HTML5 feature |
| 12:18 | <annevk42> | hsivonen, thanks for testing |
| 12:19 | hsivonen | wonders if Opera for S60 is a discontinued product and whether it's worthwhile to file bugs |
| 12:19 | <jgraham> | (it was in relation to <canvas> which I guess she covers in "Paining the Web") |
| 12:19 | <othermaciej> | good point |
| 12:19 | gsnedders | still isn't used to seeing the Opera icon in his dock where he's used to seeing Safari |
| 12:21 | <jgraham> | gsnedders: Put it somewhere else in the dock then? |
| 12:21 | <gsnedders> | Then it isn't where I instinctively click for a web browser :P |
| 12:21 | <hsivonen> | annevk42: see SRS60-3775 about request header issues |
| 12:22 | zcorpan | has his browsers side-by-side in the dock |
| 12:22 | gsnedders | is very selective about what goes in his dock |
| 12:23 | jgraham | needs all his browsers in the dock |
| 12:23 | <zcorpan> | what do you have? Finder, Opera, Trash? |
| 12:23 | annevk42 | almost never uses the dock |
| 12:23 | <jgraham> | Although Firefox removes itself for some reason |
| 12:23 | annevk42 | always searches for applications and hits enter |
| 12:23 | <jgraham> | annevk42: Quicksilver? |
| 12:23 | <gsnedders> | zcorpan: Finder, System Preferences, Mail, Adium, Opera, Colloquy, Transmit, SubEthaEdit, iTunes, Terminal, Trash |
| 12:23 | <zcorpan> | jgraham: have you checked "Keep in Dock" in the context menu? |
| 12:23 | <annevk42> | the search bar in the top right |
| 12:23 | <jgraham> | zcorpan: yes |
| 12:24 | <zcorpan> | jgraham: weird |
| 12:24 | <jgraham> | annevk42: Oh, I'm glad I'm not the only one |
| 12:24 | <jgraham> | zcorpan: (I think it is after it updates) |
| 12:24 | <zcorpan> | ah |
| 12:24 | <gsnedders> | Spotlight is quick enough to be used like that in 10.5 |
| 12:24 | <hsivonen> | gsnedders: it a kind of FAIL for OS X pref design that users need to keep System Prefs in the Dock |
| 12:24 | <zcorpan> | minefield stays in dock for me despite updates |
| 12:24 | <hsivonen> | (I have it there, too.) |
| 12:24 | <gsnedders> | hsivonen: They don't really at all |
| 12:25 | <jgraham> | (In unrelated non-news the applications folder is a really really difficult way to find applications) |
| 12:25 | <gsnedders> | hsivonen: It's in the Apple menu :P |
| 12:25 | <gsnedders> | jgraham: Um, just start typing the application name to go to that point in the list of files? |
| 12:25 | <gsnedders> | I guess that doesn't work if you use icons |
| 12:25 | <annevk42> | usually you only need like two or three letters |
| 12:25 | <annevk42> | very nice |
| 12:26 | <jgraham> | gsnedders: It doesn't organise itself in any nice way. Also I never worked out how to execute things using the keyboard |
| 12:26 | <jgraham> | And it is hard to find the folder |
| 12:26 | <gsnedders> | jgraham: Cmd+O? |
| 12:26 | <jgraham> | (like you have to find a finder window and then navigate to the applications folder) |
| 12:27 | <gsnedders> | jgraham: Keep it in the dock? |
| 12:27 | <jgraham> | gsnedders: Oh OK. It ill never replace enter in my muscle memory though |
| 12:28 | <jgraham> | gsnedders: I could do. But it feels like I am trying to fight the system (it is much easier to just use spotlight for everything) |
| 12:28 | <gsnedders> | Indeed. |
| 12:28 | <zcorpan> | i wonder why os x uses cmd+o instead of enter |
| 12:28 | <gsnedders> | zcorpan: Legacy |
| 12:29 | <gsnedders> | (Classic did) |
| 12:29 | gsnedders | wonders what NeXTSTEP did |
| 12:29 | <jgraham> | gsnedders: That should so have been changed. It is just insane to have that one part of the UI inconsistent with everything else on the system |
| 12:30 | <zcorpan> | i don't see why they can't change it now |
| 12:30 | <gsnedders> | jgraham: It is consistent. Cmd+O always opens stuff! |
| 12:30 | <zcorpan> | they could have cmd+o and enter both open, and mint a new shortcut for rename |
| 12:30 | <jgraham> | gsnedders: Enter always executes actions (except when it renames files) |
| 12:31 | <jgraham> | Plus renaming files is a really rare activity and so it makes no sense whatsoever to bind it to the most prominent key on the keyboard |
| 12:31 | <zcorpan> | e.g. cmd+enter for rename |
| 12:31 | <jgraham> | And Apple have UI people who understand that |
| 12:32 | <gsnedders> | Heck, until OS X, cmd+n was new folder |
| 12:34 | <othermaciej> | I find "enter" for rename to be kind of weird |
| 12:34 | <zcorpan> | another thing that annoys me is that os x is hard to use with just keyboard. e.g. if i get a dialog and want something else than the default button |
| 12:34 | <othermaciej> | even after using Mac for 8 years now... |
| 12:35 | <annevk42> | yeah, that sucks |
| 12:35 | <othermaciej> | zcorpan: if you turn on "full keyboard access" it's easier to use with just the keyboard |
| 12:35 | <hsivonen> | IIRC, the enter thing came along after System 6.0.7 and in 7.5 at the latest |
| 12:35 | <hsivonen> | othermaciej: easier but still harder than Windows or Gnome |
| 12:35 | <zcorpan> | othermaciej: interesting |
| 12:36 | <hsivonen> | at one point, I considered swithing to Ubuntu for development in order to get better keyboardability in Eclipse |
| 12:36 | <othermaciej> | that makes tab cycle through every control, even ones you don't normally type in |
| 12:36 | <othermaciej> | (OS X default is that tab only cycles through controls that are interesting typing targets) |
| 12:36 | <jgraham> | othermaciej: It doesn't consider dropdowns to be interesting typing targets, right? |
| 12:36 | <gsnedders> | hsivonen: It's in 7.0, I'm pretty sure |
| 12:37 | <zcorpan> | othermaciej: thanks |
| 12:37 | <hsivonen> | there's something apple got right about keyboardability: in Cancel, OK dialogs, Cancel is focused by default and OK is the default button, so both have keyboard equivs without moving focus |
| 12:37 | <othermaciej> | we try to avoid dialogs that literally say [Cancel] [OK] |
| 12:38 | <hsivonen> | othermaciej: my keyboard-related point stands, though |
| 12:38 | <othermaciej> | but anyway, Esc is always an equivalent for cancel in dialogs on Mac |
| 12:38 | <zcorpan> | it's still hard to discover which keys to press if you don't want to tab to where you want |
| 12:38 | <othermaciej> | regardless of full keyboard focus |
| 12:38 | <Rik|work> | is there a way to go to the last item of a directory in the finder ? |
| 12:38 | <zcorpan> | in windows, when i press alt, the shortcut keys get underlined |
| 12:39 | <othermaciej> | zcorpan: most apps don't have keyboard shortcuts to focus specific controls |
| 12:39 | <othermaciej> | (Safari is the main exception I can think of) |
| 12:40 | <hsivonen> | I wonder if I should bother to analyze what pages that are slower with the HTML5 parser have in common... |
| 12:40 | <hsivonen> | even if things average out in favor of HTML5 |
| 12:40 | <hsivonen> | perhaps I should... |
| 12:40 | <jgraham> | hsivonen: That sounds very interesting |
| 12:40 | <hsivonen> | more immediate benchmarking issues to address, though |
| 12:41 | <hsivonen> | for example, www.sun.com is worse with HTML5 but www.spiegel.de is better |
| 12:41 | <zcorpan> | othermaciej: some things have shortcuts (like buttons in a dialog) but no indicators as to what they are. also, i have no idea how to go to the menu bar at the top with the keyboard |
| 12:42 | <othermaciej> | there is a way, though I am not sure what it is |
| 12:42 | <othermaciej> | hsivonen: might be interesting to find if any error handling is kicking in |
| 12:43 | <hsivonen> | othermaciej: indeed. |
| 12:43 | <othermaciej> | zcorpan: this may help: http://support.apple.com/kb/HT1343 |
| 12:44 | <hsivonen> | looks like the HTML5 spec is unusually biased towards spending time in selector matching compared to Alexa top sites |
| 12:44 | <othermaciej> | it mentions that you can use Ctrl-F2 to focus the menu bar |
| 12:44 | <othermaciej> | Ctrl-F3 to focus the dock, which I did not even know was possible |
| 12:45 | <othermaciej> | the HTML5 spec uses some horrible selectors that are painful to compute |
| 12:45 | <othermaciej> | I recall Hyatt ranting about it a lot |
| 12:47 | <zcorpan> | othermaciej: thanks. (i have to press fn too) |
| 12:47 | <zcorpan> | wonder if there's a way to flip the fn modifier |
| 12:48 | <webben> | Hixie: http://www.whatwg.org/specs/web-apps/current-work/#refsRFC3986 ... that reference seems broke |
| 12:48 | <annevk42> | zcorpan, how is Web DOM Core going? |
| 12:48 | <othermaciej> | zcorpan: there is |
| 12:48 | <webben> | oh i see, missing section, nm :) |
| 12:48 | <annevk42> | zcorpan, would be nice to have a more realistic DOM spec to reference in specs |
| 12:49 | <zcorpan> | othermaciej: found it |
| 12:49 | <othermaciej> | zcorpan: in the "Keyboard" tab in the "Keyboard and Mouse" pane of System Preferences |
| 12:49 | <othermaciej> | there you go |
| 12:49 | <zcorpan> | thanks :) |
| 12:50 | <zcorpan> | annevk2: haven't done much on it lately |
| 12:53 | <gsnedders> | hsivonen: Where are up-to-date builds of HTML5 Fx |
| 12:53 | <annevk42> | zcorpan, any chance I can convince you to finish it? |
| 12:54 | <hsivonen> | gsnedders: not available. sorry. |
| 12:54 | <othermaciej> | Web DOM Core is definitely a good idea |
| 12:54 | <hsivonen> | gsnedders: I've been stuck with this Tp issue. |
| 12:54 | <othermaciej> | wonder what the odds are of Web API WG being willing to publish it |
| 12:54 | <othermaciej> | Web DOM Events would also be good |
| 12:55 | <gsnedders> | hsivonen: k |
| 12:55 | <zcorpan> | annevk42: i'm intending to finish it, it's just priorities |
| 12:56 | <zcorpan> | i should also be doing it in some working group, but i blame chaals for that |
| 12:56 | <annevk42> | yeah, Web DOM Events would be neat |
| 12:57 | <annevk42> | DOM 3 Events seems to be going nowhere :/ |
| 13:01 | <Dashiva> | Did lastweek change subtitle? |
| 13:20 | <gsnedders> | Is it bad my compulsive response to finding a broken website is to create a minimal test-case? |
| 13:20 | <annevk42> | it's good if you wanna get employed as QA person :p |
| 13:20 | <gsnedders> | :P |
| 13:22 | gsnedders | returns to reporting bug on Opera :P |
| 13:22 | annevk42 | finds http://code.google.com/p/chromium/issues/detail?id=4363 |
| 13:26 | <askara> | hi |
| 13:34 | <zcorpan> | itpastorn: "Stuff in the spec that is seeing wide implementation can be seen as very unlikely to be changed in any fundamental way, as is stuff that has been part of the spec for a long time. I.e. <aside> is robust, <hgroup> is not." - i think any feature is not robust until it's implemented |
| 13:35 | <zcorpan> | itpastorn: so <aside> is not robust and might well be dropped or changed in response to implementation experience |
| 13:35 | <zcorpan> | itpastorn: despite having been unchanged in the spec for years |
| 13:37 | <zcorpan> | itpastorn: and actually, even after it has been implemented, it can still change in incompatible ways, if it's just implemented in one browser or not widely deployed yet |
| 13:37 | <zcorpan> | itpastorn: e.g. <event-source> |
| 13:39 | <itpastorn> | zcorpan: I hear you, but can't respond in detail (In a meeting with Skolverket!) |
| 13:41 | <annevk42> | stable ≈ two implementations + reasonable deployment |
| 14:02 | <gsnedders> | Hixie: Can I send you a suggestion for one thing I want in Acid4? |
| 14:02 | <gsnedders> | Or is doing so futile? |
| 14:05 | <zcorpan> | xml core wg process http://www.w3.org/mid/CF83BAA719FD2C439D25CBB1C9D1D3020FC70A20⊙Hppc |
| 14:13 | <annevk42> | so bikesheds is actually from http://en.wikipedia.org/wiki/Parkinson's_Law_of_Triviality |
| 14:20 | <Mrmil> | html5 is like jquery - write less & do more *bloody happy face* |
| 14:27 | <hsivonen> | lack of interop: http://software.hixie.ch/utilities/js/live-dom-viewer/saved/120 |
| 14:28 | <hsivonen> | Hixie: could you please add the IE-specific header to disable the XSS protection on Live DOM Viewer? |
| 14:34 | <krijnh> | Mrmil: totally agreed! :) |
| 14:35 | <Mrmil> | krijnh: hehe :) I really look forward to using the new form elements |
| 14:36 | <krijnh> | Why don't you already? |
| 14:36 | <krijnh> | All those 0.5% Opera users will benefit :) |
| 14:39 | <Mrmil> | krijnh: Well, my own blog is very simple and written in ruby on rails, it doesn't have comments and the back-end is also very simple so there was no need for them yet. I'll do it when I get to implement more features :) |
| 14:46 | <Lachy> | hsivonen, what negative effects, if any, does sniffing the first 1024 bytes instead of 512 for encoding detection have? Does it affect performance in any significant way? |
| 14:47 | <Lachy> | I'm curious, at what point do the negative effects of sniffing more characters outweigh the benefits of doing so? |
| 14:47 | <Philip`> | It affects performance significantly if that's two packets rather than one |
| 14:48 | <jgraham> | I'm not sure that Philip`'s graph indicates that 512 bytes is past the point of diminishing returns |
| 14:48 | <hsivonen> | Lachy: I haven't measured the effect, but intuitively, what Philip` says makes sense |
| 14:48 | <Philip`> | Someone should measure the average HTTP response header size |
| 14:48 | <jgraham> | It indicates a knee in the curve before that but it's a totally different thing |
| 14:48 | <Lachy> | sure, but if the algorithm can stop as soon as it's found the encoding, then in ~80% of the cases it would stop before 512 bytes anyway, wouldn't it? |
| 14:48 | <Philip`> | and subtract from the average size of a TCP packet |
| 14:49 | <jgraham> | because the point of diminishing returns only comes when adding more bytes has a disadvantage that outweighs the advantage |
| 14:50 | <jgraham> | I would guess that having to switch the character encoding for 1 page in 5 would be rather expensive |
| 14:50 | <jgraham> | 1 page in 10 (512 bytes) might give better average performance |
| 14:50 | <jgraham> | s/512/1024/ |
| 14:52 | ap | hopes that WebKit will never have to implement that evil encoding switching thing |
| 14:52 | <Lachy> | I guess those stats from phillip are a little misleading anyway, cause they say nothing about the popularity of the sites affected. I mean, if the extra 10% of pages the get sniffed properly, are pages that virtually no-one ever looks at, then it's not really much benefit in supporting them better |
| 14:53 | <ap> | pages that only people with matching default encoding look at are also unimportant for this comparison |
| 14:54 | <jgraham> | Lachy: Actually the biggest problem with them is that they are not from a sufficiently wide range of locales. The curve could look entirely different for .jp sites wwhich are far more likely to have a non-default encoding |
| 14:54 | <Lachy> | yeah, that's also a problem |
| 14:54 | <hsivonen> | ap: whoa! what do you do instead of the evil late-switch? |
| 14:54 | <hsivonen> | ap: You'll have to implement it in order to conform unless you convince Hixie to take it out of the spec |
| 14:55 | <ap> | hsivonen: nothing - if there is no charset in http headers, <head> or 1024 bytes, we just use the default encoding |
| 14:55 | <hsivonen> | ap: that's daring |
| 14:55 | jgraham | thinks the "evil late switch" is rather good |
| 14:56 | <ap> | hsivonen: users don't complain |
| 14:56 | <Philip`> | Hmm, the most common HTTP header size seems to be around 240 bytes, and a lot are 120 to ~700 bytes, and not many are above 1000 bytes |
| 14:56 | <hsivonen> | ap: very interesting |
| 14:56 | <annevk42> | and cool |
| 14:56 | <hsivonen> | ...now that I've already toiled away implementing the evil switch |
| 14:56 | <jgraham> | priority of constituencies: it makes no sense to authors or users if moving the encoding decleration around a bit changes the behaviour |
| 14:56 | <jgraham> | Even if it is harder to implement |
| 14:56 | <ap> | hsivonen: well, I have one or two examples of sites that would benefit from this, but over the years, that amounts to "don't complain" |
| 14:57 | <hsivonen> | jgraham: with the evil switch, it makes things different if you have scripts with side effects |
| 14:57 | <annevk42> | jgraham, pages reloading is bad |
| 14:57 | <Lachy> | Philip`, is there anyway you could divide your stats up into separate graphs based on the detected encodings and/or page languages so we get a slightly better representation of different locales? |
| 14:57 | <annevk42> | jgraham, and authors can figure out what went wrong easily enough |
| 14:57 | <jgraham> | ap: Are you sure that users aren't just so used to seeing wrong character encoding that they don't complain |
| 14:58 | <jgraham> | I would never report a bug with character encoding becuase I'm so used to seeing errors |
| 14:58 | <Philip`> | Lachy: I think I don't have enough data for that to be meaningful |
| 14:58 | <ap> | jgraham: I do get bug reports about other encoding problems a plenty (less so, now that our code is more compliant) |
| 14:58 | <Lachy> | ok |
| 14:58 | <Philip`> | Lachy: and it wouldn't be trivial to do |
| 14:59 | <Philip`> | Lachy: so it's unlikely that I'll bother to do it |
| 14:59 | <hsivonen> | does IE 5.5 mode have the evil late switch? |
| 14:59 | <jgraham> | annevk42: I agree page reloading isn't that nice |
| 14:59 | <Philip`> | Lachy: (See http://philip.html5.org/data/charsets.html#usage-frequencies - there's very few that aren't utf-8 or iso-8859-1) |
| 15:00 | <hsivonen> | Philip`: your sample may be biased |
| 15:00 | <Philip`> | hsivonen: "may"? :-) |
| 15:00 | <jgraham> | hsivonen: No, his sample is biased. It is just a case of knowing what the biases are and how they are significant :) |
| 15:00 | <jgraham> | (in this case I think they are very significant) |
| 15:00 | Philip` | tried to explicitly mention the bias when mentioning the data on public-html |
| 15:01 | <Philip`> | jgraham: Why would the chosen encoding significantly affect where the author puts the encoding declaration in their page? |
| 15:02 | <Philip`> | (...assuming that's the bias you think is significant) |
| 15:03 | <ap> | Philip`: I would be interested to know not just the number of bytes necessary to read to find charset declaration, but the number of bytes outside <head> |
| 15:04 | <ap> | Philip`: WebKit encoding sniffer always looks for meta charset in <head>, even if that's huge |
| 15:04 | <jgraham> | Philip`: It is possible that languages with more bytes per character will, on avaerge, have more bytes before the encoding compared to one byte per character languages. Or less if the langauge is more compact |
| 15:04 | <hsivonen> | ap: I'm not convinced that having to track <head> is better than the evil switch |
| 15:04 | <jgraham> | Assuming that relative to the source tree, the enmcoding decleration comes in roughly the same place |
| 15:04 | <Philip`> | ap: Hmm, I don't have any data like that - I was just using the HTML5 pre-parse encoding sniffing algorithm, which ignores tags entirely (except when they're <meta>) |
| 15:05 | <Philip`> | ap: and it seems complex to try to record the location of </head> |
| 15:05 | <jgraham> | Philip`: I would be more interested in knowing how often a charset decleration comes after a <script> |
| 15:05 | <Philip`> | ap: and I'm lazy :-p |
| 15:05 | <jgraham> | But not in the first N bytes |
| 15:06 | <jgraham> | (since script side effects seem to be the major objection to the reparse) |
| 15:06 | <ap> | hsivonen, Philip`: any place in <head> used to be valid for <meta> in HTML4 |
| 15:06 | <hsivonen> | ap: HTML5 looks everywhere |
| 15:07 | <Philip`> | jgraham: Hmm, I guess the effect of multi-byte encodings would be mitigated by all the ASCII for doctypes and tag names that dominates the starts of documents, but I have no idea how much effect it would still have |
| 15:07 | <gsnedders> | So, anything interesting been happening on the lists? |
| 15:09 | <Philip`> | gsnedders: Yes |
| 15:10 | <ap> | hsivonen: as far as I can tell, it's only valid in head, no? |
| 15:10 | <hsivonen> | ap: yes |
| 15:10 | <gsnedders> | ap: yes |
| 15:11 | <annevk42> | since WebKit doesn't restrict itself to the first 1024 bytes I guess it doesn't really matter |
| 15:23 | gsnedders | is amazed at the lack of flame wars |
| 15:23 | <gsnedders> | Bikesheds are indeed being painted, but no flames. |
| 15:26 | <hsivonen> | flamelessness is good |
| 15:26 | <gsnedders> | Indeed. |
| 15:37 | <Philip`> | If the bikeshed burns down then nobody will care what colour it was |
| 15:40 | <annevk2> | gsnedders, http://krijnhoetmer.nl/irc-logs/whatwg/20070829#l-229 is at least one technorati reference |
| 15:40 | <gsnedders> | I was guessing it would be kingryan and I was trying to find stuff on the lists from him |
| 15:41 | <gsnedders> | annevk2: Should I send that to the list? |
| 15:44 | gsnedders | sends it anyway |
| 15:56 | <theMadness> | annevk2, nice blog post, you got me excited about video again. |
| 15:58 | <theMadness> | The irony, http://www.youtube.com/html5 doesn't work on Chrome. :) |
| 16:09 | <annevk42> | theMadness, yeah, it's a bit of a mess still |
| 16:09 | <annevk42> | theMadness, we'll get there :) |
| 16:14 | <theMadness> | I'm sure you will, still the irony is there :P :D |
| 16:18 | <hsivonen> | gsnedders: new HTML5 builds starting to appear: https://build.mozilla.org/tryserver-builds/hsivonen⊙mc/ |
| 16:19 | <gsnedders> | hsivonen: thx |
| 16:39 | <jgraham> | Does anyone have any idea what http://blog.typekit.com/ actualy does? |
| 16:42 | <Philip`> | No |
| 16:45 | <gsnedders> | jgraham: " Just add a line of JavaScript to your markup, tell us what fonts you want to use" |
| 16:46 | <jgraham> | gsnedders: I can already add a line of Javascript to my markup to tell you want fonts I want to use. Nothing will happen of course. |
| 16:48 | <Philip`> | http://www.flickr.com/photos/veen/3572372312/sizes/o/ - according to step 3, it involves string instruments |
| 17:14 | krijnh | starts turning evil on /irc-logs/ |
| 17:16 | <hsivonen> | what's the deal with these JS-requiring font systems when you can do it in CSS only? |
| 17:17 | <Rik|work> | hsivonen: this might be a way to DRMised them |
| 17:17 | <Philip`> | It saves people from having to copy-and-paste giant chunks of CSS that they're likely to get wrong and that will prevent the service provider from updating them |
| 17:17 | <hsivonen> | Philip`: isn't that what @import is for? |
| 17:18 | <Philip`> | hsivonen: Hmm, good point |
| 17:18 | <hsivonen> | @import has nicer parallelism properties than <script> |
| 17:19 | <Philip`> | though maybe they want the flexibility to do more client-side work (e.g. testing the UA string, verifying document.domain, etc) |
| 17:19 | <Rik|work> | hsivonen: not really |
| 17:20 | <hsivonen> | Rik|work: how do you mean? @import blocks style computation and layout but not HTML parsing. |
| 17:21 | <Rik|work> | scripts are not blocking html parsing in some browsers now |
| 17:21 | <hsivonen> | Rik|work: what browsers now do proper speculative parsing instead of just prescanning for other downloadables? |
| 17:22 | <Rik|work> | really don't know that level of details |
| 17:28 | <beowulf> | it may be a shorter way to get the weight and font you want |
| 17:29 | <beowulf> | it's a lot of css to get a font in the two formats and then set the weight |
| 17:29 | <Philip`> | It might automatically scan your page to find what characters you use that font for, so it can generate an efficient subset |
| 18:51 | <ezyang> | Sighhh... the Python implementation has 80 fails on the test-suite. As I get closer and close to full implementation, bad test cases are really going to waste my time :-( |
| 19:04 | <ezyang> | Why doesn't this work? python test_parser.py TestCase.test_tests7_7_simpletree |
| 19:11 | <Philip`> | ezyang: Feel free to fix bugs in the Python implementation ;-) |
| 19:13 | <ezyang> | Yeah, but I have to triage each failure and figure out exactly what's going on before making a call |
| 19:14 | <hsivonen> | ezyang: the tests should be mostly correct per spec except the table taint thing |
| 19:14 | <ezyang> | Ok. |
| 19:14 | <ezyang> | Is there any way to make test_parser.py run a single test? |
| 19:14 | <ezyang> | The obvious command is failing for me |
| 19:14 | <Philip`> | You could delete all the other tests, and then run it |
| 19:14 | Philip` | doesn't know of any other mechanism for that |
| 19:15 | <ezyang> | That's... not sustainable |
| 19:15 | <hsivonen> | I nkwo nothing about the Python harness |
| 19:15 | <ezyang> | kk |
| 19:15 | <hsivonen> | I make my Java harness run a single-test file first and I copy and paste the test of interest there |
| 19:15 | <ezyang> | So... what is the implementation that's closest to being correct? |
| 19:16 | <Philip`> | We did have excellent interoperability between HTML5 parsers some time last year |
| 19:16 | <hsivonen> | ezyang: I haven't evaluated wakaba's perl impl., but I believe the V.nu impl. is closer to spec than html5lib at the moment |
| 19:16 | <Philip`> | so I blame Hixie for making them all break |
| 19:16 | <ezyang> | Ok, so I should probably grab a copy of that. |
| 19:16 | <hsivonen> | ezyang: the main failure in the V.nu parser isn't visible in non-browser environments |
| 19:17 | <hsivonen> | I've been postponing fixes until I can figure out this Tp thing. |
| 19:17 | <ezyang> | not visible in non-browser environments? |
| 19:18 | <hsivonen> | ezyang: not visible in environment where scripts can't run interleaved with the parser |
| 19:18 | <ezyang> | Sorry, it's unclear to me what "visibility" means |
| 19:19 | <ezyang> | Hmm... what should JAVA_HOME be? |
| 19:19 | <hsivonen> | ezyang: the spec violation isn't detectable without a script running during the parse |
| 19:20 | <hsivonen> | ezyang: on Mac, /Library/Java/Home |
| 19:20 | <ezyang> | Ouch. |
| 19:20 | <ezyang> | (I'm on Intrepid) |
| 19:20 | <ezyang> | So... you need a JavaScript parser |
| 19:20 | <hsivonen> | ezyang: locate javac |
| 19:20 | <ezyang> | That's batty |
| 19:20 | <hsivonen> | then remove the bin/javac part |
| 19:20 | <hsivonen> | and put the prefix in JAVA_HOME |
| 19:21 | <ezyang> | Looks like I don't have javac installed |
| 19:21 | <ezyang> | Do you recommend openjdk or Sun's jdk? |
| 19:21 | <hsivonen> | openjdk |
| 19:21 | <ezyang> | So... does Java have any embedded JavaScript engines? |
| 19:22 | <ezyang> | And how are you going to deal with malicious input? |
| 19:22 | <hsivonen> | ezyang: Java does, but I haven't integrated the parser with it |
| 19:22 | <hsivonen> | ezyang: so it doesn't count as a bug in the Java version currently but it counts as a bug in the C++ version |
| 19:23 | <hsivonen> | (the bug being that the parser still clones formatting element nodes instead of creating new ones) |
| 19:23 | <hsivonen> | ezyang: /usr/lib/jvm/java-6-openjdk on Ubuntu |
| 19:24 | <hsivonen> | ezyang: if you only want the parser instead of the whole validator, it should build if you stick the dependency jars and the sources to Eclipse's default builder |
| 19:24 | <hsivonen> | (or to vanilla javac) |
| 19:25 | <ezyang> | I need the tree-building and test-suite, but I don't mind if I build the whole thing |
| 19:25 | <hsivonen> | ok |
| 19:25 | <ezyang> | In the meaantime, what's the 2nd closest to compliant implementation? |
| 19:26 | <hsivonen> | I don't know |
| 19:27 | <hsivonen> | /htmlparser/test-src/nu/validator/htmlparser/test/TokenizerTester.java and /htmlparser/test-src/nu/validator/htmlparser/test/TreeTester.java are the test harnesses |
| 19:27 | <hsivonen> | they take file paths to html5lib-format test data files as arguments |
| 19:27 | <ezyang> | Great |
| 19:27 | <ezyang> | Oh no! build fail |
| 19:28 | <ezyang> | "java.lang.ClassCastException: org.xml.sax.InputSource cannot be cast to nu.validator.xml.TypedInputSource" |
| 19:28 | <hsivonen> | ezyang: that's not a build fail. that's a run fail |
| 19:28 | <hsivonen> | ezyang: something went wrong with the schema setup |
| 19:28 | <ezyang> | well, it happened while I was running build.py! |
| 19:28 | <ezyang> | Shall I blow away my copy and try it again? |
| 19:28 | <hsivonen> | ezyang: you can ignore that and look at the parser. |
| 19:28 | <hsivonen> | it has been built by the time that error can happen |
| 19:29 | <hsivonen> | ezyang: build.py is also used for running the validator |
| 19:29 | <hsivonen> | 'all' builds it and then starts the whole thing |
| 19:31 | <ezyang> | I fail at running Java |
| 19:31 | <ezyang> | Do I just `java htmlparser/test-src/nu/validator/htmlparser/test/TokenizerTester.java`? |
| 19:31 | <hsivonen> | ezyang: no. I'll look up the incantations |
| 19:31 | <ezyang> | heh |
| 19:32 | <hsivonen> | argh. build.py doesn't build the test harnesses |
| 19:33 | <hsivonen> | hmm. I don't even remember how to do this without Eclipse with two java source dirs... |
| 19:33 | <ezyang> | I'm trying python build.py test |
| 19:33 | <hsivonen> | different 'test' |
| 19:33 | <ezyang> | Ok. |
| 19:34 | <hsivonen> | I guess it's easiest to build the tests and the parser separately |
| 19:34 | <hsivonen> | so under your checkout dir you now have jars/ |
| 19:34 | <hsivonen> | and there you have htmlparser.jar |
| 19:35 | <hsivonen> | you need to cd to htmlparser/test-src/ |
| 19:35 | <hsivonen> | and run |
| 19:38 | <hsivonen> | scratch run |
| 19:39 | <hsivonen> | you need to create a target dir, say classes as sibling to test-src |
| 19:39 | <hsivonen> | then, in test-src, run |
| 19:39 | <hsivonen> | javac -cp .:../../jars/htmlparser.jar:../../dependencies/jsontools-core-1.5.jar:../../dependencies/antlr.jar -d ../classes/ nu/validator/htmlparser/test/TreeTester.java nu/validator/htmlparser/test/TokenizerTester.java |
| 19:39 | <hsivonen> | javac is such a pain |
| 19:39 | <hsivonen> | after which you can do |
| 19:40 | <hsivonen> | java -cp .:../../jars/htmlparser.jar:../../dependencies/jsontools-core-1.5.jar:../../dependencies/antlr.jar:../classes/ nu.validator.htmlparser.test.TreeTester html5lib source files |
| 19:40 | <hsivonen> | s/source files/test files/ |
| 19:44 | <ezyang> | ../classes/nu/validator/htmlparser/test doesn't seem to exist? |
| 19:44 | <ezyang> | Also, classes already exists as a sibling to test-src |
| 19:45 | <hsivonen> | ezyang: ../classes/nu/validator/htmlparser/test should have emerged as a result of the javac... command above |
| 19:46 | <hsivonen> | ezyang: did you copy and paste from above or retype? |
| 19:47 | <ezyang> | With the first command I get: "javac: directory not found: ../classes/nu/validator/htmlparser/test/TreeTester.java" |
| 19:47 | <ezyang> | Copypasta |
| 19:48 | <hsivonen> | ezyang: there should be a space after ../classes/ |
| 19:48 | <hsivonen> | I'm guessing your terminal line wrapped just there? |
| 19:48 | <ezyang> | Yep |
| 19:49 | <ezyang> | Now I get a number of "cannot find symbol" errors |
| 19:49 | <ezyang> | Which implies that the dependencies weren't setup properly |
| 19:50 | <ezyang> | Namely, these packages don't exist: "com.ibm.icu.text.UnicodeSet" etc |
| 19:50 | <hsivonen> | hmm. I wonder why I didn't get that |
| 19:50 | <hsivonen> | to remedy |
| 19:51 | <hsivonen> | add ../../dependencies/icu4j-4_0.jar to the -cp stuff separated with colon from the other paths |
| 19:53 | <ezyang> | Second command, I get: FileNotFoundException: html5lib (No such file or directory) |
| 19:54 | <hsivonen> | ezyang: replace "html5lib source files |
| 19:54 | <hsivonen> | " with the paths of the actual html5lib tree test files |
| 19:54 | <ezyang> | haha, ok |
| 19:55 | <ezyang> | Awesome |
| 19:55 | <ezyang> | We have lift-off |
| 19:55 | <hsivonen> | great |
| 19:59 | <ezyang> | Ok, one fail in tests1.dat, which is from the fact that I just changed that |
| 19:59 | <ezyang> | Which makes me even more skeptical that my change was actually correct |
| 20:00 | <hsivonen> | was it on the topic of frameset-ok or something else? |
| 20:01 | <ezyang> | Yep |
| 20:01 | <hsivonen> | ezyang: could be bug in V.nu parser |
| 20:02 | <hsivonen> | ezyang: I didn't implement frameset-ok as a flag but as a mode |
| 20:02 | <ezyang> | Hmm... yeah, that'd probalby do it |
| 20:02 | <hsivonen> | I may have goofed in my tranformation of the algorithm |
| 20:02 | <ezyang> | *probably |
| 20:02 | <ezyang> | Because frameset-ok doesn't really make sense as a mode |
| 20:03 | <hsivonen> | oh? |
| 20:03 | <ezyang> | I mean, there are a lot of places it can get set |
| 20:04 | <ezyang> | And you can very easily go back to a previous mode, but have the frameset ok be the only thing that's different |
| 20:04 | <ezyang> | It's not obvious to me, without recopying all of the modes, how a mode frameset-ok would work |
| 20:05 | <hsivonen> | ezyang: except for frameset itself, it either just forwards to 'in body' or sets the mode to 'in body' and then moves on to 'in body' |
| 20:06 | <hsivonen> | It's past 22:00 here. I should head home. |
| 20:08 | <ezyang> | cya |
| 20:08 | <hsivonen> | later |
| 20:36 | ezyang | is awesome (fixed Python bug by changing func.__name__) |
| 20:56 | <Hixie> | http://www.grabup.com/uploads/240ccede5360b093dbf298f8946025a5.png is fantastic |
| 20:56 | <Hixie> | (notice the lower third text) |
| 20:57 | <ezyang> | Hahahahha |
| 20:58 | <gsnedders> | Uh, OK. |
| 20:58 | <gsnedders> | Hixie: Can I email you suggestion for Acid4? |
| 20:59 | <gsnedders> | Or is there no point? |
| 21:00 | <mgrdcm> | FOX Business Channel: Most popular newspaper after The Tribune Company and Amazon's Kindle. |
| 21:00 | <Hixie> | gsnedders: no point yet |
| 21:18 | <jgraham> | ezyang: BTW the python svgmathml branch is likely more spec compliant than the trunk |
| 21:19 | <ezyang> | jgraham: Oh really? |
| 21:19 | <jgraham> | Although I think it doen't have the latest AAA changes |
| 21:19 | <ezyang> | Is this, beyond just the foreign content tests? |
| 21:19 | <jgraham> | ezyang: Yeah, I did a bunch of work on that branch bu I haven't finished the tedious task of converting all the treewalker stuff to deal with namespaces |
| 21:20 | <jgraham> | So I haven't merged |
| 21:20 | <jgraham> | (actually I haven't merged because the merge was non-trivial) |
| 21:20 | <jgraham> | (so I should make some time and stop being such a crappy maintainer) |
| 21:29 | <annevk42> | anything known yet about Google and video? |
| 21:33 | <annevk42> | http://twitter.com/jdowdell/statuses/1950818992 -- "Reporters who say "the HTML 5 standard" instead of "the WhatWG's RIA proposals for hypertext markup" or such are misleading their readers." |
| 21:34 | <gsnedders> | RIA? |
| 21:35 | <annevk42> | Did people see: http://blog.typekit.com/2009/05/27/introducing-typekit/ (Especially interesting for those who talked about business models for Web fonts.) |
| 21:36 | <jgraham> | I love that Adobe are doing their best o promote HTML5 |
| 21:36 | <jgraham> | annevk42: See my comment from 5 hours ago |
| 21:39 | <Philip`> | gsnedders: Rich internet applications? |
| 21:39 | <jgraham> | annevk42: You should maybe point out to Roy that Opera shipd to a bunch of non-desktop devices |
| 21:40 | <jgraham> | And AFAIK we have the same requirements for all of them |
| 21:41 | <annevk42> | Which email is that? |
| 21:41 | <annevk42> | I might have deleted it already... |
| 21:43 | <jgraham> | annevk42: http://lists.w3.org/Archives/Public/public-html/2009May/0547.html |
| 21:44 | <annevk42> | I do have that one, but I don't see where he's suggesting we don't |
| 21:44 | <annevk42> | and the words desktop or device are not in it |
| 21:44 | <jgraham> | annevk42: He suggests that different devices require different error handling |
| 21:45 | <ezyang> | Oh, it's Roy T. Fielding |
| 21:45 | <ezyang> | He rejected my patch to Apache :-( |
| 21:45 | <annevk42> | jgraham, seems to be mostly about different types of applications |
| 21:45 | <jgraham> | annevk42: I think he is vastly overstating the number of different conformance classes |
| 21:46 | <jgraham> | annevk42: If we can sell Opera for fridges I guess we would want the same error handling requirements |
| 21:46 | <jgraham> | (similarly if it was Webkit or Gecko on the fridge of course) |
| 21:47 | <annevk42> | He's being very vague, I would say. It would help me much more if he explained more about what kind of HTML he expects these fridges/switches/etc. to consume/output and why it needs to be different from Web browsers. |
| 21:47 | <hsivonen> | Hixie: well, over here, the Web censor policeman said that Google is a browser... |
| 21:49 | jgraham | wonders if he should reply to Shelley |
| 21:49 | <hsivonen> | Hixie: when asked why he doesn't poison the DNS record for google. |
| 21:51 | <annevk42> | reminds me of http://www.youtube.com/watch?v=MunMCO3uNdA |
| 21:52 | gsnedders | stabs CSS |
| 21:53 | <Philip`> | jgraham: Depends on whether your reply would cause progress in productive areas of work, I guess :-) |
| 21:54 | <gsnedders> | There has _got_ to be a nicer way to do this than CSS tables |
| 21:55 | <jgraham> | Philip`: Yeah. I'm not sure what the best way to cause progress is |
| 21:57 | <Philip`> | gsnedders: <table> |
| 21:58 | <gsnedders> | Philip`: It isn't a table |
| 21:58 | <Philip`> | gsnedders: Presumably you're doing something layout-related, and therefore <table> is a very effective solution |
| 21:59 | beowulf | burns Philip` with fire for saying such a thing |
| 22:00 | <jgraham> | As opposed to burning him with acid I guess |
| 22:01 | <Hixie> | christ almighty. 46 messages from backtype and google alerts about "html5" |
| 22:01 | <beowulf> | well, that would be taking things to far |
| 22:02 | <annevk2> | everytime I look at twitter after a few hours there's like 400+ html5/html 5 messages |
| 22:02 | <annevk2> | not really following that anymore :) |
| 22:02 | <ezyang> | You need a "State of the HTML 5" report :-) |
| 22:03 | <Hixie> | that's mpilgrim's job :-P |
| 22:03 | <hsivonen> | annevk2: still not a "trending topic", though |
| 22:03 | <hsivonen> | (it seems that twitter is confusing 'trend' and 'fad') |
| 22:04 | <Hixie> | dear lord, i just got my first google alert for a 4chan post |
| 22:07 | <gsnedders> | Can I table row not have padding!? |
| 22:08 | <ezyang> | cell-spacing:0? |
| 22:08 | <ezyang> | erm, border-spacing |
| 22:08 | <Hixie> | gsnedders: what would it mean for a row to have padding? |
| 22:08 | <gsnedders> | Hixie: The same as anything else? What's so hard about it? |
| 22:09 | <ezyang> | Anyone know what version of simplejson I need in order to make the Python tokenizer not die? |
| 22:09 | <Hixie> | gsnedders: the row doesn't exist as a rendered construct. |
| 22:09 | <ezyang> | *tokenizer test |
| 22:09 | <gsnedders> | Hixie: Ah |
| 22:09 | <Hixie> | gsnedders: what would you do if you had three rows with different padding? what would it look like? |
| 22:09 | <gsnedders> | Hixie: That does make things more complex :) |
| 22:10 | <gsnedders> | CSS 2.1 references a "column element". What's that? |
| 22:11 | <gsnedders> | display: table-column? |
| 22:11 | <Hixie> | gsnedders: dunno, ask csswg :-) |
| 22:12 | <gsnedders> | Hixie: Hey, you're listed as an editor, for all little that's worth! :P |
| 22:12 | <Hixie> | i was hoping you wouldn't notice :-P |
| 22:13 | <ezyang> | Same goes for the ruby tokenizer tests. ARRGH |
| 22:14 | gsnedders | realizes what it all means |
| 22:14 | <gsnedders> | It just omits the table- everywhere there |
| 22:15 | <jgraham> | ezyang: I noticed the simplejson problem too :( |
| 22:15 | <jgraham> | I think it is just one set of tests that you can disable though |
| 22:15 | <ezyang> | Ok, so maybe there was an incompatible "fix" that upstream made |
| 22:16 | <jgraham> | ezyang: Yeah, they made it much more strict with character encodings |
| 22:16 | <ezyang> | JSON is such a bad format, really, since it only supports Unicode |
| 22:16 | <jgraham> | It's a bad choice for testing lone surrogates and similar things |
| 22:17 | <ezyang> | Well, I suppose I can get rid of the offending tests, pending a new test format |
| 22:19 | <ezyang> | Aweomse, only unicode characters test. |
| 22:19 | <ezyang> | ... needs to be removed |
| 22:20 | <Hixie> | wow, i just read larry's latest e-mail. he actually just totally backed down from his earlier opinions and now agrees with the position that html5 should apply to all html user agents and authors! awesome! |
| 22:20 | <jgraham> | ezyang: It would be awesome if you converted it to the same format as the tree construction tests |
| 22:20 | <jgraham> | (roughly) |
| 22:20 | <jgraham> | Like |
| 22:20 | <jgraham> | #input |
| 22:21 | <ezyang> | That might not be too difficult |
| 22:21 | <jgraham> | some data |
| 22:21 | <jgraham> | #output |
| 22:21 | <jgraham> | some tokens |
| 22:21 | <ezyang> | But in interest of not needing a binary editor, we probably want to keep them escaped |
| 22:21 | <roc> | do we know any more about Google's video story yet? |
| 22:21 | <ezyang> | (PHP's JSON parser is really lenient) |
| 22:22 | <ezyang> | We'd also need a token format |
| 22:24 | <ezyang> | gsnedders: what bugs in PHP's tokenizers were you dealing with? |
| 22:24 | <gsnedders> | Is http://svenellingen.com/stream a table? |
| 22:24 | <gsnedders> | ezyang: The failing test cases |
| 22:24 | <ezyang> | All of them? |
| 22:24 | <gsnedders> | ezyang: There are only two bugs :P |
| 22:24 | <gsnedders> | (Actually, three) |
| 22:24 | <ezyang> | Huh. I have 15 failures |
| 22:24 | <gsnedders> | I have 10 when I last ran |
| 22:24 | <jgraham> | ezyang: The json-like format is good enough |
| 22:25 | <jgraham> | for the output format |
| 22:25 | <jgraham> | unless yu want something easier to parse |
| 22:25 | <gsnedders> | ezyang: I get 10. |
| 22:26 | <ezyang> | Let me push |
| 22:26 | <ezyang> | (although that shouldn't make a difference) |
| 22:26 | <ezyang> | Ok, you should pull |
| 22:26 | <ezyang> | It's very possible that you've fixed a bunch |
| 22:26 | <ezyang> | And forgot to push your changes |
| 22:26 | <gsnedders> | There are ten failures on trunk. |
| 22:27 | <gsnedders> | I haven't touched it in days, everything is pushed. |
| 22:27 | <ezyang> | Hmmm... |
| 22:27 | <ezyang> | What version of PHP are you using? |
| 22:27 | <gsnedders> | Pastebin them |
| 22:27 | <gsnedders> | 5.2.9 |
| 22:27 | <ezyang> | Ok. Old version of PHP = more errors. |
| 22:28 | <ezyang> | With 5.2.9 I get 10 |
| 22:28 | <ezyang> | This is a bug, btw |
| 22:28 | <gsnedders> | Indeed. |
| 22:28 | <gsnedders> | Right now I'm more concerned with getting it working at least locally :P |
| 22:29 | <ezyang> | Sure, but it's easier to deal with cross-version bugs as quickly as possible |
| 22:29 | <ezyang> | I've had to deal with it in HTML Purifier, and they're nasty little buggers |
| 22:29 | <ezyang> | (anyway, that's 11 worth of more passing test-cases for TreeBuilder.php) |
| 22:29 | gsnedders | keeps on hitting bugs that crash PHP |
| 22:29 | <ezyang> | Oh? |
| 22:30 | <ezyang> | As in, segfault? |
| 22:30 | <gsnedders> | Not with html5lib, though |
| 22:30 | <gsnedders> | yeah |
| 22:30 | <ezyang> | Get a core dump and complain to the devs |
| 22:30 | <gsnedders> | That doesn't help when you need to support current releases of PHP |
| 22:31 | <ezyang> | Usually, doing some unset()s or superstitious function calls makes the crash go away :-) |
| 22:31 | <gsnedders> | Oh, here's a fun crash: |
| 22:31 | <olliej> | Philip`: weeee - http://nerget.com/pressure/pressure.html |
| 22:31 | <gsnedders> | curl_version() in some setups crashes PHP. |
| 22:31 | <gsnedders> | Just calling it at all crashes PHP. |
| 22:31 | <ezyang> | Oh. |
| 22:31 | <gsnedders> | It's great fun. :\ |
| 22:32 | <ezyang> | Well, that's no good |
| 22:32 | <gsnedders> | IIRC it's fixed now. |
| 22:32 | <olliej> | Philip`: its complete absence of html5 validation will make Hixie cry |
| 22:32 | <gsnedders> | But that is when I got to the point of just saying to users, "If the PHP devs can't create an interpreter that doesn't crash, it's not my problem." |
| 22:33 | <ezyang> | I disagree. |
| 22:33 | <ezyang> | But it depends on how much you care about your users. |
| 22:33 | <ezyang> | If you want the best experience possible, it is very much *your* problem. With open-source, you don't have to care to that level. |
| 22:33 | <gsnedders> | It had got to the point that the majority of bug fixes were working around interpreter bugs. |
| 22:34 | <gsnedders> | And that's when I just give up on the interpreter :P |
| 22:34 | <ezyang> | What the heck were you doing? |
| 22:34 | <gsnedders> | Nothing much. |
| 22:34 | <ezyang> | I've only needed to do about two dozen interpreter fixes |
| 22:35 | <Philip`> | olliej: It's a bit slow in my browsers :-( |
| 22:35 | gsnedders | goes back to his Python wunderland where he's never had to work around interpreter bugs :P |
| 22:36 | <ezyang> | Oh, I've had to work around python bugs too. |
| 22:36 | <ezyang> | They're pretty spectacular |
| 22:36 | <ezyang> | One would go away when I added a print statement |
| 22:36 | <Philip`> | olliej: but kind of neat :-) |
| 22:36 | <olliej> | Philip`: really? |
| 22:36 | <olliej> | what machine are you on? |
| 22:36 | <ezyang> | One would only happen of there was a pyc file, but not when it was missing |
| 22:37 | <Hixie> | so is www.w3.org down for anyone else? |
| 22:37 | <ezyang> | Works for me |
| 22:37 | jgraham | only remembers one python interpreter bug |
| 22:37 | <Philip`> | Hixie: http://downforeveryoneorjustme.com/www.w3.org |
| 22:37 | <jgraham> | (.iteritems() and .items() produced different results) |
| 22:37 | <Hixie> | well bummer |
| 22:38 | <ezyang> | jgraham: Haha. That sounds excellent |
| 22:38 | <gsnedders> | jgraham: They're meant to. |
| 22:38 | <ezyang> | Anyway, afk, for a bit |
| 22:38 | <gsnedders> | jgraham: One produces an iterator and the other a list :P |
| 22:38 | <jgraham> | gsnedders: I was waiting for you to say that |
| 22:39 | <Philip`> | olliej: A not particularly slow one, but one that's running old (i.e. released) versions of Opera and Firefox rather than a proper browser :-p |
| 22:39 | <olliej> | Philip`: try a firefox nightly |
| 22:39 | <jgraham> | olliej: That's cool |
| 22:39 | <olliej> | Philip`: they do much much better |
| 22:39 | <gsnedders> | I'm like Romeo and Juliet: everything after the prologue is inevitable, fate will have its course, no matter what I try. |
| 22:39 | <olliej> | Philip`: or a recent webkit build |
| 22:40 | jgraham | was getting about 1500ms/frame with three sources and quite a complex velocity field |
| 22:41 | <olliej> | jgraham: the performance is entirely dependent on overall resolution |
| 22:41 | <gsnedders> | olliej: You've changed it! |
| 22:41 | <gsnedders> | It had a white background before! |
| 22:41 | <olliej> | jgraham: number of sources is actually irrelevant |
| 22:42 | <olliej> | gsnedders: i've also improved performance a bit by assuming that there's always 0 diffusion |
| 22:42 | <jgraham> | olliej: That makes sense I guess since it presumably does the same number of calculations in any case |
| 22:42 | <olliej> | jgraham: yup |
| 22:42 | <olliej> | jgraham: the only reason webkit trunk and firefox start off slightly faster is because initially there are no gc allocated numbers |
| 22:43 | <jgraham> | (although fewer source terms would cut down a bit and you could theoretically see some difference if he canvas doesn't have to change colour I assume) |
| 22:43 | Philip` | wonders if it'd be possible to optimise it by doing the big calculations via <canvas> compositing |
| 22:43 | <olliej> | jgraham: and the number of gc numbers (and hence gc pressure) gradually increases until there are no longer any 0s |
| 22:43 | <Philip`> | olliej: Seems a bit better in some kind of Firefox 3.5, but it's still ~200ms per frame |
| 22:44 | <olliej> | Philip`: depending on resolution my measurements show either webkit-proper or chrome to be faster |
| 22:44 | <gsnedders> | olliej: So WebKit-proper or WebKit-fake? :P |
| 22:44 | <olliej> | Philip`: largely because jsc still has a stupid gc |
| 22:45 | <olliej> | gsnedders: webkit-proper and webkit-with-an-unnecessarily-replaced-js-engine |
| 22:45 | <Philip`> | olliej: I'd be more able to test that if there was a decent WebKit-based browser on Linux |
| 22:45 | <olliej> | Philip`: epiphany? |
| 22:45 | <olliej> | Philip`: apparently it works |
| 22:49 | <gsnedders> | Is onclick fired on an element and all its parents? |
| 22:49 | <gsnedders> | In what order? |
| 22:50 | <ezyang> | ooh, there's a really good quirks mode article on that |
| 22:50 | <roc> | onclick is fired on one element |
| 22:50 | <roc> | it bubbles up through its ancestors |
| 22:50 | <ezyang> | http://www.quirksmode.org/js/events_order.html |
| 22:50 | gsnedders | needs to learn about DOM Events, badly |
| 22:50 | <jgraham> | Philip`: chromium nightlies or the webkittestgtk thing? |
| 22:51 | <olliej> | Philip`: epiphany-webkit i mean |
| 22:52 | <roc> | video question... The spec says "When the current playback position reaches the end of the media resource when the direction of playback is forwards, then the user agent must follow these steps:" |
| 22:53 | <roc> | does "reaches the end of the media resource" include reaching the end due to seeking? |
| 22:55 | <Hixie> | yes |
| 22:56 | <Philip`> | Hmm, Chromium seems to be the only thing that's trivially available on Gentoo, but it complains "version `GLIBCXX_3.4.9' not found (required by ./chrome)" :-( |
| 22:56 | <gsnedders> | Hmm, I need to disable an onclick event when a click on an interactive element triggers it |
| 22:57 | <Hixie> | it's so funny seeing jd defend flash everywhere |
| 22:58 | <Philip`> | Oh, right, it works fine if I change LD_LIBRARY_PATH to point to gcc-4.3.2, so that's okay |
| 22:58 | <Hixie> | i think the fact that so many people are so happy to hear they might be able to get rid of flash pretty much sums up how frustrating his job must be |
| 22:58 | gsnedders | wonders how to do this |
| 22:59 | <Philip`> | olliej: Ooh, it's very fast in Chromium, except I don't know how fast because it doesn't render any of the text saying how fast it is |
| 23:00 | <gsnedders> | Is there any way to tell if something has a default action? |
| 23:00 | <Hixie> | i'm also amused by the people trying to get Microsoft to admit to working on <canvas> |
| 23:00 | <Hixie> | how about getting them to admit to working on DOM2 Events or something more fundamental like that first? :-) |
| 23:01 | <roc> | Hixie: thanks |
| 23:01 | gsnedders | has a strong disdain for DOM Events… |
| 23:02 | <roc> | where are people trying to get Microsoft to admit to stuff? |
| 23:02 | <olliej> | Philip`: oddly it's faster in webkit trunk, which shouldn't happen -- i assume mac chrome has some perf hit i'm unaware of |
| 23:02 | <olliej> | thy used to be on par |
| 23:05 | <olliej> | Philip`: hehehe |
| 23:05 | <olliej> | Philip`: performance characteristics of our gc |
| 23:06 | <olliej> | Philip`: starts at 30ms a frame, becomes 100ms once all the zeros go away |
| 23:13 | <gsnedders> | http://codingforums.com/showthread.php?p=821898#post821898 |
| 23:41 | <Hixie> | roc: e.g. http://processingjs.org/blog/?p=77 |
| 23:44 | <roc> | ta |
| 23:45 | <Philip`> | Seems to be quite a bit of wishful thinking in how they interpret the Microsoft people's responses |
| 23:51 | jwalden | concurs |
| 23:53 | <hober> | http://www.w3.org/QA/2009/05/_watching_the_google_io.html |
