| 00:05 | <Lachy> | I restructured and added more use cases to http://wiki.whatwg.org/wiki/Video_accessibility |
| 00:15 | <Lachy> | http://gizmodo.com/5048298/large-hadron-collider-has-black-hole-button :-) |
| 02:34 | <GregHouston> | Does anyone know if Microsoft has an IRC server, and specifically an Internet Explorer channel? |
| 07:29 | <Hixie> | GregHouston: if you find out, please let us know! |
| 07:29 | <GregHouston> | Haha |
| 08:11 | <hsivonen> | anyone planning to point out on www-tag that html5 already allows uri-lookinh strings in rel? |
| 09:20 | <annevk> | ooh, pete is not using the alt attribute in his fronteers presentation |
| 09:21 | <annevk> | also, IE still has DOM storage extensions |
| 09:21 | <annevk> | also, they are suggesting to simply set <meta> to IE7 if you think it's too much effort |
| 09:22 | <othermaciej> | did they at least prefix their extensions? |
| 09:22 | <Hixie> | of course not. they only prefix the extensions that they don't need to prefix. |
| 09:22 | <annevk> | the presentation was not clear |
| 09:23 | <annevk> | it was also not clear whether their implementation is still asynchronous |
| 09:23 | <annevk> | as it was in IE8 beta 1 |
| 09:24 | <hsivonen> | what presentation are you referring to? |
| 09:24 | <svl> | hsivonen: fronteers2008 (dutch front-end conference) |
| 09:24 | <othermaciej> | time for a Return of Embrace Extend Extinguish blogstorm? |
| 09:25 | <hsivonen> | svl: thanks |
| 09:26 | <annevk> | http://search.twitter.com/search?q=html5 2022 is complained about |
| 09:26 | <annevk> | http://twitter.com/worksology/statuses/918380010 is funny |
| 09:27 | <hsivonen> | Hixie: are rel tokens case-sensitive? |
| 09:28 | <hsivonen> | annevk: HTML5 and the LHC have different network effect considerations |
| 09:28 | <Hixie> | annevk: it would be a fair comparison if there had been two LHCs built and the goal was to have them act exactly the same in every testable respect... |
| 09:28 | <hsivonen> | colliders don't need to interoperate technically |
| 09:28 | <hsivonen> | (although we assume that laws of physics are consistent in CERN and in the North American collider) |
| 09:29 | <annevk> | Hixie, yeah |
| 09:29 | <annevk> | but it's still funny |
| 09:29 | <annevk> | and prolly reflects how most people think about it |
| 09:29 | <hsivonen> | the JS on http://hasthelargehadroncolliderdestroyedtheworldyet.com/ is funny |
| 09:29 | <Hixie> | hsivonen: it's case insensitive, but the spec doesn't appear to say that |
| 09:29 | <annevk> | hsivonen, they probably should be, although HTML5 doesn't say so |
| 09:29 | <hsivonen> | thanks |
| 09:29 | <annevk> | e.g. rel=STYLESHEET |
| 09:30 | <Hixie> | annevk: well luckily i don't really mind how people think about it :-) |
| 09:30 | <Hixie> | the 2022 date has actually worked pretty well to filter out the people who don't read |
| 09:30 | <annevk> | I rather have these people paying attention and use <canvas> then switch to Flash |
| 09:31 | <Hixie> | if people are considering flash, canvas isn't going to solve their needs |
| 09:34 | <hsivonen> | SVG-in-text/html with an IDE might, though |
| 09:38 | <Hixie> | well for that they'll likely have to wait til 2022 too, the way things are going |
| 09:38 | <annevk2> | grr |
| 09:39 | <annevk2> | i actually forgot about that feature yesterday, but it's not that interesting either yet |
| 09:40 | <doublec> | canvas works well for a lot of things that flash is probably used for (simple games, applets, ads, etc) |
| 09:41 | <doublec> | my js 8080 emulator uses canvas for the display and it runs good on firefox and webkit nightlies |
| 09:41 | <doublec> | just |
| 09:42 | <hsivonen> | Hixie: are you suggesting that a vast Google/Apple conspiracy isn't resulting in Flash-killer GWT features within a couple of years? |
| 09:43 | <Hixie> | i'm suggesting IE won't support SVG in a couple of years |
| 09:44 | <Lachy> | http://www.eweek.com/c/a/Application-Development/Douglas-Crockford-I-Want-a-Browser-War/?kc=EWKNLINF09102008STR1 |
| 09:44 | <othermaciej> | the rumors of a Google/Apple conspiracy are gratly exaggerated |
| 10:21 | <annevk> | what is the %%%% business? |
| 10:22 | <annevk> | new feature? |
| 10:22 | <annevk> | (for data: POST) |
| 10:22 | <annevk> | lol: http://ishtml5readyyet.com/ |
| 10:22 | <Hixie> | annevk: no, just porting wf2 over |
| 10:23 | <annevk> | oh ok |
| 10:23 | <Hixie> | http://ishtml5readyyet.com/ misses the point pretty spectacularily :-) |
| 10:23 | <Hixie> | by that definition, the Web isn't ready yet |
| 10:23 | <annevk> | hehe |
| 10:23 | Dashiva | goes to register isthewebreadyyet.com |
| 10:25 | <othermaciej> | doihaveevenasemblanceofaclue.com |
| 10:53 | <Philip`> | http://bholley.wordpress.com/2008/09/12/so-many-colors/ - I'm much more comfortable when the world is just RGB 0-255 and you can fiddle with your monitor's gamma settings until it looks right - things are getting too complicated now :-( |
| 10:58 | <zcorpan_> | http://micycle.wordpress.com/2008/09/11/why-ian-hickson-is-wrong-about-br-and-p-tags/ |
| 11:00 | Philip` | presumes that person is also in favour of editors inserting <i> instead of <em> when users hit the 'italics' button |
| 11:01 | <Philip`> | so at least HTML5 goes most of the way towards what they want |
| 11:03 | <zcorpan_> | considering that wysiwygs insert <br>s for linebreaks and users type generally type two line breaks when they want a paragraph break, should html5 define two or more subsequent <br>s as meaning a paragraph break? |
| 11:03 | <Philip`> | Seems better for editors to translate two <br>s into <p> |
| 11:03 | <Lachy> | zcorpan_, no. Two <br>s for a paragraph is a bad practice that should be discouraged |
| 11:03 | <Hixie> | i think i hate forms. |
| 11:03 | <zcorpan_> | but that's really hard when you have lists too and you're not working with html syntax |
| 11:04 | <zcorpan_> | and you're implementation is regexp |
| 11:04 | <zcorpan_> | Lachy: that wasn't my question though |
| 11:04 | <Philip`> | s/<br>\s*<br>/<p>/ - that wasn't hard :-p |
| 11:04 | <Hixie> | i guess tomorrow i get to specify accept-charset |
| 11:04 | <Lachy> | inserting a <p> for Enter, and <br> for Shift+Enter is acceptable, and is what MS Word does by default |
| 11:05 | <Lachy> | (although MS Word also sets the default paragraph margins to 0, so the effect not very noticable by default( |
| 11:05 | <zcorpan_> | Philip`: i guess it would work with the new rules where <ul><li>foo<p>bar</li> is allowed |
| 11:06 | <Lachy> | oh, yeah, defining that <br><br> should be treated as a paragraph break is acceptable, but shouldn't be considered conforming |
| 11:06 | Philip` | remembers originally learning that <p> was a paragraph break (like how <br> is a line break), rather than a paragraph wrapper (like <div>) |
| 11:07 | <Hixie> | that was originally true |
| 11:07 | <Philip`> | I don't think it was true when I was learning HTML, but maybe the books were just old rather than wrong |
| 11:08 | <zcorpan_> | Lachy: do you think it's useful to replace two linebreaks with <p> in wysiwyg editors? |
| 11:08 | <Lachy> | yes |
| 11:08 | <zcorpan_> | Lachy: why? |
| 11:09 | <Lachy> | because most of the time when people type 2 line breaks, they mean a new paragraph |
| 11:09 | <zcorpan_> | Lachy: so if <br><br> is defined equivalent to <p>, why bother? |
| 11:09 | <Lachy> | and typographically, the spacing between 2 paragraphs separated by 2 <br> is too much |
| 11:09 | <Philip`> | Even HTML 2.0 says <p> is non-void |
| 11:10 | <Philip`> | (but draft-ietf-iiir-html-01 say it's void, or empty or whatever the term is) |
| 11:11 | <Lachy> | Philip`, that's because HTML2 was made more compatible with the SGML approach. It's the non-specced HTML1 that TBL originally created which used <p> like a break |
| 11:13 | <Philip`> | Hmm, my earliest site just used <br> everywhere |
| 11:13 | <Philip`> | I think I didn't use <p> because I just didn't understand the point, when it was like <br> but wasted more screen space |
| 11:15 | <Hixie> | nn |
| 11:18 | <BenMillard> | zcorpan_, inferring paragraph semantics from <br><br> is something I've considered. |
| 11:19 | <BenMillard> | as Lachy points out, Return, Return doesn't always produce <br> in editing tools throughout the desktop |
| 11:20 | <BenMillard> | <p> elements allow better control of styling with CSS |
| 11:20 | <BenMillard> | I've worked with sites where the content had <br><br> and they wanted to redesign their content styles but found it hard because they weren't using <p> |
| 11:21 | <BenMillard> | AFAIK, the larger screenreaders already infer that two line breaks = a paragraph |
| 11:22 | <Philip`> | Do they do anything to indicate the presence of single line breaks? |
| 11:22 | <Lachy> | personally, I find reading blogs on blogger generally quite difficult because they insist on using only, when the WYSIWYG editor is used. It's really quite irritating having too much spacing between paragraphs |
| 11:22 | <Lachy> | *only <br> |
| 11:23 | <hsivonen> | zcorpan_: at least the old Gecko behavior of inserting br for return and paragraph break for two return sucked really, really badly |
| 11:23 | <BenMillard> | Philip`, I don't know. I've heard of them having a "next line" command but I don't know how that works. |
| 11:24 | <BenMillard> | hsivonen, that actually sounds reasonable to me...what made it so bad? |
| 11:24 | <roc> | WYSIWYG editing of structured documents is Hard |
| 11:25 | <hsivonen> | BenMillard: it was counter-intuitive, non-obvious, unreliable and incompatible with IE |
| 11:25 | <roc> | a basic problem is that when the user pressed a character key, the rendering must change. anything else is a bug |
| 11:26 | <hsivonen> | If we want to have a format that has paragraphs on the format level, we need to rub this fact in the faces of users by making return break a paragraph *and* by having non-zero paragraph margins by default |
| 11:26 | <BenMillard> | hsivonen, I know my dad uses a single return in e-mails when he starts a new paragraph. |
| 11:26 | <BenMillard> | my mum used to do the same thing but now she's been on internet forums for a while, she uses two line breaks everywhere. |
| 11:27 | <roc> | figuring out what the right or minimal thing to insert into the DOM to achieve an appropriate rendering change, in all possible situations, is really tough |
| 11:27 | <BenMillard> | having said that, an ex-girlfriend used to put song lyrics on her blog without <blockquote> and used single return between lines and 2 returns between versus... |
| 11:27 | <roc> | and even if you achieve it, it leads to unpredictable behaviour |
| 11:27 | virtuelv | really just wishes everyone could write Markdown instead |
| 11:28 | <virtuelv> | (In markdown, two trailing spaces+enter = <br> and enter = <p> |
| 11:28 | Philip` | wishes everyone just wrote text/plain |
| 11:28 | <virtuelv> | Philip`: markdown is mostly text/plain |
| 11:28 | <Philip`> | Eww, trailing spaces? |
| 11:29 | Philip` | tends to automatically delete trailing spaces whenever he sees them, because they're ugly |
| 11:29 | <doublec> | Hixie: in the audio portion of the spec, at the end of 4.7.8.0 it mentions "If the src argument is present..." but the example given calls it the argument 'url' |
| 11:29 | <virtuelv> | Philip`: yes, because the assumption is that even though you, for writing purposes, might wish to hard-wrap your plaintext file, you don't wish to get <br> in your transform to HTML |
| 11:29 | <BenMillard> | roc, I think you're right in saying it's a difficult problem. :) |
| 11:31 | <BenMillard> | zcorpan_, I think it's useful for WYSIWYG to produce <p> given the styling problems I've seen when websites redesigned...quite how it gets there is hard. and it's probably sensible to infer paragraph semantics from <br><br> |
| 13:33 | <hsivonen> | show source fixed on http://html5.validator.nu/?doc=http%3A%2F%2Fwww.geocities.co.jp%2FHollywood-Spotlight%2F2135%2F&showsource=yes#cl3c41 thanks |
| 13:33 | <hsivonen> | (whew that one has hard to track down although trivial at the end) |
| 13:35 | <zcorpan_> | hsivonen: what was the problem? |
| 13:36 | <hsivonen> | the first problem was that the byte level counted lines and columns according to SAX tradition |
| 13:36 | <hsivonen> | the second problem was that it started from the whole offset when there were more than one bad byte per buffer |
| 13:37 | <hsivonen> | the third problem was that I was trying to sync these using standard SAX line/col getters instead of specilized internal getters |
| 13:53 | <hsivonen> | I turned heuristic sniffing on in the validation facet |
| 13:55 | <zcorpan_> | hsivonen: what's heuristic sniffing? |
| 13:57 | <hsivonen> | zcorpan_: it tries to user jchardet and ICU4J heuristic sniffer to detect the character encoding statistically if there is no encoding decl on the HTTP layer on inside the first 512 bytes |
| 13:58 | <Philip`> | Do browers ever look at the domain name as an extra hint to their heuristics? |
| 13:59 | <hsivonen> | never heard of them doing it |
| 14:00 | <hsivonen> | anyway, the sniffer should reduce noise when validating badly authored CJK pages |
| 14:00 | <zcorpan_> | hsivonen: can it be sniffed to be something ascii-incompatible? |
| 14:00 | <hsivonen> | zcorpan_: no |
| 14:00 | <hsivonen> | all the previous problems with mislabeled UTF-16 remain |
| 14:01 | <zcorpan_> | hsivonen: ok. what happens if you find a real <meta> after the sniffer has decided on a particular encoding? |
| 14:01 | <zcorpan_> | hsivonen: or is that fatal anyway? |
| 14:01 | <hsivonen> | zcorpan_: if the later meta declares a different encoding, the result is still fatal |
| 14:02 | <zcorpan_> | the sniffer only looks at the first 512 bytes? |
| 14:02 | <hsivonen> | right |
| 14:02 | <hsivonen> | surprisingly, that seems to be quite enough |
| 14:09 | <zcorpan_> | hsivonen: do you have a URL handy where the sniffer makes a difference? |
| 14:11 | <hsivonen> | zcorpan_: http://html5.validator.nu/?doc=http%3A%2F%2Fwww.geocities.co.jp%2FHollywood-Spotlight%2F2135%2F&showsource=yes |
| 14:13 | <Philip`> | hsivonen: Error 65 ("Element font not allowed as child of element html in this context") says |
| 14:13 | <Philip`> | At line 139, column 8 |
| 14:13 | <Philip`> | r>↩</body>↩</html |
| 14:14 | <Philip`> | but clicking the location marker doesn't work |
| 14:15 | <Philip`> | (Also I don't see a font element there) |
| 14:19 | <hsivonen> | Philip`: whoa! that's crazy |
| 14:19 | <hsivonen> | Philip`: thanks |
| 14:20 | <hsivonen> | real-world fuzzing strikes again |
| 14:20 | <hsivonen> | how can I get Google Groups to pick up my non-⊙gc From address from Gmail? |
| 14:21 | <Philip`> | It's not really fuzzing, it's just basic testing :-p |
| 14:21 | <Philip`> | If someone generated millions of random pages and checked for errors, that'd be fuzzing; but I'm just picking a random URL and trying it and finding all these errors ;-) |
| 14:22 | <hsivonen> | Philip`: the set of URLs you are picking from does have random weird stuff though |
| 14:24 | <hallvors> | Philip`: I think Opera uses TLD as one of the factors for charset detection, but it's not a topic I know much about and I haven't checked if I'm right. UI language is also used. |
| 14:32 | <Philip`> | hsivonen: The set of URLs I'm picking from is basically just the web :-) |
| 14:33 | <Philip`> | so I expect it does have much more random weird stuff than the subset of the web controlled by people who run validators on their own pages |
| 14:33 | <Philip`> | hallvors: Okay, thanks |
| 14:35 | <hsivonen> | I want to know why the line break between </body> and </html> causes formatting elements to be reopened |
| 14:36 | <hsivonen> | I don't know yet if it is an implementation bug or a spec bug |
| 14:57 | <hsivonen> | hah. I have // XXX bug? on the relevant line asking if this is a spec bug |
| 14:59 | <hsivonen> | I wonder if I've email Hixie about this a year ago |
| 15:00 | <hsivonen> | hmm. http://www.whatwg.org/issues/data.html is not looking good |
| 15:00 | <zcorpan_> | hsivonen: how does the spec ever insert anything after the body element? |
| 15:00 | <hsivonen> | zcorpan_: it doesn't. that part is my bug |
| 15:00 | <Philip`> | I thought there wasn't any outstanding feedback on the parser |
| 15:01 | <Philip`> | (and I can't see any in the issues list) |
| 15:01 | <hsivonen> | ok. then I'll file a bug |
| 15:01 | <zcorpan_> | hsivonen: probably because Hixie started to work with wf2 instead of dealing with feedback |
| 15:02 | <takkaria> | hsivonen: when WF is done, I imagine it'll drop by a good few hundred |
| 15:02 | <hsivonen> | anyway, the spec bug is that space characters in 'after body' reconstruct the list of formatting elements |
| 15:06 | <annevk22> | http://jeffcroft.com/blog/2008/sep/11/two-thousand-twenty-two/ is part of the reason for the twitter messages |
| 15:08 | <hsivonen> | hmm. it might not be a spec bug after all... |
| 15:09 | <zcorpan_> | what jeff writes makes sense if you're an author |
| 15:11 | <zcorpan_> | Lachy: perhaps the web developer guide to html5 shouldn't mention stuff that's not widely implemented |
| 15:11 | <Philip`> | To a reasonable margin of error, everyone is an author, so it makes sense to make sense to authors |
| 15:12 | <hsivonen> | aargh. the spec is not in error |
| 15:12 | <hsivonen> | IE8, Opera and WebKit actually behave like that |
| 15:12 | <hsivonen> | Gecko doesn't |
| 15:12 | <annevk22> | seems adactio explained it already |
| 15:13 | <annevk22> | (re: jeffcroft.com post) |
| 15:13 | <hsivonen> | in Opera and WebKit, </body> splits the text node, though |
| 15:16 | <hsivonen> | looks like in the streaming mode, the Validator.nu HTML Parser gets the infoset wrong if there are space characters after </body> |
| 15:16 | <hsivonen> | I'll probably call it a feature |
| 15:16 | <hsivonen> | since fixing it would make the messages really annoying |
| 15:16 | <Philip`> | That's cheating :-p |
| 15:17 | <hsivonen> | Philip`: is it useful to throw a fatal error because the parser couldn't move an additional space inside the last <font>? |
| 15:18 | <zcorpan_> | in 2022, HTML5 will be what CSS1 is now, but CSS1 was still worth it |
| 15:18 | <annevk22> | seems I already blogged about the HTML5 timeline last december |
| 15:18 | <annevk22> | zcorpan_, nice line, might use that |
| 15:20 | <Philip`> | hsivonen: The informative message is the "End tag for body seen but there were unclosed elements" one (or at least it would be informative if it said what elements were unclosed), and then it's just quite confusing for it complain about a new font element after that point |
| 15:21 | <Philip`> | so if there was a fatal error, it'd still give the informative message, and wouldn't give the confusing message, so maybe that'd be good |
| 15:21 | <Philip`> | (but I might be missing lots of issues here) |
| 15:21 | <hsivonen> | Philip`: oh, there's definitely a bug to fix here |
| 15:21 | <hsivonen> | Philip`: I'm unsure about whether making the placement of endgame spaces just right is worthwhile, though |
| 15:22 | <Philip`> | Ah |
| 15:22 | Philip` | doesn't really care much about spaces :-) |
| 15:22 | zcorpan_ | thinks it's not worthwhile and would also like whitespace after head to just be inserted in head |
| 15:23 | annevk22 | agrees |
| 15:23 | <hsivonen> | Jeff Croft seems to miss the point between Hixie writing stuff down and not having to maintain separate site code bases for different browsers |
| 15:24 | <annevk22> | well, he also misses the point of reading beyond the point of disagreement |
| 15:29 | <Lachy> | zcorpan_, since the guide is meant to be a complete guide to HTML5, it doesn't make sense to omit stuff just because it's not implemented yet. Besides, everything will be implemented or dropped by the time HTML5 is done |
| 15:30 | <virtuelv> | zcorpan_: I'd prefer such a document to be live, and to reflect stuff people can actually test on their own |
| 15:30 | <zcorpan_> | Lachy: well you can't write everything at once anyway and the guide could be a living document evolving along with html5 and implementations |
| 15:30 | <hsivonen> | bad. I guess I'll just fix the endgame spaces |
| 15:30 | <hsivonen> | s/bad/bah/ |
| 15:30 | <annevk22> | http://lists.w3.org/Archives/Public/ietf-http-wg/2008JulSep/0469.html "I was only saying that if you want this document to be consistent with the direction HTML is headed, you should rely upon the definitions in RDFa." |
| 15:31 | <zcorpan_> | virtuelv: my point exactly |
| 15:31 | <hsivonen> | virtuelv: we should have HTML snapshots like CSS Beijing |
| 15:31 | <Lachy> | was there anything in particular that it mentions, but shouldn't right now? |
| 15:31 | <zcorpan_> | Lachy: dunno |
| 15:34 | <Lachy> | that post from Jeff Croft pretty much sums up the reasons why I stopped telling people that time line directly, and instead focussing on their ability to use the new stuff that's becoming available |
| 15:37 | <annevk22> | i managed to explain it at fronteers by talking about CSS2 |
| 15:37 | <annevk22> | people using the features, and the amount of time getting complete interop takes |
| 15:39 | <zcorpan_> | annevk22: s/got/get/ (fronteers-html5-video) |
| 15:41 | <hsivonen> | perhaps it would be better PR to pretend not to have a guess about how long it will take to get *everything* implemented in an interoperable way |
| 15:41 | <hsivonen> | "when it's ready" |
| 15:42 | <zcorpan_> | hsivonen: yeah |
| 15:43 | <annevk22> | zcorpan_, euh, where exactly? |
| 15:43 | <zcorpan_> | annevk22: "How did we got here?" |
| 15:43 | <zcorpan_> | annevk22: in the presentation, that is |
| 15:47 | <hsivonen> | http://twitter.com/riddle/statuses/918917836 |
| 15:47 | <virtuelv> | hsivonen: :) |
| 15:49 | <hsivonen> | on missing the point: http://twitter.com/singpolyma/statuses/918912066 |
| 15:49 | <annevk22> | zcorpan_, ouch |
| 15:49 | <Lachy> | wow, I think we need to improve our PR a bit. Those reactions are a bit surprising |
| 15:50 | <zcorpan_> | Hixie: don't mention 2022 in interviews :P |
| 15:50 | <hsivonen> | Lachy: not really surprising |
| 15:51 | <annevk22> | zcorpan_, fixed, damage already done though |
| 15:54 | <hsivonen> | annevk22: our education and outreach party line should probably say "XHTML 1.0" instead of "XHTML 1.x", since we aren't trying to be compatible with the stuff the XHTML2 WG does under the XHTML 1.1 name |
| 15:54 | <Lachy> | hsivonen, the fact that they don't really understand the timeline isn't surprising, but their hostility towards the spec is |
| 15:56 | <hsivonen> | when they put together CSS Eleven, I wonder what their expected commitment span was... |
| 15:56 | hsivonen | notes that Jeff Croft was on CSS Eleven |
| 15:56 | hsivonen | also notes that CSS3 is taking its time |
| 15:56 | <annevk22> | hsivonen, yeah, good point |
| 15:57 | annevk22 | fixes that while he's still connected |
| 15:58 | <hsivonen> | the aspect ratio of the demo video is wrong in Minefield |
| 15:59 | <zcorpan_> | hsivonen: i think that's a known bug in minefield |
| 15:59 | zcorpan_ | remembers someone commenting on the spec because of that bug |
| 16:23 | <takkaria> | is anyone else finding it hard to follow the privacy/disability thread? |
| 16:30 | <hsivonen> | takkaria: I got the impression that everyone but David Dailey says "Not a Problem" and I have trouble following what David Dailey said |
| 16:35 | <Lachy> | oh, Safari and Firefox incorrectly parse <meta =charset="UTF-8">, at least according to the current spec, for their encoding detection |
| 16:36 | <Lachy> | ah, but IE gets it right |
| 16:36 | <Lachy> | and Opear |
| 16:36 | <Lachy> | Opera* |
| 16:38 | <gsnedders> | takkaria: No, I just use the mark all as read feature of my mail client |
| 16:57 | <Lachy> | some character encoding detection tests are available here http://lachy.id.au/dev/markup/tests/html5/encoding/ |
| 17:00 | <Philip`> | Could you make it determine pass/fail automatically, and then have a tool which runs all the tests at once, for lazy people? |
| 17:01 | <Lachy> | yeah, eventually, I can do that |
| 17:01 | <Lachy> | I still have a few hundred more tests to make |
| 17:01 | <Lachy> | and then I can make a test harness |
| 17:02 | <Philip`> | Isn't it easier if you have a harness before you write the tests, so you can more easily run and test the tests? |
| 17:03 | <takkaria> | I was going to suggest doing them as data: urls, but I forgot IE didn't support them |
| 17:05 | <Lachy> | yeah, maybe |
| 17:06 | <Lachy> | if I can work out how. But I also have to make them capable of being integrated into Opera's testing system |
| 17:07 | <Lachy> | I should be able to write some javascript to check the textContent of the element to make sure it contains the right character, and then have that report to the test harness |
| 17:19 | <Philip`> | Lachy: Presumably something like <script>'Å' == '\xc5' ? pass() : fail()</script> would work for most of the tests |
| 17:19 | <Lachy> | Philip`, yeah, that's what I did |
| 17:20 | <Philip`> | takkaria: That's possibly a bad idea since data: URLs specify their own encoding |
| 17:20 | <Philip`> | so I guess you can't put a raw uninterpreted byte in them |
| 17:27 | <Lachy> | Philip`, if you want to create a test harness for them, that would be helpful. Just make use of the top.opener.rr(passed) function that gets called in them for obtaining the result. That's how Opera's system works |
| 17:27 | <Philip`> | Making framerate counters in SVG by having each digit represented by an object containing the text "0\n1\n2\n..." (converted to path form so that it doesn't depend on fonts or dodgy text renderers) which is dynamically moved upwards/downwards so the right sequence of digit values is visible, is a stupid idea |
| 17:29 | <Philip`> | (I only allowed for two digits, and now Chrome goes at >100fps, and I can't be bothered to go and update all my SVG and JS to make it work again :-( ) |
| 17:30 | <hsivonen> | it's weird how comments and space characters go to different places after </body> |
| 17:30 | Philip` | decides to not bother fixing it, until he rewrites Canvex in the distant future |
| 17:33 | <takkaria> | oo, Chrome does canvex that fast? |
| 17:33 | <Philip`> | Yes, at 320x240 |
| 17:33 | <Philip`> | and around 30fps at 640x480 |
| 17:33 | <gsnedders> | Philip`: So the advice is to use a higher res.? |
| 17:34 | <Philip`> | Sadly it inherits WebKit's total failure to render table layouts |
| 17:35 | <Philip`> | which makes the page take twice as much vertical space as it should, so at high resolutions it's larger than the screen, and the up/down movement keys cause the browser to scroll up and down the page, which is highly irritating |
| 17:35 | <hsivonen> | Philip`: why am I not seeing a huge fps difference with tracemonkey? |
| 17:36 | hsivonen | starts to suspect his Minefield doesn't really enable TraceMonkey |
| 17:36 | <Philip`> | hsivonen: Because it spends nearly all its time drawing nice bilinearly-scaled bitmaps to the screen, not running JS |
| 17:38 | <Philip`> | (Chrome uses the Skia library for graphics, which I presume it what makes it fast) |
| 17:39 | <Philip`> | s/it/is/ |
| 17:39 | <takkaria> | I wonder if Cairo will get as good as Skia at some point |
| 17:41 | <Philip`> | Skia is under the Apache License 2.0, so I presume Cairo can't copy any of its code |
| 17:42 | <takkaria> | yeah, someone was complaining about that on planet.mozilla.org |
| 17:42 | <Philip`> | Skia has some OpenGL code but I don't know if it actually uses that |
| 17:46 | <Philip`> | Hmm, the public Skia code doesn't even seem to really have any assembly or SSE or anything, so I don't see how it could be that much faster |
| 17:46 | <Philip`> | and I don't think it was particularly lower quality at scaling images downwards than other browsers |
| 17:47 | Philip` | will have to look more closely when he gets home |
| 17:48 | <hsivonen> | would it be bad if in the streaming mode instead of detecting the non-streamability of trailing comments I just hoisted them into body |
| 17:48 | <hsivonen> | that is, if I simply deferred the endElement events for body and html without bookkeeping of whether there are trailing comments? |
| 17:49 | <Philip`> | hsivonen: Does the streaming code currently follow the spec precisely (except in cases where it aborts with a fatal error), so this would be the first divergence? |
| 17:50 | <hsivonen> | Philip`: well, not the divergence is that trailing whitespace goes outside the body |
| 17:50 | <hsivonen> | s/not/now/ |
| 17:50 | <hsivonen> | Philip`: but yeah, until now I have imagined it followed the spec |
| 17:51 | <hsivonen> | I could still claim that it conforms if you don't set a LexicalHandler |
| 17:52 | <hsivonen> | it seems pointless to put in all the code to allow trailing comments to go into the right place but then throw a fatal error if there's a line feed after such comment |
| 17:55 | Philip` | wouldn't complain if it was just a documented deviation from the spec |
| 18:01 | hsivonen | zaps a lot of fatal errors |
| 19:01 | <Lachy> | the new Microsoft ad is even more boring than the one from last week, and it's 3 times longer |
| 19:01 | <othermaciej> | I didn't really get it |
| 19:02 | <Lachy> | I don't think anyone gets it |
| 19:02 | <Lachy> | for anyone who hasn't seen it, http://www.microsoft.com/windows/default.aspx?icid=winvan |
| 19:17 | jgraham | hasn't seen any of the Microsoft ads but maybe just getting people to talk about the ads is the idea |
| 19:21 | <Lachy> | jgraham, the problem is that the ads are backfiring because the ads suck so much, it makes Microsoft look bad |
| 19:21 | <Lachy> | it certainly doesn't want to make me buy any of their products |
| 19:22 | <Philip`> | Lachy: But you're a smelly Mac user, so you're really not the target audience for Microsoft ads :-p |
| 19:22 | <othermaciej> | I don't think they are supposed to sell product directly |
| 19:22 | <othermaciej> | they are supposed to "humanize" the company |
| 19:23 | <othermaciej> | I will admit the ads increased my estimate of Bill Gates's coolness by a small amount |
| 19:23 | <othermaciej> | but that estimate was already abysmally low |
| 19:23 | <othermaciej> | and in general the ads seem in bad taste and make both BG and Seinfeld look annoying and distant |
| 19:25 | <Lachy> | until Vista came out, I was a Windows user |
| 19:26 | Philip` | discovers that where Vista's "(My) Computer" window shows system information (network name, CPU name, RAM, etc), if you click on the text with those details (as opposed to space between them, or the textual field labels, or anywhere else in the window), the window does not get focussed |
| 19:27 | <Philip`> | (Also the detail text isn't quite lined up with the associated label text) |
| 19:28 | <Philip`> | I assume there's some kind of security-related reason for that bug, but it doesn't make me particularly happy about Vista |
| 20:15 | <hsivonen> | heh. the MS ad is Flash with a Silverlight download button on the page |
| 20:20 | <Dashiva> | I liked it! |
| 20:36 | <Hixie> | the 2022 date is useful for getting rid of people who don't read -- the interview was pretty clear about what it meant |
| 20:36 | <Hixie> | and i'm happy for people to talk about html5 :-) |
| 20:36 | <Hixie> | regarding microsoft's ad, i thought it was quite reassuring |
| 20:37 | <Hixie> | i had thought that their $300bn campaign might give them their edge back |
| 20:37 | <Hixie> | but having seen the ads, i am no longer concerned |
| 20:55 | <Hixie> | the comments on the various blogs about 2022 are encouraging |
| 20:55 | <Hixie> | people seem to be getting it |
| 20:55 | <Hixie> | i am, however, amused by the people who think in 14 years the web won't exist or will be radically different or whatever. |
| 20:55 | <gavin> | did something happen recently regarding 2022? |
| 20:55 | <Hixie> | i imagine those are the same people who thought we'd be driving flying cars... |
| 20:56 | <Hixie> | gavin: i mentioned it in an interview |
| 20:56 | <Hixie> | http://blogs.techrepublic.com.com/programming-and-development/?p=718 |
| 20:59 | <gavin> | that was a while ago though, wasn't it? |
| 20:59 | <gavin> | guess not that long ago |
| 20:59 | gavin | has been meaning to read it |
| 21:02 | <Lachy> | Hixie, we are going to be driving flying cars and riding hover boards by 2015. Back To The Future showed us that. |
| 21:04 | <gsnedders> | Hixie: Hey! I didn't exist when the web began! Things can change! |
| 21:07 | <Philip`> | gavin: The recent happening is that someone read that interview |
| 21:07 | <Philip`> | (http://jeffcroft.com/blog/2008/sep/11/two-thousand-twenty-two/) |
| 21:08 | <Lachy> | gsnedders, are you saying that changes to the human population are relevant to to the internet, or just that your birth was a significant event in its history? |
| 21:08 | <gsnedders> | Lachy: That things can change over time. |
| 21:09 | <Philip`> | gsnedders: But you're saying that the web changes slower than human life |
| 21:10 | <gsnedders> | Philip`: I change very slowly |
| 21:25 | <hsivonen> | yay for content negotiation: http://www.w3.org/2001/tag/doc/versioning-compatibility-strategies |
| 21:32 | <gsnedders> | Hmmm. |
| 21:33 | <gsnedders> | I need more than normal on the front page of my LaTeX report :\ |
| 21:35 | <gsnedders> | like, on the title page |
| 21:40 | <Lachy> | hsivonen, I don't anything about content negotiation in that document |
| 21:43 | <Lachy> | or were you referring to being sent the useless application/xml copy of it instead of the text/html version, due to content negitaion? |
| 21:52 | <hsivonen> | Lachy: I get an unstyled XML doc in Firefox |
| 22:04 | <Lachy> | I don't. I get the HTML version in Firefox |
| 22:04 | <Lachy> | check what accept headers Firefox is sending |
| 22:05 | <hsivonen> | this is Firefox 2 on ubuntu 7.10 |
| 22:06 | <Lachy> | I've got Firefox 3 |
| 22:06 | <hsivonen> | Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5 |
| 22:07 | <Lachy> | FF3 must have changed them. |
| 22:07 | <Lachy> | Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 |
| 22:46 | <Lachy> | I added a couple more features to the beta and changed the layout a little. http://html5.lachy.id.au/beta/ |
| 22:47 | <Lachy> | new features include the buttons to insert template markup |
| 22:48 | <Lachy> | and the small gap between the DOM tree panel and the toolbar below intentional, not a bug. It will have something added to the space later. |
| 23:16 | <annevk22> | markp++ |
| 23:17 | <annevk22> | we should have a bot that keeps track of what like in #webkit |
| 23:17 | <csarven> | http://ishtml5readyyet.com/ |
| 23:18 | <gsnedders> | Hmmm. I wonder whether I should do that as XHTML. |
| 23:18 | gsnedders | waits to be killed |
| 23:18 | <jgraham> | gsnedders: What? Is XHTML ready yet? |
| 23:19 | <gsnedders> | jgraham: Why wait for things to be ready? |
| 23:19 | annevk | places a comment |
| 23:19 | jgraham | feels he is missing something |
| 23:19 | <annevk> | and I make a typo, nice |
| 23:21 | <Lachy> | according to WHOIS, this is the guy that set up that site http://jcornelius.com/ |
| 23:21 | <jgraham> | annevk: What did markp say/do? |
| 23:22 | Hixie | tries to come up with a description of what the form element is |
| 23:22 | <csarven> | annevk No wonder HTML5 is taking so long with all the typoZ. :) |
| 23:22 | <Hixie> | <p>The <code>form</code> element represents a collection of <span |
| 23:22 | <Hixie> | title="category-field">data entry fields</span> that can be |
| 23:22 | <Hixie> | submitted to a server for processing.</p> |
| 23:23 | <jgraham> | Hixie: Sounds reasonable, no? |
| 23:23 | <Hixie> | good. |
| 23:23 | <Hixie> | thnks. |
| 23:23 | <csarven> | Not necessarily "data entry fields", unless type=hidden stuff is classified as such. |
| 23:24 | <Hixie> | just data fields maybe? |
| 23:24 | <Hixie> | now, wtf is accept-charset and what does it do. |
| 23:24 | Hixie | cracks open html4 |
| 23:24 | <csarven> | I suppose "entry" comes off as if the user physically taking an action on the form. |
| 23:24 | <jgraham> | data fields is arguably more precise but I think either is good enough |
| 23:25 | <annevk> | http://jeffcroft.com/blog/2008/sep/11/two-thousand-twenty-two/#c147306 well, there's that |
| 23:25 | <annevk> | csarven, hah |
| 23:25 | <csarven> | annevk That's where I came across it. I didn't get to reading the comments yet. |
| 23:25 | <annevk> | jgraham, he made a snarky remark on my blog |
| 23:25 | <nessy> | isn't accept-charset http ? |
| 23:26 | <annevk> | (that comment says, Jeff Croft: "If, in 2022, I’m still writing HTML, CSS, and Javascript, I will probably shoot myself. :)") |
| 23:26 | <othermaciej> | yeah! and if in 2008 we're still using TCP and ASCII, we should kill ourselves |
| 23:27 | <Hixie> | "The value is a space- and/or comma-delimited list of charset values." |
| 23:27 | <Hixie> | ffs |
| 23:27 | <othermaciej> | or, god forbid, coding in C |
| 23:27 | <jgraham> | annevk: Oh I see. Yeah it's unny how Jeff said all that stuff and then denied that he meant it was a negative thing. I guess he needs to work on his writing skills ;) |
| 23:27 | <Hixie> | it's like the html4 wg went OUT OF IT'S WAY to make design decisions that were as vague and annoying as possible |
| 23:27 | <jgraham> | s/unny/funny/ |
| 23:27 | <annevk> | I guess the good thing is that the smarter cookies out there get better informed because of this madness |
| 23:28 | <Hixie> | i wonder if any browsers support accept-charset and how to test it |
| 23:28 | <jgraham> | othermaciej: No need we have the LHC for that :) |
| 23:28 | <annevk> | Hixie, they do |
| 23:28 | <annevk> | Hixie, isn't that the charset that ends up being used by the browser for submission? |
| 23:29 | <Hixie> | yeah |
| 23:29 | <jgraham> | I thought browsers did something vaugely surprising with accept-charset |
| 23:29 | <annevk> | you can probably test it by using different encodings for the page and accept-charset |
| 23:29 | <annevk> | not sure how to test the multiple values thing accurately |
| 23:29 | <Hixie> | jgraham: implementing it per spec would be vaugely surprising |
| 23:29 | <annevk> | maybe with unsupported encodings |
| 23:29 | <jgraham> | Hixie: That would be midblowing ;) |
| 23:29 | <jgraham> | mindblowing even |
| 23:29 | <annevk> | you mean not possible |
| 23:33 | Lachy | starts work on an article to explain the exactly what spec timeline means for web developers |
| 23:36 | <jgraham> | Lachy: For the WHATWG blog or for your own blog? |
| 23:37 | <Lachy> | haven't decided yet. There are a few other options I could try too |
| 23:37 | <Lachy> | depends how much visibility I want to give the article |
| 23:38 | <jgraham> | I can happily write a 1 paragraph entry for the WHATWG blog |
| 23:38 | <annevk> | go for it |
| 23:38 | <jgraham> | Something that woughly reads 2022: This number is irrelevant |
| 23:38 | <jgraham> | roughly |
| 23:39 | <annevk> | sounds good |
| 23:39 | jgraham | must try hitting the right keys in the right order |
| 23:39 | <annevk> | that's how I ended up with mesaure |
| 23:40 | <annevk> | (well, correct keys, wrong order) |
| 23:41 | <annevk> | and "charset values" implies the weird matching rules? |
| 23:41 | <Lachy> | I was intending to write something a little longer that explains the spec process and outlines what each milestone means to each of the stake holders, including web devs, browser vendors and spec writers |
| 23:41 | <annevk> | oops |
| 23:41 | <annevk> | yeah, no reason we can't have both though |
| 23:41 | <jgraham> | Lachy: Sure. I think longer is good. |
| 23:42 | <jgraham> | I'll only bother if also having something short adds value |
| 23:42 | <Lachy> | I could submit it to ALA, that would give it a lot of visibility, or perhaps get it published on WaSP |
| 23:42 | <Hixie> | the 2022 date is when the spec becomes mostly irrelevant, ironically :-) |
| 23:43 | <GregHouston> | 2022 is about around the time NASA is suppose to have astronauts living on the moon. Maybe that can be worked into the blog. ;) |
| 23:43 | <Hixie> | at least, assuming that we've moved on to html6 and co by then, at least on the spec side of things |
| 23:45 | <Hixie> | ok well |
| 23:45 | <Hixie> | accept-charset interoperability result: |
| 23:45 | <Hixie> | 0. |
| 23:47 | <Lachy> | by 2022, the interplanetary internet should be working too, so that astronauts living on the moon will be able to use the internet |
| 23:47 | <jgraham> | The ping time will be horrendous |
| 23:47 | <Lachy> | http://www.sstl.co.uk/News_and_Events/Latest_News/?story=1254 |
| 23:47 | <GregHouston> | Haha. Yeah, there was a post about that on slashdot yesterday. |
| 23:47 | <Lachy> | yeah, that's where I saw it |
| 23:48 | <Hixie> | forget ping times, iirc TCP congestion control doesn't even work right with the kind of latency you'll get on the interplanatory net |
| 23:48 | <jgraham> | Well the distance to the moon / the speed of light is about 1.3 seconds which isn't too bad |
| 23:49 | <Lachy> | hopefully by then, physicists will have worked out how to make use of quantum entanglement of particles to transmit messages instantly over any distance |
| 23:49 | <hdh> | "Note that 120 sec is defined in the protocol as the maximum * possible RTT." from /usr/src/linux/net/inet/tcp.c |
| 23:49 | <jgraham> | Lachy: Only if the laws of physics as we know them are fundamentally wrong |
| 23:49 | <annevk> | https://bugzilla.mozilla.org/show_bug.cgi?id=455043 is sort of an interesting historical artifact :) |
| 23:50 | <Lachy> | jgraham, of course they're wrong. That's why they're *only* a theory! |
| 23:50 | <Hixie> | hdh: right |
| 23:50 | <Lachy> | ;-) |
| 23:50 | <hdh> | that comment mentioned Mars |
| 23:51 | <jgraham> | hdh: That might just be enough to communicate with Venus at the right time of year |
| 23:52 | <jgraham> | Mars is too far, I think |
| 23:52 | <Hixie> | hdh: can you find any evidence that tcp.c ever actually contained that? |
| 23:54 | <hdh> | http://www.linuxhq.com/kernel/v1.1/83/net/inet/tcp.c |
| 23:55 | <hdh> | I hope the part just cut out of the diff is the same as the fortune |
| 23:55 | <annevk> | Moz is doing Storage.clear() too? |
| 23:56 | <Hixie> | hdh: hm, your searching skills are better than mine |
| 23:56 | <hdh> | linux/net/inet/tcp.c mars -fortune |
| 23:56 | <othermaciej> | annevk: is their stuff still based on the old storage spec? |
| 23:57 | <annevk> | this is about implementing localStorage: https://bugzilla.mozilla.org/show_bug.cgi?id=422526 |
| 23:58 | <othermaciej> | I guess you could ask |
| 23:58 | <annevk> | petele from MS told me IE8B2 either has both async and sync or just sync btw (they did change something versus IE8B1) |