| 00:24 | <TabAtkins> | jgraham: inputmodes are generally just meant for soft keyboards, no? So it would work like the other examples - it would have a barcode button on whatever keyboard it normally pops up. |
| 00:31 | <Hixie> | TabAtkins: are there examples of OSes that support doing that? |
| 00:32 | <TabAtkins> | Not that I know of. |
| 00:32 | <TabAtkins> | (Because no mobile OS has a built-in barcode reader, I think.) |
| 00:32 | TabAtkins | leaves now. |
| 00:56 | <Hixie> | i think taking out the onbeforeunload for document.open() probably makes sense too, given the difficulty in working out what it even means |
| 02:32 | <GPHemsley> | element width trumps NBSP, right? |
| 02:32 | <GPHemsley> | explicit element width, that is |
| 02:49 | <zewt> | there's nothing special about nbsp in html, right? just a character that looks like a space but isn't a word break |
| 02:49 | <zewt> | (html has enough weirdness that I wouldn't be surprised if there was some random exception, but, well, hoping not and all that) |
| 03:06 | <zewt> | waiting for onload/onerror for an arbitrary image sure is a brittle pain without img.complete |
| 04:08 | <Hixie> | zewt: i think you're right, but check css and zcorpan's quirks spec |
| 05:36 | <MikeSmith> | when was AddSearchProvider added? |
| 05:36 | <MikeSmith> | does anybody implement it? |
| 05:37 | <MikeSmith> | oh |
| 05:37 | <Hixie> | pretty sure that's an ancient IE thing |
| 05:39 | <MikeSmith> | yeah |
| 05:51 | <gavin> | Firefox implements it |
| 05:52 | <gavin> | didn't seem that ancient to me but I guess we landed that in 2006 :/ |
| 05:52 | <gavin> | (bug 337780) |
| 06:03 | <smaug____> | looks like a Google thing ;) |
| 06:24 | <MikeSmith> | I asked because html5test dude includes in his tests |
| 06:25 | <MikeSmith> | god knows why |
| 06:31 | <zcorpan> | sigh |
| 07:15 | <MikeSmith> | friends, I'm looking for a rough estimate of how much the performance of JS engines has improved over the last 4 years |
| 07:16 | <MikeSmith> | would it be accurate to say that current JS engines are on the order of 50 times faster than they were 4 years ago? |
| 07:17 | <paul_irish> | MikeSmith: i got data for you |
| 07:17 | <MikeSmith> | ok cool |
| 07:17 | <MikeSmith> | gimme data |
| 07:17 | <MikeSmith> | Feed me, Mandrake |
| 07:21 | <paul_irish> | MikeSmith: well. here is sunspider ie6-ie10 https://github.com/h5bp/lazyweb-requests/issues/11#issuecomment-2642244 |
| 07:22 | <MikeSmith> | oool |
| 07:22 | <MikeSmith> | thanks |
| 07:22 | <paul_irish> | and here is dromaeo ie8 - http://paulirish.com/i/d914c0.png |
| 07:22 | <paul_irish> | ie8 through june 2012 |
| 07:24 | <paul_irish> | MikeSmith: so.. based on the dromaeo, we're about 10x over 4 years ago |
| 07:24 | <MikeSmith> | oh |
| 07:25 | <paul_irish> | but its mostly a DOM speed test. |
| 07:25 | <MikeSmith> | ah yeah |
| 07:25 | <paul_irish> | if octane ran on ie8 it'd more illuminating, i bet |
| 07:28 | <MikeSmith> | I wonder if there are some other ways to give some quantitative info about the JS performance improvements, other than just benchmark data |
| 07:34 | <jgraham> | MikeSmith: Like what? At the point where you start getting quantative information from a specific application, it more or less *is* a benchmark, by definition |
| 07:34 | <MikeSmith> | yeah |
| 07:35 | <MikeSmith> | trying to figure out how to explain in to a reporter |
| 07:35 | <jgraham> | I mean a more relevant/understandable metric might be "these applications run fine on modern JS engines but are unusably slow on older browsers on the same hardware" |
| 07:37 | <MikeSmith> | yeah true |
| 07:40 | <jgraham> | Hixie: So, did you put your unload + document.open tests anywhere? |
| 07:49 | <MikeSmith> | I find the best way to respond to reporters is to mostly not pay attention to the actual questions they're asking me but instead regardless of the question just steer it around so I keep repeating what I want them to put into the article |
| 07:50 | jgraham | adds "politician" to MikeSmith's career options |
| 07:50 | <odinho> | lol |
| 07:52 | <MikeSmith> | well, reporters are tricky dogs |
| 07:52 | <MikeSmith> | so you have to respond in kind |
| 07:52 | <MikeSmith> | they ask questions in this form like, "Would it be fair to say that...?" |
| 07:53 | <Ms2ger> | MikeSmith, thanks for the component :) |
| 07:53 | <MikeSmith> | np |
| 07:54 | <MikeSmith> | when they ask those questions, and if you say, "I dunno, I guess so, maybe", then they ends up writing that you believe that, in a way that makes it sound like you were the one who suggested it |
| 07:55 | <MikeSmith> | or after you tell them something, they say, "OK, understood, so from that would it be fair to say that you believe [some gross mischaracterization of what you just told them]." |
| 07:56 | <MikeSmith> | they basically have already written the article in their heads and they want to mis-ascribe the opinions to you |
| 07:57 | <MikeSmith> | anyway |
| 07:57 | <jgraham> | MikeSmith: So it would be fair to say that you think that all journalists should be sentenced to death? |
| 07:58 | <Ms2ger> | Looks like jgraham missed out on a career in journalism |
| 07:59 | <MikeSmith> | jgraham: :-) |
| 08:00 | <odinho> | Hmmmm. Robert Berjon made manifests for stuff in webapps, but he names it manifest.txt not MANIFEST as we've used before. http://dvcs.w3.org/hg/webapps/rev/47eb68524cc5 |
| 08:02 | <jgraham> | What's the point of those manifests? |
| 08:02 | <Ms2ger> | Oh, those are the useless CSSWG manifests |
| 08:02 | <jgraham> | They list which files are tests, which is fair enough] |
| 08:02 | <jgraham> | But they also give the test title? But no information about what part of the spec it is testing? |
| 08:03 | <odinho> | Seems a bit weird, I've used Ms2ger's version, where the normal version is just to list the names of the tests. |
| 08:07 | <smaug____> | Ms2ger: what is happening with parsing and serialization? |
| 08:07 | <smaug____> | you're writing a whatwg spec and MS writing w3 spec? |
| 08:07 | <Ms2ger> | Apparently so |
| 08:08 | <smaug____> | fun :/ |
| 08:08 | <smaug____> | how did that happen |
| 08:15 | <Ms2ger> | HTMLWG |
| 08:16 | <Ms2ger> | And people who have to much time on their hands and nothing useful to do |
| 08:16 | <Ms2ger> | *too much |
| 08:17 | <smaug____> | Ms2ger: whaat? HTML Wg caused that? |
| 08:17 | <Ms2ger> | Yeah |
| 08:18 | <smaug____> | More reasons to not care about HTML Wg |
| 08:19 | Ms2ger | didn't need more reasons :) |
| 09:15 | <Martin_L> | Hi. I get mixed signals whether width/height-attributes on the img-tag are deprecated or not in html5. What is the case here, in´s in, it´s out or circumstatial? |
| 09:17 | <Martin_L> | F.e. Eric Meyer´s debug stylesheet, and some other sources says it´s out. Many other tuts and discussions says they are still kickin |
| 09:18 | <tomasf> | I don't see why they would be deprecated. they serve a valid purpose, don't they? |
| 09:18 | <tomasf> | http://www.whatwg.org/specs/web-apps/current-work/multipage/the-map-element.html#dimension-attributes |
| 09:18 | <tomasf> | wait, oh |
| 09:18 | <jgraham> | Martin_L: In the spirit of "teach a man to fish" - http://www.whatwg.org/specs/web-apps/current-work/#the-img-element |
| 09:20 | <Martin_L> | jgraham: I agree, they serve a valid purpose, yes. |
| 09:20 | <jgraham> | Martin_L: (I didn't say that; tomasf did) |
| 09:21 | <Martin_L> | jgraham: tomasf: Oh crap, of cause. Sorry about that. |
| 09:23 | <zcorpan> | MikeSmith: reminder |
| 09:25 | <Martin_L> | tomasf: So I guess they are in then. Makes good sense. Thanks! |
| 09:25 | <tomasf> | np |
| 09:26 | <odinho> | zcorpan: Ms2ger got it already. |
| 09:26 | <Martin_L> | jgraham: And thank you too of cause |
| 09:26 | <odinho> | Martin_L: Never be afraid of reading the spec ;-) |
| 09:27 | <Martin_L> | odinho: Thats true :) |
| 09:49 | <odinho> | Is it really intended that we can't use variables in a sensible way any more? I mean I like [TreatUndefinedAs=Missing], why is it so discouraged to use? |
| 09:50 | <odinho> | I have to write totally stupid js code all the time to work around that. |
| 09:50 | <Ms2ger> | If you pass a variable, you pass it, no? :) |
| 09:50 | <odinho> | like openCursor(key, direction); if direction is undefined, I have to set it to "next" manually. I don't see why it can't just fall back to its own default there. |
| 09:51 | <odinho> | I mean it stringifies undefined to "undefined" and throws. |
| 09:51 | <odinho> | That's rather unhelpful imho. |
| 09:51 | <jgraham> | odinho: That's how JS works |
| 09:51 | <odinho> | So I have to do something like dir ? : dir = "next"; all over the place |
| 09:52 | <odinho> | And even for something like IndexedDB open, it's impossible to get the same behaviour with open('name', <second arg>) that you can get with open('name') |
| 09:53 | <odinho> | It's two different code paths. Not really that different, but you'll have to do if (version) open(name, version) else open(name) |
| 09:53 | <odinho> | *supershrug* |
| 09:54 | <odinho> | Have to litter my code with stupid do-no-good tests. Grr. OK, rant over. |
| 10:11 | <jgraham> | Hmm, so if I window.open a window and then window.open a new document into the same window (by naming it the same), can I get the load event on the second document? |
| 10:11 | <jgraham> | http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=1730 doesn't work |
| 10:14 | <jgraham> | (in Opera it doesn't seem to be possible to get the load event at all) |
| 10:44 | <smaug____> | jgraham: shouldn't you use window.open |
| 10:44 | <smaug____> | not document.open |
| 10:45 | <smaug____> | or maybe it doesn't matter |
| 10:45 | smaug____ | didn't remember this: // When called with 3 or more arguments, document.open() calls window.open(). |
| 10:58 | <jgraham> | smaug____: That's exactly what I was testing |
| 11:00 | <jgraham> | But I can't really work out how to write a test that shows that the name argument is obeyed if I can't work out when the second document is loaded |
| 11:00 | <jgraham> | Also, I can't really work out why there is no event, so that is something that ought to be tested on its own |
| 11:10 | <jgraham> | (well of course I can write a test, just make the pass condition happen in a timeout. But that is ofc evil) |
| 11:12 | <zcorpan> | jgraham: does it help if you use an iframe with name=x and 'x' in open()? |
| 11:15 | <jgraham> | zcorpan: Not obviously |
| 11:16 | <zcorpan> | i thought you could use onload on the iframe |
| 11:16 | <zcorpan> | but it's a different case from opening a window, so maybe both should be tested anyway |
| 11:17 | <zcorpan> | sorry if i just gave you more work :-P |
| 11:19 | <Ms2ger> | TabAtkins, rearranged a bit |
| 11:24 | <jgraham> | zcorpan: No problem :) I already suffer from something like analysis paralysis writing tests here because there is so much to test, but working out the interesting cases is hard (it's all "what if I do X and then in the middle do something surprising"), then trying to write a test with a machine checkable pass condition turns out to be hard, or the test turns out to fail in some browsers for unrelated reasons, and then finally I find that the spec d |
| 11:25 | <zcorpan> | that the spec do...? |
| 11:26 | <jgraham> | Oh man, did I not /load splitlong.pl |
| 11:26 | <jgraham> | zcorpan: No problem :) I already suffer from something like analysis paralysis writing tests here because there is so much to test, but working out the interesting cases is hard (it's all "what if I do X and then in the middle do something surprising"), then trying to write a test with a machine checkable pass condition turns out to be hard, or the test turns out to fail in some browsers for unrelated reasons, and then finally I find that the spec d |
| 11:26 | <jgraham> | ... implementation and don't know what to conclude (the spec is wrong, the implementations are wrong, life would be better sipping cocktails on a beach, etc.) |
| 11:27 | <zcorpan> | yeah |
| 11:28 | <jgraham> | So, using the load event on the iframe I can write the test I originally wanted to write, which is nice |
| 11:28 | <jgraham> | (albeit for iframes rather than windows) |
| 12:02 | <smaug____> | jgraham: so, IIRC, in Gecko script can get the load event if the inner window is reused when loading a document to just-opened window |
| 12:03 | smaug____ | wonder what is the name for inner window in the spec... I guess it is Window |
| 12:10 | <jgraham> | smaug____: I am not sure I understand how that is different from what I tried |
| 12:17 | <smaug____> | jgraham: oh, I wasn't trying say it is different |
| 12:18 | <smaug____> | just explaining what happens in Gecko |
| 12:18 | <smaug____> | event listeners are added to the inner window, and if it changes while new document is loaded, then you ofc won't get events |
| 12:21 | <jgraham> | smaug____: But when I do win1 = window.open(/*stuff*/) and then attach a handler to win1.onload, I don't get a load event which only makes sense if the inner window changes after the event handler is attached, or the load event is sync |
| 12:22 | <smaug____> | inner window changes after that, I think |
| 12:23 | <smaug____> | but before the load event fires |
| 12:23 | <jgraham> | So chagning the inner window is async? |
| 12:23 | jgraham | notes that per spec this should just be a normal navigation |
| 12:25 | <smaug____> | jgraham: it is just a normal navigation |
| 15:42 | <dglazkov> | good morning, Whatwg! |
| 16:37 | <tantek> | dglazkov do you have a good morning script? ;) |
| 16:44 | <dglazkov> | tantek: nope. Only the desire for world peace through cheerfulness :) |
| 16:44 | <tantek> | :) |
| 16:44 | <tantek> | are you going to TPAC this year? |
| 16:45 | <tantek> | There's the start of a page about it on the W3C wiki: http://www.w3.org/wiki/TPAC2012 |
| 16:45 | tantek | is on the program committee for the plenary day: http://www.w3.org/wiki/TPAC2012-Committee |
| 16:46 | <tantek> | and we're doing our planning for it out in the open in case you're curious, want to lurk, have comments: http://www.w3.org/wiki/TPAC2012-Planning |
| 16:54 | <Hixie> | jgraham: they're on hixie.ch/tests/adhoc/dom/level0/document/open/unload iirc |
| 16:54 | <Hixie> | jgraham: but they're not real tests yet |
| 16:55 | <Hixie> | 1. make the spec not fire unload events at documents that are currently executing document.open() |
| 16:55 | <Hixie> | 2. taking out the onbeforeunload for document.open() |
| 16:56 | <Hixie> | does that leave some sequence of events via nested iframes where you can get a loop... |
| 16:57 | <Hixie> | i guess not, since events only ever go down the tree, and each node can only get events so long as it's not doing d.o() |
| 16:57 | Hixie | tries to update his tests |
| 17:19 | <Ms2ger> | Yay, ap is quoting DOM 2 Events |
| 17:20 | <ap> | Ms2ger: care to quote any spec at all? |
| 17:20 | <Ms2ger> | Sure |
| 17:20 | <ap> | Ms2ger: and if that spec disagrees with previous spec, be sure to explain in detail why that was OK |
| 17:21 | <Ms2ger> | http://www.whatwg.org/specs/web-apps/current-work/multipage/webappapis.html#eventhandler |
| 17:21 | <Ms2ger> | And http://dev.w3.org/2006/webapi/WebIDL/#TreatNonCallableAsNull |
| 17:21 | <Ms2ger> | The spec disagrees with the previous spec because the previous spec wasn't implemented |
| 17:22 | <Ms2ger> | Except by webkit, apparently |
| 17:23 | <ap> | Ms2ger: it would be more effective to post that in the bug |
| 17:47 | <Hixie> | Ms2ger: yt? |
| 17:47 | <Ms2ger> | Yeah |
| 17:47 | <Hixie> | Ms2ger: MikeSmith asked us to let you know that he created the component for you so you can move the bugs over now |
| 17:48 | <Ms2ger> | Thanks, I already did :) |
| 17:48 | <Hixie> | cool |
| 17:50 | <Hixie> | ok i have a test which opera fails in one way, mozilla fails in a second, and webkit fails in a third |
| 17:50 | <Hixie> | and now IE for tie breaker! |
| 17:50 | <Hixie> | crap. IE fails it in a fourth way. |
| 17:52 | <Hixie> | browsers suck. |
| 17:53 | <Hixie> | IE appears to just end the script at document.open() during unload |
| 17:53 | <Hixie> | and opera ends the navigation |
| 17:53 | <Hixie> | both of those are too far from interop to be helpful |
| 17:54 | <Hixie> | gecko just ignores the document.write() calls |
| 17:54 | <Hixie> | that seems bad too |
| 17:54 | <Hixie> | that leaves webkit |
| 17:55 | <Hixie> | which seems to run the unloads for subframes only once... in response to the document.open(), though, not the original nav, and then it doesn't run it again for the original nav |
| 18:00 | <Hixie> | woah, document.open() in IE causes beforeunload to fire again |
| 18:00 | <Hixie> | also IE doesn't seem to fire pagehide at all |
| 18:01 | <Hixie> | i'm thinking a mixture of webkit and firefox behaviours is the way to go here |
| 18:01 | <Hixie> | have document.open/write work during unload, but make it so that the nested open() doesn't fire pagehide/unload events |
| 18:01 | <Hixie> | i wonder what happens when there's no navigation ongoing |
| 18:09 | <Hixie> | ok now looking at 003, which tests what events fire with a naked document.open() |
| 18:09 | <Hixie> | opera doesn't fire any (and is a pain about it cos it nukes timeouts extra hard somehow) |
| 18:10 | <Hixie> | firefox fires beforeunload on the doc being opened, then beforeunload, pagehide, and unload on subframes |
| 18:10 | <Hixie> | but it screws up the beforeunload handling, we learnt that yesterday |
| 18:11 | <Hixie> | webkit does the same as firefox except with no beforeunloads, which makes slightly more sense i think |
| 18:12 | <Hixie> | IE seems to kill the timeouts as aggressively as opera (weird) |
| 18:12 | <Hixie> | but it fires beforeunload for the top-level then the iframe, then unload for the top-level then the iframe |
| 18:13 | <Hixie> | so i guess that's what i was testing when i specced the spec |
| 18:15 | <Hixie> | and if you d.w() during the unload, IE jumps straight to the unloads, and then gives up on the original sequence of unloads... |
| 18:16 | <Hixie> | so you never get the inner frame's beforeunload |
| 18:16 | <Hixie> | interesting |
| 18:18 | <Hixie> | i don't understand what firefox does in this situation |
| 18:18 | <Hixie> | but not firing beforeunload seems reasonable |
| 18:18 | <Hixie> | so let's ignore beforeunload in this and try pagehide instead |
| 18:19 | <Hixie> | not firing the top level unload and pagehide makes sense too |
| 18:22 | <Hixie> | ok so if you have a subframe which, in its pagehide caused by the parent document.open()ing itself, tries to document.open() its parent, in firefox, you get two nested beforeunloads, but the second one doesn't see a pagehide |
| 18:24 | <Hixie> | o_O |
| 18:24 | <Hixie> | i got "parent is null" in one of these events (in an iframe) |
| 18:27 | <Hixie> | my head hurts |
| 18:28 | <Hixie> | that can't be right |
| 18:28 | <Hixie> | parent is null in unload in firefox? |
| 18:29 | <Hixie> | after you've done parent.document.write()? |
| 18:29 | <Hixie> | oh no |
| 18:29 | <Hixie> | nevermind |
| 18:30 | <Hixie> | IE seems to just have lots of checks that you're involved in a loop, which just bail out of the loop as soon as they detect one |
| 18:31 | <Hixie> | i don't understand what firefox is doing |
| 18:31 | <Hixie> | or webkit for that matter |
| 18:46 | <Hixie> | ok let's see... if we just make the unload algorithm bail on nested unloads, that's pretty close to what browsers do... |
| 18:51 | <Ms2ger> | Hixie, I guess it's Anne's fault that http://dom.spec.whatwg.org/ doesn't update? :) |
| 18:51 | <Hixie> | yes |
| 18:51 | <Hixie> | i hope :-) |
| 18:53 | <Hixie> | ...damnit, that breaks the regular nav case. |
| 18:53 | <Hixie> | hmm |
| 19:11 | <Hixie> | wtf is webkit doing |
| 19:13 | <Hixie> | maybe it does everything up to the document.open(), but then runs the unload again, skipping any events that were sent the first time? |
| 19:13 | <Hixie> | hmm |
| 19:15 | <Hixie> | oooh, interesting |
| 19:15 | <Hixie> | it _does_ ignore parent.document.open() from a child unload.... |
| 19:15 | <Hixie> | well not so much ignore as abort... |
| 19:18 | <Hixie> | i'm rapidly starting to see the aesthetic beauty of firefox's hardline "no document.open() during unloads" approach |
| 19:42 | <Hixie> | IE's behaviour here really makes no sense |
| 19:42 | <Hixie> | why would you call beforeunload again before aborting |
| 19:44 | <Hixie> | none of these browsers make any sense |
| 19:45 | Ms2ger | points at the topic |
| 19:46 | <Hixie> | ok this is absurd |
| 19:46 | <Hixie> | IE behaves differently if i follow a link than if i reload than if i select the url in the address bar and hit enter |
| 19:47 | <Hixie> | it varies between opera's behaviour if i reload, doing nothing at all if i hit enter, and some wacky behaviour if i follow a link |
| 21:11 | <dsheets> | "Please leave your sense of logic at the door, thanks!" does not bode well. |
| 21:18 | <Hixie> | dsheets: welcome to the web :-( |
| 21:18 | Hixie | is living that catchphrase right now trying to work out how document.open() should work when called from the unload handled of an iframe that is being unloaded because a parent frame's document.open() was called |
| 21:28 | <dsheets> | Hixie: http://en.wikipedia.org/wiki/Principle_of_explosion |
| 21:33 | <Hixie> | quite |
| 22:01 | <Hixie> | w |
| 22:01 | <Hixie> | t |
| 22:01 | <Hixie> | f |
| 22:02 | <Hixie> | having established that NONE of the browsers behave even REMOTELY interoperably, i make some compromises and write a test that assumes them |
| 22:02 | <Hixie> | all the browsers fail, IN THE EXACT SAME WAY |
| 22:03 | <Hixie> | well, except IE |
| 22:03 | <Hixie> | no idea what IE is doing |
| 22:04 | <deane> | Hang in there, Hixie, |
| 22:09 | <Hixie> | oh i know what's wrong |
| 22:21 | <Hixie> | ok with http://www.hixie.ch/tests/adhoc/dom/level0/document/open/unload/001.html firefox is close to passing what the spec says now |
| 22:22 | <Hixie> | IE is miles off. Opera has some more fundamental bugs with unload and d.o() so it's not in the running. |
| 22:22 | <Hixie> | webkit doesn't block off d.o() so it gets it wrong but that seems like something that shouldn't be too hard to fix |
| 22:23 | GPHemsley | finds it interesting that no one ever seems to read the RFC 2119 errata. |
| 22:23 | <Hixie> | http://www.hixie.ch/tests/adhoc/dom/level0/document/open/unload/002.html in webkit almost passes, it just forgets to fire beforeunload events and load/pagehide events in the current frame |
| 22:23 | GPHemsley | wonders if that makes it worth replacing RFC 2119 with a new RFC that has the errata fixed. |
| 22:24 | <Hixie> | GPHemsley: no-one reads any rfc's errata (or w3c tr/ page rec errata) |
| 22:24 | <GPHemsley> | :) |
| 22:24 | <Hixie> | that's one of the many reasons snapshot spec dev is bogus :-) |
| 22:24 | <GPHemsley> | Ah! Good argument! |
| 22:24 | <GPHemsley> | But nevertheless, the RFC 2119 errata actually change the requirement for what an RFC 2119-compliant document must say. |
| 22:25 | <GPHemsley> | (due to an accidental omission) |
| 22:25 | <GPHemsley> | as a result, few people use the errata-corrected statement in their specs—living or otherwise |
| 22:27 | <Hixie> | does HTML get it right? |
| 22:27 | <Hixie> | (whatwg.org/html) |
| 22:28 | <Hixie> | gecko gets http://www.hixie.ch/tests/adhoc/dom/level0/document/open/unload/002.html almost right, it just doesn't fire unload and pagehide in the current doc for some reason |
| 22:28 | <Hixie> | (though it does fire beforeunload) |
| 22:28 | <Hixie> | opera is again off in the weeds |
| 22:29 | <zewt> | but you can't change the text of a spec once it's etched in concrete! because... because... |
| 22:29 | <zewt> | nothing is quite as painful as reading spec-diffs |
| 22:29 | <Hixie> | IE gets it right except for pagehide not firing because |
| 22:29 | <Hixie> | zewt: how about implementing a diff spec? |
| 22:29 | <Hixie> | zewt: (as wf2 was) |
| 22:30 | <zewt> | every opengl extension is like that |
| 22:30 | <zewt> | big lists of "add this text to this section" |
| 22:30 | <Hixie> | (i wonder why the people who are all up in arms against living standards aren't up in arms against errata) |
| 22:31 | <zewt> | possibly because many of those people have "because we've always done it this way" mindsets |
| 22:32 | <Hixie> | ah, conservatism |
| 22:33 | <zewt> | conservatism itself isn't necessarily bad; changing how major things are done should be done with care--some people just go well beyond that |
| 22:33 | <zewt> | (as i'm sure you know :) |
| 22:34 | <Hixie> | nah, clearly we should just continually change things!!! :-) |
| 22:34 | <Hixie> | for the sake of it |
| 22:34 | <zewt> | it's fun! |
| 22:34 | <Hixie> | keeps people on their toes |
| 22:34 | <zewt> | so do tacks |
| 22:34 | <GPHemsley> | :) |
| 22:34 | <Hixie> | i'd think tacks keeps people in their shoes |
| 22:34 | <zewt> | also the "we learned this thing through experience 15 years ago, and therefore it applies for all time" |
| 22:35 | <Hixie> | yeah well as i'm learning first hand today, things that we learnt through experience years ago can be wrong just because we didn't do a good job learning |
| 22:35 | <Hixie> | e.g. clearly my testing for document.open() and unload was inadequate back whenever i wrote this prose |
| 22:35 | <zewt> | such as new software still pretending that arbitrary encoding support is important--after all, we learned at great pain that it was important years ago, and hey, we might want to change away from utf-8 soon! |
| 22:36 | <Hixie> | yeah, also, it's not like the Web has come up since the IETF was started |
| 22:36 | <Hixie> | so nothing has changed there |
| 22:36 | <GPHemsley> | Hixie: The erratum is the exclusion of the phrase "NOT RECOMMENDED" in the list of RFC 2119 expressions. So no, HTML doesn't get it right. And neither does DOM4. |
| 22:36 | <zewt> | of course, you and I differ on some points I'd place in this category, such as sites requiring javascript :) |
| 22:37 | <zewt> | (but life would be boring if everyone agreed on everything, wouldn't it) |
| 22:37 | <Hixie> | GPHemsley: actually HTML does get _that_ right, it doesn't use the terms RECOMMENDED per RFC2119 |
| 22:37 | <GPHemsley> | "The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in the normative parts of this document are to be interpreted as described in RFC2119." |
| 22:37 | <GPHemsley> | section 2.2 |
| 22:38 | <zewt> | what the heck |
| 22:38 | <zewt> | http://www.rfc-editor.org/errata_search.php?rfc=2119 is this really the official place to get rfc errata |
| 22:38 | <zewt> | i searched for "rfc2119 errata", this was the top link, and i closed it because it looked like some cheesy third-party site in order to find the real one |
| 22:39 | <Hixie> | GPHemsley: huh |
| 22:39 | <zewt> | ... but then the rfc itself linked me here |
| 22:39 | <Hixie> | GPHemsley: thanks for finding that |
| 22:39 | <Hixie> | GPHemsley: i need to make sure the spec is fixed there |
| 22:39 | <zewt> | i can see why nobody reads errata; i have to wade through needless typo fixes in order to find anything meaningful |
| 22:40 | <zewt> | can't just filter it; it has typo/grammar fixes marked "technical" |
| 22:40 | <Hixie> | GPHemsley: filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=18761 |
| 22:40 | <GPHemsley> | zewt: And then there's the fact that the BCP pages don't link to the errata pages of the RFCs that make them up |
| 22:41 | <GPHemsley> | Hixie: K. What should I do about DOM4? |
| 22:41 | <zewt> | (2012 and reading RFC2119 is still formatted for an 80x60 fixed-width printer) |
| 22:42 | <Hixie> | GPHemsley: file a bug on it i guess :-) |
| 22:42 | <Hixie> | GPHemsley: it should say how to do that somewhere in the spec at the top |
| 22:42 | <GPHemsley> | ah |
| 22:42 | <GPHemsley> | ok |
| 22:42 | <GPHemsley> | Ah, not part of the WHATWG component |
| 22:43 | <Hixie> | well that sucks |
| 22:43 | <Hixie> | once again there is interop on a test i wrote, where the interop is all not matching the spec |
| 22:44 | <zewt> | GPHemsley: bugzilla's component system is pretty nightmarish, heh |
| 22:44 | <Hixie> | but this is after i carefully aligned the spec to match the compromise of everything the browsers did on other tests |
| 22:45 | <Hixie> | wtf |
| 22:45 | <Hixie> | why are they all obeying document.open() in beforeunload! |
| 22:45 | <Hixie> | that is THE MAKING OF NO SENSE |
| 22:46 | <Hixie> | you can't allow document.open() in beforeunload AND fire beforeunload on document.open()! |
| 22:47 | <zewt> | oh? watch us! |
| 22:48 | <GPHemsley> | Hixie: Welcome to the Hotel California. :) |
| 22:49 | <Hixie> | i like how the browsers conveniently don't refire beforeunload in this one case |
| 22:49 | <Hixie> | because, you know, WHY BOTHER BEING CONSISTENT |
| 22:50 | <GPHemsley> | DOM4 bug is here: https://www.w3.org/Bugs/Public/show_bug.cgi?id=18763 |
| 22:50 | <GPHemsley> | Hixie: I'm sure they've all thought about this as much as you had right before you started thinking about it. ;) |
| 22:50 | <Hixie> | possible |
| 22:51 | <zewt> | bleh, Object.freeze seems more confusing than useful without strict mode to make sure it causes exceptions to be thrown, and strict mode sounds more dangerous than not with all the "awooga awooga: this causes varying behaviors" warnings around it |
| 22:51 | <Hixie> | c.f. modes considered harmful |
| 22:52 | <zewt> | and i guess ie9 doesn't support it |
| 22:52 | <zewt> | so many years until it's viable |
| 22:52 | <Hixie> | ok i guess we can have one counter for onunload and one for onbeforeunload |
| 22:53 | <Hixie> | the onunload one would prevent d.o() from being called from unload |
| 22:53 | <Hixie> | the onbeforeunload would prevent d.o() from calling beforeunload |
| 22:53 | <Hixie> | because WHY NOT |
| 22:53 | <zewt> | i'll take the possibility of having a less-stupid-javascript mode down the road, but until it's universally supported (eg. until it's not *actually* a varying mode that I have to test both sides of), no thanks |
| 22:54 | <Hixie> | the other possibility is that i just say all the browsers are wildly wrong on this one test case and hope the implementors agree |
| 22:54 | <Hixie> | any implementors around want to try to convince me one way or the other? |
| 22:54 | <Hixie> | more complexity but closer to current browsers; or further from current browsers but simpler? |
| 22:54 | <Hixie> | (there's no serious interop here) |
| 22:56 | <GPHemsley> | I think if the browser implementations vary wildly, it's probably the prime opportunity to bring logic *back* into the conversation |
| 22:57 | <GPHemsley> | just do whatever seems most logical |
| 22:58 | <GPHemsley> | (or does that not make it easier?) |
| 23:00 | <GPHemsley> | since they all do wildly different things, it seems OK to penalize them all for lack of logic and/or interoperability |
| 23:22 | <Hixie> | GPHemsley: well, in theory i agree, but if that implies a greater delta from existing implementations, it's possible they'll prefer to remain where they are than risk change |
| 23:22 | <GPHemsley> | I'd be surprised if that were the case... but at least plan B isn't terrible :) |
| 23:23 | <Hixie> | i wouldn't at all be surprised one way or the other :-) |
| 23:24 | GPHemsley | shrugs |
| 23:32 | <GPHemsley> | Hixie: I thought vendor prefixes were Bad™? |
| 23:32 | <Hixie> | reality is more subtle; what's the specific case we're talking about? |
| 23:33 | <zewt> | "Considered Harmful" Considered Harmful |
| 23:33 | <GPHemsley> | just reading Section 2.2.3 |
| 23:33 | <Hixie> | GPHemsley: that's abotu proprietary extensions, no? |
| 23:33 | <GPHemsley> | oh, yeah, maybe |
| 23:33 | <Hixie> | GPHemsley: the "vendor prefixes are bad" thing is usually regarding experiments driven from specs with active editors |
| 23:33 | <Hixie> | the key is just what'll get interop faster, basically |
| 23:34 | <GPHemsley> | I see |
| 23:34 | <GPHemsley> | so if it's already specced, they're bad |
| 23:34 | <GPHemsley> | but if it's not, then s'ok |
| 23:34 | <GPHemsley> | ? |
| 23:34 | <zewt> | not inherently, but they can be used badly (eg. for too long, etc) |
| 23:35 | <Hixie> | man opera is so far away from the others on this document.open/unload thing that it's just kinda funny testing it |
| 23:35 | <Hixie> | GPHemsley: it's more subtle than that, but to a rough first approximation, ok |
| 23:36 | <zewt> | the prefixing concept is generally under reevaluation, and there isn't yet a consensus, so you'll get different answers depending on who you ask :) |
| 23:36 | <Hixie> | well that's true about 'most anything |
| 23:37 | <zewt> | well, more so than it was until relatively recently |
| 23:38 | <Hixie> | don't confuse silent disagreement or undiscovered disagreement for agreement |
| 23:38 | <Hixie> | any more than violent discussion should be confused for disagreement |
| 23:38 | <Hixie> | e.g. my position on prefixes hasn't changed in years |
| 23:38 | <zewt> | private disagreement is different than general community-wide reevaluation, though |
| 23:38 | <zewt> | call it disagreement with more momentum if you like :) |
| 23:38 | <Hixie> | communities don't reevaluate things |
| 23:38 | <Hixie> | people do :-) |
| 23:46 | <Hixie> | one and a half days' work resolved one bug. |
| 23:46 | <Hixie> | not gonna make my targets at THAT rate! |
| 23:46 | <zewt> | you could do what lots of projects do in my experience |
| 23:46 | <zewt> | periodically close all old bugs! |
| 23:47 | <Hixie> | my goal isn't to get to zero bugs |
| 23:47 | <Hixie> | my goal is to resolve all bugs |
| 23:47 | <Hixie> | :-P |
| 23:49 | <Hixie> | jgraham's idea of putting the bug numbers in the spec, or rather, his actually doing it, is simply genius |
