| 00:28 | <annevk> | Hixie, in Web Forms 2.0 the form="" attribute is a set of IDs |
| 02:51 | <faithfulgeek> | so I'm currently reading O'Reilly's book on RESTful Web Services, curious if URI Templating is still being considered for HTML 5 |
| 02:52 | <takkaria> | I don't think it is |
| 02:53 | <faithfulgeek> | :( that was pretty exciting |
| 02:53 | <takkaria> | though I'm not quite sure what about URI templates HTML5 would be using |
| 02:54 | <faithfulgeek> | according to the book I'm reading, it was for forms |
| 02:54 | <faithfulgeek> | so you could say: <form action="..." template="something/{variable}"><input type="text" name="variable" /></form> |
| 02:56 | <takkaria> | I'm not sure where that was proposed, but it doesn't appear to be in Web Forms 2 |
| 02:56 | <faithfulgeek> | http://blog.whatwg.org/proposing-uri-templates-for-webforms-20 |
| 02:57 | <takkaria> | the likelihood of it being in HTML5 I would imagine is vanishing |
| 03:01 | <faithfulgeek> | thanks for the info |
| 03:01 | <faithfulgeek> | it looks like they're still supporting put and delete as methods though, that's good to see! |
| 03:03 | <takkaria> | the Web Forms 2 spec is now being incorporated into HTML5 |
| 03:03 | <takkaria> | so with any luck, non-Opera browsers might start implementing bits of it fairly soon :) |
| 03:03 | <faithfulgeek> | awesome |
| 03:04 | <faithfulgeek> | i'm preparing a presentation on REST services, and reading a book on it now, however the author is using a number of examples based on the proposed specs of 5 when it was written |
| 03:04 | <faithfulgeek> | so I'm trying to find out what's still valid and what's not |
| 03:05 | <takkaria> | well, the spec is the best place to look :) though as I say, the forms section is still very much in progress |
| 03:05 | <faithfulgeek> | cool, thanks takkaria! |
| 07:30 | <Hixie> | annevk: yeah the multiple id thing was dropped, see irc a few days ago |
| 09:13 | <zcorpan_> | annevk: why should getElementsByTagNameNS throw? |
| 09:14 | <zcorpan_> | annevk: i thought implementors didn't want to guarentee which element is returned because it allowed for optimization |
| 09:16 | <zcorpan_> | annevk: is step 3 unclear in createElementNS? i guess i need to specify what it means similar to how html5 defines "split on spaces" |
| 09:18 | <annevk> | zcorpan_, step 2 already talks about localName |
| 09:19 | <annevk> | zcorpan_, it does not throw now if you use a tagName of ">" or something? |
| 09:19 | <annevk> | zcorpan_, as for getElementById, I heard different arguments on that |
| 09:19 | <zcorpan_> | annevk: oops, that should be qualifiedName |
| 09:19 | <annevk> | Hixie, it would be good to still split on spaces then, to allow for extensibility |
| 09:20 | <zcorpan_> | annevk: getElementsByTagNameNS('>') does not throw no |
| 09:21 | <annevk> | k |
| 09:24 | <annevk> | zcorpan_, I think Opera and Safari at least always return the first |
| 09:24 | <annevk> | zcorpan_, and Maciej said he'd like that to be specified |
| 09:24 | <othermaciej> | getElementById? |
| 09:24 | <othermaciej> | yeah I think that should be spec'd |
| 09:25 | <othermaciej> | I think you have to return first or at least something very close to it for web compat |
| 09:27 | <roc> | you mean return the first element in the document with a given ID? |
| 09:27 | <annevk> | http://lists.w3.org/Archives/Public/public-webapi/2007Jan/thread.html#msg118 |
| 09:27 | <roc> | Yeah, that's necessary for Web compat |
| 09:27 | <roc> | if you don't always return the first in the document, Amazon breaks |
| 09:27 | <annevk> | I'm told Gecko sometimes does something differently when mutations are evolved |
| 09:27 | <roc> | that's not true anymore |
| 09:27 | <annevk> | s/evolved/involved/ |
| 09:28 | <annevk> | cool |
| 09:28 | <roc> | I seem to recall having this discussion a few months ago |
| 09:30 | <othermaciej> | I recall this as well |
| 09:30 | <annevk> | me too, though I'm not sure the above URL is that discussion |
| 09:31 | <annevk> | anyways, zcorpan_ didn't spec it as such, which is why we're having it again :) |
| 09:32 | <hsivonen> | hmm. the test results at http://www.paciellogroup.com/blog/misc/longdesc.html no longer match I8b2 |
| 09:32 | <hsivonen> | IE8b2 |
| 09:34 | <zcorpan_> | ok, fixed getElementById |
| 09:37 | <annevk> | zcorpan_, qualifiedName should not match NCName as then it can't contain a ":" |
| 09:37 | <hsivonen> | Hixie: is there any scenario where black box testing could distinguish between the tree builder managing text node coalescing in using an internal buffer and late-inserting text nodes and early-inserting text nodes and appending to them while in the tree? |
| 09:38 | <hsivonen> | s/in using/using/ |
| 09:38 | <zcorpan_> | annevk: good point |
| 09:38 | <zcorpan_> | fixed |
| 09:39 | <zcorpan_> | hsivonen: i guess you could have a setInterval that inspects the text node |
| 09:40 | <annevk> | zcorpan_, might be better to use QName instead of Name ? |
| 09:41 | <zcorpan_> | annevk: QName is NCName | PrefixedName |
| 09:41 | <hsivonen> | zcorpan_: ah. I hadn't thought of that |
| 09:41 | <hsivonen> | zcorpan_: however, the spec doesn't specify when the parser has to yield to let timeouts and intervals run |
| 09:41 | <annevk> | zcorpan_, yeah, so checking for that instead of Name and PrefixedName is a) less confusing and b) shorter |
| 09:42 | <hsivonen> | so one could just pretend that when the parser yields, it hasn't seen the text at all yet |
| 09:42 | <zcorpan_> | annevk: but it should throw different exceptions (or well it does now) |
| 09:42 | <zcorpan_> | annevk: i'm considering dropping error checking altogether |
| 09:43 | <hsivonen> | as far as I can tell, the parser only needs to yield when it sees a </script> end tag |
| 09:43 | <hsivonen> | and otherwise, yielding is up to the implementation |
| 09:43 | <hsivonen> | which makes me wonder if Web compat requires some level of discretionary yielding |
| 09:44 | <zcorpan_> | there are libraries that poll the dom every X ms for an element |
| 09:44 | <annevk> | zcorpan_, I see, woefully over engineered |
| 09:44 | <zcorpan_> | annevk: indeed |
| 09:44 | <zcorpan_> | annevk: it's because namespaces are optional in dom3 core |
| 09:45 | <zcorpan_> | right now i just want to spec how things work |
| 09:45 | <annevk> | ok, well, keep notes :) |
| 09:46 | <zcorpan_> | i am :) |
| 09:46 | <hsivonen> | zcorpan_: is the compat requirement that parser must yield every Y ms or is the compate requirement that whenever the parser yields for the CSS formatter, intervals must fire, too? |
| 09:46 | <zcorpan_> | hsivonen: don't know |
| 09:47 | <zcorpan_> | hsivonen: for the library point of view it just wants to get the element as soon as it's available |
| 09:47 | <hsivonen> | ok. I guess I should check if Hixie has already specced this |
| 09:47 | <hsivonen> | zcorpan_: yeah, but is it only to keep up with layout? |
| 09:48 | <hsivonen> | is there any way to opt in to getting mutation events for parser-initiated insertions? |
| 09:48 | <zcorpan_> | hsivonen: no i think it's mainly to have e.g. buttons do something before the page has finished loading |
| 09:49 | <hsivonen> | zcorpan_: isn't that keeping up with layout? |
| 09:49 | <zcorpan_> | hsivonen: i guess |
| 10:04 | <hsivonen> | in Gecko, the yielding from the parser depends on the user event queue |
| 10:06 | <virtuelv> | hsivonen: You're aware that you have a doppelganger here in Oslo |
| 10:07 | <virtuelv> | I got a bit freaked out when he got of at the bus stop next to Opera |
| 10:09 | <hsivonen> | virtuelv: I wasn't aware |
| 10:10 | <virtuelv> | He was so similar I tried to say hi to him |
| 10:10 | <virtuelv> | at which point he looked at me as if I was a loonie |
| 10:14 | <annevk> | heh, https://bugzilla.mozilla.org/show_bug.cgi?id=243519 is fixed |
| 10:14 | <annevk> | I think this means I can simplify my CSS when Firefox 3.1 is reasonably deployed |
| 10:17 | <roc> | don't speak too soon, it already bounced out of the tree once :-) |
| 11:13 | <Philip`> | Ooh, I found a null pointer dereference vulnerability in Google Chrome |
| 11:13 | <Philip`> | <a href="about:crash">Click me for free puppies!</a> |
| 11:14 | <Philip`> | I don't know how they didn't catch that problem |
| 11:15 | <hsivonen> | Hixie: am I right that reconstructing the list of active formatting elements is always a no-op when that step is hit in foreign content? |
| 11:18 | <hsivonen> | can the tree builder ever be in foreign content without the secondary insertion mode being 'in body', 'in cell' or 'in caption'? |
| 11:22 | <annevk> | in table seems to allow for it too, though it depends on whether foster parenting changes the insertion mode |
| 11:24 | <hsivonen> | ah. ok. for the optimization I had in mind, that suggests I should indeed only check for those modes and not for foreignness |
| 11:25 | <annevk> | seems foster parenting doesn't affect the insertion mode |
| 11:33 | <Lachy> | Philip`, I don't see the bug. When I click a link to about:crash in Chrome, it takes me to about:blank |
| 11:35 | <Lachy> | Philip`, it seems to do the same thing with all the other about: URIs too |
| 11:35 | <Philip`> | Oh :-( |
| 11:35 | Philip` | didn't actually test it |
| 11:36 | <annevk> | supposedly <a href="foo:%">x</a> or something should crash it |
| 11:37 | <annevk> | (the whole browser) |
| 11:40 | <Philip`> | That just makes it ask me about starting an external application to handle foo |
| 11:40 | hsivonen | tries to figure if the "Any other end tag" algorithm for 'in body' simplifies significantly on the implied </option> |
| 11:42 | <takkaria> | hsivonen: what optimisation are you thinking of doing? |
| 11:43 | <hsivonen> | takkaria: not searching runs of characters for spaces in certain insertion modes |
| 11:45 | <hsivonen> | takkaria: have you checked if "any other end tag" simplifies on "</option>"? |
| 11:46 | <takkaria> | no, I've not tried optimising the treebuilder at all in Hubbub yet |
| 11:48 | <annevk> | Philip`, href="fo%:x" then? |
| 11:48 | <annevk> | maybe it's patched already |
| 11:49 | <othermaciej> | some funny url thing with %s would take down the whole browser |
| 11:49 | <othermaciej> | not sure if they fixed it |
| 11:50 | <othermaciej> | (I do not believe the webkit.org version of WebKit ever had this vulnerability |
| 11:50 | <othermaciej> | ) |
| 11:50 | <annevk> | Safari had a unknown protocol vulnerability on Windows, but a different one |
| 11:51 | <annevk> | (I don't think the %-thing is a security issue though.) |
| 11:52 | <Philip`> | Someone says ctrl+l then ":%" crashes, but it works fine for me |
| 11:52 | <Philip`> | and I hope Google hasn't been automatically downloading patches to my computer without telling me about it |
| 11:53 | <hsivonen> | takkaria: at least one check simpliefies away |
| 11:55 | <Philip`> | Oh, okay, it looks like they have been downloading patches automatically without telling me |
| 11:55 | <Philip`> | since the UA version has gone from 0.2.149.27 to 0.2.149.29 |
| 11:56 | <takkaria> | hsivonen: I'll be keeping an eye on your SVN logs for optimisations to steal :) |
| 11:59 | <hsivonen> | Philip`: do new tabs start a new engine version while the browser is still running? |
| 11:59 | <Philip`> | hsivonen: No idea |
| 12:00 | <Philip`> | That would be crazy, but neat :-) |
| 12:01 | <hsivonen> | because for security updates, the user should either be prompted to restart the browser ASAP or the fix should be hot-applicable |
| 12:01 | <hsivonen> | so if they aren't prompting... |
| 12:04 | <Philip`> | At least on Vista, Chrome seems to install itself in per-user directories rather than the proper global applications directory, so you don't get UAC prompts when something is trying to update its files, which seems good for usability but bad for security |
| 12:11 | <hsivonen> | takkaria: do you have a mechanism for dropping the initial LF in textarea and pre without having a per-token memory access cost? |
| 12:11 | <hsivonen> | I just have a naive needToDropLF which is written to very often |
| 14:19 | gsnedders | has Safari crash half way through commenting on annevk's blog |
| 14:20 | <annevk> | yay |
| 14:20 | hsivonen | wonders if Parallels leaks "video memory" of the virtual machine |
| 14:20 | Retrieving | #whatwg modes... |
| 14:21 | <annevk> | I have this illusion that Hixie's and my blog are of a rare breed of blogs that end up in browser bug databases |
| 14:21 | <gsnedders> | Mine was in the IE8 one |
| 14:22 | <hsivonen> | text-shadow and @font-face need graphics layer integration and Chrome has a different graphics layer |
| 14:23 | <hsivonen> | <video> and <audio> in Safari use QuickTime |
| 14:23 | <hsivonen> | so it makes sense that those features would not work up front |
| 14:23 | <gsnedders> | SQL is likely disabled 'cos it'll be globalStorage in that branch of WebKi |
| 14:23 | <gsnedders> | *WebKit |
| 14:24 | <hsivonen> | btw, what does Chrome do about sharing the HTTP cache between processes? |
| 14:24 | <annevk> | hsivonen, if that's in response to my post, I did point that out |
| 14:24 | <gsnedders> | annevk: That was basically what I was trying to write |
| 14:25 | <hsivonen> | annevk: you didn't mention specifics :-) |
| 14:25 | <hsivonen> | anyway, Google has to have a plan for <video> |
| 14:25 | <hsivonen> | it'll be interesting to see what it is |
| 14:25 | <hsivonen> | will they use OpenCORE instead of DirectShow on Windows? |
| 14:25 | <hsivonen> | something different? |
| 14:26 | <gsnedders> | On the whole I expect they'll use DirectShow/QT/GStreamer |
| 14:26 | hsivonen | still hasn't seen an explanation of the OpenCORE MPEG-LA story for Android |
| 14:26 | <annevk> | hsivonen, fair enough :) |
| 14:27 | <gsnedders> | hsivonen: I expect the company selling/distributing it has to pay the patent fees, so unofficial builds can't have support |
| 14:33 | <hsivonen> | gsnedders: if it will work like that, it seems that the Apache license then has a whole in its patent language through which someone can introduce royalty-bearing technology as long as the royalty collector is structured as a separate entity |
| 14:33 | <gsnedders> | hsivonen: The Apache License only covers those held by those who wrote the code. |
| 14:33 | <gsnedders> | hsivonen: It has no bearing on any other. |
| 14:34 | <hsivonen> | s/whole/hole/ |
| 14:35 | <hsivonen> | it's scary when one starts making speech recognition-style errors when typing |
| 14:35 | <BenMillard> | hsivonen, I think it's quite natural. don't worry about it :) |
| 14:36 | <gsnedders> | BenMillard: Thx for dealing with the hotel BTW |
| 14:36 | <gsnedders> | BenMillard: Nice you shoving me and smedero in one room :P |
| 14:38 | <BenMillard> | gsnedders, well you two were gonna share anyway, so it made sense to me. |
| 14:38 | <BenMillard> | also, I need somewhere to retreat to after pwning you all at GT :D |
| 14:39 | <gsnedders> | BenMillard: You won't pwn me! |
| 14:39 | <gsnedders> | :P |
| 14:39 | <gsnedders> | BenMillard: You may win, but I doubt by much, unless I make a big mistake (rare) |
| 14:39 | <BenMillard> | gsnedders, to be honest I'll just be playing for fun. :) |
| 14:39 | <BenMillard> | I often make big mistakes...consistency is the part I suck at |
| 14:40 | <gsnedders> | BenMillard: Well you're the one making it competitive :) |
| 14:40 | <gsnedders> | BenMillard: Want to race around the Nรผrburgring? :P |
| 14:40 | <gsnedders> | BenMillard: Know the track? |
| 14:40 | <BenMillard> | gsnedders, I know and am faster than the AI on all the tracks from GT up to and including GT4. |
| 14:41 | <gsnedders> | BenMillard: Beating the AI isn't hard |
| 14:41 | <BenMillard> | so I won't be a noob, but I'm not pr0 either |
| 14:41 | <BenMillard> | gsnedders, I think we should start with Fuji Speedway 2005 because of the run-off areas. |
| 14:41 | <gsnedders> | BenMillard: I tend to, within Forza 2, be within the top thousand times around each track. Fear. |
| 14:42 | <gsnedders> | BenMillard: Peh! There's no damage model! |
| 14:42 | <gsnedders> | BenMillard: The Circuit de la Sarthe is fine too |
| 14:43 | <Philip`> | Hmm, is 8MB/s reasonable Validator.nu SAX parser performance? |
| 14:43 | <gsnedders> | BenMillard: The hard corners have plenty of run-off |
| 14:43 | <BenMillard> | gsnedders, Fuji has tarmac run-off so mistakes in 2-player will cost you some time, but won't be race over. |
| 14:44 | <gsnedders> | BenMillard: Peh! Mistakes should kill you! :P |
| 14:44 | <Philip`> | If I do it multicoredly then I can parse about a thousand pages per second, which I guess is okay |
| 14:44 | <hsivonen> | Philip`: is that tree-buffered or streaming? |
| 14:45 | <Philip`> | hsivonen: I think buffered, since I'm using XmlViolationPolicy.ALLOW |
| 14:45 | <BenMillard> | gsnedders, I'd like us to use a range of cars and tracks. Short courses like Autumn Ring Mini and Grand Valley East Section with Nissan mm-R Cup Car, for example. |
| 14:46 | <gsnedders> | BenMillard: I much prefer the Autumn Ring to the "mini" |
| 14:47 | <BenMillard> | gsnedders, it's a bit long for the mm-R but in 2P I guess it'll still be fun. :) |
| 14:47 | <gsnedders> | BenMillard: I can't really remember the cars |
| 14:47 | <gsnedders> | BenMillard: I'll need to practice |
| 14:48 | Philip` | is getting the input through a GZIPInputStream, which seems to compress things to ~20%, so a thousand pages a second is ~5MB/s, so hopefully his disk won't be a severe bottleneck |
| 14:48 | <BenMillard> | gsnedders, having spent several months in GT3 with all driver aids off, I've been trying the same in GT4. Takes a while to get used to but I love it now. |
| 14:48 | gsnedders | is actually in large debate trying to draw up the deliberations of the National Youth Assembly of the Church of Scotland 2008 |
| 14:49 | <BenMillard> | gsnedders, you have to turn them off in the Settings for *each* car though, which SUCKS. |
| 14:51 | <hsivonen> | I don't understand the point of David Poehlman's reply to me |
| 14:52 | <hsivonen> | Isn't it an *incredibly* bad idea for a blind person to get a computer without audio out (unless the person is *also* deaf)? |
| 14:53 | <BenMillard> | hsivonen, if they can operate a PC exclusively through Braille output then it would work, I imagine. |
| 14:54 | <BenMillard> | (and conventional or Braille-labelled keyboard input) |
| 14:54 | <wilhelm> | hsivonen: http://www.blindeforbundet.no/nbf/publikasjoner/brosjyrer/teksthefte/Leselist.jpg |
| 14:55 | <wilhelm> | Works fine without audio. |
| 14:56 | <hsivonen> | BenMillard, wilhelm: sure Braille displays exist, but it still seems like a bad idea to not have audio capability in hardware |
| 14:57 | <hsivonen> | If a person is not deaf but just somehow managed to get hardware without audio output capability, that's not an accessibility issue |
| 15:05 | <webben> | hsivonen: Agreed. Choice of hardware is a output media independence issue, but not intrinsically an accessibility issue. |
| 15:19 | <zcorpan> | i don't like dom's error checking at all |
| 15:20 | <zcorpan> | it checks for some things but not others and the things it checks sometimes don't match what xml requires anyway |
| 15:20 | <hsivonen> | It'll be interesting to see if Safari will next spoof as Chrome and if they will start having authoritative=really-Chrome and authoritative=really-Safari |
| 15:20 | <zcorpan> | and you can smuggle in stuff from other documents without checking anyway |
| 15:21 | <zcorpan> | the questions are |
| 15:22 | <zcorpan> | is there a reason why we can't drop all error checking |
| 15:22 | <zcorpan> | and |
| 15:22 | <zcorpan> | if we do, do we need to make createElement('<div>') or createElement('<div foo="bar">') do something magic |
| 15:22 | <hsivonen> | zcorpan: does IE implement full attribute tokenization for those? |
| 15:23 | <zcorpan> | hsivonen: afaict yeah |
| 15:23 | <zcorpan> | hsivonen: though i haven't tested much |
| 15:25 | <zcorpan> | document.createElement('<x y z=a x x y u>'); works as you'd expect |
| 15:26 | <Philip`> | Seems to trigger iff the first character is '<' |
| 15:29 | <hsivonen> | what if the string tokenizes to multiple tags? |
| 15:29 | <hsivonen> | what if it tokenizes to and end tag? |
| 15:29 | <hsivonen> | what about "<>"? |
| 15:29 | <annevk> | I'd rather throw an error if the first char is "<" than implementing some small start tag tokenizer just for createElement |
| 15:29 | <hsivonen> | or something else that doesn't tokenize to a start tag |
| 15:29 | <Philip`> | It ignores everything after the first '>' |
| 15:30 | <hsivonen> | annevk: presumably, one could reuse the real tokenizer |
| 15:30 | <Philip`> | It seems to throw an error if it starts with '</' |
| 15:30 | <Philip`> | (but if e.g. it starts with '<!' then it'll just make an element whose name starts with '!') |
| 15:31 | <hsivonen> | although it would probably lead to code duplication, since in a C++-based browser it could be perf win not to make the tree builder methods virtual |
| 15:31 | <Philip`> | Hmm, if you just have '<>' then it makes an element named '<>'; if you have e.g. '<>x' then it throws an error |
| 15:31 | <annevk> | fail |
| 15:32 | <hsivonen> | sounds like fun |
| 15:33 | <Philip`> | Out of n pages for an unknown value of n, I see one that does document.createElement('<iframe frameborder="0">') |
| 15:33 | <Philip`> | (http://www.movingideas.org/content/en/issue_items/education.htm) |
| 15:34 | <Philip`> | (n = tens of thousands, I think) |
| 15:35 | <annevk> | zcorpan, btw, I think adoptNode basically becomes a no-op |
| 15:38 | <takkaria> | I think that's quite a cool shortcut :) |
| 15:40 | hsivonen | continues to be amazed at an XML parser implementation where parseContent and parseElement are mutually recursive and the stack gets deeper as the parse progresses |
| 15:42 | <Philip`> | I suppose it's not even tail recursion? |
| 15:42 | <hsivonen> | Philip`: I didn't check |
| 15:42 | <hsivonen> | Philip`: though IIRC, gcc can optimize tail recursion away in C |
| 15:43 | <hsivonen> | Philip`: so perhaps they feel it's OK to ship code like that in Classpath if GCJ fixes it |
| 15:45 | Philip` | realises that storing all his page data in a single file is a bad idea since he'd need 8-byte offset pointers to refer to each page |
| 15:45 | <hsivonen> | Philip`: it's not tail recusion AFAICT |
| 15:46 | <hsivonen> | Philip`: I used a .sparseimage |
| 15:50 | <zcorpan> | hsivonen: http://validator.nu/?doc=http%3A%2F%2Fwebkit.org%2Fperf%2Fsunspider-0.9%2Fcrypto-aes.html doesn't whine about non-ascii |
| 15:50 | <Philip`> | I suppose I should just split the data into chunks, so it's easier to process in parallel |
| 15:51 | <hsivonen> | zcorpan: thanks |
| 15:52 | <zcorpan> | annevk: doesn't it change ownerDocument? |
| 15:57 | <annevk> | RB: "At this point Ian, you're plugging your ears and screaming "I can't hear you" when you say something like that. You need to stop acting like a child and step up and participate in this WG and be a real editor." |
| 15:58 | <annevk> | zcorpan, insertNode and all need to do that |
| 15:58 | <annevk> | zcorpan, and insertBefore etc. |
| 16:03 | <zcorpan> | annevk: ok |
| 16:05 | <annevk> | though maybe adoptNode should do it too in case people use it and then simply check ownerDocument |
| 16:06 | <annevk> | in any case, adoptNode is pointless |
| 16:06 | <zcorpan> | wonder if it can be dropped too |
| 16:08 | <jgraham> | RB is teh funny |
| 16:09 | <takkaria> | I like how he calls the permathread "deliberations" myself |
| 16:10 | <Lachy> | LOL! :-D "At this point Ian, you're plugging your ears and screaming "I can't hear you" when you say something like that. You need to stop acting like a child and step up and participate in this WG and be a real editor." |
| 16:11 | Philip` | tries to steal ideas from Sawzall |
| 16:11 | <hsivonen> | grr. Java TCK is still for JCP participants only |
| 16:11 | hsivonen | wants unit tests for SortedSet |
| 16:17 | <annevk> | http://hsivonen.iki.fi/chrome-ua/ :/ |
| 16:18 | <Philip`> | (It's not 0.2.149.27 any more, since they already updated it to .29) |
| 16:19 | <hsivonen> | Philip`: I started writing the post before the update |
| 16:19 | <hsivonen> | where do Classpath and Harmony keep their unit tests? |
| 16:20 | <Philip`> | "This is the WebKit version from with Chrome branched its copy." - s/with/which/ |
| 16:21 | <hsivonen> | Philip`: fixed. tahnks |
| 16:23 | <BenMillard> | hsivonen, perhaps it *is* scary to typo the response to feedback about a typo? |
| 16:24 | <hsivonen> | BenMillard: no, I think the scariness of these cases goes the other way round |
| 16:26 | <BenMillard> | hsivonen, I make typos in all cases...I just try to be brave about it :P |
| 16:27 | hsivonen | finally finds Harmony TreeSet tester |
| 16:30 | <zcorpan> | hsivonen: http://www.webaim.org/blog/user-agent-string-history/ |
| 16:38 | <annevk> | Opera/9.51 (Windows NT 5.1; U; en) is quite nice |
| 16:39 | <Dashiva> | I wonder if anyone checks for the U, ever |
| 16:40 | <hsivonen> | zcorpan: looks like I'm late :-( |
| 16:42 | <hsivonen> | what was the KHTML version WebKit originally forked from? |
| 16:43 | <hsivonen> | am I wrong about who put "KHTML" first in the UA string? |
| 16:43 | <Philip`> | The longest in my recent logs is "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; Trident/4.0; Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1) ; Embedded Web Browser from: http://bsalsa.com/; SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; .NET CLR 3.0.04506; .NET CLR 3.5.21022; Zune 2.5; InfoPath.2)" |
| 16:44 | <BenMillard> | fwiw, I've never even worked on a project where user-agent sniffing was used, let alone needed to do it myself. |
| 16:44 | <BenMillard> | nearest I've come is conditional comments for a few IE CSS fixes |
| 16:45 | <BenMillard> | and even that's quite rare |
| 16:45 | <hsivonen> | I'm pretty sure I have the history of the "KHTML" part right and the other author has it wrong |
| 16:45 | <Philip`> | I still sort-of-maintain some code that has a $ENV{HTTP_USER_AGENT} =~ /MSIE 5.*?Mac/ check |
| 16:46 | <Philip`> | since apparently style="filter:shadow(...)" did bad things on that, or something |
| 16:46 | <hsivonen> | according to http://www.useragentstring.com/pages/useragentstring.php?name=Konqueror Konqueror started including "KHTML" only at 3.2 and that release already had code flowing back from Apple |
| 16:48 | <BenMillard> | Philip`, I do use the User-Agent lines reported in my server logs to make general decisions about which browsers to spend time getting the CSS to work properly. |
| 16:48 | <BenMillard> | hence I still support IE6 |
| 16:49 | <Philip`> | Mozilla/5.0 (compatible; Konqueror/3.1; Linux 2.4.22-10mdk; X11; i686; fr, fr_FR) |
| 16:49 | <Philip`> | Mozilla/5.0 (compatible; Konqueror/3.1-rc3; i686 Linux; 20020515) |
| 16:49 | <Philip`> | are in my logs, so I guess it looks like 3.1 didn't say "KHTML" |
| 16:49 | <Lachy> | wow, now RB is claiming that "The longdesc attribute is not another linking mechanism." |
| 16:50 | <Lachy> | anyway, he's at the top of my do-not-respond list, so I definitely won't be responding to his nonsense |
| 16:52 | <BenMillard> | Lachy, as planned I've happily returned to my "ignore nearly everything which happens on Public-HTML" mode |
| 16:53 | <Philip`> | I suppose he's saying it's wrong to always think of it like <a href> when it could be processed like <iframe src> instead, which sounds sort of reasonable by itself |
| 16:53 | <BenMillard> | Lachy, it enables me to spend time doing stuff which is useful. :) |
| 16:54 | <Lachy> | Philip`, the way longdesc is implemented in UAs is exactly like a link, even if they choose to open in a new window by default. No implementation has yet used it to somehow embed the resource within the page itself |
| 16:55 | <Lachy> | although, hypothetically, I suppose they could do that, but then the same argument could be made about href too |
| 16:55 | <webben> | "This attribute specifies a link to a long description of the image". |
| 16:55 | <webben> | yep, it is a "link" of sorts, though no UI is mandated for either |
| 16:56 | <webben> | as you say |
| 16:58 | <Lachy> | BenMillard, ignoring it seems like a good idea. As of this morning, I decided to send no more responses to those longdesc threads |
| 16:58 | <annevk> | that's a bit late dude :p |
| 16:59 | <BenMillard> | webben, according to HTML4: "The alt attribute provides a short description of the image. This should be sufficient to allow users to decide whether they want to follow the link given by the longdesc attribute to the longer description, here 'sitemap.html'." -- http://www.w3.org/TR/html4/struct/objects.html#idx-long_image_description |
| 16:59 | <Lachy> | annevk, yeah, I know. I got sucked into feeding the trolls again :-( |
| 16:59 | <BenMillard> | webben, so HTML4 thinks longdesc is like href and alt is like the content area of <a href>, by my reading. |
| 17:00 | <webben> | for some value of "like href" that's true. they both specify links, namely, although different types of links |
| 17:02 | <BenMillard> | webben, according to HTML4: "The src attribute specifies the initial document the frame will contain." -- http://www.w3.org/TR/html4/present/frames.html#idx-frame-3 |
| 17:02 | <BenMillard> | webben, so HTML4 thinks src immediately loads the resource, whereas it thinks longdesc is fetched on demand. |
| 17:03 | <BenMillard> | (either of those could be changed in HTML5, of course) |
| 17:03 | <webben> | for frames at least. |
| 17:04 | <webben> | BenMillard: Something could be loaded on demand into an img or frame, I guess. |
| 17:04 | <webben> | bit like an img can be selectively enabled in Fx. |
| 17:04 | <BenMillard> | webben, hey this is weird, <iframe src> links through to <input src> for it's definition of src! (http://www.w3.org/TR/html4/present/frames.html#edef-IFRAME and http://www.w3.org/TR/html4/interact/forms.html#adef-src respectively) |
| 17:05 | <BenMillard> | webben, I was going by the Index of the HTML4 Attributes, which lists <frame src> as applying to both <frame> and <iframe>: http://www.w3.org/TR/html4/index/attributes.html |
| 17:05 | <webben> | oh noes ... best report it for the all important HTML 4.01 errata ;) |
| 17:06 | <BenMillard> | I think that's called HTML5, isn't it? :P |
| 17:40 | <BenMillard> | Hixie, I just noticed HTML4 uses bee-keeping in an example here (never noticed that before): http://www.w3.org/TR/html4/struct/global.html#edef-TITLE |
| 17:43 | <hsivonen> | zcorpan_: ASCII whining fixed. thanks. |
| 17:43 | <hsivonen> | Hixie: </p> whining on </dd> fixed. thanks |
| 17:46 | <annevk> | hsivonen, is there some Web SVN view on Validator.nu progress? |
| 17:47 | <hsivonen> | annevk: there isn't |
| 18:01 | hsivonen | cuts source location comparisons when validating cnn.com by 87% by replacing TreeSet with appropriately head and tail biased linked list-backed SortedSet implmentations |
| 18:01 | <hsivonen> | it was rather surpising that location comparisons for Show Source were a hot spot |
| 18:11 | <sicking> | annevk, Hixie: ping |
| 18:28 | Philip` | can now write data to files with an entirely lovely combination of RandomAccessFile and ByteArrayOutputStream and DeflaterOutputStream and cPickle |
| 18:29 | <Philip`> | (It makes me feel a bit dirty :-( ) |
| 18:47 | <zcorpan_> | hsivonen: do you have a regression testing system for v.nu? |
| 19:01 | <Hixie> | BenMillard: yeah that's where it comes from |
| 19:02 | <Hixie> | sicking: pong, but about to go offline for a bit |
| 19:02 | <sicking> | Hixie, word on the street is that HTML5 says that myHTMLNode.localName should return lower case? |
| 19:03 | <sicking> | Hixie, you sure that's not going to break stuff given that gecko has returned upper case for ages? |
| 19:03 | <sicking> | Hixie, or rather, what do you have to indicate that that won't break stuff :) |
| 19:04 | <Hixie> | webkit returns lowercase |
| 19:04 | <Hixie> | and i got several requests to keep at least one thing consistent between XHTML and HTML |
| 19:04 | <Hixie> | so it seemed like the least dangerous choice |
| 19:05 | <sicking> | least dangerous why? |
| 19:05 | <sicking> | it does seem like the most desireable for sure, not sure about least dangerous |
| 19:05 | <Hixie> | well tagName seemed like a big danger in comparison, e.g. |
| 19:05 | <Hixie> | and localName is relatively new compared to the others |
| 19:05 | <Hixie> | i'm not saying _not_ dangerous |
| 19:05 | <Hixie> | just _least_ dangerous |
| 19:05 | <Hixie> | i really have to go now |
| 19:06 | <Hixie> | send mail if you want to follow up |
| 19:06 | <Hixie> | or wait a few hours :-) |
| 19:06 | <sicking> | ok |
| 19:15 | <zcorpan_> | sicking: hey |
| 19:16 | <sicking> | zcorpan_, yo |
| 19:16 | <zcorpan_> | sicking: i'm working on fixing dom core - http://simon.html5.org/specs/web-dom-core |
| 19:17 | <zcorpan_> | sicking: i'm considering dropping error checking altogether, do you think that would be feasible? |
| 19:21 | <sicking> | zcorpan_, what is that spec, i've never seen it before |
| 19:21 | <sicking> | zcorpan_, it seems to have a lot of missing parts |
| 19:23 | <sicking> | zcorpan_, and specifically which error checking do you want to drop? the nodename ones? |
| 19:26 | <zcorpan_> | sicking: i started to work on it last week |
| 19:26 | <zcorpan_> | sicking: the checking against XML and XMLNS productions |
| 19:28 | <sicking> | zcorpan_, how do you mean? |
| 19:28 | <zcorpan_> | e.g. createElementNS throws if you pass in something that's not a QName |
| 19:28 | <sicking> | zcorpan_, ok |
| 19:28 | <sicking> | zcorpan_, is that something that we really don't want to enforce? |
| 19:29 | <sicking> | zcorpan_, we've enforced that in gecko for a while and I don't think i've seen any bugs about it |
| 19:29 | <zcorpan_> | sicking: thing is that it's not enforced, you can still get elements that aren't QName by adopting elements from other documents |
| 19:30 | <zcorpan_> | sicking: and the checking is arbitrary, everything isn't checked and some things are checked but not against what xml says but something different |
| 19:30 | <sicking> | zcorpan_, hmm.. |
| 19:30 | <sicking> | zcorpan_, i guess the html parser can produce a somewhat larger set of node names |
| 19:30 | <sicking> | zcorpan_, still has some restrictions though |
| 19:31 | <zcorpan_> | sicking: indeed |
| 19:31 | <sicking> | zcorpan_, the two things that i remember specifically not wanting to allow was null characters and spaces in node names |
| 19:31 | <zcorpan_> | sicking: i'd be fine with checking for things that the html parser can't produce |
| 19:32 | <zcorpan_> | sicking: but right now it's just arbitrary and useless imho |
| 19:32 | <sicking> | zcorpan_, i'd be fine with loosening things a little, but i don't think i want to get too crazy |
| 19:32 | <sicking> | zcorpan_, i don't see much value in allowing too crazy node names |
| 19:33 | <zcorpan_> | sicking: ok |
| 19:34 | <sicking> | zcorpan_, but in general allowing the DOM and the parser to create the same set of names makes sense to me |
| 19:35 | <zcorpan_> | sicking: ok. thanks |
| 19:36 | <zcorpan_> | sicking: another thing, gecko in quirks mode allows createElement('<div>'), but opera and webkit don't |
| 19:36 | <zcorpan_> | sicking: is that something that could be changed in gecko? |
| 19:36 | <sicking> | zcorpan_, yeah, that originally came from some internal sites at IBM |
| 19:37 | <sicking> | zcorpan_, hard to say, i'm sure sites will break if we remove it |
| 19:37 | <sicking> | zcorpan_, the syntax originally comes from IE which allows you to do stuff like createElement('<div foo=bar>') |
| 19:38 | <sicking> | zcorpan_, but we didn't want to go that far |
| 19:38 | <sicking> | zcorpan_, i think we added support for this pretty recently, around 4 years ago or so |
| 19:40 | <zcorpan_> | sicking: hmm. i see we have at least one bug on createElement('<p>') |
| 19:40 | <zcorpan_> | http://www.voetaf.com.br/ |
| 19:41 | <zcorpan_> | or it does document.createElement("<OPTION>"); |
| 19:42 | <zcorpan_> | i don't want to have createElement be different in quirks mode though |
| 19:48 | <zcorpan_> | sicking: do you consider '1' to be a crazy element name? |
| 19:49 | <sicking> | zcorpan_, well, i think the discussion should be had in a broader audience. But from a security point of view that is fine with me |
| 19:49 | <zcorpan_> | sicking: ok |
| 19:49 | <sicking> | zcorpan_, possibly we could allow crazier names for HTML nodes than for non-HTML nodes |
| 19:54 | <Hixie> | clearly some characters shouldn't be allowed in tag names |
| 19:54 | <Hixie> | e.g. ' ' or '>' |
| 19:54 | <Hixie> | so if we're going to have to do checks anyway |
| 19:55 | <Hixie> | it seems like we might as well do more |
| 19:56 | <zcorpan_> | IE allows ' ' and '>' as tag name |
| 19:57 | Hixie | is generally reluctant to change the spec given how much effort has gone into following the spec and testing it in the first place |
| 20:00 | <zcorpan_> | i wonder where dom core discussion should take place |
| 20:06 | <hsivonen> | zcorpan_: I have a system waiting without the tests, because I haven't yet seen Hixie say that the spec is stable enough for a lot of test to be written |
| 20:06 | <hsivonen> | zcorpan_: I suppose i should start writing tests regardless |
| 20:23 | <zcorpan_> | hsivonen: you could write tests as you fix bugs |
| 20:24 | <zcorpan_> | hsivonen: how does the system work? if i want to contribute with tests |
| 20:26 | <hsivonen> | The system requires each test to live on an HTTP server somewhere |
| 20:27 | <hsivonen> | then the tester front end is asked to dump JSON for that URL |
| 20:27 | <hsivonen> | this JSON can the be edited to make the permitted error locations more wide |
| 20:28 | <hsivonen> | then the JSON reference dump is committed to a big JSON file using the front end tool |
| 20:28 | <hsivonen> | the front end can then run all the tests in the big file or be asked to run individual tests |
| 20:29 | <hsivonen> | also, there's a testing system for the tokenizer (html5lib) and thee builder (html5lib) |
| 20:29 | <hsivonen> | but the bugs you found recently where ouside the tokenizer in the IO layer |
| 20:30 | <hsivonen> | I'm not at my develoment machine ATM |
| 20:30 | <hsivonen> | I can write docs for this tomorrow |
| 20:31 | <zcorpan_> | hsivonen: so how would a test for the ascii bug look like? |
| 20:32 | <hsivonen> | zcorpan_: <!DOCTYPE html><title>รค</title> served without charset on the HTTP layer |
| 20:33 | <zcorpan_> | hsivonen: doesn't it need to say somehow what is expeced? |
| 20:34 | <hsivonen> | zcorpan_: yeah, but I can't autogenerate the reference JSOn from this computer |
| 20:34 | <zcorpan_> | hsivonen: ah ok |
| 20:34 | <hsivonen> | but it's basically the out=json format |
| 20:54 | <Dashiva> | I see JF still thinks that any decision made at any point equals attaching semantic meaning |
| 20:58 | <Lachy> | Dashiva, that line of reasoning is just stretching the truth in order to fit his preconceived notions |
| 20:58 | <Dashiva> | How would he handle an image that was selected at random, like Hixie's front page image? |
| 20:59 | <Lachy> | now he's going for the whole "choice" argument, saying we should include it simply because it provides another choice |
| 20:59 | <Hixie> | why do you people even listen to the guy |
| 20:59 | <annevk> | sicking, pong |
| 20:59 | <Hixie> | he's obviously either a crackpot or a troll |
| 21:00 | <Lachy> | Hixie, we don't, he's just funny |
| 21:00 | <Lachy> | well, his arguments are |
| 21:00 | Hixie | starts his stopwatch to see how long it takes for someone to complain to public-html about his inappropriate behaviour |
| 21:00 | <Dashiva> | Hixie: I do it to atone for my otherwise merciless commentary |
| 21:00 | <jgraham> | I wonder if he has ever heard of the paradox of choice? Or used a Mac |
| 21:01 | <Dashiva> | I bet he's a big fan of linux on the desktop ;) |
| 21:01 | jgraham | is a big fan of gnome-on-linux-on-the-desktop :) |
| 21:02 | <annevk> | sicking, I guess you settled it with Hixie |
| 21:23 | annevk | wonders who those anonymous people are who are spamming Chrome accessibility links on his blog |
| 22:26 | <annevk> | news.google.com/newspapers is slowish |
| 22:26 | <annevk> | been a long time since I've encountered that at a Google site |
| 22:27 | <annevk> | (where slowish means not possible to use) |
| 22:28 | <Philip`> | Seems to work alright for me, although the timeline view indicates that "google" has been mentioned at fairly constant non-zero rate since 1890 |
| 22:32 | <svl> | date extraction is totally screwy. taking birthdays and the like as publication dates |
| 22:33 | <Philip`> | It has a Wikipedia page dated to 1969 too |
| 22:37 | <Lachy> | oh, cool, that must have been from the old days when wikipedia was edited on blackboards with chalk and dusters. |
| 22:39 | <Philip`> | Reverting vandals was a huge pain back then |
| 22:40 | <annevk> | the frontpage is fast enough btw |
| 22:40 | <annevk> | it was browsing newspapers that was not doable |
| 22:41 | annevk | finds "4004 BC" |
| 22:44 | <Lachy> | Philip`, yeah, especially those vandals that did their handywork with spray paint. |
| 22:52 | Philip` | wonders if anyone has made a form of XML that allows efficient random access into files |
| 23:32 | <annevk> | Opera actually shows EXIF data if you rightclick an image and hit properties |
| 23:33 | <annevk> | seems that Flickr removes it for everything but the original photo though |
| 23:36 | <annevk> | roc, thanks for http://weblogs.mozillazine.org/roc/archives/2008/09/some_boring_css.html |
| 23:36 | <Hixie> | earliest mention of me seems to be: |
| 23:36 | <Hixie> | Aug 16, 1999 - "I am quite happy to work for mozilla just to get a decent, free, standards compliant browser onto the market," said Ian Hickson, a Web developer from the UK who contributed to the mozilla BugAThon project. "That is an incentive in itself, the rest is just a bonus." |
| 23:36 | annevk | filed that long ago |
| 23:36 | <Hixie> | (earliest mention in actual news, anyway) |
| 23:36 | <annevk> | Google claims my about page is the earliest mention of me |
| 23:36 | <Hixie> | i was 19 at the time. i was a random student, not a "Web developer from the UK" |
| 23:36 | <annevk> | from 1986 |
| 23:37 | <Hixie> | hah |
| 23:41 | <roc> | annevk: no sweat |
| 23:43 | <annevk> | I don't think I ever positioned the root element for any purpose, but positioning the body element against the root element that has a border was something I tried |
| 23:43 | <annevk> | (which then failed in Firefox at which point I filed that bug) |
| 23:45 | <roc> | when you filed the bug I don't think anyone except Opera got it right |
| 23:47 | <annevk> | yeah |
| 23:50 | <Hixie> | othermaciej, roc, annevk: your input on http://lists.w3.org/Archives/Public/ietf-http-wg/2008JulSep/0441.html would be very welcome |
| 23:51 | <Hixie> | if there's someone in your respective organisations i should ping in particular, i'd be happy to do so, just let me know |
| 23:51 | <othermaciej> | Hixie: interesting |
| 23:51 | <othermaciej> | Hixie: any quantitative results available? |
| 23:52 | <Hixie> | the numbers vary a lot based on the kind of page, from what i understand |
| 23:52 | <othermaciej> | Hixie: I am interested in how much it saves compared to gzip compression |
| 23:53 | <othermaciej> | Hixie: or other straightforward compression schemes |
| 23:53 | <Hixie> | well, for a page like, say, the google results page, gzip can only compress the page, whereas this can compress the header and footer parts dramatically |
| 23:54 | <othermaciej> | I see a slide deck, guess I will look at that |
| 23:54 | <othermaciej> | sure it sounds interesting in theory |
| 23:54 | <roc> | Lab result |
| 23:54 | <Hixie> | the proposal is in the PDF |
| 23:54 | <roc> | About 40 percent data reduction better than Gzip alone on Google search. |
| 23:54 | <othermaciej> | I would like to see numbers |
| 23:54 | <roc> | See faster Google search results. Especially under low bandwidth and high latency condition. |
| 23:54 | <roc> | so would I |
| 23:54 | <Hixie> | i shall poke for numbers |
| 23:54 | <othermaciej> | preferably on a wide range of sites |
| 23:55 | <othermaciej> | having a per-site compression index does carry some risks |
| 23:55 | <othermaciej> | complexity, new attack surface, etc |
| 23:55 | <Hixie> | for sure |
| 23:55 | <othermaciej> | but it also sounds in theory like it could be a big win |
| 23:55 | <roc> | yeah |
| 23:55 | <Philip`> | Also it'd be interesting to compare to gzip with a preset dictionary |
| 23:55 | <roc> | in principle it sounds good |
| 23:55 | <othermaciej> | true, a preset dictionary for the general web including common html and css constructs might be a big win too |
| 23:56 | <roc> | this could subsume that if you allow Access-Controls on dictionaries |
| 23:57 | <Philip`> | (Also maybe to gzip of multi-request/response keepalived stream (i.e. compress the whole stream, not just each response separately)) |
| 23:57 | <othermaciej> | and btw I am specifically interested in perf on a large variety of realistic examples, not just the best-case examples |
| 23:57 | <Hixie> | yeah |
| 23:57 | <othermaciej> | (or else convincing argument that best case is very common) |
| 23:57 | <roc> | search pages are pretty common |
| 23:57 | <Philip`> | Maybe we could just hardcode Google's header and footer into all UAs |
| 23:57 | <roc> | but yeah |
| 23:58 | <othermaciej> | I would hope it is more broadly applicable than google search result pages |
