| 00:11 | <fantasai> | Hixie: I believe you wrote tests proving the opposite in 2005 :) |
| 00:12 | <fantasai> | Hixie: http://www.w3.org/Style/CSS/Test/CSS3/Selectors/current/html/tests/css3-modsel-27a.html |
| 01:18 | <jamesr__> | Hixie: Window object that's not a global scope? |
| 04:22 | <MikeSmith> | fyi dvcs.w3.org is down and I can't do anything to fix it right now because I can't even ssh into it a the moment |
| 04:22 | <MikeSmith> | likely will not be back til Europe comes online |
| 04:23 | <MikeSmith> | the lesson is, move your spec sources to github |
| 04:28 | <MikeSmith> | when did writing technical documents in HTML become such a challenge for Web developers? https://github.com/whatwg/serial/issues/3 |
| 04:37 | <zewt> | losing hope at the future of the web when even github does that "don't link to the real file, link to a page that does an html refresh to the file" crap |
| 04:38 | <zewt> | re: no, really, copying a download link on my desktop and wgetting it in a terminal doesn't mean i want to download a 15k html file |
| 06:31 | <MikeSmith> | kinetik: dunno if you're on the dashjs mailing list but https://groups.google.com/d/msg/dashjs/4UfYEYZ_Zno/5lMubhuqxfcJ |
| 07:24 | <kinetik> | MikeSmith: thanks, i wasn't aware of it! |
| 07:40 | <MikeSmith> | kinetik: cheers |
| 09:28 | <Ms2ger> | annevk, ping |
| 09:33 | <jgraham> | zewt: I am starting to wonder if you are turning into RMS and mainly browsing the web async through command line tools :) |
| 09:34 | <Ms2ger> | Javascript is the devil's work! |
| 09:39 | <MikeSmith> | yay https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/t0XiZuMey7M ("Intent to Implement and Ship: Moving DOM attributes to prototype chains") |
| 09:40 | <Ms2ger> | Woo |
| 09:40 | <Ms2ger> | - The new behavior makes it easy to port Blink�s C++ implementation into JavaScript and reduce complexity of Blink. For example, we are planning to move editing implementation (e.g., execCommand) from C++ to JavaScript. With the new behavior, we just need to hook DOM attribute getters/setters and implement the logic all in JavaScript. |
| 09:41 | <MikeSmith> | though still "This change will regress several micro benchmarks by 10% or so. We have been working on this project for two years and are concluding that it would be hard to decrease the regression any more without crankshafting binding callbacks to V8." |
| 09:41 | <MikeSmith> | Ms2ger: yeah part that sounds pretty coold |
| 09:41 | <Ms2ger> | We'll see :) |
| 09:42 | <MikeSmith> | V8 sure seems to introduce a lot of quirky limitations |
| 09:43 | <Ms2ger> | Well, they've had a speed advantage because their setup meant they didn't have to do some checks |
| 09:44 | <MikeSmith> | ok |
| 10:06 | <jgraham> | "we just need to implement all the logic in javascript" - that's a usage of the word "just" that I haven't previously encountered |
| 10:09 | <Ms2ger> | I read "we just need to hook DOM attribute getters/setters, and then we can implement the logic all in JavaScript." |
| 10:11 | <jgraham> | I think what they meant to write was "we just need to hook COM attribute getters/setters, and then arghhh execCommand my eyes, my eyes, they burn, make it go away, please Mummy, please…" |
| 10:14 | <Ms2ger> | COM? |
| 10:17 | <jgraham> | er, DOM |
| 10:17 | <jgraham> | Although freudian slip really |
| 11:02 | <zcorpan> | nice. i didn't know that was a two-year project already |
| 11:03 | <zcorpan> | (or i didn't know it was a project at all) |
| 11:16 | <Ms2ger> | That's quite long |
| 11:17 | <Ms2ger> | We haven't even been working on webidl bindings for two years |
| 11:35 | <annevk> | Ms2ger: yo |
| 11:37 | <Ms2ger> | annevk, I think I figured it out... Wasn't sure if http://dom.spec.whatwg.org/#node-is-inserted would be called on all nodes in the inserted tree or just the roots of the subtrees |
| 12:22 | <smaug____> | "We cannot observe any regression in Robohornet." |
| 12:22 | <smaug____> | robohornet is still a thing? |
| 12:23 | <smaug____> | I thought it died immediately after it was announced |
| 12:38 | <MikeSmith> | smaug____: I don't remember hearing about it all |
| 12:40 | <smaug____> | https://github.com/robohornet/robohornet doesn't look too active |
| 12:41 | <smaug____> | robohornet was just mentioned in the google doc about getter/setters |
| 12:42 | <smaug____> | and that doc was dated 2013 Oct 30 |
| 12:57 | <Ms2ger> | xhr-1 is back? |
| 12:57 | <Ms2ger> | "Initially, we'd planned to put together a draft with only the parts that are *already compatibly* supported across the major implementations, but it turned out that most of the major features are showing *subtle differences* in behavior." |
| 12:57 | <Ms2ger> | ... and that's surprising? |
| 13:07 | <Ms2ger> | odinho, so RESO INVALID? |
| 13:21 | <annevk> | Ms2ger: it's only invoked for the inserted node |
| 13:22 | <annevk> | Ms2ger: if that node has descendants, they're not notified |
| 13:22 | <annevk> | Why does Ms2ger keep leaving the channel? |
| 13:23 | <annevk> | As for "xhr-1", sounds like everything old is new again. |
| 13:27 | <annevk> | Blink finally getting major IDL compliance boost: https://groups.google.com/a/chromium.org/d/msg/blink-dev/t0XiZuMey7M/j9PnVUUzBuUJ |
| 13:39 | <zcorpan> | i see 201 cases of <link charset> that's different from the document's content-type charset in webdevdata june |
| 13:40 | <zcorpan> | and 2359 <link charset>s in total |
| 13:40 | <Ms2ger> | annevk, because my class isn't in the restaurant |
| 13:42 | <Ms2ger> | annevk, and yeah, that's what I ended up with, but I was a little confused by things like... "for each node in nodes, in tree order, run node is inserted." |
| 13:42 | <annevk> | Ms2ger: DocumentFragment man |
| 13:42 | <Ms2ger> | Yeah |
| 13:43 | <zcorpan> | 808 if i also log files with no content-type charset |
| 13:43 | <Ms2ger> | Maybe it'd make more sense to use "in order", or so |
| 13:43 | <annevk> | Soon we're gonna define ShadowRoot... |
| 13:43 | <Ms2ger> | Since nodes is a list, not a tree |
| 13:43 | <annevk> | Hmm, are they not still in a tree? |
| 13:43 | <Ms2ger> | Not anymore, at that point |
| 13:44 | <Ms2ger> | Oh, for inserted, they're in the new tree |
| 13:48 | <zcorpan> | 322 if i take <meta charset> into account |
| 13:50 | <annevk> | zcorpan: Hixie: SimonSapin: I don't see the point in dropping <link charset> / <?xml-stylesheet charset?> as long as you still inherit from the document |
| 13:50 | <annevk> | zcorpan: Hixie: SimonSapin: both are in control of a potential attacker |
| 13:50 | <annevk> | zcorpan: Hixie: SimonSapin: so given that, the compatibility risk does not seem worth it |
| 13:51 | <SimonSapin> | agreed |
| 13:51 | <zcorpan> | yeah |
| 13:51 | <zcorpan> | the motivation would probably be to simplify things if nobody uses it |
| 13:51 | <SimonSapin> | I kept it in http://dev.w3.org/csswg/css-syntax/#environment-encoding |
| 13:51 | <zcorpan> | but people seem to use it |
| 13:52 | <SimonSapin> | zcorpan: do we have data on that? |
| 13:52 | <zcorpan> | SimonSapin: see above |
| 13:52 | <zcorpan> | next step would be to check if the style sheet actually contains non-ascii, but i'm not sure it's worth the trouble |
| 13:53 | <zcorpan> | SimonSapin: i can dump the data somewhere suitable. was there a bug about specifying <link charset> in html? |
| 13:54 | <SimonSapin> | z |
| 13:54 | <SimonSapin> | zcorpan: https://www.w3.org/Bugs/Public/show_bug.cgi?id=14703#c20 |
| 13:55 | <zcorpan> | not a clean bug :-) i can file a new one though |
| 13:55 | <SimonSapin> | Hixie: told me to post it there, but I can make a new one if it helps |
| 13:55 | <SimonSapin> | s/:// |
| 13:56 | <zcorpan> | oh, ok then i'll just use that bug |
| 14:01 | <SimonSapin> | zcorpan: also http://lists.w3.org/Archives/Public/www-style/2013Oct/0690.html |
| 14:02 | <zcorpan> | SimonSapin: yep |
| 14:05 | <zewt> | jgraham: D: |
| 14:06 | <annevk> | smaug____: your comment in https://www.w3.org/Bugs/Public/show_bug.cgi?id=23565 makes it seem as if you have not read the bug |
| 14:06 | <annevk> | smaug____: what am I missing? |
| 14:11 | <zcorpan> | commented in the bug |
| 14:12 | <Ms2ger> | annevk, I think the argument about undefined==omitted really isn't as strong as some people make it out to be |
| 14:13 | <smaug____> | annevk: I have read the bug. And undefined !== omitted |
| 14:13 | <annevk> | Ms2ger: it's now core of the language |
| 14:13 | <Ms2ger> | annevk, it's not, it's core of what TC39 thinks the language should be |
| 14:14 | <Ms2ger> | annevk, in practice, it isn't true right now |
| 14:14 | <smaug____> | right |
| 14:14 | <annevk> | Ms2ger: unless you change ES6, that's nonsense |
| 14:14 | <Ms2ger> | annevk, and making it true has costs that may well be bigger than the benefit |
| 14:15 | <annevk> | Ms2ger: again, unless you change the direction of the language, this is not an argument we need to have here |
| 14:15 | <Ms2ger> | annevk, changing the direction of the language is fine with me |
| 14:15 | <annevk> | Ms2ger: so make it so |
| 14:16 | <annevk> | Ms2ger: meanwhile I'll skate to where the puck is going to be |
| 14:16 | <Ms2ger> | annevk, but people in TC39 seem to be so stubborn about it that it's not worth my time |
| 14:17 | <Ms2ger> | annevk, and backcompat in the DOM seems to be ignored |
| 14:17 | <annevk> | Ms2ger: have you ever engaged with them? |
| 14:17 | <annevk> | Ms2ger: just arguing with me on the sidelines is not going to do you much good and kind of feels like a waste of time for both of us |
| 14:18 | <Ms2ger> | annevk, you introduced a bug in dom |
| 14:18 | <Ms2ger> | annevk, who else should I argue with? |
| 14:18 | <smaug____> | Ms2ger: you're an editor too. Fix the bug :p |
| 14:18 | <Ms2ger> | annevk, and do you think that arguing with tc39 about this is not a waste of time? |
| 14:19 | <annevk> | Ms2ger: well, I think you're wrong and I think it makes sense to strive towards undefined and omitted being equal |
| 14:20 | <Ms2ger> | annevk, perhaps in general |
| 14:20 | <Ms2ger> | annevk, but in actual APIs, it seems to turn out to be developer-hostile or not web compatible |
| 14:20 | <Ms2ger> | annevk, case in point, classList.toggle |
| 14:21 | <annevk> | Ms2ger: that bug is not about classList.toggle |
| 14:21 | <Ms2ger> | annevk, sure, so that makes two cases where undefined==omitted leads to a dev-hostile API |
| 14:21 | <annevk> | What exactly is dev-hostile? |
| 14:22 | <Ms2ger> | cloneNode() not doing a deep clone is dev-hostile |
| 14:22 | <Ms2ger> | toggle("foo", bar) working right iff bar is not undefined is dev-hostile |
| 14:22 | <annevk> | cloneNode() not being equal to cloneNode(undefined) is more dev-hostile imo, especially longer term. |
| 14:22 | <smaug____> | why? |
| 14:23 | <annevk> | Because it would be inconsistent with all other APIs |
| 14:23 | <Ms2ger> | I'm not convinced it's *more* dev-hostile |
| 14:23 | <annevk> | So you cannot simply pass arguments through to a cloneNode() invocation. You have to special case undefined. |
| 14:24 | <Ms2ger> | The simply "pass through arguments" point is, to use one of the words you seem to like a lot, nonsense |
| 14:24 | <Ms2ger> | That's what ... is for |
| 14:25 | <annevk> | I don't see how ... would work in an API that takes an object as argument and you just want to pass one of that object's properties to cloneNode() |
| 14:25 | <Ms2ger> | That's not "simply pass through arguments", though |
| 14:25 | <annevk> | Yes it is |
| 14:26 | <annevk> | Anyway, s/arguments/parameters/ if that makes it easier |
| 14:26 | <Ms2ger> | I fully agree that cloneNode(something that happens to be undefined) should do a deep clone |
| 14:26 | <Ms2ger> | But we can't do that |
| 14:26 | <Ms2ger> | Yay webcompat |
| 14:27 | <Ms2ger> | But making cloneNode() not do a deep clone is throwing the baby out with the bathwater, IMO |
| 14:27 | <Ms2ger> | As bz said, it's the tail wagging the dog |
| 14:27 | <smaug____> | oh, cloneNode(undefined) should definitely not do deep clone |
| 14:28 | <annevk> | I'm going back to doing something useful |
| 14:28 | <smaug____> | :) |
| 14:28 | <smaug____> | lunch time |
| 14:28 | <Ms2ger> | Agreed to fix it as Gecko is going to implement it, then? |
| 14:46 | <Ms2ger> | Interestingly, the only hits on Google for sobbenbunker are brucel's |
| 15:02 | <annevk> | This is so fucked: https://rniwa.com/2013-10-29/web-compatibility-story-of-scrolltop-and-scrollleft/ |
| 15:04 | <annevk> | Where did zcorpan go? |
| 15:04 | <annevk> | I wonder how https://www.w3.org/Bugs/Public/show_bug.cgi?id=20976#c11 is relevant. |
| 15:05 | <annevk> | Never mind. |
| 15:30 | <annevk> | Domenic_: should there be some kind of convenience callback for promises when they complete? E.g. rather than .then(a,a) have .complete(a) or some such? |
| 15:30 | <Domenic_> | annevk: you mean like .then(a)? |
| 15:30 | <annevk> | Domenic_: so if you have cleanup code you don't do the mistaken thing of .then(a) |
| 15:30 | <Domenic_> | oh you mean .finally(a) |
| 15:30 | <annevk> | Domenic_: that's invoked for the failure case too? |
| 15:30 | <annevk> | Domenic_: ah right, finally |
| 15:30 | <Domenic_> | yes i really want .finally |
| 15:30 | <Domenic_> | not sure if there's political will for it, we tried earlier and decided not to rock the boat too much |
| 15:31 | <Domenic_> | might be worth trying again? |
| 15:31 | <annevk> | Domenic_: let's wait until we have two stable browsers shipping promises |
| 15:31 | <annevk> | Domenic_: and maybe some tests? |
| 15:31 | <Domenic_> | yeah seems good. |
| 15:31 | <Ms2ger> | Tests are good |
| 15:32 | <Domenic_> | we have lots of tests for the hardest part of the API, but only for one of the sugar methods. |
| 15:32 | <Domenic_> | also want to convert to test-262 form |
| 15:45 | <annevk> | Domenic_: for streams; is there an issue of notifying the reader of the writer having stopped writing to the stream because an error of sorts occurred? |
| 15:45 | <annevk> | Domenic_: for connection dropping, timeout, etc. |
| 15:55 | <MikeSmith> | annevk: re https://www.w3.org/Bugs/Public/show_bug.cgi?id=20976#c8 the components work seems to be creating some unwelcome side effects |
| 15:55 | <MikeSmith> | the xml:base-under-another-name things |
| 15:56 | <MikeSmith> | in that specific case |
| 15:56 | <annevk> | MikeSmith: if Chrome implements it correctly it might be okay, but xml:base has always been fraught with bugs |
| 16:15 | <Hixie> | no opinions on how ports should work, huh |
| 16:21 | <dglazkov> | good morning, Whatwg! |
| 17:08 | <annevk> | Hixie: I'm having a hard time with GC vs memory |
| 17:18 | <Hixie> | annevk: hm? |
| 18:17 | <Domenic_> | annevk: yeah that's generally handled by pipe, but, yeah, error notification is tricky, worth opening an issue for tracking. |
| 18:37 | <marcosc> | Is anyone planning to (or already) implement this quota API? https://dvcs.w3.org/hg/quota/raw-file/tip/Overview.html |
| 18:40 | <aklein> | Hixie: yt? I've got a MessageChannel/MessagePort question |
| 18:41 | <Hixie> | shoot |
| 18:41 | Hixie | is actually deeply in MessagePort right now |
| 18:41 | <aklein> | Hixie: see the attachment on https://code.google.com/p/chromium/issues/detail?id=312962 |
| 18:41 | <Hixie> | marcosc: i don't understand why it's necessary, fwiw |
| 18:41 | <aklein> | basically I clone a port via postMessage |
| 18:41 | <aklein> | then transfer it again |
| 18:42 | <aklein> | neither Chrome nor Safari throw, even though I'm transferring the "target" port |
| 18:42 | <aklein> | I expect what ends up happening is the message (and the transferred port) end up in limbo, since the cloning process neuters the MessagePort that was expected to receive the message |
| 18:43 | <Hixie> | uh yeah, shouldn't that throw? |
| 18:43 | <marcosc> | Hixie, I'm thinking the same thing... but was not sure if maybe someone was implementing it. |
| 18:43 | <Hixie> | aklein: nobody could ever _want_ to write that though right? |
| 18:43 | <aklein> | the trick is that in a multi-thread, multi-process architecture it's hard to synchronously answer the question "what's the remote end of this port" |
| 18:43 | <aklein> | Hixie: right, it's a stupid thing to do |
| 18:43 | <Hixie> | yeah, i could see it'd be hard to tell |
| 18:44 | <aklein> | I'm wondering if we can relax the spec to not throw there |
| 18:44 | <aklein> | but I can admit that it seems nice to tell the author they've done something stupid |
| 18:44 | <Hixie> | aklein: so you're saying "If any of the objects in transfer are either the source port or the target port (if any), then throw a DataCloneError exception and abort these steps" should be changed? |
| 18:45 | <Hixie> | or rather, it should only check for source port |
| 18:45 | <aklein> | Hixie: that's the line I'm asking about, yeah. source port (should) be easy enough to check |
| 18:45 | <Hixie> | we can have an async requirement later that says "if it's the target port, abort, and optinally notify the author in the console" |
| 18:45 | <aklein> | Chrome can check the target port only in a really simple case |
| 18:45 | <aklein> | Hixie: that sounds much more implementable |
| 18:45 | <annevk> | Domenic_: done |
| 18:45 | <aklein> | haven't tried IE yet to see what it does |
| 18:46 | <Hixie> | aklein: can you file a bug on me to do that? http://whatwg.org/newbug |
| 18:46 | <Hixie> | aklein: while i have you here and thinking about ports, any opinion on http://lists.w3.org/Archives/Public/public-whatwg-archive/2013Oct/0362.html ? |
| 18:47 | <aklein> | Hixie: heh, I'll take a look, but I only ended up here due to a memory leak |
| 18:47 | <aklein> | will file a spec bug |
| 18:47 | <Hixie> | aklein: heh |
| 18:47 | <aklein> | (after lunch, apparently) |
| 18:47 | <Hixie> | aklein: i only ended up here due to trying to define how scripts execute |
| 18:47 | <aklein> | Hixie: ha |
| 18:47 | <Hixie> | funny how many things end up at message ports :-P |
| 18:52 | <Hixie> | wtf, does firefox not support MessageChannel? |
| 18:52 | <Hixie> | even IE supports MessageChannel |
| 18:53 | <Hixie> | speaking of which... any IE10 or IE11 people able to get me the results of running http://www.hixie.ch/tests/adhoc/dom/web-apps/postMessage/ports/001.html and http://www.hixie.ch/tests/adhoc/dom/web-apps/postMessage/ports/002.html ? |
| 18:55 | <annevk> | Hixie: https://bugzilla.mozilla.org/show_bug.cgi?id=911972 |
| 19:23 | <annevk_> | Hixie: will run in IE10 in a bit |
| 19:25 | <annevk> | Hixie: 001: did not receive, 002: received |
| 19:28 | <aklein> | Hixie: filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=23685, reading that thread now |
| 19:30 | <aklein> | Hixie: I probably don't know enough about history in Chromium to answer that thread well, but (C) sounds the best to me. |
| 19:32 | <annevk> | rafaelw: have you discussed with wycats what needs to happen for microtasks btw? |
| 19:32 | <annevk> | rafaelw: Hixie is apparently blocking on you guys |
| 19:38 | <rafaelw> | annevk: I think the discuss needs input from others. |
| 19:39 | <rafaelw> | I don't see Yehuda or I convincing each other. |
| 19:39 | <rafaelw> | s/discuss/discussion |
| 19:40 | <rafaelw> | Although this reminds me that Polymer hit an issue that was apropos. I'll go add info about that to the bug. |
| 19:52 | <Hixie> | annevk: thanks. |
| 19:53 | <rniwa> | annevk: indeed! |
| 19:53 | <Hixie> | aklein: looks like chrome and IE make the port get owned by the Window that received it, and so don't deliver if that frame gets navigated away |
| 19:53 | <Hixie> | which isn't intuitive to me as an author, but i understand why it happens |
| 20:25 | <zcorpan_> | i wonder if mpeg la will just remove the upper cap in the future to avoid the loop hole |
| 20:33 | <jamesr__> | the blockage on microtasks is about what to do when a microtask spins the event loop, right? |
| 20:33 | <jamesr__> | i tried to remove the HTML tokenizer dependency |
| 20:33 | <Domenic_> | no it's about different microtasks sources being interleaved or separate |
| 20:34 | <jamesr__> | ah |
| 20:34 | <jamesr__> | just FIFO |
| 20:34 | <jamesr__> | everything else is insane |
| 21:08 | <smaug____> | yes, microtasks should be fifo |
| 21:13 | <jamesr__> | make that FIFO, make the parser not spin the event loop, make sync XHR + window.showModalDialog() throw an exception when called from a microtask. done |
| 21:15 | <Hixie> | "make the parser not spin the event loop"? |
| 21:17 | <jamesr__> | Hixie: right now 12.2.5.4.8 The "text" insertion mode has a step that invokes the spin the event loop algorithm |
| 21:17 | <jamesr__> | if you managed to call that from within a microtask, you'd have a bad time |
| 21:17 | <Hixie> | i know, there's a bug about it |
| 21:17 | <Hixie> | you can't just not spin the event loop though |
| 21:18 | <jamesr__> | but i don't think the behavior of that algorithm is observably different from an algorithm that doesn't invoke the spin the event loop |
| 21:18 | <Hixie> | i mean, the alternative is to hang... |
| 21:18 | <jamesr__> | i think you can |
| 21:18 | <jamesr__> | nah |
| 21:18 | <jamesr__> | you can just refactor it. i send a proposal to whatwg a month ago, you replied, and i haven't had a chance to respond yet |
| 21:18 | <jamesr__> | we don't actually spin the event loop in blink |
| 21:18 | <jamesr__> | i doubt any browser really does |
| 21:18 | <Hixie> | if you don't return to the event loop, the event loop doesn't pump, so you can't do anything that requires the event loop |
| 21:18 | <Hixie> | since the parser is waiting for hte event loop to pump something... |
| 21:19 | <jamesr__> | you just return |
| 21:19 | <Hixie> | (https://www.w3.org/Bugs/Public/show_bug.cgi?id=20821) |
| 21:19 | <Hixie> | returning is what spinning the event loop is |
| 21:19 | <Hixie> | "spin the event loop" is just "remember where you are, return, and then when the condition is met, queue a task to resume" |
| 21:23 | <jamesr__> | hm, well couldn't you just return to running microtasks? |
| 21:24 | <Hixie> | sure, the parser isn't a problem here |
| 21:24 | <Hixie> | it's showModalDialog() that's the probelm |
| 21:24 | <Hixie> | problem |
| 21:24 | <Hixie> | and document.close() |
| 21:25 | <Hixie> | well, actually, i guess the parser is too |
| 21:25 | <Hixie> | the problem is that the spec says to suspend the current task |
| 21:25 | <Hixie> | and there's no task running in a micortask |
| 21:25 | <Hixie> | microtask |
| 21:25 | <jamesr__> | ah, but you don't need to suspend the current task |
| 21:26 | <jamesr__> | since there's nothing to keep track of. once you hit the step in the algorithm that would spin the event loop you can just run the rest of the steps asynchronously |
| 21:26 | <jamesr__> | there's no context to return to |
| 21:26 | <Hixie> | there is in showModalDialog() |
| 21:26 | <jamesr__> | right. that should throw if called in a microtask |
| 21:27 | <Hixie> | i proposed that, people didn't like it |
| 21:27 | <Hixie> | see e.g. https://www.w3.org/Bugs/Public/show_bug.cgi?id=20821#c3 #c4 and #c5 |
| 21:28 | <jamesr__> | hrm |
| 21:29 | <jamesr__> | well, i suppose if folks feel that having showModalDialog work in microtasks is important they can propose a way to make it work |
| 21:29 | <Hixie> | i proposed a way to do that too (see the end of that bug) |
| 21:29 | <Hixie> | it's just waiting on dom to be edited, but anne wants something else to be resolved first |
| 21:30 | <Hixie> | not sure what that is exactly, but it's in https://www.w3.org/Bugs/Public/show_bug.cgi?id=22296 |
| 21:43 | sicking | wishes showModalDialog would just die a painful death |
| 21:44 | <Hixie> | we could make it die quicker by making it throw here |
| 21:44 | <sicking> | does anyone know how much it's used? Event-loop spinning is terrible for both authors and implementors |
| 21:44 | <Hixie> | i don't think it's used much on the open web |
| 21:44 | <Hixie> | more so probably in intranets and obscure web apps |
| 21:44 | <Hixie> | (in https://www.w3.org/Bugs/Public/show_bug.cgi?id=20821#c3 you argued it shouldn't throw, fwiw) |
| 21:45 | <sicking> | i think we implemented it because it was used on some yahoo property |
| 21:45 | <Hixie> | i know the chrome guys keep trying to kill it |
| 21:45 | <Hixie> | so if you want some support, you can definitely find it there :-) |
| 21:45 | <Hixie> | support in a quest to kill it, i mean |
| 21:47 | <sicking> | Hixie: got any names? |
| 21:47 | <Hixie> | jamesr__ (see above), aklein, abarth... |
| 21:48 | <abarth> | SHOW MODAL DIALOG |
| 21:48 | <abarth> | that thing is a disaster |
| 21:49 | <sicking> | abarth: does chrome do warnings for deprecated APIs? |
| 21:49 | <sicking> | abarth: i.e. would you guys be willing to add a warning anytime its used and gather stats on how often that is? |
| 21:50 | <abarth> | sure |
| 21:50 | <sicking> | great, i bet we could do that too. I'll email |
| 21:50 | <abarth> | I'll add it right now |
| 21:50 | <sicking> | yay! |
| 21:51 | <aklein> | abarth: will happily lgtm such a usecounter |
| 21:51 | <sicking> | Hixie: does the new <dialog> still support modal (as in sync and event-loop-spinning) APIs? |
| 21:51 | <Hixie> | sicking: see how eager they are? i'm telling you, they hate it ;-) |
| 21:51 | <Hixie> | sicking: no |
| 21:51 | <sicking> | Hixie: great |
| 21:52 | <Hixie> | sicking: you call showModal() and it returns right away |
| 21:52 | <rafaelw> | sicking: I thought the issue with showModalDialog was OutlookWebAccess uses it. |
| 21:52 | <sicking> | nice |
| 21:52 | <Hixie> | sicking: if it takes long enough for <dialog> to get figured out, it might get updated to return a promise |
| 21:52 | <Hixie> | sicking: for now it fires an event on the <dialog> when closed |
| 21:54 | <jamesr__> | every now and then we try to kill it and find another page that depends on it that we can't break |
| 21:54 | <jamesr__> | but it's worth trying again |
| 21:55 | <sicking> | adding warnings first tends to be a good way to give it a declining usage rate |
| 21:55 | <sicking> | rather than an increasing one "because it's there" |
| 21:55 | <sicking> | killing it at this point is likely too early, but it's not too early to start driving down adoption |
| 21:56 | <jamesr__> | we only barely support it |
| 21:58 | <sicking> | it was a pretty late addition for us. I'm sad that we didn't resist harder. |
| 22:01 | <zcorpan_> | i see 65 showModalDialogs in http://webdevdata.org june data set (no external scripts) |
| 22:04 | <zcorpan_> | sicking: does warnings work for decreasing usage? |
| 22:05 | <zcorpan_> | sicking: absolute usage, that is? |
| 22:05 | <sicking> | zcorpan_: i don't actually have hard data. But I don't know if we're measuring it anywhere. What I do know is that we've received relatively little complaints about removing APIs once we've been warning about them for a while. Much more complaints when we remove APIs without warning first. But that could be a conicidence. |
| 22:10 | <zcorpan_> | sicking: is there a list of things you are warning about or have warned about, with start-end dates? |
| 22:12 | <sicking> | zcorpan_: see this file and its history: http://mxr.mozilla.org/mozilla-central/source/content/base/public/nsDeprecatedOperationList.h |
| 22:13 | <zcorpan_> | sicking: thx |
| 22:14 | <sicking> | zcorpan_: warning text here: http://mxr.mozilla.org/mozilla-central/source/dom/locales/en-US/chrome/dom/dom.properties#47 |
| 22:23 | <zcorpan_> | mutation events seems like a suitable thing to check for |
| 22:25 | <zcorpan_> | although that sort of thing is likely to be in external scripts maybe |
| 22:26 | <sicking> | seems like we're already warning, no? |
| 22:28 | <zcorpan_> | yes. i mean check the usage of it and see if it has changed over time |
| 22:32 | <zcorpan_> | 97 showModalDialogs in webdevdata's september data set (102,000 pages). so ~0.1% use showModalDialog in inline scripts |
| 22:35 | <Domenic_> | I ... I may have used showModalDialog ... don't hurt me ... https://github.com/NobleJS/setImmediate/blob/master/qUnitTest/tests.js#L80-L96 |
| 22:52 | <jamesr__> | that's a silly test |
| 22:52 | <Domenic_> | nah, it failed before i added some interesting code |
| 23:00 | <zcorpan_> | sicking: march 2012, 0 instances of mutation events (small dataset though, i'm downloading the bigger december 2012 dataset now). september 2013, 86 instances out of 102,000 pages |
| 23:00 | <sicking> | zcorpan_: what dataset are you looking at? some set of urls? Or usage statistics from some browser? |
| 23:01 | <zcorpan_> | sicking: http://webdevdata.org |
| 23:01 | <sicking> | that's cool |
| 23:02 | <sicking> | i don't know if that's an approach that would make me feel comfortable with removing an API implementation though... |
| 23:04 | <zcorpan_> | i agree |
| 23:05 | <Hixie> | the bias towards home pages in these public data sets is the biggest problem i've seen with them |
| 23:05 | <Hixie> | home pages are a different kettle of fish entirely to the majority of web content, in my experience |
| 23:05 | <zcorpan_> | yeah, and lack of external scripts and styles is also a problem |
| 23:06 | <Hixie> | yeah |
| 23:06 | <Hixie> | (still, better than nothing) |
| 23:06 | <Hixie> | lack of external scripts and styles was the biggest problem i had doing research at google |
| 23:06 | <zcorpan_> | i've filed bugs about that but i haven't done any work to fix it, and it appears no one else has either |
| 23:07 | <zewt> | (what does "home pages" mean, exactly) |
| 23:07 | <gsnedders> | How does CommonCrawl stand up, BTW? |
| 23:08 | <zcorpan_> | zewt: GET / |
| 23:08 | <zewt> | "home pages" to me means "my personal website" (which seem not that common these days, overall) |
| 23:09 | <TabAtkins> | "the facebook home page" clearly means www.facebook.com, on the other hadn. |
| 23:09 | <zewt> | that's pretty meaningless to me |
| 23:09 | <TabAtkins> | Shrug, ok. |
| 23:10 | <zewt> | most people would probably interpret that as the page you see when logged in (not the login page), which incidentally are both served as "www.facebook.com" |
| 23:10 | <Hixie> | "home page" is pretty much industry standard speak for "/" |
| 23:11 | <zcorpan_> | gsnedders: how do i use it? |
| 23:12 | <gsnedders> | zcorpan_: Practically, you use Elastic MapReduce. The dataset, uncompressed, is over 100TB, so one can't really download it. |
| 23:15 | <zewt> | "XMLHttpRequest Level 1" :| |
| 23:15 | <zcorpan_> | gsnedders: is it free to run searches? i don't even see where to start. i tried creating an account but don't like to continue when it requires my credit card details :-| |
| 23:16 | <zcorpan_> | also, amazon account registration fails at handling non-ascii input |
| 23:17 | <gsnedders> | zcorpan_: No, you need to have credit for AWS server time |
| 23:17 | gsnedders | realizes why he can't ssh into his desktop |
| 23:17 | <gsnedders> | It's not turned on. |
| 23:20 | <odinho> | classic fault with modern computers. |
| 23:23 | <zcorpan_> | gsnedders: can i do this sort of thing with Elastic MapReduce? http://www.w3.org/Bugs/Public/show_bug.cgi?id=14703#c21 |
| 23:25 | <gsnedders> | zcorpan_: You can do anything! Typically with Java, but anything! |
| 23:25 | <gsnedders> | zcorpan_: Also doing stuff on the entire dataset is kinda expensive. |
| 23:30 | <zcorpan_> | gsnedders: ok, so on the plus side it has deep pages. it doesn't seem to have external styles or scripts. and i'm totally unfamiliar with how to run the searches, and i have to pay for it |
| 23:34 | <Hixie> | oh bummer, something broke in my bug updating code |
| 23:34 | <zewt> | who's going to say it |
| 23:39 | <TabAtkins> | I tried to report a bug about ti, but... |
| 23:39 | <Hixie> | i don't understand what's wrong |
| 23:40 | <Hixie> | it's complaining about a bad token |
| 23:40 | <Hixie> | but the token is right... |
| 23:41 | <Hixie> | the hell |
| 23:41 | <Hixie> | TabAtkins: the bug _reporting_ code is actually fine :-P |
| 23:41 | <Hixie> | it's only the script that updates the bug with the diff that's broken |