| 00:00 | <olliej> | roc: i'd like sampling based perf, we actually can do it, but it's fairly awful, and doesn't provide sufficient information for us to be able to give a useful profile |
| 00:01 | <olliej> | roc: we use it to work out what opcodes are taking too long |
| 00:01 | <roc> | you need stacks |
| 00:01 | <roc> | getting stacks in Tracemonkey would be interesting, since there's inlining going on |
| 00:01 | <olliej> | roc: yeah, i've often wondered how shark does it with such minimal perf impact |
| 00:01 | <olliej> | roc: hehe |
| 00:02 | <olliej> | roc: i see there work on tracking trace behaviour |
| 00:02 | <olliej> | roc: which is awesome |
| 00:02 | <roc> | Yeah |
| 00:02 | <olliej> | roc: i forget who was working on it, but is [s]he aware of my bug on that? |
| 00:02 | <roc> | Dave Mandelin |
| 00:02 | <roc> | what bug? |
| 00:03 | <olliej> | erm |
| 00:03 | <olliej> | roc: one moment |
| 00:03 | <Hixie> | i just commented out a block of code that does the most amount of work (i thought!) per page load in status.js |
| 00:03 | <Hixie> | the metric i'm timing went from 8319ms to 8416ms |
| 00:03 | <Hixie> | ... |
| 00:03 | <roc> | I'd like to have Dave's visualization in the progress bar :-) |
| 00:04 | <olliej> | roc: https://bugzilla.mozilla.org/show_bug.cgi?id=471645 |
| 00:05 | <roc> | thanks :-) |
| 00:05 | <roc> | of course, traces should just not abort :-) |
| 00:06 | <olliej> | roc: heh |
| 00:06 | <olliej> | roc: there's always exceptions :D |
| 00:06 | <olliej> | roc: our jit handles exceptions, but it isn't pretty to watch |
| 00:07 | <roc> | This is going to be an ongoing problem for JS though ... to get good performance you'll always need an aggressive compiler, and the more aggressive the compiler, the less predictable the performance |
| 00:07 | gsnedders | puts on angry face to try and make him do work quicker |
| 00:08 | <roc> | which is one reason all the efforts to achieve really good performance for higher-level languages than C/C++ have, to a large extent, failed |
| 00:08 | <Hixie> | ok i have narrowed down the 8000ms performance hit to the whitespace between two of my lines of code |
| 00:08 | <Hixie> | (@&*$(@!%&(!@#%! |
| 00:08 | <Hixie> | i wonder if what's happening is that the toc script is running between two of my timeouts or something |
| 00:09 | <olliej> | roc: i don't believe matching -O2/3 is feasible (at least not consistently) but i think O1 should be |
| 00:09 | <olliej> | Hixie: what are you working on? |
| 00:09 | <Hixie> | olliej: making the spec load faster in firefox |
| 00:09 | <gsnedders> | status.js |
| 00:09 | <gsnedders> | in the spec |
| 00:10 | <olliej> | Hixie: ah |
| 00:10 | <Hixie> | nope, not the toc script. |
| 00:10 | gsnedders | wonders why status annotations aren't done as part of the compiling of the spec |
| 00:11 | <gsnedders> | I guess that'd mean the spec would have to be regened to change them |
| 00:12 | <gsnedders> | I also guess that'd mean me coding it |
| 00:12 | <Hixie> | heh |
| 00:13 | <Hixie> | the toc script could be done pretty easily |
| 00:13 | <gsnedders> | Yeah, that could and should be done |
| 00:13 | <Hixie> | (it does a bit more than the short toc now, btw) |
| 00:13 | <gsnedders> | Email me :P |
| 00:13 | <Hixie> | no rush |
| 00:14 | <gsnedders> | Indeed not, I'm currently listening to Leonard Cohen |
| 00:14 | <gsnedders> | </bad joke> |
| 00:14 | <gsnedders> | Also, email doesn't mean a rush. I have emails to deal with going back to mid-last year :) |
| 00:15 | <Hixie> | i just mean i'm more interested in the other things you've on your list :-) |
| 00:15 | gsnedders | looks at Facebook mailbox, then realizes he clicked on the wrong one, and clicks on "spec-gen" |
| 00:16 | <gsnedders> | Hixie: What do I have outstanding from you? |
| 00:16 | <Hixie> | cross-spec xrefs |
| 00:16 | <gsnedders> | :) |
| 00:17 | <gsnedders> | OK, _apart_ from xdoc xref? |
| 00:17 | <Hixie> | i think that's it |
| 00:17 | <gsnedders> | mid:Pine.LNX.4.62.0808051950100.5140⊙hdc too |
| 00:17 | <gsnedders> | Accessibility and specgen |
| 00:17 | <Hixie> | what's that one? |
| 00:17 | <Hixie> | oh yeah |
| 00:17 | <Hixie> | that too |
| 00:18 | <gsnedders> | First the "make everyone-except-Hixie happy" release :P |
| 00:18 | <Hixie> | making it even faster would be nice too |
| 00:19 | <gsnedders> | I'd like that too, but I'm not sure quite how much quicker I can get in Python |
| 00:20 | <Hixie> | ok seriously, i don't understand why it takes 8s for firefox to run this 0ms setTimeout callback |
| 00:22 | <Hixie> | i'm gonna stick the html5 spec in an iframe in acid4 and just call that the test, i think |
| 00:24 | gsnedders | copies a whole load of emails into the spec-gen folder |
| 00:25 | gsnedders | wonders about rewriting Anolis in C++ in an attempt to learn C++ |
| 00:26 | gsnedders | wonders what browser-compat. HTML parsers there are that can be used without including the whole rendering engine |
| 00:27 | <sicking> | Hixie, firefox seems to be struggling pretty bad with rendering the HTML5 spec lately :( |
| 00:27 | <Hixie> | sicking: yeah, and i can't work out why |
| 00:27 | <sicking> | Hixie, dunno if something's changed recently |
| 00:27 | <Hixie> | sicking: i just spent the last 2 hours trying to pin it down |
| 00:27 | <sicking> | more annotations? |
| 00:27 | <Hixie> | sicking: the annotations don't appear to be the cause of the slowdown |
| 00:28 | <Hixie> | sicking: i mean, they take a few seconds here and there, but i'm seeing 8s pauses in between two of my callbacks, and stuff like that |
| 00:28 | <sicking> | Hixie, ping bz for a profile, he rocks at finding hotspots |
| 00:28 | <sicking> | some of it felt like rendering to me, but i'm not sure |
| 00:29 | <gsnedders> | sicking: Wait, you feel how long code takes to execute? Dude, you should be a millionaire! |
| 00:29 | <sicking> | gsnedders, it's all in the finger tips |
| 00:30 | <sicking> | also laying my ear against the terminal window helps |
| 00:31 | <Hixie> | i just disabled all the scripts |
| 00:31 | <Hixie> | and it's still slowish |
| 00:32 | <doublec> | I get the 'this script is taking too long to execute' all the time |
| 00:32 | <Hixie> | i wonder which script |
| 00:33 | <doublec> | hmm, not happening now. It was happening a lot yesterday. |
| 00:33 | <Hixie> | i've done a bunch of changes |
| 00:33 | <Hixie> | which might help |
| 00:34 | <doublec> | it got to the point where vi was my browser of choice for the spec |
| 00:34 | <jcranmer> | not elinks? |
| 00:34 | <doublec> | I didn't think to try a text mode browser :) |
| 00:35 | <Hixie> | looks like a big chunk of the time is spent rendering the Status boxes |
| 00:43 | <Lachy> | hey, why is section 2.1.1 XML marked as controversial? What issue could anyone possibly have with it? |
| 00:43 | <Hixie> | Lachy: annotations may be wrong right now |
| 00:43 | <Hixie> | i'm fiddling with the script |
| 00:45 | <Lachy> | Hixie, I don't see how you fiddling with the script could be messing up the annotations, since all the others marked controversial, actually are controversial |
| 00:45 | <Hixie> | hm |
| 00:45 | <Hixie> | maybe an ID changed? |
| 00:46 | <Lachy> | it says it was last set on 2008-12-15. So check SVN for that date and see which section had that ID. |
| 00:46 | <sicking> | Lachy, i consider it offensive! |
| 00:47 | <Lachy> | what's offensive about it? |
| 00:47 | <Hixie> | oh it was set by dean |
| 00:47 | <Hixie> | i'm sure he finds all kinds of things offensive |
| 00:47 | <sicking> | it doesn't cater to my swedish ancestry. Or something |
| 00:48 | <Hixie> | Lachy: feel free to update it |
| 00:48 | <Hixie> | assuming the annotation script works :_) |
| 00:49 | <Lachy> | maybe the status section needs a notes section for people to write or link to reasons for marking controversial |
| 00:49 | <Lachy> | s/status section/status boxes/ |
| 00:50 | <Lachy> | anyway, I changed it to Working Draft for now |
| 00:51 | gsnedders | procrastinates and thinks about Anolis2 |
| 00:51 | <Hixie> | the real solution is to not use the status boxes to mark controvesry |
| 00:52 | <Lachy> | why was controversy added to the available options then? |
| 00:52 | <Hixie> | because it seemed like a good way to show that we were willing to work with the w3c |
| 00:54 | <sicking> | Hixie, does it ever stop consuming CPU if I wait? |
| 00:54 | <sicking> | Hixie, going on a couple of minutes here and it's still chugging away |
| 00:55 | <Hixie> | sicking: yes, but i'm still tuning it. |
| 00:55 | <sicking> | Hixie, you should see if firebug is finding any hotspots |
| 00:55 | <Hixie> | firebug doesn't work for me |
| 00:55 | <Hixie> | for some reason |
| 00:55 | <sicking> | yay! |
| 00:55 | <sicking> | CPU is down |
| 00:55 | <gsnedders> | It's all these impatient young'uns nowadays, unable to stop waiting :P |
| 00:56 | <sicking> | now all i need to do is to not close this tab ever again :) |
| 00:56 | <Hixie> | part of the problem is i'm trying to balance the script doing work and the browser doing layout |
| 00:56 | <gsnedders> | s/stop waiting/wait/ |
| 00:56 | <Hixie> | if i portion off the script's work into tiny bits, the browser tries to do a layout in between each iteration |
| 00:56 | <Hixie> | if i do all of it at once, the browser locks up |
| 00:57 | <Hixie> | if firefox did layout of the spec faster, this would be much less of an issue |
| 00:57 | <gsnedders> | Firefox-- |
| 00:58 | <sicking> | Hixie, can't you make all annotations display:none until you've positioned them all |
| 00:58 | <sicking> | Hixie, and then flip them all on at the end |
| 00:58 | <Hixie> | hm, that's an idea |
| 00:59 | <sicking> | not sure if changing a rule at the end is faster, or if looping through them all and removing a class is |
| 00:59 | <sicking> | iirc we optimize poorly rule changes |
| 01:00 | <sicking> | but that might have been additions/subtractions of rules/stylesheets. Not changing existing rules |
| 01:00 | <sicking> | and we might also be optimizing it better these days |
| 01:00 | <gsnedders> | Everything should just run in 0 CPU time, then everything would be fine |
| 01:02 | <Hixie> | oh wow yeah making them display:none definitely helps |
| 01:02 | <Hixie> | still slow though |
| 01:03 | <Hixie> | and the restily at the end takes an ungodly amount of time |
| 01:03 | <Hixie> | restyle, even |
| 01:03 | <Hixie> | (restily?!) |
| 01:03 | <gsnedders> | That isn't even a thought -> audio -> text fail. |
| 01:07 | <gsnedders> | What's the amperage of normal US home power sockets? |
| 01:10 | <Hixie> | holy crapamoli |
| 01:10 | <Hixie> | removing document.getElementById() sped things up by a factor of 3 |
| 01:13 | <Hixie> | sicking: is there some way to get firefox to prime its ID cache or something? |
| 01:16 | <sicking> | hmm |
| 01:16 | <sicking> | there is |
| 01:16 | <sicking> | why do you want to do it though? |
| 01:17 | <Hixie> | getElementById() is where all the time is being spent |
| 01:17 | <sicking> | in calls that fail or succeed? |
| 01:17 | <Hixie> | literally 20s of the 30s or so of loading it is spent in that one function |
| 01:17 | <Hixie> | all succeeds |
| 01:17 | sicking | goes to look at the code |
| 01:18 | <sicking> | do you know if each call takes approx the same amount of time, or is there one call that all of a sudden takes a ton of time? |
| 01:18 | <sicking> | (where we prime the cache) |
| 01:19 | <sicking> | and are you not using the result of the gEBI call? How can you otherwise just remove it? |
| 01:20 | <Hixie> | i replaced it with document.body |
| 01:20 | <sicking> | (i'm asking if you accidentally killed more code than the gEBI call) |
| 01:20 | <Hixie> | i turned this: |
| 01:20 | <Hixie> | function sectionToElement(section) { return document.getElementById(section); |
| 01:20 | <Hixie> | } |
| 01:20 | <Hixie> | into this: |
| 01:20 | <Hixie> | function sectionToElement(section) { return document.body; return document.getElementById(section); |
| 01:20 | <Hixie> | } |
| 01:20 | <Hixie> | and two thirds of the time went away |
| 01:20 | <Hixie> | there might be some misses, actually |
| 01:20 | <Hixie> | but most will be hits |
| 01:21 | <gsnedders> | Damn that cmd+w! |
| 01:22 | <sicking> | and you're sure that doing whatever operation to the same element tons of times is the same as doing it to different elements? |
| 01:22 | <Hixie> | i do target = sectionToElement(section) followed by: |
| 01:22 | <Hixie> | target.parentNode.insertBefore(this.panel, target.nextSibling); |
| 01:22 | <Hixie> | oh |
| 01:22 | <Hixie> | so |
| 01:22 | <Hixie> | no |
| 01:23 | <Hixie> | in fact that would indeed be cheaper |
| 01:23 | <othermaciej_> | I don't know the context here but "doing whatever operation to the same element tons of times is the same as doing it to different elements" is not the case for most DOM operations |
| 01:23 | <Hixie> | i guess the time is really spent on insertBefore |
| 01:23 | <Hixie> | since document.body.nextSibling will always be null |
| 01:23 | <sicking> | Hixie, would it? inserting is about the same no matter where it happens |
| 01:23 | <Hixie> | which would turn that into a cheap append |
| 01:23 | <sicking> | basically |
| 01:23 | <sicking> | wait, unless you're inserting outside of what's displayed |
| 01:24 | <Hixie> | actually i guess that the first one would be different, but all subsequent inserts would be happening before the first one |
| 01:24 | <Hixie> | so yeah, it should be no different |
| 01:24 | <othermaciej> | wouldn't insertBefore be more expensive than appending in Gecko, due to the array representation of child nodes? |
| 01:24 | <sicking> | hmm.. actually |
| 01:24 | <sicking> | insertBefore(..., null) turns into appendChild |
| 01:25 | <Hixie> | let me try again with the document.body in the insertBefore but still doing the document.gEBI |
| 01:25 | <othermaciej> | (in WebKit it would be about the same unless it causes excessive style recalc or rebuilding of the render tree) |
| 01:25 | <sicking> | which we've optimized more heavily since it matters a lot during parsing |
| 01:25 | <sicking> | i.e. the layout engine is better at dealing with appendChild |
| 01:25 | <othermaciej> | (since we have a linked list representation of children) |
| 01:26 | <sicking> | Hixie, how many gEBI lookups do you do? |
| 01:26 | <Hixie> | 300 or so |
| 01:26 | <Hixie> | one per status box |
| 01:26 | <sicking> | so after 64 lookups we start priming |
| 01:26 | <Hixie> | apparently there are 270 hits and 47 misses |
| 01:27 | <sicking> | 64 lookups of different IDs. Doesn't matter if they return null or not |
| 01:27 | <sicking> | but looking up 'hello' 100 times does not prime |
| 01:27 | <Hixie> | these are all different |
| 01:27 | <sicking> | so would be interesting if lookup number 60 or so takes a long time. I doubt it though |
| 01:28 | <sicking> | try changing your insertBefore into appendChild and see if that makes a difference |
| 01:28 | <sicking> | or |
| 01:29 | <sicking> | start by looking up 65 'random' ids before doing anything else |
| 01:29 | <sicking> | and just time that part |
| 01:30 | sicking | wonders if this lazy priming is really worth it |
| 01:31 | <Hixie> | yeah appendchild is really fast compared to insertbefore, and insertbofer on document.body is really fast compared to doing it in the middle of a big doc |
| 01:31 | <Hixie> | not doing gEBI doesn't actually save time once i take this into account |
| 01:31 | <sicking> | cool |
| 01:32 | <Hixie> | so basically dom manipulation is what is taking a long time |
| 01:32 | <sicking> | well, it's rather the rendering after that takes time i would think |
| 01:32 | <sicking> | hmm.. |
| 01:32 | <sicking> | maybe not actually |
| 01:32 | <Hixie> | no the rendering is turned off right now |
| 01:32 | <Hixie> | i did the display:none thing you suggested |
| 01:33 | <sicking> | do you have very long child lists? |
| 01:33 | <Hixie> | yes |
| 01:33 | <Hixie> | very very very long |
| 01:33 | <Hixie> | the entire spec long |
| 01:33 | <sicking> | are you inserting into the long lists? |
| 01:33 | <Hixie> | yes |
| 01:33 | <Hixie> | i'm inserting these boxes all the way down this list |
| 01:34 | <sicking> | "all the way down"? |
| 01:34 | <sicking> | s/elements/boxes/? |
| 01:34 | <sicking> | s/boxes/elements/? |
| 01:34 | <Hixie> | basically the spec is a long list of h2/h3/h4 elements, p elements, div elements, etc |
| 01:34 | <Hixie> | and for almost every h2/h3/h4 element, i'm inserting a div element next to it |
| 01:35 | <sicking> | how many children are we talking here? |
| 01:35 | <Hixie> | 10032 |
| 01:35 | <Hixie> | javascript:alert(document.body.childNodes.length) = 10032 |
| 01:35 | <sicking> | we are going to end up doing a linear search through this list a lot |
| 01:36 | <sicking> | are you inserting these in order? |
| 01:36 | <Hixie> | no |
| 01:36 | <sicking> | ish? |
| 01:36 | <Hixie> | i'm probably inserting them in the order they were created |
| 01:36 | <sicking> | just random, not even close top-to-bottom |
| 01:36 | <Hixie> | which probably looks pseudo-random |
| 01:36 | <sicking> | chronological spec creation wise? |
| 01:37 | <Hixie> | chronological status annotation creation wise |
| 01:37 | <Hixie> | i guess |
| 01:37 | <Hixie> | i don't know |
| 01:37 | <Hixie> | it's certainly not spec order |
| 01:37 | <sicking> | ok |
| 01:37 | <Hixie> | it could also be some random mysql order |
| 01:37 | <sicking> | still surprises me a little, it shouldn't be *that* slow to search the list, though 10032 is a lot |
| 01:38 | <sicking> | can you change to spec order and see if it makes a difference? |
| 01:38 | <sicking> | or |
| 01:38 | <sicking> | can you avoid inserting into this long list? |
| 01:38 | <Hixie> | i don't really have a good way to figure out the spec order |
| 01:39 | <Hixie> | well i could put divs all over the place |
| 01:39 | <Hixie> | but then i'd be working around a particular browser's limitation |
| 01:39 | <Hixie> | which i keep telling people i won't do for IE :-) |
| 01:39 | <sicking> | can you insert these elements as children of the hx/p/divs? rather than as siblings |
| 01:39 | <sicking> | hah |
| 01:39 | <sicking> | fair enough |
| 01:39 | <Hixie> | inserting divs into hxs and ps would be a spec violation |
| 01:40 | <Hixie> | i do actually insert them into the divs when that's possible |
| 01:40 | <sicking> | spec schmeck. No-one reads specs anyways :) |
| 01:40 | <sicking> | well, we'll have to release the profile hounds on this and see what's up |
| 01:41 | <sicking> | can i turn off annotations somewhere for now? |
| 01:42 | <Hixie> | not currently |
| 01:42 | <Hixie> | but i might add that feature shortly |
| 01:42 | <gsnedders> | Turn of JS! |
| 01:42 | <gsnedders> | *off |
| 01:44 | <sicking> | i was gonna, turns out we don't have easy-access prefs for turning off JS on a site-by-site basis :( |
| 01:44 | <sicking> | i'm sure we have it somewhere, just no UI for it |
| 01:44 | <sicking> | we do have prefs for images, popups, cookies and addons though.... awesome |
| 01:50 | <roc> | use noscript or something |
| 01:54 | <annevk3> | Hixie, can you generate a copy of the spec without all the scripts? |
| 01:55 | <annevk3> | Hixie, they are actually becoming a pain for me in Opera too |
| 01:55 | <gsnedders> | annevk3: But I thought Opera was quick! |
| 01:55 | <gsnedders> | I mean, that's what the marketing says! |
| 01:55 | <annevk3> | are you saying you trust TV commercials as well? |
| 01:56 | <Hixie> | yeah i can just have a slow browsers mode |
| 01:58 | <annevk3> | :) |
| 02:24 | <Hixie> | ok you can now stick ?slow-browser on the end of the URL to disable the scripts |
| 02:24 | <Hixie> | and ?profile to get timings |
| 02:45 | <annevk4> | Hixie, the W3C editor's draft is still marked WD |
| 09:22 | <hsivonen_> | for people interested in HTML5 parsing: integration with layout now sucks less https://build.mozilla.org/tryserver-builds/2009-03-02_06:05-hsivonen⊙if/ |
| 09:22 | <hsivonen_> | innerHTML setter should work, too |
| 09:22 | <Lachy> | Hixie, since section 2.5.4 (relationship to flash, etc.) was removed, are you intending to leave it out for good, or are you still interested in readding it once it has been rewritten? |
| 09:23 | <Lachy> | I have that action item that I need to deal with this week about rewriting it with Larry and I need to know if I should bother spending time on it |
| 09:23 | <roc_> | hsivonen_: awesome! |
| 09:24 | <hsivonen_> | roc: thanks. I'm using nsTArray as a very naive set in the notification batching code. I should see if there's something better. |
| 09:24 | <roc> | set? |
| 09:25 | <roc> | nsTHashtable maybe |
| 09:25 | <roc> | if you're doing element-of a lot |
| 09:25 | <hsivonen_> | roc: a set of elements that that I know aren't touching the notification boundary between the old and new parts of the tree |
| 09:26 | hsivonen_ | looks up nsTHashtable |
| 09:26 | <roc> | you may also want to look at nsHashKeys.h |
| 09:26 | <hsivonen_> | roc: ok. thanks |
| 09:38 | <Hixie> | hsivonen_: i've given up on that fight, so unless someone else thinks we should keep it, i'm ok with just dropping it |
| 09:38 | <hsivonen_> | Hixie: did you mean Lachy? |
| 09:38 | <Hixie> | er yes |
| 09:38 | <Hixie> | Lachy: ^ |
| 09:39 | <hsivonen_> | Hixie: btw, making the tree builder not read from the DOM during AAA turns out to be useful for the single-threaded case as well |
| 09:39 | <Hixie> | i'm sure |
| 09:40 | <hsivonen_> | Hixie: because timeouts don't need to flush the tree builder |
| 09:40 | <Hixie> | timeouts? |
| 09:40 | <hsivonen_> | Hixie: scripts that run through setTimeout/interval |
| 09:40 | <Hixie> | ah |
| 09:40 | <hsivonen_> | Hixie: since whatever they do wouldn't affect the queue of pending tree ops |
| 09:46 | <Lachy> | Hixie, I don't think it's worth fighting for either. There are much more important things to worry about. |
| 09:50 | <Lachy> | hsivonen_, why does your HTML5 build of Mozilla suffer from the unresponsive script issues in the HTML5 spec, whereas the latest trunk build doesn't? Are you using some older components? |
| 09:50 | <Hixie> | latest trunk isn't so hot either |
| 09:51 | <Lachy> | yeah, but at least the trunk doesn't need to show the unresponsive script dialog asking to stop the script. |
| 09:52 | <hsivonen_> | Lachy: the HTML5 stuff branched in December |
| 09:53 | <Lachy> | ok |
| 09:55 | Lachy | decides to work on the HTML 5 Reference today |
| 09:55 | <hsivonen_> | I think I should merge in new stuff from the trunk once 1) I have eliminated the leaks I introduced and 2) the trunk itself is in good shape |
| 10:17 | <john_fallows> | Hixie: what is the type of the "open" event for EventSource and WebSocket ? (it is not hyperlinked like the others) |
| 10:18 | <Hixie> | find the text that fires the event, there should be some term of art used to fire it |
| 10:18 | <Hixie> | probably "fire a simple event" |
| 10:19 | <Hixie> | follow the link for that term of art and it'll answer the question, unless i screwed up |
| 10:20 | <hsivonen_> | I think I found the cause of the bug zcopran reported about doctype sometimes not showing up in the DOM in the HTML5 parsing Gecko builds |
| 10:23 | <john_fallows> | Hixie: yes, fire a simple event, which "does not bubble, but is cancelable (unless otherwise stated)" - what would it mean to cancel a WebSocket / EventSource open event? |
| 10:27 | <Hixie> | if no default action is specified, then nothing |
| 10:28 | <john_fallows> | ok, thanks |
| 10:35 | <john_fallows> | Hixie: one of the other pieces of feedback on that email thread that prompted the change from <eventsource> to EventSource mentioned sharing stream data at the browser as a killer feature for SSE, what do you think? |
| 10:36 | <Hixie> | sharing stream data? |
| 10:36 | <john_fallows> | yeah, across tabs to avoid 2 physical streams for the same logical information |
| 10:37 | <Hixie> | ah, interesting |
| 10:37 | <Hixie> | technically the spec allows that already i think |
| 10:37 | <Hixie> | though technically the second tab would need to be sent all the events so far |
| 10:38 | <Hixie> | ok i should definitely be in bed |
| 10:38 | <Hixie> | nn |
| 10:38 | <john_fallows> | nn |
| 10:55 | <annevk> | http://code.google.com/p/tircd/ is interesting |
| 11:00 | <jgraham> | annevk: It seems to encourage real-time conversations via twitter in a way that it's not clear that twitter can really manage (I know it is far from unique in having this property) |
| 11:42 | <Philip`> | Did Google change its link colour? It looks a bit more cyan to me than usual |
| 11:42 | <Philip`> | but it might just be my eyes |
| 11:43 | <virtuelv> | Philip`: dunno -- color: #0029cc; |
| 11:44 | <virtuelv> | default is #0000cc |
| 11:44 | <Lachy> | Philip`, looks the same color to me |
| 11:45 | <Lachy> | maybe your monitor is getting old and rendering colours wrongly |
| 11:45 | <Philip`> | Hmm, it's different in Opera than in Firefox |
| 11:46 | <Philip`> | Maybe it's a per-cookie thing? |
| 11:47 | <Philip`> | The front page is #0000cc, but the search results page uses #03e |
| 11:47 | <Philip`> | It's weird and disturbing :'-( |
| 11:48 | <Philip`> | (and it's definitely a real change in the markup, not just monitor/eyes/etc) |
| 11:51 | <hsivonen_> | Philip`: are they decaying the color over time based on cookie? |
| 11:54 | <Philip`> | hsivonen_: That would be kind of neat, but totally absurd |
| 11:55 | <Philip`> | Also I didn't notice this problem yesterday, so it's a sudden change and not a decay :-) |
| 11:55 | Philip` | guesses it's just some kind of experiment |
| 12:41 | jgraham | hates Swedish telecoms companies |
| 13:12 | <Lachy> | Hixie, from section 5.1 Browsing Contexts, "The origin of the about:blank Document is set when the Document is created..." - shouldn't that say "The origin [and the effective script origin] ..." |
| 13:14 | <Lachy> | hmm, maybe not. |
| 13:14 | <Lachy> | Section 5.4 Origin only sets the origin: |
| 13:14 | <Lachy> | If a Document has the address "about:blank" |
| 13:14 | <Lachy> | The origin of the Document is the origin it was assigned when its browsing context was created. |
| 13:16 | <Philip`> | jgraham: More than British ones? |
| 13:23 | <jgraham> | Philip`: Yes on the quite reasonable basis that I no longer have to deal with british ones. |
| 13:24 | <jgraham> | ANd also on the basis that I could always get an internet connection within the first 6 weeks of trying there, whereas that has not been the case here |
| 13:27 | <jgraham> | Although admittedly my experiences with both English and Swedish telecoms companies suffer from small number statistics |
| 13:28 | hsivonen_ | decides to try implementing frameset-ok as an insertion mode |
| 13:41 | <jgraham> | hsivonen_: Hacker news comment threads (e.g. http://news.ycombinator.com/item?id=500781 ) have doubled text, some in grey, with the HTML 5 Firefox |
| 13:43 | <hsivonen_> | jgraham: thanks. It seems that node removals from parent during AAA aren't properly notified to layout. |
| 13:44 | <hsivonen_> | jgraham: if you try selecting the text, some of the text doesn't exist as selectable |
| 13:44 | <jgraham> | hsivonen_: Oh yes, I noticed that but forgot to say :) |
| 14:16 | <gsnedders> | MikeSmith: I was going to ping you about something. Any idea what? |
| 14:19 | <MikeSmith> | gsnedders: yeah, you were finally going to send me that big bag of dope you've been promising |
| 14:19 | <gsnedders> | Ah, OK. |
| 14:20 | <MikeSmith> | gsnedders: plus, you said you were going to write a poem about me |
| 14:20 | <gsnedders> | Ah, OK. |
| 14:20 | <MikeSmith> | you said it would be along the lines of Gilgamesh |
| 14:20 | <MikeSmith> | but with more sex |
| 14:23 | <gsnedders> | Ah, OK. |
| 14:40 | <Lachy> | gsnedders, I think I need something like an include mechanism in anolis, so that I can include automatically generated bits together with the rest |
| 14:41 | <gsnedders> | Lachy: email |
| 14:41 | <Lachy> | specifically, what I have is the element descriptions being extracted and generated from the HTML5 spec, and I need each of those to be included along with the custom explanatory text that I write for each |
| 14:41 | <gsnedders> | Lachy: Email. |
| 14:43 | <jgraham> | Surely that should be eMail if you are progressively adding caps :p |
| 14:43 | <Lachy> | jgraham, no, it's e-mail or E-Mail |
| 14:44 | <jgraham> | but everything that is foo -> foo on the internet gets a lowercase e |
| 14:47 | <Philip`> | jgraham: Do you mean "foo -> efoo"? |
| 14:48 | <Philip`> | I guess eRDF supports your case |
| 14:50 | <Lachy> | I can't think of anything else that has a lowercase e like that. |
| 14:52 | <gsnedders> | What the best way to teach someone how to use a compuer? |
| 14:52 | <gsnedders> | *computer |
| 14:52 | <jgraham> | gsnedders: No one knows |
| 14:52 | <Philip`> | gsnedders: Give them one and tell them not to worry about breaking it |
| 14:52 | <gsnedders> | :P |
| 14:53 | <jgraham> | gsnedders: However a more sensible question would have more parameters like the age and background of the person involved |
| 14:54 | <gsnedders> | jgraham: 65, has minimal experience using Mac OS 7 asking for help every approx. 0.5 seconds |
| 14:54 | <Philip`> | Other useful parameters include what the goal of teaching them to use a computer is |
| 14:55 | <gsnedders> | Philip`: Use teh power of teh intarwebs!111!!eleventy! |
| 14:56 | Philip` | knows an elderly person who likes going to classes at the local Apple store |
| 14:56 | <gsnedders> | (Or, use the web and email) |
| 14:56 | <jgraham> | gsnedders: So what are the main problems? |
| 14:56 | <gsnedders> | Philip`: local here means 80 mlles away |
| 14:56 | <jgraham> | Like typical problems would be "fear of data loss" |
| 14:56 | <gsnedders> | jgraham: Not knowing how to do anything, more or less :) |
| 14:57 | <jgraham> | Is it paranoia about breaking something or... |
| 14:57 | <gsnedders> | "I just don't like using it." |
| 14:59 | <jgraham> | Replace the desktop with sugar, explain it is designed for children and that you have no idea how to use it either? |
| 14:59 | jgraham | will think of a serious suggestion in a moment |
| 14:59 | <Philip`> | I'm not sure that much sugar would be particularly healthy |
| 14:59 | <gsnedders> | Also, lack of intuition about how to delete something (y'know, you see that delete button?) |
| 15:00 | <Philip`> | By "that delete button", do you mean "that button which says <--- on it"? |
| 15:00 | <jgraham> | gsnedders: Have you turned on text in icons? That seems like it would help by reducing the abstraction level |
| 15:01 | <gsnedders> | Philip`: The delete button that says delete on it |
| 15:01 | <jgraham> | (Does OSX even do that?) |
| 15:01 | <gsnedders> | jgraham: Yeah |
| 15:01 | <gsnedders> | jgraham: yeah |
| 15:01 | <gsnedders> | jgraham: It is turned on. |
| 15:02 | <jgraham> | Hmm. I think people have difficulty with the abstract concepts associated with using a computer, particularly if they are old |
| 15:02 | <jgraham> | But I don't know what you do about it |
| 15:02 | <gsnedders> | Nor do I. |
| 15:03 | <Philip`> | Teach them through repetition to know which actions are needed to perform the tasks they want to perform |
| 15:03 | <Philip`> | As long as nothing changes much (e.g. they don't accidentally resize their windows), that works well enough to be beneficial in practice |
| 15:04 | <jgraham> | http://www.google.com/search?q=teaching+old+people+to+use+a+computer+techniques&btnG=Search&hl=en&sa=2 seems like it might be helpful |
| 15:05 | <jgraham> | Actually the sugar suggestion, whilst impractical, is not entirely non-serious for roughly the reason Philip` mentioned; the fact that everything runs fullscreen means there is a lot less conceptual baggage around window mangement |
| 15:05 | Philip` | hopes it's not considered too patronising to talk about "old people" like this |
| 15:10 | Philip` | discovers that GCC 4.3 does data flow analysis to detect aliasing violations in C++, which is pretty neat |
| 15:12 | <Philip`> | (It is, admittedly, less neat that the language supports errors that can't be detected without data flow analysis, and can't reliably be detected even with data flow analysis) |
| 15:13 | <Philip`> | (but that's what makes it fun) |
| 15:14 | <gsnedders> | Heh. |
| 15:15 | <gsnedders> | Side-effect of my mother's great computing skill: just got an email saying payment has to be made by 28 Feb for where I was meant to be going during Easter holidays. |
| 15:15 | <gsnedders> | (It has, inevitably, not been made.) |
| 15:20 | gsnedders | thinks the sugar idea might not be a bad one |
| 15:25 | <jgraham> | It seems you can run sugar in its own window, which is nice |
| 15:26 | <Philip`> | Can you combine it with the 3D rotating virtual desktops of Compiz to make a sugar cube? |
| 15:41 | Philip` | sees that about 15% of Canvex visitors over the past ten days have 1024x768 screens, and almost everyone else it at least 1280x800 |
| 15:41 | <Philip`> | which I suppose is nice in terms of knowing that there's no point caring about 800x600 |
| 15:41 | <Philip`> | and not much point in caring about anything below 1280x800 |
| 15:42 | <Lachy> | Philip`, sure, but remember that not everyone maximises their window and on a 1024 screen, a non=maximised window may only be about 800px wide |
| 15:42 | <svl_> | Philip`: but of course that half of those with larger resolutions won't be running fullscreen, and will probably have their browser widths set to something close to 800 or 1024 |
| 15:42 | svl_ | is slow |
| 15:43 | <Lachy> | on my 1920x1200 screen, my browser window is only about 1200px wide |
| 15:44 | <Philip`> | (Hmm, and 40% of the 1024x768 users were IE, which I really don't care about in Canvex) |
| 15:45 | <Philip`> | Lachy: But at least they can choose to maximise their browser in order to fully experience my compelling content |
| 15:45 | <Philip`> | rather than simply not having a big enough monitor |
| 16:55 | <sayrer> | does HTML5 cover interoperability of mixed SSL / non-SSL pages? |
| 17:01 | <jgraham> | "Let L be a string of the same length as S where each character of L is either the Unicode lowercase |
| 17:01 | <jgraham> | equivalent of the corresponding character of S |
| 17:01 | <sayrer> | I ask because I noticed that Safari leaves SSL indicators in that case while Firefox turns them off |
| 17:01 | <jgraham> | " - has ES3.1 really abandoned the cases where case shifting changes the number of characters |
| 17:05 | jgraham | should ask on es-discuss but doesn't want to without some confirmation he is not being totally dozy |
| 17:05 | <gsnedders> | This is why I don't post to mailing lists. |
| 17:07 | <Philip`> | jgraham: Do you have an example where lowercasing changes the number of characters? |
| 17:07 | <Philip`> | (in whatever locale it's meant to be) |
| 17:08 | <jgraham> | Philip`: In some locales, yes. |
| 17:09 | <jgraham> | Note that the draft also says toUpperCase behaves in exactly the same was as toLoerCase |
| 17:09 | <jgraham> | toLowerCase |
| 17:09 | <jgraham> | and toUpperCase has several non-locale-dependant cases where the length changes |
| 17:10 | <jgraham> | e.g. u00DF -> u0053 u0053 |
| 17:13 | <Philip`> | alert("\uFB00".toUpperCase()) seems to consistently give U+FB00 in browsers |
| 17:16 | <jgraham> | Philip`: AFAICT Squirrelfish and V8 give FF for that case |
| 17:16 | <Philip`> | Oh |
| 17:17 | <Philip`> | alert("\uFB00".toUpperCase()) seems to consistently give U+FB00 in the three browsers I tested, which excludes anything based on WebKit |
| 17:17 | <gsnedders> | WebKit from a few days ago gives FF |
| 17:18 | <jgraham> | (and if the intention was to ignore special cases like this, it is surprising that the next paragraph in the spec specifically draws attention to the fact that SpecialCasings.txt must be considered) |
| 17:19 | gsnedders | thinks teh spec is b0rked |
| 17:20 | <jgraham> | For bonus points, decide what is supposed to happen with "\u03A3\u03A".toLowerCase()3 |
| 17:20 | <jgraham> | er, "u03A3\u03A3".toLowerCase() |
| 17:21 | <jgraham> | s/"u/"\u/ |
| 17:21 | gsnedders | waits for jgraham to eventually get there |
| 17:21 | <jgraham> | Or something. |
| 17:21 | <jgraham> | Look you know what I mean |
| 17:21 | <gsnedders> | Oh, sure. |
| 17:58 | <Philip`> | sayrer: I don't remember ever seeing HTML5 cover anything SSL-related like that |
| 17:59 | <Philip`> | (which is probably intentional, since it's a UI issue and isn't really related to HTML interoperability) |
| 18:13 | <sayrer> | Philip`, there are lots of things in the spec that aren't related to HTML interoperability |
| 18:13 | <sayrer> | but I could see whether the page is considered secure influencing some parts of navigation |
| 18:14 | <sayrer> | also cache policies |
| 18:18 | <Philip`> | sayrer: It does seem to be mentioned in the context of navigation: "Note: Typically user agents are configured to not report referrers in the case where the referrer uses an encrypted protocol and the current page does not (e.g. when navigating from an https: page to an http: page)." |
| 18:18 | <Philip`> | (I imagine one could argue whether this kind of thing should be a normative requirement) |
| 18:21 | <sayrer> | maybe it's not a big deal |
| 18:21 | <sayrer> | a mixed-context page should get all of the restrictions an SSL page does |
| 21:50 | <Hixie> | jmb: btw, the google maps bug was fixed |
| 21:50 | <Hixie> | let me know if you spot any others |
| 21:51 | <jmb> | Hixie: thanks :) |
| 21:51 | <jmb> | Hixie: I shall :) |
| 21:51 | <gsnedders> | Hixie says having been reminded :P |
| 21:52 | <Hixie> | :-) |
| 22:26 | Philip` | wonders if 8KB is unacceptably large for a favicon |
| 22:28 | <Philip`> | Hmm, looks like it's well above average, but some other sites have quarter-megabyte favicons, so I won't feel too guilty |
| 22:29 | Philip` | now has a nice animated 16x16 Sierpinski gasket favicon |
| 22:29 | <Hixie> | QUARTER MEGABYTE?! |
| 22:30 | <Philip`> | http://l4d.com/blog/images/favicon.ico |
| 22:31 | <Hixie> | wow, they're ready for the high res world |
| 22:31 | <Philip`> | It's still only a 16x16 icon |
| 22:32 | <Philip`> | Looks like they've got a high-res BMP version of the image after the IEND chunk in the PNG |
| 22:32 | <Hixie> | that wasn't 16x16 for me |
| 22:32 | <Hixie> | unless safari is showing me some other chunk |
| 22:33 | <Philip`> | Hmm, Opera and Firefox show me a 16x16 one |
| 22:34 | <Philip`> | Safari tries to download the file instead of displaying it |
| 22:34 | <Philip`> | Actually it looks like the file has a low-res PNG, then a low-res BMP, then a high-res PNG, then a high-res BMP |
| 22:35 | <Hixie> | what's the outer format? |
| 22:35 | <Hixie> | or are they just concatenated |
| 22:36 | <Philip`> | http://images.wikia.com/half-life/en/images/6/64/Favicon.ico is pretty huge too |
| 22:36 | <Hixie> | "images/6/64/" indeed |
| 22:36 | <Philip`> | Those numbers are just from the MD5 of the filename :-p |
| 22:36 | <Hixie> | likely story! |
| 22:37 | <Philip`> | About outer format: Oh, I thoughtlessly assumed it was PNG, but actually it's not, so presumably it's the new Windows ICO format that embeds high-res PNGs |
| 22:37 | <Hixie> | aah |
| 22:38 | <Philip`> | $ echo -n Favicon.ico|md5sum - |
| 22:38 | <Philip`> | 64682bf96f86015fb949533728963457 - |
| 22:38 | <Philip`> | It's a very likely story that that's the MD5 :-) |
| 22:40 | <Hixie> | :-P |
| 22:41 | <Philip`> | (Well, there's a 1 in 256 chance that that was a coincidence, except I already know how Mediawiki generates directory names for images) |