| 00:09 | <Philip`> | Wow, I'd forgotten how great Verlet integration is when compared to Euler integration |
| 00:17 | <Philip`> | http://canvex.lazyilluminati.com/misc/physics.html - I don't know why it doesn't work nicely in Opera - the circle rendering is broken and it only goes at 10fps :-( |
| 00:18 | <Philip`> | Also it's extremely jerky in FF3, but at least FF2 works fine... |
| 00:22 | <MasterLexx> | okay, now i am not anymore so sure of the success of html 5 http://www.webdevout.net/tidings/2007/04/23/the-whimzical-world-of-html-5/ |
| 00:24 | <MasterLexx> | i hope those html5 guys will make something good out of it, but i don't think this will happen in the next time |
| 00:25 | <Hixie> | we're the html5 guys :-) |
| 00:31 | <MasterLexx> | ohh |
| 00:32 | <MasterLexx> | hmm, i hope you guys fix those things |
| 00:35 | <Hixie> | what do you want us to fix? |
| 00:42 | <MasterLexx> | i meant those things described there, like the bugmode |
| 00:42 | <MasterLexx> | and the thing with no version information.... why not? i don't think it can harm. |
| 00:42 | <Hixie> | the bugmode was just an idea someone proposed, we're not doing it |
| 00:43 | <Hixie> | why would you want version information? it's just more stuff for you to remember when you write HTML pages |
| 00:43 | <Hixie> | and most people don't bother with it anyway |
| 00:43 | <MasterLexx> | browsers have to bother with it |
| 00:43 | <Hixie> | why? |
| 00:43 | <Hixie> | they haven't up to now... |
| 00:43 | <MasterLexx> | it's not bad, at least let is a option! |
| 00:43 | <Hixie> | i don't understand what you would want it for |
| 00:44 | <Lachy> | only IE is going to bother implementing a bug mode switch |
| 00:44 | <MasterLexx> | i meant, i could still be there as optional emlement |
| 00:44 | <Hixie> | right, but what would it be good for? |
| 00:44 | <Hixie> | there's no point having an optional thing if it isn't used for anything |
| 00:44 | <Hixie> | just makes people who don't understand HTML think it's important and confuses them |
| 00:45 | <MasterLexx> | as wrtitten in the article, what if something goes wrong? what if one docuemnt has to be handeled in another manner? |
| 00:45 | <MasterLexx> | (sorry for my grammar, i am german) |
| 00:45 | <Hixie> | i don't understand why you would want documents to be handled in a different manner |
| 00:45 | <Hixie> | wouldn't we want just one set of rules? |
| 00:46 | <Hixie> | having multiple different sets of rules just seems like it would be really confusing for authors |
| 00:46 | <MasterLexx> | what if in a future html 6 some elemets are deprecated... |
| 00:46 | <MasterLexx> | i don't think so, you have one set of elements and attributes that you use, like in xhtml 1.0 strict, i don't use others... |
| 00:46 | <Lachy> | elements still have tob e supported, even if they're deprecated |
| 00:46 | <Hixie> | deprecating them doesn't mean browsers stop supporting it |
| 00:47 | <Hixie> | e.g. browsers still support <p align="">, but align="" isn't in HTML5 |
| 00:47 | <MasterLexx> | but then this is some sort of quirks mode |
| 00:47 | <Hixie> | no, it's just the one mode |
| 00:47 | <Hixie> | we're trying to remove quirks mode as much as possible |
| 00:47 | <Hixie> | just have one mode |
| 00:48 | <MasterLexx> | oh god |
| 00:49 | <MasterLexx> | i think, there will be always other versions and things that are left out of new ones... |
| 00:49 | <Hixie> | they'll be left out of the language, but that doesn't affect what browsers have to do |
| 00:49 | <Hixie> | browsers just have one set of code that handles all versions |
| 00:49 | <MasterLexx> | nahh okay, i think i will wait a bit and see what heppens to html5 |
| 00:50 | <MasterLexx> | i don't think i understand much of this, but it would meen that there will be a mess of elemets and attributes that all always have to be supported by browsers, there will never be a clear html this way |
| 00:51 | <Hixie> | yes, browsers will always support old documents |
| 00:51 | <Hixie> | having a version doesn't change that |
| 00:51 | <madmoose> | Browsers that want to be backwards compatible have to support all the old stuff anyway. |
| 00:52 | <Hixie> | note though that even though browsers have to support old stuff, it doesn't mean new versions of html can't be "clean" |
| 00:52 | <Hixie> | e.g. HTML5 doesn't have <tt> and <center> and so on |
| 00:52 | <Hixie> | even though browsers support <tt> and <center> |
| 00:52 | <MasterLexx> | okay okay, i read today the first time about html 5 in the news on selfhtml... i think i need to know more first |
| 00:52 | <madmoose> | Microsofts argument for a version number (if I understand it correctly) is that they want to support old bugs in their implementation, but their release cycle isn't going to coincide with html versions anyway. |
| 00:54 | <Lachy> | Microsoft's argument is flawed |
| 00:54 | <Lachy> | they want to perpetuate every bug in every single browser version, for all time |
| 00:55 | <madmoose> | Well that's their prerogative. |
| 00:55 | <madmoose> | It doesn't have anything to do with html version numbers though. |
| 00:56 | <mpt> | gsnedders, iCab doesn't have alerts asking you if you want pages to render per spec or per Web, but it does have checkboxes for it |
| 00:57 | <mpt> | hsivonen, on the Web at least, starship names are possibly more common than ship names |
| 00:59 | <MasterLexx> | what? |
| 01:00 | <MasterLexx> | bye and good night |
| 08:28 | <annevk> | " |
| 08:28 | <annevk> | HTML5 is that spec. That was the original goal of the WHATWG effort, and |
| 08:28 | <annevk> | continues to be this goal. There are already other groups writing |
| 08:28 | <annevk> | specifications that don't take today's content into account, e.g. XHTML2. |
| 08:28 | <annevk> | Those specs will be ignored. I have no intention of writing a spec that |
| 08:28 | <annevk> | will be ignored, it seems like a spectacular waste of time and of the |
| 08:28 | <annevk> | human race's resources." |
| 08:32 | <Hixie> | hm? |
| 08:33 | <annevk> | I liked the way you phrased it |
| 08:34 | <annevk> | btw, it seems like <script for= event=> needs to be implemented :( |
| 08:36 | <Hixie> | it's not backwards compatible |
| 08:37 | <annevk> | it's implemented in IE and Firefox and is used by plugins |
| 08:37 | <annevk> | executeSql() isn't backwards compatible either for that matter :) |
| 08:37 | <Hixie> | it's used in firefox? |
| 08:38 | <Hixie> | executeSql doesn't cause scripts to run when they shouldn't |
| 08:38 | <annevk> | yeah |
| 09:21 | <mikeday> | some of the imperative pseudo-code/prose in the HTML5 spec is rather difficult to follow |
| 09:29 | <annevk> | you have to be a native en-GB-x-Hixie speaker |
| 09:30 | <mikeday> | that could be awkward |
| 09:31 | <mikeday> | it's rather frustrating, as you can almost represent all this stuff with regular expressions |
| 09:31 | <mikeday> | which would be a lot easier to check that you've got it right |
| 09:32 | <mikeday> | I'm stuck on the "get an attribute" step |
| 09:32 | <annevk> | if you read carefully it shouldn't be a problem |
| 09:32 | <mikeday> | the code gets rather long and fiddly |
| 09:37 | <annevk> | you don't have to follow the specification |
| 09:37 | <annevk> | you just have to ensure that A > algorithm > B is identicala |
| 09:37 | <jgraham> | mikeday: Charset sniffing? Yeah, I didn't like doing that either |
| 09:37 | <annevk> | actually, A > B > C |
| 09:37 | <annevk> | where B can be English prose or C |
| 09:37 | <annevk> | or Python, etc. |
| 09:38 | <mikeday> | right |
| 09:45 | <mikeday> | the charset sniffer seems to parse attributes on close tags, eg. </foo bar="baz"> |
| 09:45 | <annevk> | yeah |
| 09:45 | <annevk> | tokenizer does that too |
| 09:46 | <mikeday> | does the tokenizer parse them then throw them away? |
| 09:46 | <annevk> | yes |
| 09:46 | <mikeday> | phew :) |
| 09:49 | <mikeday> | what I meant about the spec is that the description is actually lower level than the code |
| 09:49 | <mikeday> | it's easier to implement a high level spec with low level code than the reverse. |
| 09:49 | <annevk> | hmm |
| 09:49 | <annevk> | isn't the spec at the same level? |
| 09:50 | <annevk> | charset sniffing needs to be done at the byte level |
| 09:51 | <mikeday> | I mean it's very imperative |
| 09:51 | <mikeday> | the spec is longer than your python implementation, for example |
| 09:51 | <mikeday> | and much harder to understand |
| 09:53 | <annevk> | so how can it be done in the same way being as exact as it is now? |
| 09:53 | <annevk> | if it can be improved I suppose it should be done |
| 09:54 | <mikeday> | that's what I'm trying to figure out |
| 09:54 | <mikeday> | using regular expressions would be an obvious place to start |
| 09:54 | <mikeday> | and it's easy to see how that could be done for most of it |
| 09:55 | <mikeday> | for example: <![^>]*> |
| 09:55 | <mikeday> | that's the regular expression to match <!DOCTYPE...> and similar junk and skip over it |
| 09:56 | <mikeday> | similarly for comments: <!--([^-]|-[^-]|--[^>])*--> |
| 09:56 | <mikeday> | defining it using a regular expression means that there is no ambiguity about <!--> vs. <!---> vs. <!----> |
| 09:57 | <mikeday> | start tags and get attribute are a little trickier, but I think can still be done |
| 09:58 | <mikeday> | to match the beginning of a start tag: </?[A-Za-z][^\s><]* |
| 09:59 | <mikeday> | (or end tag, as it has an optional slash) |
| 10:00 | <mikeday> | the resulting regular expressions could just about be pasted straight into lex or perl or whatever |
| 10:01 | <annevk> | however, it makes it harder to introduce <!--> as comment |
| 10:02 | <mikeday> | very easy, just change the regular expression |
| 10:02 | <mikeday> | much easier than editing the prose |
| 10:03 | <mikeday> | actually, the expression I pasted before is a little bit too strict |
| 10:03 | <annevk> | if you're going down that route you have to define what subset of regular expressions and such... |
| 10:03 | <mikeday> | <!--([^-]|-+[^>])*--> would be better |
| 10:03 | annevk | prefers the prose actually |
| 10:04 | <mikeday> | that's not a problem, many many specifications use standard subset of regular expressions or BNF |
| 10:04 | <mikeday> | oh well :) |
| 10:05 | <annevk> | regular expressions also encourages a particular implementation |
| 10:05 | <annevk> | which isn't necessarily good |
| 10:06 | <annevk> | meeting |
| 10:06 | <mikeday> | hmm, I think the current prose is more biased towards a particular implementation |
| 10:06 | <mikeday> | whereas regular expressions can be implemented directly, or used as specification for hand written parser |
| 10:12 | <mikeday> | ahah, regular expression for attributes: [\s/]*([^<>][^=\s/<>]*)[\s]*=[\s]*('[^']*'|"[^"]*"|[^\s<>]*) |
| 10:13 | <mikeday> | it may look like line noise, but you don't have to be an en-GB-x-Hixie speaker to understand it :) |
| 11:27 | <annevk> | mikeday|away, you have to be crazy instead :p |
| 11:32 | <mikeday> | it's not really as nasty as it looks :) |
| 12:10 | <gsnedders> | mikeday: and how do you define error handling with ABNF/regex? |
| 12:11 | <mikeday> | you don't have to |
| 12:11 | <mikeday> | charset sniffing doesn't do error handling |
| 12:12 | <gsnedders> | mikeday: the majority of the tokeniser does, though |
| 12:12 | <mikeday> | the tokeniser is more complex |
| 12:13 | <mikeday> | but even that could be "more formalised" than it currently is |
| 12:13 | <gsnedders> | mikeday: then where were you going to use ABNF/regex? in the document conformance section? |
| 12:13 | <mikeday> | I'm just looking at charset sniffing now |
| 12:15 | <mikeday> | currently it is defined imperatively: go forward one byte, if it's this then goto step 1, otherwise step 2... |
| 12:15 | <gsnedders> | trying to work out how to implement things without using regex when given like that can get rather complex |
| 12:17 | <mikeday> | eh? you mean if I give you a regular expression you don't know what to do with it, or what? |
| 12:17 | <gsnedders> | I mean trying to implement a complex regular expression without using regular expressions can be hard to work out |
| 12:18 | <mikeday> | well, not really; regular expressions can be transformed into code mechanically |
| 12:18 | <mikeday> | unlike prose. |
| 12:19 | <Dashiva> | The regular expressions have to be created from prose first, though |
| 12:19 | <Philip`> | Would BNF be easier to understand and less line-noise-like than regular expressions, but still work about the same? |
| 12:20 | <mikeday> | yes |
| 12:20 | <gsnedders> | BNF is slightly easier, yes |
| 12:20 | <mikeday> | you would create definitions for commonly used bits |
| 12:20 | <mikeday> | avoid regular expression style shorthand |
| 12:20 | <mikeday> | more like the EBNF in the XML spec |
| 12:21 | <gsnedders> | I have a preference of ABNF, personally |
| 12:21 | <mikeday> | Comment ::= '<!--' Char* '-->' |
| 12:21 | <mikeday> | (as a rough example) |
| 12:24 | <annevk> | tree construction is now 63 lines... |
| 12:24 | <annevk> | two simple functions :) |
| 12:25 | <mikeday> | sounds good! |
| 12:26 | gsnedders | still doesn't really know how to parse URIs without using regular expressions, when you don't know how many parts of the URI you have |
| 12:27 | <mikeday> | you mean like optional query parameters or port numbers? |
| 12:27 | <gsnedders> | or schemes, or authority, etc. |
| 12:28 | <mikeday> | it's pretty horrible |
| 12:29 | <mikeday> | :) |
| 12:29 | <gsnedders> | I can think of ways of doing it, but all very expensive |
| 12:29 | <gsnedders> | and in a non-cached interpreted language… |
| 12:30 | <mikeday> | the overlap between URLs and filenames makes things even worse |
| 12:31 | <mikeday> | c:foo is a filename, not a URL with scheme "c" |
| 12:31 | <mikeday> | of course, http://slashdot.org is a valid filename on Linux... |
| 12:32 | <gsnedders> | what FSes is it not valid on? |
| 12:33 | <gsnedders> | NTFS? |
| 12:39 | <annevk> | so it will become a little longer I'm afraid |
| 12:39 | <annevk> | need to deal with after the last closing tag too |
| 12:39 | <annevk> | oops |
| 12:42 | <gsnedders> | only two exams left this year! |
| 12:58 | <mikeday> | Windows won't like http://... as a filename I suspect |
| 13:02 | <Dashiva> | \/:*?"<>| are illegal |
| 13:02 | <mikeday> | but anyway, if you try to use "http://..." as a filename, many programs will treat it as a URL instead |
| 13:03 | <mikeday> | 'cos it starts with http: |
| 13:03 | <mikeday> | can't really blame them |
| 13:20 | <gsnedders> | Mac OS X won't like http:// as a filename, but HFS+ doesn't care. You can actually create a file called that going through the POSIX layers of OS X |
| 13:45 | annevk | wonders why mike uses both tabs and spaces |
| 13:45 | annevk | doesn't like that |
| 13:47 | <MikeSmith> | annevk - mike = me? |
| 13:48 | <annevk> | no, mikeday |
| 13:48 | <annevk> | in his libhtml project |
| 13:51 | <MikeSmith> | maybe because he inherited parts of the code from somebody ... |
| 13:52 | <MikeSmith> | happens to me sometimes |
| 13:52 | <annevk> | seems like he's starting from zero |
| 13:52 | <annevk> | (there's not much there so far) |
| 14:04 | <annevk> | XML5 sort of works now :) |
| 14:05 | <annevk> | there's no spec yet, but there's an implementation |
| 14:06 | <Dashiva> | What are the major changes so far? |
| 14:07 | <annevk> | I don't have DOCTYPE nodes (DOCTYPEs do affect processing of entities), I got </>, I got error handling |
| 14:07 | <annevk> | s/got/have// |
| 14:08 | <annevk> | I need to make testcases at some point and once I tweaked stuff a bit more I want to set up some online demo so people can generate trees for themselves |
| 14:36 | <Philip`> | zcorpan: http://canvex.lazyilluminati.com/misc/physics.html (probably works best in Firefox) seems to be the desired kind of concept, and it's not particularly complex, though I still don't think it could get close enough to Elasto Mania without having their code to copy :-( |
| 14:37 | <annevk> | Philip`, btw, instead of using toDataURL and drawImage() one could use getImageData and putImageData |
| 14:38 | <met_> | Philip`looks nice |
| 14:39 | <zcorpan> | Philip`: cool! |
| 14:39 | <Philip`> | annevk: You can't really use get/putImageData if you want to save the image between browser sessions, because it's not unlikely that the user will change their screen resolution or switch to a different browser, and then ImageData will no longer correspond to the correct size (and you have no way of knowing what the correct size would be) |
| 14:41 | <Philip`> | Also it seems incredibly inefficient saving ImageData to disk, because it'll be dozens of bytes per pixel, whereas toDataURL is nice since it's about the best compression possible |
| 14:41 | <Philip`> | (Er, except it's base64-encoded, which kind of damages that a bit) |
| 14:41 | <annevk> | the first is an argument for having canvas pixel == image data pixel and the second, yeah fair enough |
| 14:41 | <Philip`> | (but not a lot) |
| 14:42 | <annevk> | doesn't have to be base64 encoded in theory |
| 14:43 | <Philip`> | Hmm, can you get Unicode URIs with no limits on whatever characters are included? Then you could do image/png;base65536,<...> which'd be better |
| 14:43 | <annevk> | Philip`, I managed to jump out your physics model |
| 14:43 | <annevk> | I'm falling hard and forever :) |
| 14:43 | <met_> | me too |
| 14:43 | <Philip`> | The jumping-through-walls thing is an intentional feature ;-) |
| 14:43 | <met_> | on the left side |
| 14:44 | <Philip`> | because apparently that's what Elasto Mania does, so I'm just doing the same, though I'm probably using larger timesteps so it's a more visible problem |
| 14:44 | <Dashiva> | Philip`: Might as well stick to base256, no? :) |
| 14:44 | <Philip`> | Dashiva: Depends on whether it's being stored on disk as UTF-8 or UTF-16 |
| 14:45 | <Philip`> | Actually, neither of those would work because they've got funny non-codepoint values :-( |
| 14:45 | <Dashiva> | Yep |
| 14:45 | <Philip`> | If you're storing ISO-8859-1 or UCS-2, then it'd work as base 256/65536 nicely |
| 14:47 | <Philip`> | annevk: If you had canvas pixel == image data pixel, why would one want to use get/putImageData instead of toDataURL/drawImage? |
| 14:48 | <annevk> | security |
| 14:48 | <Philip`> | Ah, right |
| 14:50 | <Philip`> | ...though toDataURL/drawImage should have the same security permissions/restrictions as ImageData (I think), except that current implementations don't do that |
| 14:50 | <annevk> | It's still unclear to me if you can somehow get an unsafe data: URL |
| 14:53 | <Philip`> | If you've got any kind of data: URL at all, how is being able to new Image()/drawImage/toDataURL any worse than simply transmitting the data: URL string directly to somebody? |
| 14:57 | <Philip`> | If you've got an image which was loaded from an external data: URL (or in another document or something) and you can't actually get the data: URL string out from it, then I think that's handled under different security rules and it's given a different origin so you can't drawImage/toDataURL it, so maybe that handles the problems (but I should probably leave security issues to people who understand them :-) ) |
| 14:58 | <annevk> | I suppose data: URIs might be "safe" then |
| 14:58 | <annevk> | as long as you don't use data:image/svg+xml, or something |
| 15:41 | <zcorpan> | btw, the presentation went well yesterday |
| 16:02 | <gsnedders> | exams over! w00t! |
| 16:05 | <Philip`> | Just until next year? :-) |
| 16:07 | <zcorpan> | html5.org seems to be down :( |
| 16:09 | <hasather> | zcorpan: hmm, that happens fairly often |
| 16:10 | <MikeSmith> | zcorpan - presentation? |
| 16:10 | <zcorpan> | MikeSmith: yeah, http://www.robertnyman.com/2007/04/26/geek-meet-may-2007-html-5-and-xhtml/ |
| 16:12 | <hasather> | zcorpan: probably because of this: http://www.dreamhoststatus.com/2007/05/23/more-dns-issues/ |
| 16:21 | <zcorpan> | hasather: ok |
| 16:32 | <annevk> | zcorpan, what questions did you get? |
| 16:33 | <annevk> | zcorpan, and what about the other presentation? |
| 16:35 | <zcorpan> | annevk: mostly about document conformance things (like <font>), versioning (and doctypes), if html5lib could parse tag soup, whether the presence/absence of "/" in void elements need to consistent... |
| 16:35 | <zcorpan> | when html5 will be ready/used/implemented |
| 16:36 | <annevk> | it's used and implemented... ready? well... |
| 16:36 | <annevk> | :) |
| 16:36 | <zcorpan> | jarvklo talked about xhtml and the mobile web, mostly |
| 16:37 | <zcorpan> | he had some good ideas about what can be done server side, like checking conformance without using a third party |
| 16:37 | <annevk> | how XHTML is fucked up there? |
| 16:38 | <zcorpan> | not really |
| 16:39 | <zcorpan> | more that the w3c and wap forum (or what it is) have finally come to an agreement about what markup to use for mobiles |
| 16:39 | <annevk> | oh that |
| 16:40 | <annevk> | I think vendors have mostly decided that HTML is to be used for mobiles |
| 16:40 | <annevk> | (Vendors being Apple, Nokia and Opera here...) |
| 16:40 | <zcorpan> | ok |
| 16:40 | <zcorpan> | i'd encourage you to talk to jarklo directly though |
| 16:41 | <annevk> | the actual news from "wapforum" is that they're no longer going to subset and then superset W3C specs |
| 16:41 | <annevk> | like they did with WML2 and XHTML Mobile Profile |
| 16:41 | <zcorpan> | indeed |
| 16:41 | <annevk> | not that XHTML is now recommended or something |
| 16:42 | <zcorpan> | i thought it was |
| 16:43 | <annevk> | yeah, it probably still is |
| 16:43 | <zcorpan> | on what grounds i don't know, really |
| 16:44 | <annevk> | "latest, greatest" |
| 16:44 | <annevk> | Anyone know how to escape !- inside a Linux terminal? |
| 16:45 | <othermaciej> | \? |
| 16:45 | <annevk> | I'm trying to test comments but doing 'python test.py "<!-- -->"' doesn't work |
| 16:45 | <othermaciej> | backslash or single quote |
| 16:46 | <annevk> | I tried backslash, didn't work |
| 16:46 | <annevk> | Single quote doesn't seem to work either... |
| 16:46 | <othermaciej> | what shell are you using? |
| 16:47 | <annevk> | Ah wait, backslash does work |
| 16:47 | <annevk> | The problem is that the backslash ends up in my Python script... |
| 16:47 | <othermaciej> | echo "<"\!"-- -->" |
| 16:47 | <annevk> | I'm using "GNOME Terminal 2.x" |
| 16:47 | <othermaciej> | does what you'd want in bash |
| 16:48 | <othermaciej> | the terminal is not the shell |
| 16:48 | <annevk> | ah ok |
| 16:48 | <annevk> | that does work |
| 16:48 | <annevk> | thanks |
| 16:58 | <annevk> | twitter is funny... it escapes your text input and then counts the number of characters and complaints about it being over 140... |
| 16:59 | <Dashiva> | Even better with forum software showing title previews, first 10 chars or so, after escaping |
| 17:00 | <Dashiva> | Here we &nb... -> |
| 17:00 | <annevk> | the thing is that the client side check does count the visual characters and it therefore does get submitted and ends up in their database |
| 17:15 | <annevk> | whatwg is down |
| 17:16 | <hasather> | annevk: DH is having DNS issues |
| 17:21 | <annevk> | k |
| 17:36 | <zcorpan> | html5.org is up again |
| 17:38 | <zcorpan> | perhaps i should blog about the presentation at blog.w.o |
| 17:39 | <annevk> | you have a blog now? :) |
| 17:39 | <zcorpan> | blog.whatwg.org |
| 17:41 | <annevk> | heh |
| 18:16 | gsnedders | has been given the best reason _ever_ for using <em> for italics even though they've been told better — "we prefer it". |
| 18:19 | <Hixie> | if anyone can work out the code ni http://img.shopping.com/jfe/JavaFrontEnd-fe55.1.1-874/js/tabMenus.js gets called in a way that actually does something, i'll give them 500 points. |
| 18:19 | <Hixie> | a sample page that gets that js file is http://www1.uk.shopping.com/xPP-hobs--neff-price_range_630_800 |
| 19:02 | <Philip`> | http://66.102.9.104/search?q=cache:4IXIf9DhazkJ:zhulianxing.blogspot.com/feeds/posts/default/7688979022477086776 - back in February it had <a ... onmouseover="startShow('1','6');setMenusSize('8');" onmouseout="sMH();hIfr();" ...> |
| 19:04 | <Philip`> | Uh, March |
| 19:04 | <Philip`> | (probably) |
| 19:06 | <Philip`> | (I really don't know why http://zhulianxing.blogspot.com/ posted shopping.com's front page on their blog...) |
| 19:07 | <Hixie> | aah |
| 19:07 | <Hixie> | interesting |
| 19:12 | <bewest> | what will 500 points get me? |
| 19:12 | <nickshanks> | ian, did you see my mailing list suggestion? is it workable? |
| 19:13 | <Hixie> | bewest: dunno :-) |
| 19:13 | <Hixie> | nickshanks: which one? |
| 19:13 | <zcorpan> | http://blog.whatwg.org/html5-geekmeet |
| 19:14 | <Hixie> | bewest: thanks, though, that's very helpful |
| 19:14 | <nickshanks> | ian: one document or two |
| 19:17 | <Philip`> | "Does that mean that you can convert any old HTML document to XML by feeding it through html5lib?" - not really, since it seems a significant number produce DOMs that can't be serialised to well-formed XML |
| 19:17 | <Hixie> | nickshanks: when did you send it? |
| 19:17 | <Hixie> | oh i see it |
| 19:17 | <nickshanks> | about 20 mins ago. i can't receive emails now, so haven't seen if anyone replied |
| 19:17 | <Hixie> | haven't gotten to that yet in my e-mail |
| 19:17 | <Hixie> | :-) |
| 19:17 | <zcorpan> | Philip`: yeah, true |
| 19:17 | <Hixie> | there's a reply |
| 19:17 | <nickshanks> | but since you popped up in #webkit, i thought i'd ask :) |
| 19:18 | <zcorpan> | Philip`: you can probably convert it to XML5 however ;) |
| 19:18 | <Philip`> | (Actually, I'm not sure how significant a number - at least there are some with <!--------> which I think can't be done, and some with invalid characters in attribute names, but I never looked at what the actual problems were and if they could be worked around easily) |
| 19:19 | <bewest> | I don't think that javascript is used on that page |
| 19:19 | <bewest> | Hixie: it looks like legacy stuff that someone new is trying to clean up |
| 19:19 | <bewest> | Hixie: looks to me like thereis more than one author involved in the javascript across the site |
| 19:20 | <Hixie> | seems likely |
| 19:20 | <Hixie> | oh well |
| 19:20 | <bewest> | sometimes new people may not like javascript that goes out onthe site... but they can't necessarily just get rid of it because it's not clear what might break |
| 19:22 | <Philip`> | shopping.com on archive.org shows that the tabMenus thing wasn't there six months ago, so it's a new addition (and then half-removal) |
| 19:22 | <Hixie> | fun |
| 19:22 | <Philip`> | http://wordsandpictures.dyndns.org/cgi-bin/parsetree/parsetree.py?source=%3Cspacer+type%22block%22+width%3D%221%22+height%3D%221%22%3E%3C%2Fspacer%3E - aha, that's one I found that couldn't be serialised to XML |
| 19:23 | <Philip`> | Can XML5 do that? :-) |
| 19:23 | <Hixie> | hm, the tag wants to talk to me |
| 19:23 | <Hixie> | that can't bode well |
| 19:25 | <Philip`> | Hallucinating about speaking HTML tags? |
| 19:26 | <Hixie> | no, the w3c tag |
| 19:26 | <Hixie> | apparently there is "significant interest" in me joining them for lunch next week |
| 19:26 | <Dashiva> | Bring a food taster |
| 19:27 | <Hixie> | it'll be in a google cafeteria, so i think i'm safe |
| 19:28 | <Dashiva> | Polonium or whatnot, I tell you |
| 19:29 | <othermaciej> | Hixie: perhaps they want you to say hello to their little friend |
| 19:35 | <nickshanks> | Dashiva: that's the soviets silly |
| 19:35 | <nickshanks> | soogle isn't microsoft |
| 19:35 | <nickshanks> | -s +g |
| 19:35 | <Hixie> | nickshanks: replied |
| 19:35 | <nickshanks> | what did you say? :) |
| 19:36 | <nickshanks> | (i can't get email atm.) |
| 19:36 | <Hixie> | you said that an option would be to "simply have two views of the spec" |
| 19:36 | <Hixie> | i said that it was from "simple" |
| 22:32 | <jgraham> | html5lib now has BeautifulSoup support (at last. I really made a meal of implementing it) |
| 22:32 | <Hixie> | what's BeautifulSoup? |
| 22:33 | <jgraham> | http://www.crummy.com/software/BeautifulSoup/ |
| 22:33 | <jgraham> | (we just build a tree in that format, the BeautifulSoup parser is irrelevant, obviously) |
| 22:34 | <Hixie> | ah ok |
| 22:34 | <jgraham> | Simon Willison asked for it at XTech so he could use his getElementsByCSSSelector function with html5lib |
| 22:39 | <Hixie> | ah |
| 22:50 | <zcorpan> | is there a reason why http://wiki.whatwg.org/wiki/HTML5_Presentations doesn't link to hsivonen's slides? |
| 22:52 | <hasather> | annevk: oh, I'll update it now |
| 22:55 | zcorpan | adds a link, if it shouldn't be there then revert it... :) |
| 23:01 | <nickshanks> | while you're att it, you can translate the page to swedish ;-) |
| 23:06 | <zcorpan> | lol |
| 23:16 | <zcorpan> | hsivonen: the expansions of XSD and XHTML5 in your thesis say "XML" in <abbr title> in your thesis |
| 23:38 | <mpt> | The perils of invisible metadata |
| 23:41 | <Dashiva> | I wouldn't say title is invisible |
| 23:41 | <jruderman> | just hiding |
| 23:44 | <mpt> | well, yeah |
| 23:44 | <mpt> | Semi-visible |
| 23:44 | <mpt> | like <title> in most browsers |
| 23:44 | <mpt> | hence "Welcome to Adobe GoLive 5" etc |
| 23:46 | <nickshanks> | if title was in the body, would that be a Good Thing ? |
| 23:46 | <nickshanks> | (assuming it had been that way since HTML 1) |
| 23:46 | <Hixie> | it's not where in the markup that matters in this case |
| 23:46 | <Hixie> | since the element is by definition not rendered in the main page |
| 23:47 | <Hixie> | and the main page title (H1) is often not an appropriate <title> |
| 23:49 | <mpt> | I think probably the only way to fix that problem is for browsers to not have toolbars at the top of the window |
| 23:50 | <Hixie> | we kind of have that now with the tab bars |
| 23:50 | <nickshanks> | well, titles go in the tab bar, and that's only 20 chars wide or so |
| 23:50 | <mpt> | |That's not reall...| |
| 23:50 | <Hixie> | i don't see the toolbar going away |
| 23:50 | <nickshanks> | tabs are not real? what! waaaaaa |
| 23:51 | nickshanks | holds his head in his hands* |
| 23:51 | <mpt> | -ly a solution :-) |