| 00:00 | htmlfivedotnet | suggests http://www.sun.com/software/vmware/getit.jsp |
| 00:02 | <hsivonen> | Philip`: so each instruction number corresponds to one byte op and one byte arg, right? |
| 00:02 | <hsivonen> | so the size in roughly number of instructions times two? |
| 00:08 | <hsivonen> | nope. times one |
| 00:09 | <Philip`> | hsivonen: javap shows the byte offset of each instruction, so you should be able to just look at the last one in the method |
| 00:09 | <Philip`> | (Instructions are variable length; I've got no idea what a sensible average is) |
| 00:10 | <hsivonen> | now I got the big method to compile |
| 00:10 | <hsivonen> | much better but still sucks |
| 01:23 | <Hixie> | annevk: yt? |
| 01:23 | <Hixie> | On Fri, 11 Apr 2008, Anne van Kesteren wrote: |
| 01:23 | <Hixie> | > |
| 01:23 | <Hixie> | > Euhm, setItem() takes two strings. Therefore I'd expect null, undefined, |
| 01:23 | <Hixie> | > etc. to be stringified. |
| 01:23 | <Hixie> | i don't understand what that means |
| 01:27 | <Dashiva> | null => 'null' |
| 01:39 | <Hixie> | but why? |
| 03:08 | <othermaciej_> | what is setItem? |
| 03:09 | <othermaciej> | DOM APIs are pretty inconsistent about whether null is treated same as empty string, or same as 'null', when they take a string |
| 03:11 | <Hixie> | Storage.setItem() |
| 03:11 | <Hixie> | i guess we'll have to get heycam to decide the default, and then give us a flag thingy for the cases where it's the other way around |
| 03:13 | <heycam> | Hixie, currently null gets passed as null to DOMString arguments unless the [NoNull] extended attribute appears on it |
| 03:13 | <heycam> | then it'll always get stringified |
| 03:13 | <Hixie> | to what? |
| 03:13 | <heycam> | to 'null' |
| 03:13 | <Hixie> | oh |
| 03:13 | <Hixie> | is that ever what we want? |
| 03:13 | <Hixie> | i'd have expect it to be null or '' |
| 03:14 | <heycam> | i think i remember some things actually stringifying the parameter, resulting in 'null' |
| 03:14 | <heycam> | was it .textContent? dunno now. |
| 07:17 | <jacobolus> | hmm. this question had no response in #webkit, so i'll try here. does anyone know what the proper behavior is for rendering a table where the tbody has a specific height set in css? |
| 07:17 | <jacobolus> | webkit ignores the height, ff2 makes it take up that much space, but leaves rows rendering as they had, ff3 expands rows until they fill up the specified height |
| 07:17 | <jacobolus> | this doesn't seem to really be covered by http://www.w3.org/TR/CSS21/tables.html |
| 07:18 | <jacobolus> | example: http://cs179-spring-2008.seas.harvard.edu/wheatmuffin/prototype/index_2008.04.27-3.html |
| 07:18 | <jacobolus> | here, ff2 does what I want it to, while the other two don't |
| 07:18 | <jacobolus> | if this is unspecified, is there some better way of achieving the same effect? |
| 07:20 | <jacobolus> | opera also seems to ignore it |
| 07:21 | <Hixie> | jacobolus: see css |
| 07:21 | <Hixie> | iirc 'height' doesn't apply to table sections |
| 07:22 | <jacobolus> | all elements but non-replaced inline elements, table columns, and column groups |
| 07:22 | <jacobolus> | which would seem to imply it should apply to row groups |
| 07:23 | <jacobolus> | the behavior difference between ff2 and ff3 is also puzzling though |
| 07:26 | <jacobolus> | Hixie: in general, what happens to heights in tables seems rather underspecified |
| 07:27 | <Hixie> | yeah |
| 07:27 | <Hixie> | indeed |
| 07:27 | <Hixie> | let the wg know |
| 07:28 | <jacobolus> | what's the best way to do that? |
| 07:29 | <jruderman> | http://landfill.bugzilla.org/complaints/show_bug.cgi?id=22 |
| 07:30 | <jacobolus> | jruderman: there are no steps to reproduce there |
| 07:30 | <jruderman> | jacobolus: if you think of good ones, you should add them |
| 07:31 | <jacobolus> | jruderman: also, no expected behavior vs. actual behavior |
| 07:31 | <jruderman> | otoh, it's a complaint system, so not everything needs steps to reproduce |
| 07:31 | <jacobolus> | :p |
| 07:31 | <jruderman> | for example, http://landfill.bugzilla.org/complaints/show_bug.cgi?id=21 does fine without them |
| 07:32 | <jacobolus> | Hixie: wait, is the css 3 tables spec really password protected? |
| 07:33 | <jacobolus> | (it's a working draft, according to http://www.w3.org/Style/CSS/current-work) |
| 07:33 | <jacobolus> | or does that just mean they don't have anything yet? |
| 07:36 | <Hixie> | don't ask me, i gave up on the csswg a year or more ago |
| 07:36 | <jacobolus> | heh. fair enough |
| 07:37 | <jacobolus> | well, any suggestions for how to get a scrollable tbody with a fixed thead, without setting the height of the tbody and setting its overflow-y to scroll? |
| 07:37 | <jacobolus> | (I suppose that's a bit off topic for this channel; not sure where else I'd ask) |
| 07:38 | <othermaciej> | css wg is planning more openess |
| 07:38 | <othermaciej> | that process is moving at a gradual place |
| 07:42 | <Hixie> | i'd have used another g word |
| 07:42 | <Hixie> | "glacial" |
| 07:45 | <Hixie> | but to each his own |
| 07:54 | <annevk> | Hixie, for quite a few things null becomes 'null' |
| 07:54 | <annevk> | iirc |
| 07:54 | <annevk> | for IE compat |
| 07:54 | <Hixie> | k |
| 07:55 | <Hixie> | someone should let me know what they are so i can pepper [NoNull]s around the spec |
| 07:55 | <Hixie> | :-) |
| 08:03 | <annevk> | Hixie, "<span>browsing content</span>" |
| 08:05 | <Dashiva> | othermaciej: Does refusing IRC logging make up part of that process? ;) |
| 08:05 | <othermaciej> | Dashiva: they just want the logging done in a carefully considered, measured, slow way |
| 08:10 | Dashiva | avoids further comment |
| 08:11 | <jacobolus> | Dashiva: someone might prevent you from running for world leader 20 years from now, if they see what you wrote in some technical IRC channel! |
| 08:12 | <Dashiva> | That reminds me of the conspiracy of light mail when Hyatt became editor |
| 08:15 | <jacobolus> | Dashiva: and you see, because of IRC logs (http://krijnhoetmer.nl/irc-logs/html-wg/20070423#l-55) now zcorpan is implicated too. |
| 08:15 | <Dashiva> | That's okay, he was part of the vast browser wing conspiracy already |
| 08:16 | <annevk> | and also proud member of the secret WHATWG cabal |
| 08:17 | <Hixie> | not gonna be secret for long if y'all keep talking about it in public!!! |
| 08:18 | <othermaciej> | I thinkt it was top secret that the secret cabal is secret |
| 08:18 | <othermaciej> | how can you just openly admit that it is secret like that? |
| 08:19 | annevk | is not sure what to say |
| 08:19 | <Dashiva> | One of these days I'm actually going to join #whatwg-secret-treehouse |
| 08:19 | annevk | blames krijn for logging |
| 08:19 | jacobolus | hears nothing |
| 08:28 | <jacobolus> | Hixie: do people *really* want modal dialogs in html5? modal dialogs suck :/ |
| 08:29 | <jacobolus> | can't you just ignore them and hope they go away? :) |
| 08:29 | <Hixie> | both mozilla and safari were forced to implement showModalDialog() |
| 08:29 | <Dashiva> | If you don't give them modal dialogs, they create them with CSS and ruin your page |
| 08:29 | <Hixie> | apparently if you don't give them modal dialogs, they don't support our browser |
| 08:29 | <Dashiva> | (or that) |
| 08:38 | <annevk> | should there be a way to do in page modal dialogs? like limit all interactivity to a given DOM element and descendents |
| 08:40 | <annevk> | so you can implement your own menus and such in case the native ones are not good enough |
| 08:42 | <jacobolus> | annevk: you mean instead of dumping a gigantic invisible un-clickable element over the whole page, then putting the new element w/ a higher z-index? |
| 08:43 | <jacobolus> | that seems to work reasonably well in my experience |
| 08:43 | <jacobolus> | but maybe isn't super clean (requires javascript) |
| 08:43 | <jacobolus> | annevk: doesn't seem like enough of a use case to add as a feature though |
| 08:44 | <jacobolus> | also, encouraging people to use modal dialogs is bad :) |
| 08:45 | <jgraham__> | annevk: "should there be a way [...] to do modal dialogs" is already "no but we have to sped the existing method. I don't think we need authors to have more ways to annoy their users :) |
| 08:45 | <jgraham__> | s/sped/spec/ |
| 08:45 | <annevk> | I was mostly thinking about contextmmenus and normal menus |
| 08:45 | <annevk> | and similar uses |
| 08:45 | <annevk> | which are modal in some way too |
| 08:46 | <annevk> | though they're arguably not dialogs so I messed that up |
| 08:47 | <jgraham__> | Well I guess if you can enforce the "click anywhere off the menu and normal operations are restored" behaviour then it wouldn't be so bad |
| 08:47 | <Hixie> | we have a solution for menus already |
| 08:53 | <krijn> | -_- |
| 09:25 | <hsivonen> | it's a bit silly that there should be two parse errors in '<!DOCTYPE html SYS'EOF |
| 09:27 | <Hixie> | you only have to report one :-) |
| 09:27 | <Philip`> | It's a bit silly that '<!DOCTYPE' has more parse errors than either '<!DOCTYP' or '<!DOCTYPE ' |
| 09:27 | <hsivonen> | Hixie: the test cases want two |
| 09:27 | <Hixie> | the test cases are fascist |
| 09:28 | <hsivonen> | but then they want only one for '<!DOCTYPE html PUBLIC'EOF |
| 09:28 | <hsivonen> | that's painful |
| 09:30 | <hsivonen> | Philip`: I'm back to reasonable perf by keeping the tokenization loop just under 8000 bytes |
| 09:31 | <Philip`> | hsivonen: Hopefully future versions HotSpot (and other people's JVMs) won't have a smaller limit than that - seems a little dodgy but I'm not sure what else you could do :-/ |
| 09:33 | <hsivonen> | Philip`: tweaking things for HotSpot are painful and silly enough. I'm not going to worry too much about IBM or BEA or whatever JVMs at this point |
| 09:34 | <hsivonen> | Philip`: anyway, any conclusions yesterday about switch itself are wrong |
| 09:34 | <hsivonen> | the thing that makes switch "death slow" is that making a huge switch easily makes the method too large |
| 09:37 | <hsivonen> | now I have to add a couple of states for [CDATA[ it'll be interesting to see if doing so breaks the limit again |
| 09:38 | <hsivonen> | also, I wonder if object fields and spilled locals make a perf difference |
| 09:38 | <hsivonen> | and how many locals fit it registers on x86_64? |
| 09:42 | <annevk> | you're going to add math support? |
| 09:42 | <Hixie> | anyone got a pool going on how long it'll take for the svgwg to get back to us, btw? |
| 09:43 | <annevk> | given that Doug is on holiday I guess it will take a while |
| 09:46 | <Hixie> | i guess we'll wait until after webforms2 is dealt with |
| 09:48 | <annevk> | eternity+1 |
| 09:48 | <Philip`> | Interacting with other WGs is fun |
| 09:48 | <Hixie> | actually the dealine for wf2 is rapidly approaching |
| 09:49 | <Hixie> | june? july? something like that? |
| 09:49 | <annevk> | true |
| 09:49 | annevk | looks |
| 09:49 | <annevk> | July 2008 per http://www.w3.org/2007/10/forms-tf/charter-proposal |
| 09:49 | <annevk> | (and some e-mail that states the charter has been approved by the TF by implicit consent) |
| 09:50 | <hsivonen> | annevk: yes, I'm going to add math support |
| 09:50 | <hsivonen> | but I think I should prepare XTech slides first |
| 09:55 | <annevk> | hmm, XTech slides... |
| 10:35 | hsivonen | finds -XX:-DontCompileHugeMethods |
| 10:41 | <hsivonen> | it's particularly Not Nice that the option isn't documented in the usual HotSpot documentation |
| 10:45 | <Philip`> | http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6453531 - "The VM is tuned for compiling for the common programming paradigm, which includes generally small methods." - it would be nice if it was merely tuning, rather than order-of-magnitude differences |
| 10:51 | <hsivonen> | I'd be interested to know when compiling a > 8000-byte method actually hurts |
| 10:52 | <Philip`> | It would hurt when the compiler is O(n^2) |
| 10:53 | <hsivonen> | perhaps, but the 8000 sucks big time for parsers and generated code |
| 10:54 | <hsivonen> | it's quite reasonble to compile a program written in a non-Java language into one huge Java method with a lot of goto |
| 11:03 | <Philip`> | Maybe it's a problem of trying to optimise the JVM for benchmarks and for common applications, since that's how people try to measure performance, and any code that does something significantly different will lose out |
| 11:05 | <hsivonen> | well, yeah, but it's not like tokenizer state machines (generated or hand-written) or dynamic or functional languages compiled to Java are rare and bizarre these days |
| 11:08 | <hsivonen> | it seems that other people who've hit this problem are doing something as enterprisey as JSP! |
| 11:19 | <Philip`> | hsivonen: Enterprisey people can just buy a 16-core CPU to replace their old server, and that'll make up for the loss of performance between Java 1.5 and 1.6 |
| 11:22 | <Philip`> | Hmm, I wonder who's making 16-core CPUs |
| 11:22 | <Philip`> | Oh! Sun is - how convenient |
| 15:49 | <htmlfivedotnet> | Philip: Of course they are. And they cost how much? 10K Euros? |
| 15:57 | <Philip`> | htmlfivedotnet: The 16-core CPUs? I have no idea how much they are likely to be, but I'd have to guess they're not cheap :-) |
| 16:01 | <gsnedders> | Philip`: Sun aren't making 16-core CPUs. They only make 8-core ones (which can run 64 threads concurrently). |
| 16:05 | <Philip`> | gsnedders: 8 cores wouldn't be enough to make up for an order of magnitude performance loss, so I was thinking of the not-quite-released Rock processors which Wikipedia says has 16 cores :-p |
| 16:05 | <gsnedders> | ah, Rock. That isn't released! That doesn't count :P |
| 16:08 | <Philip`> | gsnedders: I never said Sun was actually shipping 16-core processors, only that they were making them |
| 16:08 | <Philip`> | and http://blogs.sun.com/jonathan/entry/rock_arrived indicates that they have made at least one |
| 16:55 | <htmlfivedotnet> | Has anyone else heard here about MS plans to throw CSS3 under the bus? |
| 16:56 | <htmlfivedotnet> | oh god. nevermind. please don't listen to me. i just read an april fools joke that spanned across two sites. i hate april 1st. |
| 17:18 | <gsnedders> | htmlfivedotnet: They already support some CSS3 modules (such as almost all of selectors) in IE7 :P |
| 17:26 | <htmlfivedotnet> | gsnedders: Yeah. I knew that too. I just woke up, haven't had my coffee, and wasn't thinking straight. Oh well. |
| 17:33 | <htmlfivedotnet> | I have a question, and please let me know if this isn't a good place to ask, and i'll keep them out of here, but there are pages, like the google cache page, that use frames. With the html5 spec, would the only way to be able to display the page in a similar manner be to use scripting? And if so, doesn't it seem inefficient to remove functionality from the html spec? It seems like the client-side and server-side would have to d |
| 17:34 | <takkaria> | htmlfivedotnet: your comment was cut off at "would have to d" |
| 17:34 | <htmlfivedotnet> | do more work in a case like this |
| 17:37 | <Philip`> | htmlfivedotnet: Google cache has never used frames, as far as I've seen - it just adds some code into the top of the page to create its ugly box with information |
| 17:37 | <Philip`> | Might you be thinking of Google Image search results instead? |
| 17:38 | <htmlfivedotnet> | yes. i'm sorry, i do mean google image search. |
| 17:38 | <Philip`> | I suppose that could be implemented using <iframe> instead |
| 17:39 | <Philip`> | Don't know if there would be any problems with that approach |
| 17:39 | <htmlfivedotnet> | well, there would be the backwards compatibility issue |
| 17:39 | <Philip`> | <iframe> is backwards-compatible |
| 17:40 | <htmlfivedotnet> | i know recent browsers don't behave the same with an iframe in all cases, at least as far as setting it to the page width, and positioning (which i guess is a css-issue moreso) |
| 17:40 | <htmlfivedotnet> | which is i guess where the major part of the scripting would come in, and window resizing. |
| 17:41 | <Philip`> | Ah, okay |
| 17:42 | <hsivonen> | hmm. Image Report shows that I've written bad alt text in 2003 |
| 17:42 | Philip` | isn't quite sure of what problems there are |
| 17:44 | <htmlfivedotnet> | accessibility is a major one, from what i've heard, as well as search engine crawling: they determine it to be a separate page (which may or may not be the intended result... i'm not sure) |
| 17:45 | <Philip`> | htmlfivedotnet: Perhaps it's reasonable to say that browsers will have improved in the years before everyone should start using HTML 5, and so iframe CSS bugs won't matter much by then |
| 17:45 | <Philip`> | and people like Google can still use <frameset> if they want to be more compatible with really old browsers, because they don't care whether their code validates or not |
| 17:47 | <htmlfivedotnet> | philip: good point. i guess i don't see the *ahem* "sense of logic" in ditching frames, but keeping something that doesn't have any practical use like the "font" element... unless its specifically there because wysiwyg editors currently like it |
| 17:48 | <Philip`> | htmlfivedotnet: It seems very likely that <font> will be removed from the spec, since everyone hates it, and Hixie just hasn't got around to editing that section yet |
| 17:49 | <Philip`> | http://www.whatwg.org/specs/web-apps/current-work/multipage/section-presentational.html#the-font - "This entire section will probably be dropped." |
| 17:51 | <htmlfivedotnet> | philip: Well that sets my mind at ease. Haven't read that part in a while. Just wanted to say my piece, thank you :-) |
| 17:52 | gsnedders | notes that WYSIWYG editors will just move over to span/div instead :P |
| 17:52 | <Philip`> | gsnedders: Is that a bad thing? |
| 17:52 | <gsnedders> | Philip`: It's no better than the status quo. |
| 17:53 | <gsnedders> | But there again, due to the very nature of WYSIWYG editors they will always output presentational HTML |
| 17:53 | <Philip`> | Hixie said the <font style> thing was an attempt to attach the stigma of 'font' onto 'style' (to discourage people from using 'style'), but it seems to have just attached the stigma to the HTML5 spec instead, |
| 17:53 | <Philip`> | s/,$// |
| 17:54 | <htmlfivedotnet> | i just assumed that it was to allow legacy WYS editors to have an easier transition to new specs |
| 17:56 | <Philip`> | htmlfivedotnet: In the current spec, the only attribute allowed on font is style, and the style attribute is not allowed on any other element; so I think that makes it harder for existing WYSIWYG editors to transition, since they either use <font face size color> or they use <span style> |
| 17:56 | <Philip`> | *they currently use either ... |
| 17:59 | <htmlfivedotnet> | ah. well, i haven't used one in a long while. well cool. thanks for clearing that up |
| 18:00 | <Philip`> | gsnedders: Is the status quo a bad thing? |
| 18:00 | <gsnedders> | Philip`: No, it just seems change for no reason. |
| 18:02 | <Philip`> | gsnedders: Uh, isn't the point of the status quo that it's *not* a change? |
| 18:02 | <gsnedders> | Philip`: I said it's no better than the status quo, not that it is the status quo |
| 18:03 | <Philip`> | gsnedders: Oh, then what is the status quo if it's not using span/div? |
| 18:03 | <gsnedders> | Philip`: That is the status quo. I meant font@style is no better. |
| 18:04 | <Philip`> | gsnedders: Ah, I didn't gather that meaning from your statements :-p |
| 18:05 | gsnedders | hopes he's less confusing in real life |
| 18:06 | <htmlfivedotnet> | haha |
| 18:06 | <Philip`> | gsnedders: When you said "It's no better than the status quo.", I didn't realise that the antecedent of "it" was from half a dozen lines earlier :-) |
| 18:06 | <htmlfivedotnet> | who's on first gsnedders? |
| 18:07 | <gsnedders> | htmlfivedotnet: huh? |
| 18:08 | <htmlfivedotnet> | gnsedders: http://www.phoenix5.org/humor/WhoOnFirst.html |
| 18:09 | <gsnedders> | heh. |
| 18:36 | <gsnedders> | Hmm, if you believe some of my photos' metadata, I've been taking photos on 6th August 2099. |
| 18:37 | <Philip`> | gsnedders: That metadata would make an excellent basis for the semantic web |
| 18:39 | <gsnedders> | I think the dates are totally wrong though, I don't think it's even August. I wasn't on Maderia then. |
| 18:41 | <Philip`> | gsnedders: I think you may be missing a more obvious discrepancy in the dates |
| 18:41 | <gsnedders> | Philip`: I mean discounting the year :) |
| 18:41 | <gsnedders> | So none of it is right whatsoever :) |
| 18:41 | <Dashiva> | What about the time zone? :) |
| 18:42 | <Philip`> | gsnedders: If that's what you meant then you should have said that :-p |
| 18:42 | <gsnedders> | Dashiva: That isn't given :P |
| 18:42 | <gsnedders> | Lesson learnt from this: don't take photos of the Firth of Forth. It screws with your camera :P |
| 18:42 | <Dashiva> | But if it was wrong, you'd have pictures taken at 6 am and stuff |
| 18:42 | <gsnedders> | (or is that the conclusion?) |
| 18:43 | <Philip`> | gsnedders: You need to do a more extensive investigation |
| 18:44 | <gsnedders> | The photos were taken sometime between 23 July 2003 and 22 January 2005. |
| 18:44 | <Philip`> | I suggest taking photos in the same place with somebody else's camera, and then see whether the ill effects affect you or the camera's owner |
| 18:44 | <gsnedders> | And I don't remember being on Maderia in that time |
| 18:44 | <gsnedders> | Philip`: I'll try taking a photo from the train on the way to Cambridge :P |
| 18:45 | <Philip`> | (Do you mean Madeira, as in Madeira cake?) |
| 18:46 | <gsnedders> | (I mean Maderia as in the island in the Atlantic Ocean where the Maderia cake originates from) |
| 18:47 | <Philip`> | (Okay, so you do mean Madeira, not Maderia) |
| 18:47 | maikmerten | wonders if Hixie is active right now |
| 18:47 | <gsnedders> | Philip`: Stop picking on the kid with dyspraxia! :P |
| 18:47 | <gsnedders> | (But yes) |
| 18:48 | <gsnedders> | (and the cake is spelt the same way) |
| 18:48 | <gsnedders> | Actually, I can narrow the date down further. It's after 24 July 2003. |
| 18:48 | <Philip`> | (I was just checking it wasn't some obscure place that I had never heard of and that sounded like somewhere more familiar :-) ) |
| 18:48 | <gsnedders> | (It's a common spelling mistake, actually) |
| 18:49 | <Philip`> | (Google says only about 1% get it wrong, which is hugely better than the number of people who misspell colour) |
| 18:50 | <gsnedders> | Moving swiftly on, http://twitter.com/gsnedders/statuses/798868533 |
| 18:52 | <gsnedders> | (There is a story behind that) |
| 18:53 | <jwalden> | Philip`: color :-P |
| 18:53 | <jwalden> | </snark> |
| 19:16 | <hsivonen> | othermaciej: you may have noticed from the logs that I refactored the Validator.nu parser to use switch instead of methods |
| 19:17 | <othermaciej> | hsivonen: I didn't |
| 19:17 | <othermaciej> | hsivonen: use switch instead of methods for what? |
| 19:17 | <hsivonen> | othermaciej: re: our perf speculation last summer, data now shows that I wasn't nuts to use one method per state |
| 19:17 | <hsivonen> | othermaciej: tokenizer states |
| 19:18 | <hsivonen> | switch has other nice qualities, but perf in Java doesn't appear to be one of them |
| 19:28 | <othermaciej> | hsivonen: how did you do your method lookup before? |
| 19:29 | <hsivonen> | othermaciej: switching to states was method calls. switching to data state was return. there were additional loops around comments and attributes so it wasn't recursive |
| 19:30 | <othermaciej> | hsivonen: I see |
| 19:31 | <othermaciej> | if I were coding it in C++, I'd probably use an array of function pointers per state, but a switch statement might indeed be faster |
| 19:31 | <othermaciej> | (right now our tokenizer is much simpler and more ad-hoc) |
| 19:39 | <jwalden> | there's a tableswitch JVM instruction that probably sufficiently optimizes things |
| 19:39 | Philip` | 's tokeniser spends all its time copying characters between buffers and allocating memory, and no time on the actual switch :-( |
| 19:40 | <hsivonen> | jwalden: sufficiently, yes, but methods aren't madly worse in Java |
| 19:41 | <jwalden> | sure |
| 19:41 | <jwalden> | I wouldn't assert substantial differences between the two |
| 19:41 | <hsivonen> | in fact, on the client VM in short runs, methods are a bit better |
| 19:41 | <hsivonen> | I have to rerun my long server VM tests |
| 19:42 | <hsivonen> | I'm going to keep switch, though, because it enables other nice things |
| 19:42 | <jwalden> | switch does allow commoning of a case with another case sharing its tail, tho |
| 19:42 | <jwalden> | without jumping to a different method and having call setup costs |
| 19:43 | <Philip`> | Methods + inlining would work the same |
| 19:43 | <hsivonen> | (the other nice things are: 1) full suspendability at any point, 2) app owning the IO loop, 3) document.write() and 4) line-by-line porting to C, C++ or Objective-C) |
| 19:44 | <Philip`> | (I want a port to JavaScript) |
| 19:44 | <jwalden> | sure, if you can do it; that's getting into tricky territory in terms of implementation, tho |
| 19:44 | <jwalden> | which is what matters, this all being theoretically equal |
| 19:44 | <hsivonen> | Philip`: you should check if GWT can compile the Validator.nu HTML parser into JS |
| 19:45 | <Philip`> | hsivonen: Compiling Java into JS sounds like more evil than I could bear |
| 19:54 | <jgraham__> | More evil than Philip`can bear? Isn't that some theoretical upper bound on evilness? :) |
| 19:54 | <hsivonen> | Philip`: re: copying buffers: that's one area where the Validator.nu HTML parser isn't optimized |
| 19:55 | <hsivonen> | it always copies element and attribute names, comment contents and attribute values into auxiliary buffers |
| 19:56 | <hsivonen> | this could be changed to happen only when the input buffer can't be used as the backing store of those buffers |
| 19:56 | Philip` | wonders if he should make his parser use UTF-8 everywhere, and just blindly pass char* encoded strings through the tokeniser |
| 19:57 | <jgraham__> | Philip`: Which parser is this? |
| 19:57 | <hsivonen> | well, I use UTF-16 everywhere |
| 19:57 | <Philip`> | jgraham__: The C++ instantiation of my language-independent one |
| 19:57 | jgraham__ | was planning to make chtml5lib do that but hasn't actually worked on chtml5lib |
| 19:58 | <jgraham__> | (where by "that" I mean "use utf-8 everywhere") |
| 19:58 | <Philip`> | hsivonen: I imagine you don't have much choice in string representation when you're using Java :-) |
| 19:58 | <hsivonen> | jgraham__: is chtml5lib a line-by-line port of the Python code? |
| 19:58 | <jgraham__> | hsivonen: chtml5lib is not even vapourware :) |
| 19:58 | <jgraham__> | But the idea was to follow the python code closely |
| 19:58 | <hsivonen> | Philip`: I mean, whatever comes before the tokenizer is responsible for not passing lone surrogates to the tokenizer |
| 19:58 | <Philip`> | Does the spec still say that <table>errôr</table> ought to give a parse error for each character? |
| 19:59 | <jgraham__> | not necessarily line-by-line |
| 19:59 | <hsivonen> | jgraham__: you might get better perf in other ways |
| 19:59 | <jgraham__> | hsivonen: This is true |
| 19:59 | <hsivonen> | I think both my code and Philip`'s code are likely to lead to more performant C than the html5lib code |
| 20:00 | <Philip`> | hsivonen: About UTF-16: Ah, right |
| 20:00 | <Philip`> | What would make an html5lib port non-performant? |
| 20:01 | <hsivonen> | Philip`: it has more recursion and polymorphism that you'd expect to see in C code |
| 20:01 | Philip` | currently just has a big dumb switch and lots of if statements, since his attempts at optimisation had no measurable effect so he took them out again |
| 20:02 | <Philip`> | hsivonen: Ah, makes sense |
| 20:02 | <hsivonen> | all my optimizations that make the tokenizer loop over or under 8000 bytes have a very measurable effect :-) |
| 20:02 | <jgraham__> | It may well have more recursion than python code that aims to be performant |
| 20:03 | <Philip`> | I solve that by using a language without such arbitrary limits :-) |
| 20:03 | <jgraham__> | But optimum performance is not a stated design goal (fortunately) |
| 20:03 | <Philip`> | (Well, I suppose I've occasionally written C++ methods large enough that the compiler simply rejected my program) |
| 20:03 | <jgraham__> | (although it is obviously nice to be faster) |
| 20:03 | <Philip`> | jgraham__: There's already a correct implementation of html5lib, in Python, so isn't the whole purpose of chtml5lib to be fast? |
| 20:04 | <hsivonen> | jgraham__: I thought the goal of chtml5lib was to make Python fast by using C under the hood |
| 20:08 | <jgraham__> | I mean the design goal of html5lib-in-python |
| 20:08 | <jgraham__> | Using C is obviously supposed to help perf :) |
| 20:08 | <Philip`> | Ah, right |
| 20:10 | <jgraham__> | Although I'm not even clear that the project is worth doing now (globally, it may be for me personally) since Philip`and takkaria and hsivonen may all produce C based html5 parsers which I could write python bindings for |
| 20:10 | <jgraham__> | "the project" being chtml5lib |
| 20:10 | <Philip`> | My parser is mostly a toy/experiment so hopefully someone will make a good one instead :-) |
| 20:10 | <htmlfivedotnet> | is failing 1600 of the 7400 tests a normal behavior, or am i missing libs? (html5lib) |
| 20:11 | <jgraham__> | htmlfivedotnet: It's not normal but it shouldn't test libs that you don't have either |
| 20:12 | <Philip`> | htmlfivedotnet: Which version of html5lib? |
| 20:12 | <htmlfivedotnet> | trunk |
| 20:12 | <Philip`> | Ran 7650 tests in 23.214s |
| 20:12 | <Philip`> | FAILED (failures=46, errors=3) |
| 20:12 | <Philip`> | is what I get on trunk |
| 20:13 | <htmlfivedotnet> | FAILED (failures=4, errors=1630) |
| 20:13 | <jgraham__> | Do you have any/all of lxml, BeautifulSoup, pyxdom, chardet? |
| 20:13 | <Philip`> | (for Python, not Ruby) |
| 20:13 | <jgraham__> | (and probaly some others I forget) |
| 20:13 | htmlfivedotnet | doublechecks lxml |
| 20:14 | <htmlfivedotnet> | jgraham__: i know i don't have the others |
| 20:15 | <jgraham__> | Can you tell from the error messages what is failing? (or throw some of the output online and I'll have a look) |
| 20:15 | <jgraham__> | FAILED (failures=4) |
| 20:15 | <jgraham__> | is what I get |
| 20:15 | Philip` | tries installing chardet |
| 20:15 | <jgraham__> | My tree seems to have some patches in though :) |
| 20:16 | <htmlfivedotnet> | test_title_body_mismatched_close, test_title_body_named_charref, test_script, test_script_src |
| 20:16 | <Philip`> | Ran 7651 tests, failures=46, errors=3 |
| 20:16 | <htmlfivedotnet> | installing lxml gives the same result, but a few different run-time outputs |
| 20:16 | <jgraham__> | htmlfivedotnet: Those are sanitizer tests. How hard would it be to dump some of the output to a file and put it online somewhere |
| 20:17 | <jgraham__> | ? |
| 20:17 | Philip` | goes home |
| 20:17 | <htmlfivedotnet> | jgraham__: no problem. one sec |
| 20:17 | <htmlfivedotnet> | http://pastebin.ca/1000764 |
| 20:18 | <hsivonen> | jgraham__: It would be nice to have automated Java to C, C++ and Objective-C translation for the Validator.nu HTML parser tokenizer and abstract tree builder |
| 20:18 | <Philip`> | hsivonen: Why not start from an abstract language that avoids the complexities of Java, and convert from that into Java and C and C++ etc? |
| 20:19 | <jgraham__> | htmlfivedotnet: Those are the same failures I get. What are the errors? |
| 20:19 | <hsivonen> | Philip`: because I already have a Java impl and C, C++ and Objective-C are structurally similar |
| 20:19 | <hsivonen> | nn |
| 20:19 | <htmlfivedotnet> | all 1630 of them? for some reason python runtests.py > text.txt isn't putting them to a text file, and my console doesn't have 8000 lines of buffer |
| 20:20 | <htmlfivedotnet> | jgraham__: you know what... looks like i have json problems. let me try to fix that. |
| 20:20 | <Philip`> | htmlfivedotnet: python runtests.py 2>&1 >text.txt |
| 20:20 | <jgraham__> | htmlfivedotnet: Nah, I think just a few should be enough to wok out what's going on. |
| 20:21 | <htmlfivedotnet> | i keep getting "AttributeError: class simplejson has no attribute 'loads'". |
| 20:21 | <Philip`> | (to redirect stderr onto stdout, then to save both in the .txt file) |
| 20:21 | <htmlfivedotnet> | so i think my json is broken. |
| 20:21 | <jgraham__> | htmlfivedotnet: You need to install simplejson |
| 20:21 | <htmlfivedotnet> | Philip`: Thanks. I'll remember that |
| 20:21 | <jgraham__> | That would explain a lot :) |
| 20:22 | <jgraham__> | We should make a better error message there :) |
| 20:22 | <jgraham__> | Philip`: I'm also curious what faliures you are getting? |
| 20:23 | <Philip`> | jgraham__: Maybe support.py should just die when simplejson is missing, instead of trying (and failing) to implement it itself |
| 20:24 | <Philip`> | jgraham__: I'll tell you in ~40 minutes :-) |
| 20:24 | jwalden | wishes everybody could just get along and use a single mailing list for spec discussion |
| 20:24 | <htmlfivedotnet> | 3 errors, 4 fails (same failures): http://pastebin.ca/1000774 |
| 20:24 | <jgraham__> | Philip`: Yes. It should. That was a hack that someone (Sam?) added and I forgot to take out when it stopped working |
| 20:25 | <jgraham__> | htmlfivedotnet: I think I have fixes for those errors in my tree (it's an issue with the test harness iirc) |
| 20:25 | <jgraham__> | So it's working as well for you as for anyone else |
| 20:25 | <jgraham__> | I need to fix the other issues |
| 20:26 | jgraham__ | will have a look later this evening |
| 20:26 | <htmlfivedotnet> | seems to be. i figured something was wrong on my end... |
| 20:27 | <jgraham__> | jwalden: Either one of those things seems pretty unlikely on it's own, so them both happening seems very improbable :) |
| 20:27 | <jwalden> | I know, I'm just feeling grouchy |
| 21:04 | <Philip`> | jgraham__: Oops, those failures existed because I have another file of tree-construction tests in testdata |
| 21:04 | <Philip`> | If I remove that file, I only get 4 failures, 3 errors |
| 21:04 | <jgraham__> | Philip`: That sounds like the expected behaviour |
| 21:05 | <Philip`> | I don't know which of my uncommitted tests are still legitimate given the changes to the spec, so I'll ignore them until I get around to checking parser things again in the future |
| 21:08 | <Hixie> | man, addressing the needs of bloggers was a stroke of genius |
| 21:09 | <Hixie> | every time a blogger looks at html5, they're all like "sweet, this makes blog way better" |
| 21:09 | <Hixie> | and then they like html5 |
| 21:11 | <jgraham__> | Hixie: presumably that method of optimisation would lead to specs that mainly address the needs of other specs (since the main people who read specs are people writing other specs) |
| 21:11 | <Hixie> | well it wasn't intentionally optimised that way |
| 21:12 | <jgraham__> | I'm not suggesting it was :) But it provides a model of why some specs end up so divorced from reality |
| 21:12 | <jgraham__> | or at lkeast from the needs of real users |
| 21:12 | <Hixie> | oh for sure |
| 21:13 | <Hixie> | annevk: i put to you a challenge: get the XHR2 spec agreed to by everyone before the F2F, so i don't have to go :-) |
| 21:13 | <jgraham__> | Hixie: Impossible things take longer |
| 21:13 | <jgraham__> | :) |
| 21:13 | <Hixie> | shouldn't be that impossible |
| 21:13 | <Hixie> | just need to get sicking to tell us what he wants |
| 21:14 | jgraham__ | actually has no idea what the status of XHR2 is |
| 21:15 | <jgraham__> | I thought it was just AC that was an issue for Mozilla? Or is the AC dependency the only remaining XHR2 issue? |
| 21:17 | <Hixie> | ac/xhr2, same thing |
| 21:18 | <jgraham__> | Oh OK |
| 21:18 | <jgraham__> | Philip`: If you svn update html5lib it shouldn't have the three test errors now, assuming I checked the right code in |
| 21:19 | <othermaciej_> | I think Mozilla's issue was cookies |
| 21:19 | <othermaciej_> | I owe some writing on security issues related to cookies |
| 21:19 | <othermaciej_> | in particular I am pretty convinced now that *not* sending them is a security risk |
| 21:20 | <Philip`> | jgraham__: "FAILED (failures=4)" - looks like success |
| 21:20 | <othermaciej> | (sadly meetings all day today) |
| 21:20 | <jgraham__> | Philip`: Thanks |
| 22:41 | <Hixie> | annevk: do you know if you have yet defined same-origin security policies for CSSOM? |
| 22:42 | <Hixie> | in particular, that a script shouldn't be able to mutate a StyleSheet object from another origin |
| 22:56 | <fantasai> | Hixie: note that the Web Forms spec explicitly requires Unicode case-folding. |
| 22:56 | <Hixie> | yeah wf2 is old and crusty |
| 22:56 | <fantasai> | if you're not sure you want that (seemed from your message to hsivonen that you didn't) you should probably remove it |
| 23:13 | <htmlfivedotnet> | Hixie: Did you just read a blog post about why html5 is great for blogs, thus leading to your comment? I just wonder if it was my recent post out of some strange coincidence |
| 23:14 | <Hixie> | fantasai: wf2 will be merged with html5 in due course, until then it's frozen |
| 23:14 | <Hixie> | htmlfivedotnet: no idea which blog it was |
| 23:29 | <annevk> | no gta4 for me tonight |
| 23:30 | <annevk> | line was just too long |
| 23:30 | <Hixie> | amazon is shipping it to me tomorrow |
| 23:30 | <Hixie> | it's already on a truck somewhere |
| 23:30 | <Philip`> | annevk: Was there a midnight release? |
| 23:30 | <annevk> | yeah |
| 23:31 | <annevk> | but i was too late because i was going to see a movie and since i have to get up early tomorrow waiting until 2AM or something didn't seem like a feasible plan |
| 23:31 | <Philip`> | Was that like the PS3 release where everybody was beating each other up to get ahead in the line, or was it like the Wii release where everyone make cookies for each other? |
| 23:32 | <annevk> | it was a normal line |
| 23:32 | <Philip`> | Oh, how unexciting |
| 23:32 | <Hixie> | what's the origin of a Document whose URI is about:blank? |
| 23:34 | <annevk> | the Access-Control-Origin is "null" |
| 23:35 | <annevk> | unless it's inside some <iframe> I suppose and it gets the origin from somewhere else |
| 23:35 | <Hixie> | that's what i mean |
| 23:35 | <jwalden> | that doesn't jibe with HTML5's origin for about:blank-spawned windows |
| 23:36 | <Hixie> | html5 doesn't define about:blank origin at the moment |
| 23:36 | <Hixie> | there's a big red box for that case |
| 23:36 | <Hixie> | i just added it |
| 23:36 | <annevk> | I suppose it's kind of hard to get an about:blank and initiate some kind of cross-site request without having it associated with some other origin :) |
| 23:36 | <jwalden> | oh, I'm thinking of javascript: |
| 23:36 | <Hixie> | on another note, i just defined how document.domain works |
| 23:36 | <jwalden> | ooh |
| 23:36 | jwalden | looks |
| 23:37 | <Hixie> | search for "Effective script origin" for the juicy bits |
| 23:37 | <Hixie> | and if you have a better term than "effective script origin", let me know |
| 23:39 | <jwalden> | what happened to the multipage version? the URL seems awol right now |
| 23:39 | <jwalden> | http://www.whatwg.org/specs/web-apps/current-work/multipage/ |
| 23:40 | <annevk> | changelog: http://html5.org/tools/web-apps-tracker?from=1501&to=1502 |
| 23:40 | <Hixie> | uh |
| 23:40 | <Hixie> | dunno |
| 23:40 | <Hixie> | will try to fix |
| 23:42 | <jwalden> | I think the port part doesn't match what Moz does (it uses the port, but I'm not sure how), but I don't think anyone will care |
| 23:43 | <jwalden> | we do have a bug against this, tho, in that we allow "example.org/foo/bar/baz"; I think right now, being equivalent to "example.org" :-( |
| 23:43 | <Hixie> | as far as i can tell, mozilla ignores the port once you set document.domain, no? |
| 23:44 | <jwalden> | ...I'm not sure |
| 23:44 | <Hixie> | yeah i decided to err on the side of safety with not allowing path components |
| 23:44 | <Hixie> | since webkit doesn't do it |
| 23:44 | <jwalden> | I can't see a good reason to allow them |
| 23:44 | <Hixie> | so i'm guessing it's not needed for web compat |
| 23:44 | <jwalden> | I'm sort of scared that we do, actually |
| 23:44 | <Hixie> | heh |
| 23:44 | <Hixie> | i know the feeling :-) |
| 23:44 | <Hixie> | multipage is fixed |
| 23:45 | <jwalden> | the port thing I know we were using the value with a SetHostPort call at one time, until we discovered that method wasn't implemented and reverted to string-buildup |
| 23:45 | <jwalden> | but how a specified port affects anything, I don't know |
| 23:45 | <jwalden> | it might not |
| 23:46 | <Hixie> | oh you mean specifying it in document.domain? |
| 23:46 | <Hixie> | interesting |
| 23:46 | <Hixie> | from what i saw of the webkit source, that definitely isn't supported over there |
| 23:47 | <Hixie> | i think that for the purposes of XHR, 'origin' is now well-defined in all cases except about:blank iframes |
| 23:47 | <Hixie> | and windows |
| 23:47 | <annevk> | I recall we have some dragons around there too. I should probably get Hallvord to review... |
| 23:48 | <jwalden> | is "manual override" yet to be defined? |
| 23:48 | <Hixie> | no |
| 23:48 | <Hixie> | it's just a value |
| 23:49 | <Hixie> | that isn't a port number |
| 23:49 | <jwalden> | should define "same" then with respect to it |
| 23:49 | <Hixie> | "manual override" is the same as "manual override" but not anything else |
| 23:49 | <Hixie> | do i need to say that? |
| 23:49 | <jwalden> | er |
| 23:49 | <jwalden> | I'm stupid |
| 23:49 | <jwalden> | ignore me! |
| 23:49 | <Hixie> | heh |
| 23:49 | <Hixie> | :-/ |
| 23:50 | jwalden | is forgetting about symmetry |
| 23:50 | <Hixie> | jwalden: on another note, you sent feedback saying that document.open() doesn't reset the origin, but as far as i can tell, the spec doesn't let you call .open() unless your origin is the same anyway |
| 23:50 | <Hixie> | although now i guess the origin could be changed by a script that was document.domain'ed the same |
| 23:51 | jwalden | shall have to re-page that in |
| 23:51 | <Hixie> | but i don't think it really matters much in that case... |
| 23:51 | <Hixie> | i can just reply to the mail if you'd rather |
| 23:53 | <jwalden> | yeah, looking back I'm not sure what I was thinking there |
| 23:54 | <Hixie> | k |
| 23:54 | <Hixie> | i'll reply saying i'm ignoring you, and if you or someone else decides i'm wrong, i'm sure you or they will reply :-) |
| 23:55 | <jwalden> | there was a funky postMessage test sicking requested that was that situation, and which my initial implementation tickled, but I can't rationalize the question given that and how things should actually work otherwise |
| 23:56 | <Hixie> | did we decide if MessageEvent.origin should be in punycode (like document.domain) or fully Unicode? |
| 23:57 | <jwalden> | I wanted fully Unicode |
| 23:57 | <annevk> | no |
| 23:57 | <jwalden> | but no, no decision |
| 23:57 | <jwalden> | wait |
| 23:57 | jwalden | looks again |
| 23:57 | <annevk> | punycode is also consistent with Access-Control-Origin (though that's mostly because of HTTP limitations) |
| 23:58 | <jwalden> | we restrict document.domain to only be settable to puncode? |
| 23:58 | <jwalden> | I don't really like that |
| 23:58 | <Hixie> | well, the spec as written now does |
| 23:58 | <Hixie> | i guess i haven't checked browsers |
| 23:58 | jwalden | sees what Moz does with IDN |
| 23:59 | <jwalden> | I think we accept IDN |
| 23:59 | <Hixie> | yup |
| 23:59 | <Hixie> | looks like you do, from testing on ☺.damowmow.com |
| 23:59 | <Hixie> | oh actually i was testing safari |
| 23:59 | <Hixie> | so i guess i should change the spec |