| 00:05 | <jgraham> | Things that surprise me: "ReviewBoard" and "amazing" in the same sentence |
| 00:06 | <jgraham> | I can only imagine this is compared to using Bugzilla comments for code review or something |
| 04:49 | <llrcombs> | poll: who thinks that <track> should have a method for adding/removing cues? |
| 04:50 | <llrcombs> | so JS could download a file in a non-WebVTT (that's the format, right?) format, parse it, and feed it to <track> |
| 04:50 | <llrcombs> | (right now, you'd have to parse it, then convert it to WebVTT and feed it to <track> as a data: URL) |
| 10:40 | <annevk> | logs down? |
| 10:41 | <annevk> | hmm, seems like something else is going on, maybe krijnh's new caching system? |
| 11:06 | <hsivonen> | (Member-only) http://lists.w3.org/Archives/Member/tag/2011Jun/0056.html |
| 11:14 | <Dashiva> | You tease |
| 11:14 | <Dashiva> | annevk: confirmed no logs for today, it updated fine yesterday after his announcement though |
| 11:27 | <Dashiva> | xml-dev thread on namespaces in html5 is enlightening |
| 11:28 | <smaug____> | w3c should do less communication in member only lists |
| 11:29 | <Ms2ger> | But then how can people make ludicrous claims without being called out for it? |
| 11:30 | <Dashiva> | Ms2ger: Simply make calling out people for ludicrous claims a non-conforming use of the internet |
| 11:32 | <Dashiva> | "I can imagine some cases where the document size would more than double using this scheme - not an unimportant consideration for high-performance worldwide document distribution. Perhaps the ideal would have been to allow both encodings." |
| 11:32 | <Dashiva> | This is how simplicity ends. |
| 13:06 | <krijnh> | Ping |
| 13:07 | <krijnh> | Hm |
| 13:11 | <krijnh> | Ah, little bug. Fixed anne! |
| 14:15 | <annevk> | wait, tweakers.net said Firefox 5 is released |
| 14:15 | <annevk> | mozilla.com however says something different |
| 14:16 | <annevk> | ah I see, they link to the ftp server |
| 14:16 | <annevk> | for which you have to have login credentials |
| 14:16 | <annevk> | good times |
| 14:16 | <annevk> | oh well, release builds are boring anyways |
| 14:17 | <jgraham> | I think it's released on Mon or Tue |
| 14:17 | <jgraham> | But yeah, that just means it's obsolete :) |
| 14:18 | <annevk> | aaah |
| 14:19 | <annevk> | David has a @mozilla.com address |
| 14:19 | <annevk> | guess that means he has even more time to provide awesome reviews :) |
| 14:28 | <krijnh> | Awesome fast /irc-logs/ is awesome \o/ |
| 14:31 | <annevk> | awesome krijn is awesome |
| 14:31 | <annevk> | as long as it works anyway |
| 14:31 | <krijnh> | Yeahyeah :) |
| 14:32 | <krijnh> | Why didn't I do it like this before.. |
| 14:33 | <krijnh> | Ah, right, HTML5 wasn't supported in browsers yet |
| 14:35 | <annevk> | meh |
| 14:35 | <annevk> | parts of HTML5 were in browsers before you started web development :p |
| 14:35 | <krijnh> | ORLY |
| 14:35 | <Ms2ger> | What, innerhtml? |
| 14:36 | <krijnh> | <image> for sure |
| 14:36 | <krijnh> | Anyway |
| 14:36 | <krijnh> | Permission to let you people be again? :] |
| 14:36 | <annevk> | charset registry is another failure it seems |
| 14:36 | <krijnh> | (And stop breaking my server!) |
| 14:36 | <annevk> | half a year! |
| 14:37 | <krijnh> | See you tomorrow annevk o/ |
| 14:37 | <Ms2ger> | annevk, no, seriously? |
| 14:40 | <annevk> | krijnh, might just make it :) |
| 14:40 | <annevk> | Ms2ger, one day Web Encodings will be an actual document that can be implemented |
| 14:40 | <annevk> | problem might be that nobody cares or dares touching that code |
| 14:41 | <Ms2ger> | Can't blame them |
| 14:43 | <annevk> | oh, Facebook is part of the W3C now |
| 14:52 | <annevk> | Ms2ger, btw, you made a change where you described something in terms of appendChild or some such; given mutation events I'm not sure that's a good idea |
| 14:53 | <Ms2ger> | Hmm, I guess |
| 14:53 | Ms2ger | has done his best to avoid thinking about them |
| 14:55 | hsivonen | notes that the mutation events of innerHTML are described like that |
| 14:57 | <annevk> | I'm hoping smaug wins |
| 14:57 | <Ms2ger> | Don't we all? :) |
| 15:32 | <annevk> | I wonder if someone filed a bug on Opera to do what Gecko does for http://www.w3.org/Bugs/Public/show_bug.cgi?id=11960 |
| 15:38 | <annevk> | whoa lots of activity in http://lists.w3.org/Archives/Member/tag/2011Jun/ |
| 15:38 | <annevk> | unusual |
| 15:51 | <AryehGregor> | Ooh, there's some juicy stuff there. |
| 16:03 | <annevk> | http://www.w3.org/TR/1998/NOTE-xh-19980511 sweet |
| 16:06 | <annevk> | I better stop reading up on DOM Level 3 Events I think |
| 16:31 | AryehGregor | loves discovering all the quirks that non-HTML5 text/html parsers have -- like apparently Opera allows <h1>foo<h2>bar</h2>baz</h1> and doesn't auto-close the <h1> |
| 16:32 | <Ms2ger> | Old Gecko might've supported that as well |
| 16:32 | <AryehGregor> | The only thing that's better than understanding how insane the HTML parser is is understanding how insane *three* HTML parsers are, two of them undocumented. |
| 16:43 | <annevk> | haha |
| 16:43 | <annevk> | I wish W3C AB minutes were public |
| 17:22 | <gsnedders> | AryehGregor: I do still like our approach, of using pointers to get the right layout while still having a weird DOM as if we weren't actually doing half of what is needed for compat. |
| 17:23 | AryehGregor | has not studied it in detail |
| 17:23 | <AryehGregor> | Or at all. |
| 17:23 | gsnedders | looked at it a bit a couple of years back |
| 17:23 | <gsnedders> | Then I mostly got dragged into ES-land, and jgraham has become the parser guy. :P |
| 17:24 | <The_8472> | * AryehGregor loves discovering all the quirks that non-HTML5 text/html parsers have -- like apparently Opera allows <h1>foo<h2>bar</h2>baz</h1> and doesn't auto-close the <h1> <- imo autoclosing tags is more of a mess than nesting elements that shouldn't be nested. |
| 17:24 | <AryehGregor> | The_8472, sure, but we have to for compat, so it's nice that we're finally getting to see everyone move to the same way of doing it. |
| 17:25 | <The_8472> | yeah, moving in the worse direction :( |
| 17:27 | <MikeSmith> | in other news, http://www.karlgroves.com/2011/06/16/barriers-to-improving-the-accessibility-game-plan/ is worth reading |
| 17:29 | <MikeSmith> | AryehGregor: btw, any chance you might be able to be in Santa Clara the week of the TPAC? |
| 17:29 | <MikeSmith> | end of October |
| 17:29 | <AryehGregor> | MikeSmith, when's TPAC? |
| 17:29 | <AryehGregor> | No. |
| 17:29 | <AryehGregor> | I'll be in school. |
| 17:29 | <MikeSmith> | oh |
| 17:29 | <MikeSmith> | ah |
| 17:31 | <gsnedders> | AryehGregor: Pff, that's no excuse! |
| 17:31 | <AryehGregor> | It is at the school I'm going to. |
| 17:32 | <The_8472> | AryehGregor, a very fundamental problem with accessability is that nobody pays for it. |
| 17:32 | <MikeSmith> | The_8472: interesting |
| 17:32 | <gsnedders> | AryehGregor: I may well be there provided I have no assessments that week. :P |
| 17:32 | <The_8472> | we do mostly web-based backends at work. the customers don't ask for accessability, they want a solution fast and cheap. and interactive (usually fancy widgets based on JS libraries) |
| 17:32 | <MikeSmith> | that's also a fundamental problem with browsers |
| 17:34 | <MikeSmith> | finding customers who do actually care about accessibility and doing work for them instead is one way to screws that I guess |
| 17:34 | <The_8472> | i mean even lesser disabilities like red-green blindless are only considered peripherially (e.g. when it comes to indicator colors) |
| 17:35 | <The_8472> | lesser but common i mean |
| 17:35 | <The_8472> | rare ones... it would be time spent that nobody pays for |
| 17:40 | <The_8472> | http://www.karlgroves.com/2011/06/16/barriers-to-improving-the-accessibility-game-plan/#comment-19 <- |
| 17:40 | <The_8472> | i agree with that one |
| 17:47 | <MikeSmith> | wow |
| 17:47 | <MikeSmith> | I think that may be the only time I have seen that dude say something halfway sensible |
| 17:56 | <hsivonen> | hmm. http://www.cafepress.de/dd/45953815 |
| 17:57 | <hsivonen> | for a lot of stuff, I'd probably prefer CSV over RDF |
| 17:58 | <Ms2ger> | You must hate Semantics |
| 17:58 | <hsivonen> | no HTML5 shirts or mugs at http://www.cafepress.com/W3C_shop |
| 17:58 | <hsivonen> | I guess the W3C is really about RDF |
| 18:00 | <MikeSmith> | maybe if dude added a toilet-paper product with that design he'd get more buyers |
| 18:13 | <MikeSmith> | he should add some products with this design - |
| 18:14 | <MikeSmith> | http://www.brucelawson.co.uk/2011/with-the-power-of-html5/ |
| 18:15 | <Ms2ger> | And we reached Godwin |
| 18:48 | <jgraham> | gsnedders: You like the old Opera parsing approach?! I guess there had to be someone... |
| 18:49 | <gsnedders> | jgraham: In a sarcastic manner |
| 18:57 | <AryehGregor> | I found an unusually fun non-serializability issue in WebKit: insertText with bad characters in the value. Like \r, or \0. |
| 18:58 | AryehGregor | looks at the HTML parsing algorithm for inspiration on how to fix it |
| 19:15 | <jgraham> | """If we could generate a highly visible lawsuit every month â letâs say it cost $1 million a year to do that â we would see an increase in demand for our services ten times that. Good investment, no?""" |
| 19:19 | <llrcombs> | poll: who thinks that <track> should have a method for adding/removing cues? |
| 19:19 | <llrcombs> | so JS could download a file in a non-WebVTT (that's the format, right?) format, parse it, and feed it to <track> |
| 19:19 | <llrcombs> | (right now, you'd have to parse it, then convert it to WebVTT and feed it to <track> as a data: URL) |
| 19:19 | <hsivonen> | jgraham: where's the quote from? |
| 19:20 | gsnedders | wonders why jgraham never cites quotations |
| 19:21 | <Ms2ger> | A habit from the time he was working on his PhD? :) |
| 19:21 | <zewt> | Read more at: |
| 19:22 | <jgraham> | From the article MikeSmith already linked to |
| 19:22 | <jgraham> | http://www.karlgroves.com/2011/06/16/barriers-to-improving-the-accessibility-game-plan/#comment-18 |
| 19:22 | <jgraham> | Well from a comment |
| 19:24 | <zewt> | "read more at" may be the most abusive, hostile javascript nonsense yet, heh |
| 19:24 | <zewt> | certainly among the most annoying |
| 19:26 | <llrcombs> | zewt: read more at? |
| 19:26 | <zewt> | clipboard hijacking |
| 19:26 | <llrcombs> | oh, that |
| 19:26 | <llrcombs> | I block tynt |
| 19:27 | <llrcombs> | JS Blacklist FTW |
| 19:27 | <zewt> | you can't block it--not if a site tries hard enough (most don't, though) |
| 19:27 | <llrcombs> | oh, you always can |
| 19:27 | <llrcombs> | Safari 5 extensions have access to beforeload |
| 19:27 | <zewt> | well, by disabling javascript entirely, or large swaths of API :) |
| 19:28 | <llrcombs> | so you can download each script yourself, check it for clipboard events, and block it if it uses them |
| 19:28 | <llrcombs> | (otherwise, redirect the script to a data: url so you don't have to load 2x) |
| 19:28 | <zewt> | "each script"--but a page can merge all of its scripts together, making it all-or-nothing |
| 19:28 | <llrcombs> | ooh, ouchie on that one |
| 19:29 | <llrcombs> | fine, regex replace the script's contents |
| 19:29 | <zewt> | anyhow, manually squinting at every website's scripts isn't exactly a practical solution |
| 19:29 | <llrcombs> | it can be done programatically |
| 19:29 | <zewt> | javascript is trivial to obfuscate enough to make text searching useless |
| 19:29 | <llrcombs> | also, is it possible to destroy events? |
| 19:30 | <zewt> | no, I wish there was a way to enumerate event listeners from script |
| 19:30 | <AryehGregor> | Is there some good way, given a string, to pass it through the HTML parser to parse as a string literal? |
| 19:30 | <llrcombs> | they'd have to mention the event name somewhere in the script, so you could just replace the name with some event that doesn't exist |
| 19:30 | AryehGregor | is tempted to use <plaintext> :) |
| 19:30 | <llrcombs> | AryehGregor: you mean, force it to ignore markup? |
| 19:30 | <zewt> | window.addEventListener("cli" + "ck") :) |
| 19:30 | <llrcombs> | that'd be CDATA |
| 19:30 | <llrcombs> | ... |
| 19:30 | <llrcombs> | damn you |
| 19:31 | <Ms2ger> | "HTML" |
| 19:31 | <llrcombs> | but I think a regex could catch that |
| 19:31 | <AryehGregor> | No it wouldn't. |
| 19:31 | <llrcombs> | alright, nevermind then |
| 19:31 | <Ms2ger> | But yes, <svg><![CDATA[]]></svg> |
| 19:31 | <AryehGregor> | I mean, I have a JavaScript string and I want to say in my specification to do something to the string so that inserting it into an existing text node won't make things non-serializable. |
| 19:31 | <AryehGregor> | Like so it will handle \r and nulls and unpaired surrogates and things like that. |
| 19:32 | <llrcombs> | zewt: regex for something separated by () or , and containing "c", "l", "i", "c", and "k" in that order |
| 19:32 | <llrcombs> | OR! |
| 19:32 | <llrcombs> | oh, here's an idea |
| 19:33 | <zewt> | what good does that do you? aside from the fact that you can trivially make it contain none of those things, that doesn't tell you anything about what the click listener is for |
| 19:34 | <AryehGregor> | val = range.createContextualFragment("<plaintext>" + val).firstChild.firstChild; |
| 19:34 | <zewt> | trying to weed through scripts and find evil uses of APIs will never work--the APIs need to not allow evil things in the first place |
| 19:34 | <AryehGregor> | val = range.createContextualFragment("<plaintext>" + val).firstChild.firstChild.data; |
| 19:35 | <llrcombs> | window._addEventListener = window.addEventListener; window.addEventListener = function(event,handler,capture){if(event == "copy"){return false;}else{window._addEventListener(event,handler,capture);}}; |
| 19:35 | <Ms2ger> | .textContent? |
| 19:35 | <llrcombs> | YES |
| 19:36 | <zewt> | that doesn't help, you don't need copy to implement clipboard hijacking |
| 19:36 | <zewt> | (well, it "helps", but not against people deliberately trying to circumvent things) |
| 19:36 | <AryehGregor> | .textContent would be slightly simpler, yes. |
| 19:40 | <zewt> | llrcombs: fyi, the simplest way to prevent most clipboard hijacking methods is to disable the multiple-selection API entirely from JS |
| 19:40 | <zewt> | it's not guaranteed--there are ways to do it without that, but they're a lot less reliable |
| 19:40 | <llrcombs> | what's the multiple-selection API? |
| 19:41 | <zewt> | the API that lets selections contain multiple ranges (which AryehGregor here is all too familiar with) |
| 19:41 | <llrcombs> | I mean, how do you access it? |
| 19:41 | <zewt> | don't recall off-hand |
| 19:41 | <AryehGregor> | zewt, nobody but Gecko supports multiple selections in it anyway . . . |
| 19:41 | <AryehGregor> | Also, what do you mean "disable" it? |
| 19:41 | <AryehGregor> | getSelection() should always work. |
| 19:41 | <AryehGregor> | Plus, how can it be used in clipboard hijacking? |
| 19:42 | <llrcombs> | AryehGregor: unless you say "window.getSelection = function(){};" |
| 19:42 | <AryehGregor> | Well. Yeah, true. |
| 19:42 | <AryehGregor> | And document.getSelection too. |
| 19:42 | <llrcombs> | how do you do clipboard highjacking without the copy event? |
| 19:42 | <AryehGregor> | Except you can always get one from some other document you create, unless maybe you override the prototype or some voodoo magic like that? |
| 19:42 | <zewt> | those scripts work by creating a non-visible (not hidden, just not visible to the user) div containing the spam text, capturing various events (copy, onclick, etc), and adding the div containing the spam to the selection |
| 19:42 | <AryehGregor> | You could use execCommand("copy"), but not all browsers let you. |
| 19:43 | <AryehGregor> | Then they wait for the user to copy themselves? |
| 19:43 | <zewt> | there are various code paths for different browsers, though--been a while since I looked at it |
| 19:43 | <zewt> | right; it's really "selection hijacking" |
| 19:43 | <AryehGregor> | Ah, yeah, not really any way to avoid that. |
| 19:43 | <AryehGregor> | You shouldn't even need multiple code-paths for the latest versions of all browsers. :) |
| 19:44 | <AryehGregor> | (IE<9 has a totally different selection API) |
| 19:45 | <zewt> | ah here's one implementation of it (old, current ones probably have changed a lot): https://zewt.org/~glenn/copy_paste.js |
| 19:45 | <The_8472> | <zewt> llrcombs: fyi, the simplest way to prevent most clipboard hijacking methods is to disable the multiple-selection API entirely from JS <- then you could click-jack by carefully appending a zero-width but visible element containing text into the current, single-range selection... |
| 19:46 | <The_8472> | with hidden overflow |
| 19:46 | <AryehGregor> | There aren't separate APIs for single- and multiple-selections. |
| 19:46 | <AryehGregor> | At least not standard ones. |
| 19:47 | <zewt> | ultimately it's a losing battle, which is why I havn't pursued it |
| 19:47 | <The_8472> | well, there are functions to add ranges |
| 19:47 | <AryehGregor> | They don't work to actually give you multiple ranges per Selection except in Gecko. |
| 19:47 | <zewt> | (but I'm happy to grumble about it now and then to see if anyone has any new ideas, since it's seriously abusive) |
| 19:48 | <The_8472> | even if you can't manipulate the ranges directly you might just check for selection changes and insert elements into the dom directly as the selection happens, so even a read-only API can be circumvented |
| 19:48 | <AryehGregor> | Why do browsers expose a copy event at all? |
| 19:48 | <The_8472> | they don't need to |
| 19:49 | <The_8472> | they can just expose the keypress/mouse clicks and you're good to insert your invisible ranges |
| 19:49 | <The_8472> | just wait for the ctrl from ctrl+c |
| 19:49 | <zewt> | yeah I implemented a version that works on a timer and just watches the selection, I think |
| 19:49 | <The_8472> | and the mousedown for rightclick->copy |
| 19:49 | <zewt> | (been a while so I don't recall how much actually worked; was devil's-advocating to see how unpreventable this stuff is) |
| 19:49 | <The_8472> | and then there is the flash hijack that can directly copy things into your clipboard... |
| 19:50 | <AryehGregor> | Browsers could also hide certain keypresses from the site. |
| 19:50 | <zewt> | well, anyone sane and educated blocks flash anyway |
| 19:50 | <AryehGregor> | Well, if Flash allows that, nothing we can do except kill Flash. :) |
| 19:50 | <The_8472> | hiding ctrl clicks is a bad idea |
| 19:50 | <The_8472> | rich text editors need that |
| 19:51 | <AryehGregor> | Only ones that actually trigger a copy. |
| 19:51 | <AryehGregor> | Or only expose it after the copy has already happened. |
| 19:51 | <The_8472> | you don't need to wait that long |
| 19:51 | <The_8472> | you can manipulate the dom optimistically |
| 19:51 | <The_8472> | even if no copy happens |
| 19:52 | <AryehGregor> | That's not possible to prevent, granted. |
| 19:52 | <The_8472> | of course one could modify the copy action of browsers to only include what's *rendered* |
| 19:52 | <The_8472> | but i'm sure that's not a trivial task |
| 19:53 | <The_8472> | and then people might start trickery with visible but transparent text... |
| 19:53 | <AryehGregor> | They already do something like that. |
| 19:53 | <AryehGregor> | At least some do. |
| 19:53 | <AryehGregor> | Like WebKit. |
| 19:53 | <zewt> | that's impossible, in general--you need to copy selected text that's offscreen, so you can just put the spam text offscreen |
| 19:53 | <AryehGregor> | It's not going to help much for fixed-position off-screen stuff. |
| 19:54 | <zewt> | looks like the codepath in this script for chrome is to create a new block with the selected text, select it, and revert the selection in a 0ms timer |
| 19:54 | <zewt> | which really shouldn't work: clipboard copying should happen before any events fire, to prevent pages from messing with the page when they think you're going to copy |
| 19:55 | <zewt> | it's pretty bizarre that browsers actually allow onkeydown to cancel almost any key, even core browser stuff |
| 19:56 | <The_8472> | well, then you just modify the selection before the copy happens... e.g. on every mouse move/cursor key press, i.e. when the selection happens, not when the copy happens |
| 19:56 | <The_8472> | that sentence was brought to you by the redundancy department of redundancy |
| 19:56 | <zewt> | that doesn't work with this chrome codepath |
| 19:56 | <The_8472> | well, so they'll change it |
| 19:57 | <The_8472> | bad guys always adapt |
| 19:57 | <zewt> | to what? |
| 19:57 | <The_8472> | as long as you leave them an opening, they'll use it |
| 19:57 | <The_8472> | to your defenses |
| 19:58 | <zewt> | that's no reason to not try :) in particular, if you can make the remaining hacks inconvenient or brittle enough, it's a deterrant |
| 19:58 | <AryehGregor> | That's fatalistic. |
| 19:59 | <The_8472> | the timer polling solution is simple enough... so, do you have a way to defend against that? |
| 19:59 | <zewt> | the timer polling approach doesn't work with this method, and thinking over it I can't think of any way to make it work, at least without breaking user selections in weird ways |
| 19:59 | <The_8472> | with what method? |
| 20:00 | <zewt> | 1: create new div 2: copy the selected text into the div 3: add spam 4: save the selection 5: select the new div 6: in a timer, set the selection back to the original (after the copy completes) |
| 20:00 | <zewt> | that's what this code does in chrome/webkit (and I'm guessing IE, havn't looked that hard) |
| 20:01 | <The_8472> | my point is that it doesn't have to do it |
| 20:01 | <The_8472> | it's just what its authors deemed as the most robust way |
| 20:01 | <zewt> | and I'm asking: how can you do it in a polling way? |
| 20:02 | <The_8472> | you don't. you insert the hidden text into the dom in place |
| 20:02 | <zewt> | that's a whole lot more brittle and likely to break things badly, which like I said, is a deterrant |
| 20:03 | <zewt> | inserting a 0x0 div in the middle of the DOM has a lot more ways to screw up an existing site and its scripts than putting one at the end of the document |
| 20:03 | <The_8472> | not that brittle, considering they would control their own code. if it breaks some javascript widget they can work around it |
| 20:04 | <The_8472> | for starters, you could use a span |
| 20:04 | <zewt> | most people using this aren't exactly spending hours maintaining it (or even necessarily know how it works); they just drop it into their site; and if you have to keep dealing with ugly scripts breaking things, that'll encourage people to not use it |
| 20:05 | <The_8472> | that is assuming they are sane people |
| 20:05 | <The_8472> | sane people wouldn't try to annoy users by breaking their copy&paste |
| 20:05 | <zewt> | the alternative is to assume that they're competent people, which I think is highly questionable |
| 20:06 | <AryehGregor> | Wrong, sane people can be extremely obnoxious. |
| 20:12 | <The_8472> | i think it's non-sane people paying competent people... |
| 20:12 | <The_8472> | iow: blame marketing |
| 20:14 | <AryehGregor> | I think you're amazingly optimistic about how much a typical developer cares about their what their users actually want. |
| 20:23 | <AryehGregor> | Hmm, I just accidentally upgraded from Firefox 5 to 6, and now Firebug has disabled itself. |
| 20:23 | <AryehGregor> | Can I try to persuade it that it's compatible and see if it works? |
| 20:24 | <AryehGregor> | extensions.checkCompatibility? |
| 20:25 | <llrcombs> | you mean 4 to 5? |
| 20:25 | <AryehGregor> | No, I mean 5 to 6. |
| 20:25 | <AryehGregor> | I'm using Aurora. |
| 20:25 | <Ms2ger> | .6.0b? |
| 20:25 | <llrcombs> | oh, alrighty |
| 20:25 | <AryehGregor> | 6.0a2? |
| 20:27 | <Ms2ger> | Oh, right |
| 20:27 | <Ms2ger> | If you used Nightly, you could use extensions.checkCompatibility.nightly :) |
| 20:28 | <llrcombs> | why can't FF just suck it up and write some proper dev tools? |
| 20:28 | <llrcombs> | s/FF/mozilla |
| 20:28 | <AryehGregor> | They are. |
| 20:28 | <llrcombs> | oh, goody! |
| 20:28 | <AryehGregor> | But they're way behind the curve. |
| 20:28 | <AryehGregor> | Since they relied on Firebug for so long. |
| 20:28 | <llrcombs> | they've got the dev console, but I've heard nothing good about it |
| 20:28 | <llrcombs> | at all |
| 20:29 | <llrcombs> | well, I hear it's good with CSS |
| 20:29 | <llrcombs> | but not JS, at all |
| 20:31 | <The_8472> | firebug works on aurora though, you just have to install a beta of it or override compatibility |
| 20:31 | llrcombs | <3 WebKit Web Inspector |
| 20:32 | <zewt> | even IE9's stuff seems better than FF's, from what I've used of each |
| 20:32 | <llrcombs> | that's just sad |
| 20:33 | <llrcombs> | nothing should be worse than IE |
| 20:33 | <llrcombs> | ever |
| 20:34 | <zewt> | firefox's web console thing is fairly embarrassing; even the simple javascript console feels like a first-pass concept implementation, not a production-release implementation |
| 20:34 | <zewt> | eg. pressing up into input history leaves you at the *start* of the line |
| 20:35 | <llrcombs> | ...lolwat..? |
| 20:35 | <llrcombs> | well, it's better than Vista |
| 20:37 | <AryehGregor> | Hmm. Going to Live DOM Viewer and hitting "download" right now causes Firefox 6.0a2 to hang. |
| 20:38 | <AryehGregor> | Can anyone else reproduce? |
| 20:38 | <llrcombs> | isn't there a mozilla IRC network? |
| 20:38 | <AryehGregor> | Yes, but I'm not on it. |
| 20:38 | <AryehGregor> | There's also a Bugzilla. |
| 20:38 | <AryehGregor> | But I'm doing work and am not really interested in taking the time out to file every crash bug I find. |
| 20:39 | <AryehGregor> | Hangs probably aren't exploitable, right? So I can say what triggered it publicly, I guess. |
| 20:39 | <llrcombs> | too bad I'm not on FX, or I'd try to reproduce it for you, and then I might even file a bugzilla |
| 20:40 | <AryehGregor> | Seems just setting the textContent of an element to "\ud800" does it. |
| 20:40 | <zewt> | a whole bugzilla? |
| 20:40 | <llrcombs> | zewt: yeah, it takes a while to upload |
| 20:40 | <llrcombs> | and sometimes weird things happen |
| 20:41 | <llrcombs> | SUP DAWG, I HERD U LIEK BUGFIXEZ, SO I FILED BUGZILLA IN UR BUGZILLA SO U CAN FIX WHILE YOU FIX! |
| 20:41 | <zewt> | guh |
| 20:46 | <Ms2ger> | WFM, FWIW |
| 21:15 | <zewt> | i wonder why opera's reload scrolling behavior is so much better than firefox and chrome's |
| 21:15 | <zewt> | maybe they're waiting until onload or something to scroll and opera does it as soon as possible |
| 21:16 | <The_8472> | the problem is that reloading may load images too, which requires several reflows |
| 21:17 | <The_8472> | which may change the position of the anchor |
| 21:17 | <zewt> | ff and chrome's behavior is just really bad and annoying and opera's works well |
| 21:17 | <zewt> | i always reload in firefox, it leaves me at the top, I start scrolling down the page, then seconds later it suddenly scrolls to the old position |
| 21:25 | <AryehGregor> | Are there tests for the HTML5 serializer anywhere? |
| 21:26 | AryehGregor | just found a bug in both Gecko and WebKit HTML5 serialization |
| 21:43 | <AryehGregor> | annevk, is there any way using CSSOM View or something to tell whether a <br> is collapsed or is actually creating a line break? I.e., whether it could be removed without affecting layout? |
| 21:43 | <AryehGregor> | You could actually remove it, I guess . . . that might work. |
| 21:44 | <realityking> | I'm toying around with the history API |
| 21:45 | <realityking> | I need to set a stateObj for the initially loading page so I can get back to that state trough the popstate event |
| 21:45 | <realityking> | but that where the trouble starts |
| 21:45 | <realityking> | I have the following inside a domready event: |
| 21:45 | <realityking> | history.replaceState({"page": page}, null, window.location); |
| 21:45 | <realityking> | history.state = {"page": page}; |
| 21:45 | <realityking> | but that doesn't work |
| 21:45 | <realityking> | (just one of those doesn't either) |
| 21:46 | <realityking> | it does work fine if I reload the page once |
| 21:46 | <realityking> | am I missing something or could this be a browser bug? |
| 21:46 | <realityking> | I tested with Safari 5.1beta and Firefox 4 |
| 21:47 | <AryehGregor> | Hmm, actually removing it works for me, I guess. <br>'s behavior doesn't seem very well-defined at all . . . |
| 21:54 | <AryehGregor> | Oh, of course -- it messes up ranges. |
| 21:55 | AryehGregor | tries display: none instead |
| 22:04 | <clair> | I'm not sure how much detail to go into in copying over code for the examples at http://wiki.whatwg.org/wiki/Dialogs - does anyone know will the entire javascript function be needed or just those lines relevant to showing the dialog? |
| 22:05 | <clair> | I'm new to this so I don't know how much real world example detail is needed :) |
| 22:08 | <AryehGregor> | clair, I dunno, I guess enough for people to figure out how it works and what it does. |
| 22:08 | <AryehGregor> | A description might be more useful than copying the code, especially if you can link to the code. |
| 22:10 | <clair> | Hmm, yeah. It's minified code which doesn't help, but I guess I can say "It displays this element" or somesuch |
| 22:13 | <The_8472> | minified code is a crime imo. we already have compression at the protocol level |
| 22:14 | <clair> | The only thing it seems to be good at is making it harder for other people to read :( |
| 22:14 | <clair> | It's situations like this I'm thankful for webkit inspector's pretty print :) |
| 22:15 | <The_8472> | pretty print can only do so much when variable names get substituted too |
| 22:17 | <clair> | Yeah. Luckily, this code is pretty simple so it's easy to work out what the variables do, but you're right, I've never used minified code unless it's something like jquery - never seen the point |
| 22:20 | <erlehmann> | can anyone tell me why this bloats up memory in firefox and opera? http://daten.dieweltistgarnichtso.net/src/wer-kuesst-wen/ |
| 22:21 | <erlehmann> | webkit seems to have no problems. |
| 22:21 | <jgraham> | AryehGregor: What bug did you find in serialization? |
| 22:22 | <erlehmann> | i think it may be a problem because i load these images repeatedly. |
| 22:22 | <AryehGregor> | jgraham, <pre>\nfoo</pre> serializes to <pre>\nfoo</pre> which parses to <pre>foo</pre>. |
| 22:22 | <erlehmann> | but then that would be a serious caching bug, wouldn't it? |
| 22:22 | <AryehGregor> | HTML says to add a linebreak after a <pre> start tag always. |
| 22:22 | <AryehGregor> | It would probably make more sense to only add one if the first character is a linebreak. |
| 22:22 | <erlehmann> | lots of small images shouldn't bloat memory. |
| 22:22 | <jgraham> | AryehGregor: OK, it is the bug I knew about then :) |
| 22:22 | <AryehGregor> | But anyway it's a browser bug, even if there's also a spec bug. |
| 22:22 | <AryehGregor> | Also, Gecko serializes <xmp> wrong, it escapes < and & and such. |
| 22:23 | <jgraham> | AryehGregor: We try to do that right but I am a bit scared it will have some compat impact |
| 22:23 | <jgraham> | (with Ragnarok) |
| 22:24 | <zewt> | erlehmann: havn't looked at that, but oddly, it's WebKit i've always found is really really bad at loading small images (or any images) repeatedly |
| 22:24 | <erlehmann> | zewt, i am working to fix the issue that the images are loaded repeatedly every frame, but over time, it will still bloat. |
| 22:31 | <AryehGregor> | Could someone explain why this is 0? http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1032 |
| 22:31 | AryehGregor | scratches his head |
| 22:31 | <AryehGregor> | It doesn't make sense to me. The span creates a box, why should the box have zero height? |
| 22:32 | <AryehGregor> | Hmm, does clientHeight only work on blocks, maybe? |
| 22:32 | <AryehGregor> | Oh, right. |
| 22:32 | <AryehGregor> | "The clientTop, clientLeft, clientWidth, and clientHeight attributes must return zero if the element does not have any associated CSS layout box or if the CSS layout box is inline." |
| 22:32 | <AryehGregor> | I think I want offsetHeight. |
| 22:33 | <AryehGregor> | Why the difference, I don't know . . . |
| 22:33 | <erlehmann> | he, still not as bad as inadvertedly triggering a memory leak. |
| 22:34 | <jgraham> | AryehGregor: All those APIs are weird I think |
| 22:34 | <AryehGregor> | Apparently. |
| 22:34 | <jgraham> | I meaniirc they are a hotch-potch of things that different browsers invented |
| 22:35 | <jgraham> | Whihc doesn't typically lead to great quallity |
| 22:49 | <llrcombs> | I still would like some input on my idea though |
| 22:49 | <llrcombs> | about a method for <track> to programatically add cues |
| 22:50 | <llrcombs> | (add/remove/edit) |
| 23:18 | <clair> | If anyone's interested I've put some code examples on the wiki for the dialog proposal, I'll add in some more once I figure out how they work |