| 00:00 | <TabAtkins> | Alternately: Most people were taught OO in Java or C++, so of *course* they dislike anything with a different system. |
| 00:00 | <zewt> | (that isn't how I've ever thought of OO) |
| 00:00 | <Hixie_> | that's true of some people, but other people i've talked to are people with a decade+ of experience with C++ and Java and other languages |
| 00:00 | <Hixie_> | just because you learnt one model doesn't mean you don't prefer others. |
| 00:00 | <Hixie_> | i originally learnt without OO and i prefer OO, for instance. :-) |
| 00:01 | <Hixie_> | (for many purposes; obviously, not all.) |
| 00:01 | <TabAtkins> | Sure, it's cool to prefer whatever. I like CLOS best out of every one I've found, for example. |
| 00:01 | <TabAtkins> | Which is definitely not prototype-based. It's "generic function-based", if anything. |
| 00:01 | <Hixie_> | and what i'm saying is that it's an active _dislike_ for js' model that i see |
| 00:01 | <zewt> | i learned in basic on an apple II, but i try not to let that hold me back |
| 00:01 | <TabAtkins> | I've never seen that. Shrug. |
| 00:01 | <Hixie_> | you just saw it from zewt :-) |
| 00:02 | <Hixie_> | anyway. all this is skipping past the point that i thought was particularly interesting, which is that the JS model isn't the model browsers use, so so long as we have it, you can't "explain the platform" with it |
| 00:02 | <jsbell> | zewt: Do you also read $ as "string" ? |
| 00:02 | <Hixie_> | so "explain the model" is both not a good argument, and not one that actually applies |
| 00:02 | <Domenic_> | it's definitely the model browsers use |
| 00:02 | <Domenic_> | they just have access to one extra primitive, namely actual private state |
| 00:02 | <Domenic_> | there are direct APIs for this in V8 and SpiderMonkey |
| 00:02 | <Domenic_> | SetHiddenValue/GetHiddenValue in V8 |
| 00:03 | <zewt> | not really, it's probably been 20 years since I've touched "classic" basic, heh |
| 00:03 | <TabAtkins> | Hixie_: Huh? Browsers use JS+magic. We're just trying to explain the magic so we can do things that look the same in pure JS. |
| 00:03 | <zewt> | much more time learning to hate $ thanks to perl and php |
| 00:04 | <Hixie_> | ...browsers use C++... |
| 00:04 | <TabAtkins> | Hixie_: I'm talking about what authors see. |
| 00:05 | <TabAtkins> | Browsers talk to the author with JS+magic. |
| 00:05 | <Domenic_> | some use rust. some use self-hosted stuff (i.e. JS). that's all unobservable to authors. authors see JS APIs. |
| 00:05 | <Hixie_> | so clearly i don't even know what you mean by "Explain the platform" then |
| 00:06 | <TabAtkins> | It means reducing the size of that "magic" bit. |
| 00:06 | <TabAtkins> | So that it's all just "JS". |
| 00:07 | <Hixie_> | i don't understand. what kind of magic are we talking about? |
| 00:07 | <Hixie_> | i mean, we're not talking about implementing Event or Node or Document or Window in JS, right? |
| 00:07 | <Hixie_> | or WebSocket, or XMLHttpRequest, or Location, or History |
| 00:07 | <TabAtkins> | Everything that can't be reproduced in pure JS (or can't be reproduced in a remotely similar way; for example, if it requires substantially more memory or processing time to do in JS over what native gets). |
| 00:08 | <zewt> | (incidentally, i've completely lost the discussion, heh) |
| 00:08 | <Hixie_> | surely anything that can be reproduced in JS should just be a library |
| 00:08 | <TabAtkins> | Or at least minimizing that "magic" to the small set of things that really are impossible to provide securely, or just far too difficult. |
| 00:08 | <Hixie_> | the whole point of having a platform is to provide things you can't do in a library |
| 00:08 | <Domenic_> | That should be about access to capabilities, not about basic expressive semantics |
| 00:08 | <TabAtkins> | No, it's also to provide common idioms so we're all talking the same language for common things. |
| 00:08 | <Hixie_> | i think that hits my problem with this |
| 00:08 | <zewt> | err, what? |
| 00:09 | <Domenic_> | (the former being access to a web socket, the latter being 'having private state' |
| 00:09 | <TabAtkins> | I am *super* not getting into the "never provide anything in the platform that can be done in JS" argument. |
| 00:09 | <Hixie_> | i guess that argument is the crux of the matter |
| 00:09 | <TabAtkins> | That argument is decided. The people who say "never" are wrong, and nobody listens to them. |
| 00:09 | <Hixie_> | ... |
| 00:10 | <Hixie_> | i think the opposite is clearly true |
| 00:10 | <Hixie_> | we almost never add features that can just be done in libraries |
| 00:10 | <TabAtkins> | Writing some code a few times in browsers is better than having it written by millions of authors and sent down over millions of page connections. |
| 00:10 | <Hixie_> | there's no point |
| 00:10 | <TabAtkins> | You can reproduce basically the entire platform with a socket library and WebGL. |
| 00:10 | <TabAtkins> | Your argument is invalid. ^_^ |
| 00:10 | <Hixie_> | that is true for things that browsers can do better, but by definition, if browsers can do it better, then it's not something that can be done in JS |
| 00:11 | <Hixie_> | if your argument was what we applied to the platform, there'd be almost no JS out there |
| 00:11 | <Hixie_> | and browsers would be terabytes in size |
| 00:11 | <zewt> | (i'm confused and surprised; I thought it was, at least among most people here, universally agreed that things should go in the platform even if they can be done in libraries if they're common enough, since developers shouldn't need to load a bunch of libraries to do basic stuff) |
| 00:12 | <zewt> | (with the meaning of "common enough" being more debated) |
| 00:14 | <Hixie_> | i don't think we've ever added anything that can be done in JS as well as natively. What did you have in mind? |
| 00:14 | <Hixie_> | we add things that people do as well as they can, but that native could do far better, to the platform, for sure |
| 00:14 | <zewt> | for example, the whole URL API that anne's been working on--i'm definitely tired of having to copy around query parameter parsing code everywhere I go, as well as that everyone reading my code has to learn the particular API I'm using, instead of seeing a common, standard API and knowing it already |
| 00:15 | <TabAtkins> | zewt: Yes, exactly. |
| 00:16 | <Hixie_> | the bulk of that API is Location and HTMLAnchorElement, which can't be done with JS |
| 00:16 | <zewt> | i'm talking about the API to parse out a URL into components |
| 00:17 | <Hixie_> | that's just the Location/HTMLAnchorElement API split out into a separate independent component |
| 00:17 | <zewt> | which people do all the time in JS, and there's no performance issue there, it's just a pain in the ass, and ridiculously commonly needed |
| 00:18 | <TabAtkins> | Hixie's argument would, for example, kill Set, since it's just a library over Map. (Map is needed, since you can't do Map in Map-less JS without severe performance penalties - lookup is O(n).) |
| 00:18 | <Hixie_> | yeah i really don't understand why we have many of the new JS features, Set included. |
| 00:18 | <TabAtkins> | And I don't understand why you don't understand, thus the difficulty in explaining more advanced things. |
| 00:19 | <zewt> | exaggeration aside i don't think browsers would be "terabytes in size" even if this was taken too far; Python has a very broad standard library (much more than I'd ever argue for browsers), and it's maybe 60 megs |
| 00:19 | <Hixie_> | (but it's clear that JS isn't being build with the same principles in mind as we're using e.g. for HTML) |
| 00:19 | <TabAtkins> | It seems very self-evident to me, as someone who does web programming regularly. |
| 00:19 | <Hixie_> | TabAtkins: ditto, but the opposite is what seems self-evident. :-) |
| 00:19 | <TabAtkins> | zewt: Yeah, but loading an extra 60megs into each tab is somewhat less good. |
| 00:20 | <Hixie_> | zewt: if it was taken to its logical extension, no web authors would write any code. |
| 00:20 | <Hixie_> | zewt: so browsers would have the code of every app in the world :-) |
| 00:20 | <TabAtkins> | Hixie_: That's not the logical extensions, that's ad absurdum. |
| 00:20 | <zewt> | well, that can be alleviated (you don't load things until they're used, shared memory for precompiled bytecode, etc) |
| 00:20 | <zewt> | Hixie_: like I said before, "common enough" |
| 00:20 | <zewt> | a tetris API is clearly not common enough, so people will still have to implement tetris themselves :) |
| 00:21 | <TabAtkins> | zewt: Yeah, maybe. I suspect we'll end up moving into the "broad standard library" world eventually, anyway. |
| 00:21 | <Hixie_> | i guess the logical extension would be anything that's implemented at least 5 times, so not everything. |
| 00:21 | <TabAtkins> | A realistic cutoff is quite a bit higher, but something like that. |
| 00:21 | <zewt> | TabAtkins: a similar trick in Python for server-based worker pools is to load everything you need before you fork workers, for example |
| 00:22 | <zewt> | Hixie_: my guess is tetris has been implemented more than 5 times, but I'd still say it's not common enough :) |
| 00:22 | <zewt> | ("been implemented" = in javascript) |
| 00:23 | <TabAtkins> | Right now the criteria seems to be "implemented at least thousands of times, or implemented in a few popular libraries used by millions", roughly. |
| 00:23 | <Hixie_> | anyway, i don't think that's the right criteria |
| 00:23 | <Hixie_> | i think we should add things to the platform when doing so provides something that you can't do from the authoring side. |
| 00:24 | <zewt> | it seems like you're arguing that there are only two possibilities, implementing only what can't be done in libraries at all, or implementing everything ever; there are a lot of places in-between |
| 00:24 | <TabAtkins> | Shrug, it's a reasonable calculus, when you consider author time vs browser dev time, and user page-load time. |
| 00:24 | <Hixie_> | now, that might be just consistency across a lot of authors, the way URL is (it can be cheaply added since it's just the existing API made independent) |
| 00:24 | <Hixie_> | but my point is that if that's your criteria, then it doesn't make any sense to talk about making the platform into something you can do in JS |
| 00:25 | <Hixie_> | since the whole _point_, under this design philosophy, is to provide things that can't be done |
| 00:25 | <Hixie_> | and so it's a futile goal |
| 00:25 | <TabAtkins> | Most of us don't operate under your particularly strict criteria, so that's irrelevant. |
| 00:25 | <Hixie_> | TabAtkins: you know, it's incredibly frustrating and insulting when you just dismiss other people's concerns repeatedly. |
| 00:25 | <TabAtkins> | Hixie_: You know that I can say the exact same thing back, right? |
| 00:25 | <Hixie_> | "i disagree with you, so i'll ignore you" |
| 00:26 | <Hixie_> | i'm not ignoring you |
| 00:26 | <Hixie_> | i've been trying to understand your point of view for a few hours now |
| 00:26 | <TabAtkins> | "I disagree with you, so I'll just repeatedly ask for use-cases and not accept anything you say." |
| 00:26 | <Hixie_> | while you keep saying you're giving up |
| 00:26 | <TabAtkins> | ^_^ |
| 00:26 | <Hixie_> | there's a qualitiative difference here |
| 00:26 | <Hixie_> | qualitative even |
| 00:26 | <TabAtkins> | If your definition of use-case explicitly excludes the kinds of things we're trying to do, there's not really a difference. |
| 00:27 | <TabAtkins> | (Which in many of these cases is "make author's lives easier by having better consistency in the platform and across independent libraries".) |
| 00:27 | <TabAtkins> | I mean, I've explained it. You didn't accept the explanation. I can't do a lot about that. |
| 00:28 | <TabAtkins> | I've already learned from talking to you for years that you have certain opinions about programming languages that are very different from mine, and different from those of many involved in JS and DOM standards. |
| 00:28 | <TabAtkins> | And they aren't the kind of differences that can generally be bridged just by explaining. You've learned things differently, and prefer different patterns. Shrug. |
| 00:29 | <zewt> | Hixie_: ... he's not dismissing anything, I typed the exact same thing he did (and ^U'd it since he said it first) |
| 00:30 | <zewt> | you're saying "if this is your criteria, then this doesn't make sense"; that's *not* his criteria, so that's irrelevant |
| 00:35 | <Hixie_> | zewt: i'm specifically referring to e.g. "we've just ignored you and worked around it", "it's not worth explaining to you", "I'm sorry you don't understand", "You just don't accept it. Shrug.", "I refuse to explain the concept of private state to you", "It's... not worth explaining a basic computer science concept to you", "That argument is decided. The people who say "never" are wrong, and nobody listens to them", "Your argument is invalid", etc |
| 00:37 | <Hixie_> | on another note, i'm still curious about the use case for "frozen". nothing in the platform acts like that, does it? what is it for? |
| 00:38 | <TabAtkins> | Hixie_: Several of those are seriously basic concepts which I shouldn't have to explain. Wikipedia is an easier reference than asking me. |
| 00:39 | <TabAtkins> | I am indeed sometimes sorry you don't understand. Like I just said, you prefer different patterns, and sometimes seem to have a hard time accepting that patterns you personally dislike are still liked by others, and so things using those patterns are okay to develop. |
| 00:39 | <TabAtkins> | The "Your argument is invalid." was a joke, referencing the meme. |
| 00:41 | <zewt> | i've thought about using "frozen" in the past; if I remember correctly, it would only throw in strict mode? or was that something else similar to it |
| 00:41 | <TabAtkins> | zewt: Yeah. |
| 00:41 | <TabAtkins> | It no-ops in sloppy mode. |
| 00:42 | <zewt> | (having properties just silently not change seems horribly confusing, so I didn't use it, and strict is useless until every browser supports it) |
| 00:42 | <TabAtkins> | zewt: Every modern browser does, no? |
| 00:42 | <zewt> | don't know--they didn't when I looked at that feature |
| 00:43 | <TabAtkins> | Pretty sure they do now, but I can't name when each got it. |
| 00:44 | <zewt> | (i also don't recall why I wanted it, or if I was just looking at it randomly) |
| 00:52 | <zewt> | i know I've wanted things like that in Python even recently, eg. where I return an array or a dictionary by reference and I want to make sure the caller doesn't accidentally modify it |
| 00:53 | <zewt> | (usually I end up making a deep copy instead, which is usually okay) |
| 00:54 | <TabAtkins> | Yeah, but it's silly to have to defensively eat the cost of a copy, when most of the time the caller won't even modify anything. Forcing the cost on the rare modifying cases is better. |
| 00:56 | <zewt> | well, as long as the cost is only when you try to modify something frozen, not on everything |
| 00:58 | <TabAtkins> | Yeah. |
| 00:59 | <TabAtkins> | Otherwise, you're looking at a functional data structure. Those are pretty interesting, but definitely harder to use. ^_^ |
| 00:59 | <zewt> | okay, this "es6 template string" thing that somebody randomly linked on the list definitely looks like pointless language bloat |
| 01:00 | <TabAtkins> | It's "how do I embed DSLs in JS". |
| 01:00 | <TabAtkins> | The answer is "it's complicated", apparently. |
| 01:01 | <zewt> | python's formatting model seems simpler and better |
| 01:01 | <TabAtkins> | You can process things more powerfully than Python's simply str.format |
| 01:02 | <zewt> | don't know about str.format, i mean the '%(x)s' % {'x': foo} thing |
| 01:02 | <zewt> | maybe format is the same thing |
| 01:03 | <zewt> | that avoids putting code in the string itself |
| 01:03 | <TabAtkins> | Yeah, .format is the same thing. |
| 01:03 | <TabAtkins> | Preferred now. |
| 01:03 | <zewt> | not by me, heh |
| 01:04 | <TabAtkins> | Has the nice benefit that you can pass it to map()! |
| 01:04 | <zewt> | i've never seen map() used in python except by people who haven't learned comprehensions |
| 01:04 | <TabAtkins> | Hah, I've used both. |
| 01:04 | <zewt> | in my experience map is 100% always harder to read |
| 01:07 | <zewt> | (and I use traditional format strings wherever I can, unless the format string is from an external source or too complex; they're just much more concise and easier to author) |
| 01:08 | <zewt> | no comparison between '%ix%i' % (x, y) and '%(x)ix%(y)i' % { 'x': x, 'y': y } |
| 01:08 | <zewt> | which is about the level of most inline formatting |
| 01:13 | <Hixie_> | so what _is_ the point of freezing? |
| 01:14 | <zewt> | well, the Python case I had applies to any language (making sure that people don't modify things accidentally, without having to make a deep copy all the time) |
| 01:15 | <zewt> | whether that's a practical issue in JS code I couldn't say, but I've wanted it in other places |
| 01:16 | <Hixie_> | can't you just do that with getters and setters? |
| 01:16 | <TabAtkins> | zewt: Using .format, it's just "{0}x{1}".format(x,y). You can use named placeholders instead, passing them as named arguments. You can also do formatting, but I haven't needed to, so whatever. |
| 01:16 | <TabAtkins> | Hixie_: No, because those can be overridden. |
| 01:16 | <zewt> | TabAtkins: i don't want to learn a completely different placeholder system; I've been using C-style ones for two decades and I don't have to think about it |
| 01:17 | <zewt> | TabAtkins: well, in the "making sure people don't write to this by accident" case, it doesn't matter if there's a back door, it's just to prevent accidents |
| 01:17 | <TabAtkins> | zewt: Sure. I haven't ever had to, so I don't care, and I appreciate the visual separation that the {} provides. |
| 01:17 | <TabAtkins> | zewt: Sure, but there are some use-cases where you really dont' want a back door, like running untrusted code (what Caja does). |
| 01:18 | <zewt> | (most of the cases of trying to protect code from other code in the same context seems unconvincing to me, but I won't claim I've looked at it thoroughly) |
| 01:18 | <Hixie_> | TabAtkins: well sure but if people want to screw around... |
| 01:18 | <TabAtkins> | zewt: Many are ill-founded, granted, but there are reasonable cases for sandboxing code. |
| 01:19 | <zewt> | i know we're not nearly there yet (and may never be, but who knows), but kicking untrusted code into a worker (a completely different context) seems like such a better direction |
| 01:22 | <TabAtkins> | Yeah, I'm not familiar enough with the stuff that Caja is used for to know how well that would work. |
| 01:23 | <Hixie_> | the caja stuff seems like such a case of wack-a-mole |
| 01:23 | <Hixie_> | it's basically retrofitting a security model into something that was never designed with it in mind |
| 01:26 | <TabAtkins> | Welcome to the web. |
| 01:27 | <Jasper> | I am not reading that scrollback. |
| 01:27 | <Hixie_> | which part? |
| 01:27 | <Hixie_> | TabAtkins: which part? |
| 01:27 | <TabAtkins> | Hixie_: Which part of what? |
| 01:28 | <Hixie_> | TabAtkins: if you mean, the web is like that too, then yeah, that's why i don't think doing caja in it is a good idea :-) |
| 01:28 | <TabAtkins> | Yeah, I just meant that *everything* on the web is retrofitting onto a system that wasn't designed for whatever it is you're doing. ^_^ |
| 01:29 | <Hixie_> | well yeah, but security is a case where if you get it slightly wrong, you've lost |
| 01:29 | <Hixie_> | unlike most things, where if you get it slightly wrong, you've still mostly won |
| 02:38 | <TabAtkins> | Another theoretical benefit of freezing is that it allows harder optimizations - you're guaranteed that the shape of the object won't change after the freeze. |
| 02:39 | <TabAtkins> | That's "theoretical" because, afaik, V8 still actually uses the slow path for frozen objects, so freezing gives you *worse* performance. That's just because of them not going to the effort to fix it yet, not anything intrinsic; there's a bug against them to actually optimize frozen objects. |
| 02:46 | <Hixie_> | TabAtkins: are host objects "frozen" in any sense? |
| 02:47 | <TabAtkins> | That depends on the object, I guess. |
| 02:47 | <TabAtkins> | You can usually put expandos on them, so no. |
| 02:47 | <Hixie_> | so freezing isn't for "explaining the platform"? |
| 03:10 | <TabAtkins> | I dunno. I forget exactly what freezing disallows, so it might be needed to explain some things. |
| 03:13 | <cabanier> | TabAtkins: it seems that freezing just makes things harder and slower for the v8 compiler |
| 03:18 | <TabAtkins> | cabanier: That's for now. It *should* make several optimizations easier and more certain, with no need to reserve the ability to de-optimize. |
| 03:22 | <cabanier> | TabAtkins: not sure why that would be. It might make it easier to write code that can be optimized well |
| 03:22 | <cabanier> | TabAtkins: from what I understand from v8, it generates code as if the classes are frozen |
| 03:31 | <TabAtkins> | Yeah, but it has to de-optimize when you do change things. |
| 03:32 | <cabanier> | TabAtkins: it depends, right? In general, it just assumes a new frozen class and generates assembly for that |
| 03:32 | <cabanier> | Hixie_: I have to agree with Tab about "dismissing other people's concerns" |
| 03:33 | <cabanier> | Hixie_: we've going round and round about how the current path syntax and the stroking algorithm don't work |
| 03:33 | <cabanier> | Hixie_: but it seems our concerns are constantly dismissed (with no proof) |
| 03:43 | <Hixie_> | cabanier: i thought you'd sent mail that was still in the queue, is it not? |
| 03:43 | <cabanier> | Hixie_: queue? |
| 03:43 | <Hixie_> | have you sent a mail i haven't replied to yet? |
| 03:44 | <cabanier> | Hixie_: yes although it seems like we're stuck in a loop |
| 03:45 | <Hixie_> | i am not aware of any loop |
| 03:45 | <cabanier> | Hixie_: for instance, I never got a reply on dashing |
| 03:45 | <Hixie_> | there's e-mail that i still have to reply to, sure |
| 03:45 | <Hixie_> | there's currently 492 e-mails in my queue and 184 e-mails |
| 03:45 | <Hixie_> | er, 184 bugs |
| 03:45 | <cabanier> | :-) |
| 03:45 | <Hixie_> | that's not a loop and it's definitely not dismissing concerns, it's just being slow |
| 03:45 | <Hixie_> | i'll happily cop to that |
| 03:46 | <Hixie_> | well, not happily |
| 03:46 | <Hixie_> | but without reservation |
| 03:47 | <Hixie_> | i'm about 2 months lagged right now |
| 03:47 | <Hixie_> | on e-mail i haven't intentionally delayed |
| 03:47 | <Hixie_> | and about 30 months lagged on e-mail that's blocked on other things |
| 03:47 | <cabanier> | Hixie_: yeah, I can believe that you're overloaded :-) |
| 03:47 | <Hixie_> | anyway, gotta ga, tv :-) |
| 03:47 | <cabanier> | Hixie_: for me, it's hard to make progress |
| 03:48 | <cabanier> | Hixie_: since implementors think the issues aren't resolved |
| 03:48 | <cabanier> | Hixie_: enjoy! |
| 04:53 | <Hixie_> | cabanier: i replied to those e-mails for you |
| 04:54 | <cabanier> | Hixie_: thanks! |
| 05:16 | <Hixie_> | cabanier: also replied to https://www.w3.org/Bugs/Public/show_bug.cgi?id=23386 |
| 05:23 | <cabanier> | Hixie_: thanks! replied |
| 07:17 | <Ms2ger> | Hixie_, usually when people start with "This is a suggestion to fix major problems relating to developing a more modern application as related to browser history issues.", I give up :) |
| 07:52 | <annevk> | Hixie_: FWIW, I don't think everyone in TC39 is convinced Object.freeze() at all should exist. Mark Miller got them through in some compromise decision... Same goes for "use strict" as far as I can tell. |
| 07:52 | <annevk> | Hixie_: it's not quite as like-minded as TabAtkins makes it out to be |
| 07:54 | <annevk> | Object.freeze() in particular is quite badly designed as it doesn't actually "freeze" objects. It just freezes some of its properties, but not e.g. internal state. |
| 08:20 | <annevk> | jsbell: not throwing for non-new makes subclassing harder to support |
| 08:21 | <annevk> | jsbell: once IDL is updated to support ES6-style classes that'll be clearer |
| 08:28 | <zcorpan> | "Having moved into open standards, DRM is easy to turn off later" http://www.w3.org/2013/04/drm/debate_outline.html |
| 08:30 | Ms2ger | blinks |
| 08:42 | <annevk> | o_O |
| 09:12 | <nicoo> | Bullshit overflow. |
| 09:16 | <MikeSmith> | in Gecko IDLs what does [Throws] mean? |
| 09:16 | <annevk> | MikeSmith: it means it can throw an exception |
| 09:16 | <annevk> | Still need to talk about bz about that. Might be good for IDL too... |
| 09:16 | <MikeSmith> | ok |
| 09:17 | Ms2ger | is skeptical about specs getting it right |
| 09:17 | <MikeSmith> | and [GetterThrows] means it can throw on getting? |
| 09:22 | <Ms2ger> | Yep |
| 09:24 | <MikeSmith> | I see [Constant] in there too, which seems useful |
| 09:24 | <MikeSmith> | sorta |
| 09:24 | <annevk> | Ms2ger: pretty much everything can throw in theory I guess |
| 09:24 | <annevk> | Ms2ger: maybe Gecko could be smarter about it... |
| 09:24 | <annevk> | Ms2ger: e.g. if something has DOMString as argument, it can throw... |
| 09:25 | <Ms2ger> | Well, the Throws bit doesn't include webidl exceptions |
| 09:38 | <annevk> | Ms2ger: ah, see, this is why I should talk to bz |
| 10:01 | <smaug____> | MikeSmith: yeah, [Constant] is useful, though often it should be [SameObject] I guess |
| 10:01 | <smaug____> | [Pure] is more implementation detail, probably not anything for specs |
| 10:03 | <MikeSmith> | what is [Pure]? |
| 10:04 | <smaug____> | the getter returns the same value as long as any setters or methods (which might change the underlying data) haven't been called |
| 10:05 | <MikeSmith> | ah |
| 10:07 | <smaug____> | I wonder if document.images should be [SameObject] |
| 10:07 | <smaug____> | and other similar .foos on document |
| 10:31 | <jgraham> | zcorpan: You don't happen to remember what features of range-request.php are actually required by the preload tests, so you? |
| 10:31 | <jgraham> | *do |
| 10:32 | <jgraham> | I am wondering if it is possible to just bake-in support for range requests and then use the pipe features of wptserve to recreate the whole required featureset |
| 10:32 | <jgraham> | (the pipe features would give you support for trickling the requests) |
| 10:33 | <jgraham> | (the thing that seems most problematic is support for caching) |
| 10:54 | <zcorpan> | jgraham: i remember that there are tests that check that e.g. off is fetched by first making a 0-inf range request, then a request at the end, then a request at the beginning again |
| 10:56 | <zcorpan> | jgraham: but i don't remember what the whole required feature set is. |
| 10:58 | <zcorpan> | jgraham: but i guess stuff was implemented in range-request on a it's-necessary basis rather than it's-possible basis |
| 11:03 | <jgraham> | Yeah, I could just do a straight port of course |
| 11:03 | <MikeSmith> | dumb question: in WebIDL is there a way to define a property as a direct property of an object rather than a property of its prototype? |
| 11:04 | <jgraham> | MikeSmith: I don't remember such a feature (but might be wrong). What's the use case? |
| 11:08 | <MikeSmith> | jgraham: No use case. What I'm wondering about very specifically is, in implementations of the Notification API, the "permission" property and "requestPermission" property/function are direct properties of the Notification object, not properties of its prototype. |
| 11:08 | <MikeSmith> | so first I wonder why that is |
| 11:08 | <MikeSmith> | and second I wonder if there's some reason why the implementations do that, how it could even be expressed in WebIDL |
| 11:09 | <jgraham> | Does "implementations" in this case mean blink? |
| 11:09 | <MikeSmith> | no gecko as well |
| 11:09 | <jgraham> | Hmm |
| 11:09 | <jgraham> | I thought Gecko did the prototype thing for IDL properties |
| 11:09 | MikeSmith | doublechecks |
| 11:10 | <MikeSmith> | Notification.hasOwnProperty("permission") returns true in gecko too |
| 11:12 | <MikeSmith> | while, e.g., Notification.hasOwnProperty("icon") returns false |
| 11:13 | <MikeSmith> | so some members of the IDL in the spec become properties of the prototype and others ("permission" and "requestPermission") become direct properties of the object |
| 11:16 | <jgraham> | They are properties of the interface object afaict |
| 11:16 | <jgraham> | Because they are declared as "static" |
| 11:16 | <jgraham> | http://dev.w3.org/2006/webapi/WebIDL/#es-operations |
| 11:16 | <jgraham> | "If the operation is static, then the property exists on the interface object." |
| 11:18 | <MikeSmith> | ah |
| 11:19 | <MikeSmith> | So then I think maybe idlharness.js might not yet have support for recognizing them as such |
| 11:20 | <MikeSmith> | it seems to be expecting them in the prototype |
| 11:20 | <jgraham> | Since idlharness.js hasn't been updated in several years, that seems quite likely |
| 11:20 | <jgraham> | But you didn't have anything else to do today, right? ;) |
| 11:21 | <MikeSmith> | haha |
| 11:21 | <MikeSmith> | the other thing this makes me wonder about then is, why is the Notification spec defining them as static |
| 11:22 | <MikeSmith> | no other specs seem to have IDLs with similar static attributes |
| 11:22 | <MikeSmith> | and until recently I think V8 didn't even support them |
| 11:24 | <MikeSmith> | hmm actually I guess I can understand why in this specific case |
| 11:24 | <MikeSmith> | given the way that the perms mechanism works in Notifications |
| 11:24 | <MikeSmith> | I guess the difference is that no other specs are using that kind of mechanism |
| 11:26 | jgraham | wonders how multiple byte ranges are actually supposed to work e.g. what does bytes=1-10,20-30 return? Why does bytes=1-15,10-20 return the same as bytes=1-20? |
| 11:33 | <jgraham> | Oh, maybe you just use a funky response type |
| 11:33 | <jgraham> | the spec could make that clearer |
| 12:34 | <annevk> | MikeSmith: URL.createObjectURL(...) works the same way |
| 12:35 | <MikeSmith> | annevk: ah OK |
| 12:35 | <MikeSmith> | so fwiw I'm hacking static attribute/operation support into idlharness.js now |
| 12:36 | MikeSmith | looks at URL IDL |
| 12:36 | <annevk> | MikeSmith: it's defined in the File API, somewhat confusingly |
| 12:37 | <MikeSmith> | ok |
| 12:37 | MikeSmith | looks there |
| 12:37 | <zcorpan> | the "don't nest dfn elements" rule helped me find a mistake (i used dfn when i meant var) |
| 12:37 | <MikeSmith> | yay |
| 14:07 | <zcorpan> | Domenic_: nice presentation |
| 14:08 | <zcorpan> | MikeSmith: i added another static method today |
| 14:08 | <MikeSmith> | zcorpan: CSSOM? |
| 14:08 | <zcorpan> | yeah |
| 14:10 | <MikeSmith> | well I got the idlharness support working locally |
| 14:11 | <MikeSmith> | so I'll submit a patch for it |
| 16:39 | <Hixie_> | annevk-cloud: huh, ok. thanks for the update. |
| 16:49 | <bholley> | Hixie_: hey |
| 16:49 | <bholley> | Hixie_: now a good time? |
| 17:17 | <dglazkov> | good morning, Whatwg! |
| 17:29 | <Hixie_> | bholley: hey |
| 17:29 | <Hixie_> | bholley: sure! |
| 17:56 | <barnabywalters> | where is the best place to ask about potential implications of HTML DRM? |
| 17:57 | <TabAtkins> | Depends on what you want. HTMLWG is good if you want frustrating non-answers to any concerns. Here is okay if you want people venting their spleen. |
| 17:57 | <jgraham> | It depends what you mean "implications" |
| 17:59 | <barnabywalters> | okay, so the question is: will DRM-protected HTML mean browser extensions can no longer make changes to web UIs, i.e. access+modify the DOM? |
| 17:59 | <TabAtkins> | The current DRM efforts are purely about <video>. |
| 18:00 | <TabAtkins> | But if we ever do have DRM for HTML itself, then yes, that's almost certainly what it means, or at least it will be severely restricted. |
| 18:00 | <barnabywalters> | okay, so all the “DRM will kill view-source” stuff is inaccurate? |
| 18:00 | <TabAtkins> | No, eventual DRM will. The only spec so far (EME) won't, though it's still horrible. |
| 18:02 | <barnabywalters> | boooo :( |
| 18:02 | <barnabywalters> | okay, thanks |
| 18:03 | <barnabywalters> | Can I cite these logs as a source for “DRM will prevent users from being able to take control of their web UIs”, or is there a better source? |
| 18:05 | <jgraham> | You could, but that isn't what anyone said, really |
| 18:05 | <jgraham> | DRM *for HTML* would do that |
| 18:05 | <jgraham> | So far there is no concrete proposal for that |
| 18:05 | <barnabywalters> | ah, sorry — noted |
| 18:05 | <jgraham> | Although Jeffe Jaffe at W3C has hinted it is something he would like |
| 18:06 | <jgraham> | *Jeff |
| 18:09 | <jgraham> | (I think. Although I can't find the source for thinking that right now) |
| 18:11 | <jgraham> | (hm, it is possible that I was thinking of someone else's characterisation of his position. So probably best ignore me) |
| 18:15 | Ms2ger | submits a /. article about jgraham's claim |
| 18:17 | <jgraham> | Ms2ger: It's OK, no one has read /. for about 10 years |
| 18:18 | <jgraham> | Ms2ger: More usefully, do Mozilla have anything like .headers files that can match more than one file? |
| 18:19 | <Ms2ger> | Not that I know of |
| 18:19 | <jgraham> | e.g. if I want to add some header to all html files in a directory |
| 18:19 | <jgraham> | Hmm |
| 18:19 | <jgraham> | That would seriously improve some of these ported-from-apache cases |
| 18:22 | <Ms2ger> | Seems like something useful to add |
| 18:22 | <Ms2ger> | Maybe |
| 18:23 | <Ms2ger> | I dunno if everything-in-this-dir would be the right granularity |
| 18:23 | <jgraham> | No, well apache has a whole load of ad-hoc microsyntaxes for this stuff |
| 18:23 | <jgraham> | <FilesMatch "\.(vtt|json)$"> for example |
| 18:34 | <niloy> | can someone tell me if transition events are suppose to bubble up? |
| 18:36 | <TabAtkins> | niloy: http://dev.w3.org/csswg/css-transitions/#transitionend |
| 18:37 | <niloy> | so the problem is, I have 'transitionend' on a parent element which I am interesed in, but a third party component is also using transition inside it |
| 18:37 | <niloy> | its bubbling up and messing up my code |
| 18:38 | <niloy> | the third party component is simply having transition effects |
| 18:38 | <niloy> | how should I handle this case? |
| 18:39 | <TabAtkins> | You've gotta figure out some way to distinguish the component's events from the ones you're interested in. |
| 18:40 | <niloy> | TabAtkins, okay... thanks, I would assume there are valid use cases for having the event bubble up |
| 18:41 | <TabAtkins> | Yeah, it's so you can put a listener on a parent element and listen to events from a bunch of children, rather than having to register individual listeners on everything. |
| 18:42 | <niloy> | but that can be said about 'load' & 'focus' too |
| 18:43 | <TabAtkins> | Sure. A lot of events bubble. Some don't. The reasoning is often historical. |
| 18:44 | <niloy> | okay! |
| 18:48 | <bholley> | Hixie_: back again |
| 18:48 | <Hixie_> | hey! |
| 18:48 | <bholley> | Hixie_: \o/ |
| 18:49 | <bholley> | oh happy evening |
| 18:49 | <bholley> | Hixie_: so, shall we jump in? |
| 18:49 | <bholley> | Hixie_: do you prefer PM or here? |
| 19:02 | bholley | pokes Hixie_ |
| 19:11 | <Hixie_> | bholley: here's good |
| 19:11 | <Hixie_> | bholley: sorry, got distracted by some bug |
| 19:11 | <bholley> | Hixie_: cool |
| 19:11 | <bholley> | Hixie_: so |
| 19:11 | <Hixie_> | and for some reason had my volume low so didn't hear the beeps |
| 19:11 | <bholley> | Hixie_: per my last email, I think we should just do null prototypes for cross-origin objects |
| 19:11 | <Hixie_> | that makes things simpler, certainly |
| 19:11 | <Hixie_> | though doesn't that mean we need to move everything to the obejcts? |
| 19:11 | <bholley> | Hixie_: as in, making things |own|? |
| 19:12 | <bholley> | Hixie_: that's a good question. We wouldn't need to in Gecko, but I don't know how to spec that magic |
| 19:12 | <Hixie_> | as in, if the prototypes aren't there, then the methods better be somewhere that exists |
| 19:12 | <bholley> | Hixie_: I wonder how Blink deals with this |
| 19:12 | bholley | tries to remember if Blink returns null or throws |
| 19:12 | bholley | looks up the bug |
| 19:13 | <bholley> | ok, yeah. Webkit/Blink throw |
| 19:13 | <Hixie_> | well either way, if you can't look up the prototype... |
| 19:13 | <Hixie_> | i guess the automatic lookup could be exempt |
| 19:13 | <bholley> | Hixie_: but yeah, anyway. Making them all |own| should be fine, I'd think |
| 19:13 | <Hixie_> | (but then we'd still need to talk about the prototype being unique per origin) |
| 19:13 | <bholley> | Hixie_: I'm happy to experiment with this in Gecko if you like |
| 19:14 | <Hixie_> | making them |own| means putting them on the object directly? |
| 19:14 | <bholley> | Hixie_: (making them own) |
| 19:14 | <bholley> | Hixie_: right |
| 19:14 | <Hixie_> | lgtm |
| 19:14 | <bholley> | Hixie_: which isn't visible, given that enumeration is forbidden |
| 19:14 | <Hixie_> | instanceof Location would stop working too, i guess |
| 19:14 | <bholley> | Hixie_: except for Object.getOwnPropertyDescriptor |
| 19:14 | <Hixie_> | if that even works now |
| 19:14 | <bholley> | Hixie_: no, it would work |
| 19:14 | <bholley> | Hixie_: per heycam's webIDL trick |
| 19:14 | <Hixie_> | oh right, webidl does magic for instanceof |
| 19:14 | <Hixie_> | forgot about that |
| 19:14 | <bholley> | Hixie_: it's not about the prototype, it's the branding |
| 19:14 | <Hixie_> | k |
| 19:14 | <bholley> | Hixie_: ok, cool. Sorted |
| 19:14 | bholley | adds that to his list |
| 19:15 | <Hixie_> | and that affects Location and Window, right? |
| 19:15 | <bholley> | Hixie_: correct |
| 19:15 | <Hixie_> | ok |
| 19:15 | <bholley> | Hixie_: assuming we've since removed Document from the list of XO-available properties |
| 19:15 | <Hixie_> | yeah, that's on my list |
| 19:15 | <Hixie_> | making contentDocument and other ways of getting Documents throw |
| 19:15 | <bholley> | Hixie_: I think the Gecko patch I landed has made it to release |
| 19:15 | bholley | checks |
| 19:16 | <bholley> | Hixie_: yes. So proven to be web-compatible |
| 19:16 | <bholley> | Mozilla23 |
| 19:16 | <bholley> | Hixie_: so, moving onto Location |
| 19:18 | <bholley> | Hixie_: My proposal has been for both (a) security checks against the BC-principal at the time of invoke/get/set, and (b) security checks against the Document principal at the time of property lookup |
| 19:18 | <Hixie_> | let's be very explicit when we talk about origins, rather than using terms like "BC-principal", because that got us into trouble last time we discussed this |
| 19:19 | <bholley> | Hixie_: well, my beef is that the expansion of "BC-principal" is super long |
| 19:19 | <Hixie_> | well sure |
| 19:19 | <Hixie_> | just copy-and-paste :-) |
| 19:19 | <Hixie_> | alternatively, we can define them once |
| 19:20 | <Hixie_> | and then refer to them by letter or whatever |
| 19:20 | <bholley> | Hixie_: "The principal of the document whose Window is the target of the WindowProxy of the same browsing context containing the Window whose Document is associated with the Location object we're discussing" |
| 19:20 | <Hixie_> | by "principal" you mean "origin"? |
| 19:20 | <bholley> | Hixie_: yes, sorry |
| 19:21 | <bholley> | Hixie_: that is my definition of BC origin |
| 19:21 | <bholley> | Hixie_: which is a mutable value |
| 19:21 | <Hixie_> | so the origin of the active document of the browsing context of the Window of the Document of the Location object being accessed? |
| 19:22 | <Hixie_> | what teh spec calls the "relevant Document"? http://www.whatwg.org/specs/web-apps/current-work/#location |
| 19:22 | <bholley> | Hixie_: correct |
| 19:22 | <bholley> | Hixie_: great |
| 19:22 | <Hixie_> | ok |
| 19:22 | <bholley> | Hixie_: "relevant document's origin" |
| 19:23 | <bholley> | Hixie_: that's a fine term to use |
| 19:23 | <bholley> | Hixie_: contrasted with the "owner document's origin" |
| 19:23 | <Hixie_> | owner document here being the one Location is associated with |
| 19:23 | bholley | isn't sure if something else should be used in lieu of the word "owner" |
| 19:23 | <bholley> | Hixie_: ok |
| 19:23 | <Hixie_> | ("Each Document object in a browsing context's session history is associated with a unique instance of a Location object") |
| 19:23 | <bholley> | "associated document's origin" and "relevant document's origin" |
| 19:23 | <Hixie_> | ok |
| 19:23 | <bholley> | those terms good? |
| 19:23 | <Hixie_> | "good" is relative, but they'll do :-) |
| 19:24 | <bholley> | \o/ |
| 19:24 | <bholley> | so |
| 19:24 | <bholley> | reframing |
| 19:24 | <bholley> | My proposal has been for both (a) security checks against the relevant document origin at the time of invoke/get/set, and (b) security checks against the associated document origin at the time of property lookup |
| 19:24 | <bholley> | Hixie_: IIRC, we at some point agreed on (a), but then the fog may have reappeared |
| 19:26 | <Hixie_> | and we're comparing this origin to what, the script's incumbent origin? |
| 19:26 | <Hixie_> | incumbent script's origin, rather |
| 19:26 | bholley | pauses to make sure he gets this right |
| 19:27 | <bholley> | yes |
| 19:27 | <Hixie_> | please hold, verifing... |
| 19:28 | bholley | stirs his split-pea soup |
| 19:29 | <Hixie_> | hmm |
| 19:29 | <Hixie_> | i disagree with (b), i think |
| 19:29 | <bholley> | Hixie_: do you agree with (a)? |
| 19:29 | <Hixie_> | i think so |
| 19:30 | <bholley> | Hixie_: ok |
| 19:30 | <bholley> | so |
| 19:30 | <bholley> | b |
| 19:30 | <Hixie_> | i think (a) is what i wrote at https://www.w3.org/Bugs/Public/show_bug.cgi?id=20701#c32 in the four items in the dashed bulleted list |
| 19:30 | <Hixie_> | (b) i disagree with because parent.siblingIframeInDifferentOrigin.location.replace(newurl) should work |
| 19:31 | <Hixie_> | iirc |
| 19:31 | <Hixie_> | but i think this gets to the first paragraph prefixed with # in that same comment |
| 19:31 | <bholley> | Hixie_: right - my beef with c32, which is what started this whole discussion, is that you switched _all_ security checks to use the "relevant document origin", when I believe we should only move half of them |
| 19:31 | <Hixie_> | if we have that paragraph, we don't need (b) because you can't see any changes the owner document's origin does |
| 19:32 | <Hixie_> | the #-paragraphs don't use the relevant origin |
| 19:32 | <Hixie_> | they use the owner origin |
| 19:32 | <bholley> | Hixie_: in c32? |
| 19:32 | <Hixie_> | yeah |
| 19:32 | <bholley> | "that's not the same as Location object's associated Document's |
| 19:32 | <bholley> | browsing context's active document's effective script origin." |
| 19:33 | <bholley> | Hixie_: that sounds like "relevant document origin" to me |
| 19:33 | <bholley> | Hixie_: oh, I misunderstood "#' |
| 19:34 | <Hixie_> | basically your (a) is trying to deal with the same attack vector as my 4 "-" paragraphs, and your (b) is trying to deal with the same attack vector s my 2 "#" paragraphs |
| 19:34 | <Hixie_> | i think we agree on (a) entirely at this point |
| 19:34 | <bholley> | Hixie_: I believe so, yes |
| 19:34 | <Hixie_> | and (b) is where we disagree |
| 19:34 | <bholley> | roger |
| 19:34 | <bholley> | let me mull this for a second |
| 19:34 | <Hixie_> | and when i say disagree, i mean you have a proposal, and i don't know shit |
| 19:34 | <Hixie_> | because this stuff confuses me a lot :-) |
| 19:38 | <bholley> | well, Hixie has a proposal too |
| 19:39 | <bholley> | which I believe does indeed solve the same attack vector |
| 19:39 | <bholley> | since they're "different objects" |
| 19:39 | <bholley> | though |
| 19:39 | <Hixie_> | i'm happy, eager even, to consider other ways to solve it |
| 19:40 | <Hixie_> | i don't think your (b) really works though, because it prevents parent.siblingIframeInDifferentOrigin.location.replace(newurl) which i'm pretty sure (off the top of my head) should work |
| 19:40 | <Hixie_> | i really should develop some console that makes cross-origin testing easier |
| 19:40 | <bholley> | Hixie_: why would it prevent replace? replace is allowed cross-origin |
| 19:41 | <bholley> | Hixie_: oh, sorry. I guess I'm baking in some assumptions here |
| 19:41 | <Hixie_> | heh |
| 19:41 | <bholley> | Hixie_: for the security checks I propose in (b), I'm proposing that the cross-origin-accessible properties remain accessible even if the security check fails |
| 19:42 | <Hixie_> | the attack i'm worried about is something like origin A does "self.location.replace.secret = document" and origin B tries to get to "thatOtherWindow.location.replace.secret" |
| 19:42 | <bholley> | Hixie_: well, per spec, each has a different version of |replace|, right? |
| 19:43 | <Hixie_> | well, i'm assuming that's not an assumption i should be making :-) |
| 19:43 | <Hixie_> | if we're good with the #-paragraphs (which are what the spec says now), then i think we don't have any need for anything extra to handle (b) |
| 19:43 | <Hixie_> | but do we want those paragraphs? |
| 19:43 | <Hixie_> | i do not know |
| 19:44 | <bholley> | Hixie_: well, those paragraphs aptly describe the Blink/WebKit architecture |
| 19:44 | <bholley> | Hixie_: and less-so Gecko's Xray architecture |
| 19:45 | <bholley> | Hixie_: I'm happy to keep the spec mostly the way it is, but I'd like to keep the door open spec-wise for Xrays |
| 19:45 | <bholley> | since we may do that in Servo too (remains to be seen) |
| 19:46 | <Hixie_> | well so long as there's no user-detectable difference, i am happy to open it as wide as a barn door can open |
| 19:46 | <Hixie_> | author-detectable, i should say |
| 19:46 | <Hixie_> | what would it mean to leave it open for Xrays? |
| 19:47 | <bholley> | Hixie_: basically, I'm fine with continuing to orient the security bits of the spec as they are, so long as we're willing to occasionally tweak things one way or another so that they're implementable for us without pulling an Opera ;-) |
| 19:47 | <Hixie_> | i certainly wish to do anything possible to ensure the continued existence of gecko |
| 19:47 | <Ms2ger> | Heh |
| 19:47 | <Ms2ger> | How about Servo? |
| 19:47 | <bholley> | Hixie_: and, ideally, implementable for someone else who wants to do the Xray thing with less complexity than Mozilla's baggage requires |
| 19:47 | <bholley> | (cough Servo) |
| 19:48 | <Hixie_> | Ms2ger: i just want multiple entirely independent browser implementations. the more the better. |
| 19:48 | <bholley> | amen |
| 19:48 | <Hixie_> | bholley: what would that mean in concrete spec terms? |
| 19:49 | <bholley> | Hixie_: so, in a nutshell - the spec describes a world in which we create a separate JS reflection of a given cross-origin object for each origin that observes it |
| 19:49 | <Hixie_> | sounds right |
| 19:49 | <bholley> | Hixie_: in this world, it doesn't really matter if each origin defines orthogonal sets of properties on the object, because they never interfere with each other |
| 19:50 | <Hixie_> | right, though to make it easier to implement, you don't want to allow that, right? |
| 19:51 | <bholley> | Hixie_: correct. With Xrays, all the origins look at the same object, but with a special set of glasses that filter out all the crap |
| 19:51 | <bholley> | Hixie_: which works well until we start allowing those origins to put their own junk on the object as well |
| 19:51 | <bholley> | Hixie_: we do, in fact, have the machinery to do that in Gecko, but I'd like to avoid exposing that to the web |
| 19:52 | <Hixie_> | yeah |
| 19:52 | <Hixie_> | sounds like what the spec says, right? |
| 19:52 | <Hixie_> | or does it need to be even tighter |
| 19:52 | <Hixie_> | these glasses apply to everything including function objects like location.replace, right |
| 19:52 | <bholley> | Hixie_: correct |
| 19:53 | <bholley> | Hixie_: so currently, I don't see what in the spec would prevent each origin from defining funny properties on a cross-origin Location object |
| 19:53 | <Hixie_> | and "These objects must have the prototype chain appropriate..." should be changed to say they're null prototypes? |
| 19:53 | <bholley> | Hixie_: right |
| 19:53 | <Hixie_> | yeah, i was coming to that conclusion too |
| 19:55 | <Hixie_> | ok let me try to write some text, one sec |
| 19:58 | <cabanier> | Hixie_: "dismissing other people's concerns" |
| 19:58 | <Hixie_> | bholley: ok what do you think of https://www.w3.org/Bugs/Public/show_bug.cgi?id=20701#c50 ? |
| 20:02 | <annevk> | bholley: so I was thinking... If ECMAScript were to define the multiple global story, it'd have to tackle some kind of abstract origin concept too, as realms could suddenly become connected or disconnected due to document.domain |
| 20:02 | <bholley> | Hixie_: reading |
| 20:03 | <annevk> | bholley: and if it does that, it'd have to define how objects referenced across globals were to behave once disconnected, which means we could argue for Gecko's arguably better design to be standardized |
| 20:04 | <bholley> | annevk: yeah. I think it's the right approach, but it's a royal PITA for Webkit/Blink to implement |
| 20:04 | <annevk> | prolly also Trident |
| 20:04 | <annevk> | I wonder what Allen's plan with respect to this is at the moment |
| 20:05 | <annevk> | Multiple globals is definitely on the table, but maybe it's not ES6 material |
| 20:05 | <Hixie_> | annevk: btw while you're here... what's the story with application/x-www-form-urlencoded? seems URL has some version of it, but not quite the same as HTML? |
| 20:05 | <annevk> | Hixie_: my idea was for it to move to URL |
| 20:05 | <annevk> | Hixie_: differences might be bugs |
| 20:06 | <annevk> | Hixie_: sorry :/ |
| 20:06 | <Hixie_> | wouldn't that lead to dependencies from URL to HTML? |
| 20:07 | <Hixie_> | e.g. for <isindex>? |
| 20:07 | <Hixie_> | and accept-charset and so on? |
| 20:08 | <annevk> | Hixie_: I figured those would just be parameters to the algorithm |
| 20:08 | <Hixie_> | oh so we'd split the algorithm in half? |
| 20:08 | <annevk> | Hixie_: e.g. part of the application/x-www-form-urlencoded format |
| 20:08 | <annevk> | s/e.g./as in/ |
| 20:11 | <bholley> | Hixie_: https://www.w3.org/Bugs/Public/show_bug.cgi?id=20701#c51 |
| 20:12 | <bholley> | Hixie_: the only big question there is whether we're willing to disallow property modifications on alien objects |
| 20:12 | <bholley> | Hixie_: if we are, I think the rest will work |
| 20:12 | <Hixie_> | i am. dunno if others are. :-) |
| 20:12 | <Hixie_> | abarth: ping |
| 20:12 | <bholley> | Hixie_: it'll involve some hackery on the Gecko end, but stuff I'm totally willing to do to settle the spec stuff on this |
| 20:13 | <Hixie_> | bholley: what do you mean by "not be able to define or modify", btw? Throw? No-op? Do whatever freezing does? |
| 20:14 | <Hixie_> | annevk: i dunno, it seems like it'd make the algorithms much harder to follow and i don't see the real gain to be had |
| 20:14 | <abarth> | Hixie_: hi |
| 20:14 | <bholley> | Hixie_: it's up for debate. We currently throw for the cross-origin objects themselves, and don't do any checks on the functions pulled off of them. If we made the functions alien objects, it's probably simplest to do it by Freezing them |
| 20:14 | <Hixie_> | abarth: https://www.w3.org/Bugs/Public/show_bug.cgi?id=20701#c50 and 51 and 52 |
| 20:15 | <bholley> | Hixie_: at which point it probably makes the most sense to cause Location and Window to implement frozen semantics |
| 20:15 | <bholley> | Hixie_: which we can probably do |
| 20:15 | <Hixie_> | bholley: on the alien versions? makes sense to me. |
| 20:15 | <Hixie_> | bholley: what exactly are freezing semantics? |
| 20:15 | <bholley> | Hixie_: I don't know - presumably they're defined in ES? |
| 20:15 | <annevk> | Hixie_: URL needs the serialization algorithm for URLQuery |
| 20:16 | <annevk> | Hixie_: XMLHttpRequest needs it for sending URLQuery to a server |
| 20:16 | <Hixie_> | annevk: hm, interesting |
| 20:16 | <Hixie_> | annevk: ok, will look more later. might just end up having two versions one for forms and one for the cleaner stuff. |
| 20:16 | <abarth> | Hixie_: I don't think we're going to implement that |
| 20:16 | <annevk> | Hixie_: for similar reasons I'm afraid I might end up defining multipart/form-data |
| 20:17 | <Hixie_> | annevk: larry said he's respeccing that; see the bug |
| 20:17 | <Hixie_> | annevk: send him feedback |
| 20:17 | <abarth> | Hixie_: that requires JS engine magic |
| 20:17 | <annevk> | Hixie_: yeah, I have some private email I need to go through |
| 20:17 | <Hixie_> | i have to go to lunch, any change abarth and bholley you can discuss this amongst yourselves while i forage? :-) |
| 20:17 | <annevk> | Hixie_: lets avoid multiple algorithms that are essentially the same though |
| 20:17 | <abarth> | bholley: hi |
| 20:17 | Ms2ger | finds it pretty funny that Servo has new Comment(), but not document.createComment() |
| 20:18 | <abarth> | bholley: I don't really understand the problem you're trying to solve |
| 20:18 | <abarth> | bholley: can you help me understand? |
| 20:18 | <bholley> | abarth, Hixie_: I actually have to eat dinner |
| 20:18 | <abarth> | ok |
| 20:18 | <bholley> | abarth: can I ping you back in a little bit? |
| 20:18 | <abarth> | sure |
| 20:18 | <bholley> | abarth: cool |
| 20:59 | <Hixie_> | bholley: (back) |
| 21:48 | <Hixie_> | cabanier: you say you're not proposing anything, but aren't you in fact proposing that the spec change? |
| 21:49 | <Hixie_> | or did i misunderstand the conversation? |
| 21:50 | <cabanier> | Hixie_: I want the spec to reflect reality |
| 21:50 | <Hixie_> | reality is there's one browser whose feature that nobody yet uses, no? |
| 21:50 | <Hixie_> | s/that// |
| 21:51 | <Hixie_> | i mean, i want the spec to reflect reality too, but generally there's two ways to do that. |
| 21:51 | <Hixie_> | and if we're not constrained by legacy content, we should pick the better solution. |
| 21:51 | <cabanier> | I think we're already constrained |
| 21:52 | <cabanier> | ie http://paperjs.org/reference/style/ |
| 21:52 | <Hixie_> | i don't see what about that page constrains us |
| 21:52 | <cabanier> | not sure how paper.js works under the hood but they must already rely |
| 21:53 | <cabanier> | on existing dashing behavior |
| 21:53 | <cabanier> | pdf.js is shipping too in firefox |
| 21:53 | <Hixie_> | paper.js alone wouldn't constrain us, it'd have to be some software built on paper.js that relies on a particular dashing behaviour |
| 21:53 | <cabanier> | well, yes :-) |
| 21:53 | <Hixie_> | firefox doesn't yet implement the spec's API, so it doesn't constrain us either as far as I can tell |
| 21:54 | <cabanier> | they use a prefixed API that's basically the same |
| 21:54 | <Hixie_> | the example on http://paperjs.org/reference/style/ really supports justin's proposal, i have to say |
| 21:54 | <cabanier> | yeah. it does look nicer |
| 21:55 | <cabanier> | but again, if we want to help authors that have existing content, we should follow what the graphics libraries do |
| 21:55 | <Hixie_> | if there's existing content, but is there? |
| 21:56 | <cabanier> | svg? |
| 21:56 | <cabanier> | flash? |
| 21:56 | <cabanier> | pdf? |
| 21:56 | <cabanier> | gdi? |
| 21:56 | <Hixie_> | neither of those are canvas. |
| 21:56 | <cabanier> | but people are porting their assets to canvas |
| 21:56 | <Hixie_> | and all of those could work with justin's proposal trivially |
| 21:56 | <cabanier> | nono, Justin's proposal is actually quite hard |
| 21:57 | <cabanier> | and wouldn't match existing SVG assets |
| 21:57 | <Hixie_> | because...? |
| 21:57 | <cabanier> | ? |
| 21:58 | <cabanier> | because it would render dashes differently |
| 21:58 | <Hixie_> | (i feel our conversations would go much quicker if when you made an assertion, you immediately explained it, rather than waiting for me to prompt you to tell me why you made it) |
| 21:58 | <Hixie_> | justin's proposal is to not stop the dashes, unless there's an annotation that says to reset the dash offset, yes? |
| 21:58 | <cabanier> | Justin's proposal rearranges dashes so they don't fall on joins or endcaps |
| 21:58 | <Hixie_> | so it would be trivial to port any path from svg to canvas, you'd just have to reset the dash offset when you do a moveTo or whichever |
| 21:59 | <Hixie_> | oh i just meant his simpler proposal |
| 21:59 | <Hixie_> | sure, his more elaborate one would need more in-depth changes. |
| 21:59 | <cabanier> | let me look that one up. |
| 22:00 | <cabanier> | Justin and I are saying the same thing |
| 22:02 | <Hixie_> | that's not how i interpreted his statements but ok, s/justin's proposal/the annotation proposal/ |
| 22:02 | <cabanier> | annotation proposal? |
| 22:03 | <Hixie_> | to not stop the dashes, unless there's an annotation that says to reset the dash offset |
| 22:03 | <cabanier> | that's my proposal. right? |
| 22:04 | <cabanier> | dashes are reset when you do a moveTo or when you start a new path |
| 22:04 | <cabanier> | (new path does a moveTo as well) |
| 22:06 | <Hixie_> | in this proposal, moveTo()s would not necessarily be so annotated |
| 22:06 | <bholley> | Hixie_, abarth - shall we talk? |
| 22:06 | <Hixie_> | cabanier: there'd be an API whereby you can change the moveTo() to reset or not reset. |
| 22:06 | <Hixie_> | bholley: sure |
| 22:06 | bholley | looks for abarth |
| 22:07 | <Hixie_> | cabanier: (the default ideally being not to reset) |
| 22:07 | <Hixie_> | cabanier: same for anything else that creates a new subpath. |
| 22:07 | <bholley> | Hixie_: bz pointed out that freezing won't work spec-wise on Window, given that named properties are dynamic and visible cross-origin |
| 22:07 | <Hixie_> | cabanier: you'd presumably also be able to reset anywhere else |
| 22:07 | <bholley> | Hixie_: so we could either approximate it, or say that the objects themselves are governed by security exceptions, and (optionally) freeze the methods pulled off of them |
| 22:07 | <Hixie_> | bholley: that's one reason i was asking what "freezing" meant |
| 22:07 | <cabanier> | I don't think anyone is asking for this behavior. |
| 22:07 | <cabanier> | it's super confusing |
| 22:08 | <Hixie_> | cabanier: ... |
| 22:08 | <Hixie_> | cabanier: i'm asking for the ability to not reset the offset. I'm trying to find a way to make you happy while still preserving the ability to do this. work with me here. |
| 22:08 | <cabanier> | ok :-) |
| 22:09 | <Hixie_> | bholley: i don't mind how we freeze it, though. |
| 22:09 | <cabanier> | I'm pretty sure that apple will object |
| 22:09 | <bholley> | Hixie_: what do you think about the Functions? |
| 22:09 | <bholley> | Hixie_: null prototypes? Frozen? |
| 22:09 | <Hixie_> | bholley: or even if it's different for Window/Location and Functions |
| 22:09 | <Hixie_> | bholley: both? |
| 22:09 | <cabanier> | they can't implement this since it would rely on measuring the length of the paths which is expensive |
| 22:09 | <bholley> | Hixie_: I'm ok with that. The null prototype is necessary to solve the general problem we've been having with prototypes |
| 22:09 | <Hixie_> | cabanier: you said that about everyone and then justin disagreed with you, so i'd much rather take their word for it than guess. |
| 22:10 | <bholley> | Hixie_: the freezing would just be for consistency |
| 22:10 | <Hixie_> | bholley: the freezing would be to allow UAs to not actually have unique objects per origin |
| 22:10 | <bholley> | Hixie_: right, that's a very fair point |
| 22:11 | <cabanier> | Justin was not disagreeing with me. He wants something in addition to align the dashes |
| 22:11 | <bholley> | Hixie_: thanks for thinking of it :-) |
| 22:11 | <Hixie_> | cabanier: in the e-mail he just sent, he said he "could easily be convinced otherwise" |
| 22:12 | <cabanier> | Hixie_: he sent another one |
| 22:12 | <bholley> | Hixie_: in Gecko, we've gotten away with just creating different function objects for each global, but that's not tenable spec-wise |
| 22:12 | <Hixie_> | afterwards? |
| 22:12 | <bholley> | Hixie_: so yeah, I'm for it :-) |
| 22:13 | <Hixie_> | bholley: ok. i think you and i are on the same page (finally! heh, sorry it took so long). but sounds like abarth isn't... |
| 22:13 | <bholley> | Hixie_: did you talk to him? |
| 22:13 | <Hixie_> | not since you did |
| 22:13 | <Hixie_> | i asked him to comment on the bug |
| 22:14 | <bholley> | ok. I don't _think_ it should require magic on their end |
| 22:14 | <Hixie_> | bholley: i'll rewrite the proposal we came up with in one place so it's easier to comment on |
| 22:14 | <bholley> | given what I understand about their engine |
| 22:14 | <bholley> | it may be that abarth misunderstood the proposal |
| 22:14 | <bholley> | or that I misunderstand the intricacies of their engine |
| 22:16 | <TabAtkins> | Regarding "Not covered by traditional media". |
| 22:16 | <TabAtkins> | Wut |
| 22:16 | <cabanier> | Hixie_: I think the default should be that every moveTo restarts the dash pattern. It's not unreasonable to have a flag that doesn't do so, but I have to think about that |
| 22:17 | <Hixie_> | cabanier: again... why? why do you think that should be the default? just because it's the default in other systems? |
| 22:17 | <TabAtkins> | Since that matches <path> behavior (I think), that sounds reasonable to me. |
| 22:17 | <cabanier> | Hixie_: I've talked to a couple of people here and they think it wouldn't be stable |
| 22:17 | <Hixie_> | cabanier: because...? |
| 22:17 | <Hixie_> | TabAtkins: that would be a reasonable argument, yeah |
| 22:18 | <Hixie_> | TabAtkins: (if there's no other argument and it can be overridden) |
| 22:18 | <TabAtkins> | Pretty sure <path> resets the stroke only on new subpaths, which are generated by movetos. |
| 22:18 | <cabanier> | Hixie_: I see stephan replied |
| 22:18 | <TabAtkins> | But yeah, having some flag for it doesn't sound unreasonable. |
| 22:18 | <Hixie_> | cabanier: is he not on the list? i don't see his e-mail |
| 22:19 | <Hixie_> | bholley: so we're saying on Window and Location objects cross-origin, and any attempt to set or configure a property should throw? |
| 22:22 | <Hixie_> | bholley: probably simpler if we're doing that to just have all the objects behave like that, rather than have Function objects behave differently than Location, no? |
| 22:25 | <cabanier> | Hixie_: I got Stephan's mail. did it not go through for you? |
| 22:25 | <Hixie_> | i don't see it on http://lists.w3.org/Archives/Public/public-whatwg-archive/2013Oct/ |
| 22:29 | <cabanier> | Hixie_: he's going to subscribe |
| 22:29 | <cabanier> | Hixie_: let me go ask some more people to see what they think. |
| 22:29 | <cabanier> | (internally) |
| 22:29 | <Hixie_> | cabanier: what would be useful is why they think what they think, not just what they think |
| 22:38 | <cabanier> | Hixie_: talked to someone else who gave me a reason why your approach doesn't work. |
| 22:39 | <cabanier> | Hixie_: end caps contribute to the length of the path |
| 22:39 | <cabanier> | Hixie_: so, if you cut the path, you add 2 caps which are also dashed |
| 22:40 | <cabanier> | Hixie_: so the dashes will no longer line up in your approach |
| 22:40 | <cabanier> | Hixie_: I will send an email to make this clearer |
| 22:41 | <Hixie_> | the caps aren't dashed, per the spec |
| 22:41 | <Hixie_> | they're just caps |
| 22:41 | <Hixie_> | TabAtkins: (he's on a week break now) |
| 22:43 | <Hixie_> | bholley: you still there? does this look ok? http://junkyard.damowmow.com/523 |
| 22:45 | <Hixie_> | heycam: your input on http://junkyard.damowmow.com/523 would be good too |
| 22:45 | <cabanier> | Hixie_: sorry. talk to Stephan. He said it doesn't matter |
| 22:45 | <cabanier> | s/talk/talked |
| 22:46 | <bholley> | Hixie_: reading |
| 22:46 | <Hixie_> | pretty sure i screwed up Window, specifically the supported property names stuff |
| 22:47 | <bholley> | Hixie_: - All the members, including supported property indices and supported property |
| 22:47 | <bholley> | names, must be "own" properties, not on the prototype. |
| 22:47 | <bholley> | Hixie_: is that because of other parts of the spec? Or because of this discussion? |
| 22:47 | <Hixie_> | because of this discussion. |
| 22:47 | <bholley> | Hixie_: oh |
| 22:48 | <Hixie_> | specifically, us making prototype=null |
| 22:48 | <TabAtkins> | Hixie_: Huh? |
| 22:48 | <Hixie_> | bholley: but i'm not tied to it |
| 22:48 | <bholley> | Hixie_: but only in the cross-origin case, right? |
| 22:48 | <Hixie_> | TabAtkins: the traditional media thing |
| 22:48 | <TabAtkins> | Oh, now I can parse your sentence. A week-long ban. |
| 22:48 | <bholley> | Hixie_: I can't tell if this proposal is general or implicitly referring to the cross-origin caser |
| 22:49 | <Hixie_> | bholley: oh you want the properties to only be own properties in the Alien Object case? |
| 22:49 | <Hixie_> | bholley: general. |
| 22:49 | <Hixie_> | bholley: the cross-origin stuff is mentioned explicitly lower. |
| 22:49 | <bholley> | Hixie_: oh yeah, I was definitely thinking that this only applied to the cross-origin case |
| 22:49 | <Hixie_> | k |
| 22:50 | <Hixie_> | bholley: ok, i removed the first item in Location and Window and added the following to the Alien Object definition: |
| 22:50 | <Hixie_> | * promote all the members found on its prototypes, including supported |
| 22:50 | <Hixie_> | property indices and supported property names if any, to "own" properties |
| 22:50 | <Hixie_> | on the object itself. |
| 22:51 | <bholley> | Hixie_: link me to a refreshed version? |
| 22:51 | <Hixie_> | one sec |
| 22:51 | <Hixie_> | reload |
| 22:51 | <Hixie_> | (i am actually editing this in a bugzilla textarea, heh) |
| 22:52 | <heycam> | what is the reason for making these changes for cross origin objects? I think I overheard bholley mentioning this at the summit but don't remember hearing the reason |
| 22:53 | <bholley> | heycam: define "these changes" |
| 22:53 | <bholley> | heycam: we're trying to write a spec for cross-origin access that is both secure and implementable |
| 22:53 | <Hixie_> | bholley: the reason is "the spec is in looney town right now" |
| 22:53 | <heycam> | bholley, the removal of the prototype, making properties not enumerable, moving indexed/named properties to the instance |
| 22:53 | <Hixie_> | er, s/bholley/heycam/ |
| 22:53 | <bholley> | heycam: it's a long story |
| 22:53 | <Hixie_> | bholley: (reload again) |
| 22:53 | <gsnedders> | How much of the basic DOM stuff comes from NN? Most of it? |
| 22:53 | <bholley> | heycam: but for the prototype |
| 22:54 | <bholley> | heycam: consider - what do the prototypes look like, cross-origin? |
| 22:54 | <Hixie_> | gsnedders: NN and its contemporaneous IE |
| 22:54 | <bholley> | heycam: it's a tricky question |
| 22:54 | <bholley> | heycam: and in particular, every UA but Gecko currently cops out on that question and either throws or returns null |
| 22:54 | <bholley> | heycam: and it's probably easier to make gecko return null than the get the other UAs to implement whatever we cook up |
| 22:54 | <heycam> | bholley, can you normally access say window.Object from a cross origin window? |
| 22:54 | <Hixie_> | bholley: ok, i think it now also handles the supported property names |
| 22:54 | <bholley> | heycam: no |
| 22:54 | <heycam> | bholley, ok |
| 22:55 | <gsnedders> | Hixie_: Surely a fair bit is NN purely from it shipping with scripting first? |
| 22:55 | <heycam> | bholley, makes sense to do something then |
| 22:55 | <Hixie_> | gsnedders: "first" back then didn't mean much. it was probably only a matter of months. |
| 22:56 | <heycam> | bholley, still, it might be odd to describe the cross origin Window object to have a null [[Prototype]] when the same object, from its own window, does have a prototype |
| 22:56 | <Hixie_> | gsnedders: (less than 12 months) |
| 22:56 | <bholley> | heycam: trust me, it's going to be odd no matter what we do |
| 22:56 | <Hixie_> | gsnedders: (sept 1995 to aug 1996) |
| 22:56 | <heycam> | maybe they aren't "the same" object for some definition of same? |
| 22:56 | <bholley> | heycam: exactly |
| 22:56 | <bholley> | heycam: each origin gets its own view on the object |
| 22:56 | <bholley> | heycam: exactly how distinguishable those views are depends on how we spec it and how you implement it |
| 22:56 | <heycam> | bholley, aha, so some sort of forwarding proxy object? |
| 22:56 | <Hixie_> | "trust me, it's going to be odd no matter what we do" <-- preach it, brother. |
| 22:57 | <bholley> | heycam: in Gecko, yes. in Webkit/Blink, it's a separate reflector per origin |
| 22:57 | <heycam> | bholley, ok. as long as the spec describes it that way. otherwise describing how [[Prototype]] looks different on the same object is going to be hard to understand. :) |
| 22:58 | <gsnedders> | Hixie_: Any idea where I might find any documentation of what's in NN2.03? |
| 22:58 | <Hixie_> | gsnedders: not off-hand. try wikipedia's references? |
| 22:58 | <Hixie_> | bholley: unless you see anything you think should change, i'm gonna post this to the bug. i need to bail momentarily. |
| 22:58 | <gsnedders> | Mostly dead-trees, sadly |
| 22:58 | <bholley> | Hixie_: this looks good |
| 22:58 | <bholley> | Hixie_: two small nits |
| 22:58 | <Hixie_> | gsnedders: yeah |
| 22:59 | <bholley> | Hixie_: (1) Given that we'll probably handle functions by freezing them, it will be hard to throw a SecurityError proper |
| 22:59 | <gsnedders> | Hixie_: And the university library doesn't happen to have them. Somewhat unsurprisingly. :) |
| 22:59 | <Hixie_> | bholley: yeah i was asking about that earlier. you prefer to have two kinds of frozen than just one type of Alien Object? |
| 23:00 | <bholley> | Hixie_: I don't know. We could mimic the frozen-ness exceptions on Window and Location, modulo the named property thing |
| 23:00 | <Hixie_> | so change the last bullet point to from "were themselves Alien Objects" to "were themselves frozen"? but I don't know what that means w.r.t. their prototype, etc. |
| 23:00 | <bholley> | Hixie_: yeah |
| 23:00 | <bholley> | Hixie_: it's a tricky detail |
| 23:01 | <bholley> | Hixie_: I don't know how best to spec it |
| 23:01 | <bholley> | Hixie_: it's just a question of the SecurityError |
| 23:01 | <bholley> | Hixie_: like, we could have Window throw the same error that frozen objects throw |
| 23:01 | <bholley> | Hixie_: and just swallow the fact that it won't totally behave like a frozen object due to the named properties thing |
| 23:02 | <Hixie_> | i know nothing about frozen objects, so i don't know the implications of this |
| 23:02 | <bholley> | Hixie_: we can't have Object.isFrozen(xoWin) == true |
| 23:02 | <bholley> | because that would imply it never changes properties |
| 23:02 | <Hixie_> | my concern is that you not be able to do "otherWindow.postMessage.prototype.toString = ..." |
| 23:02 | <Hixie_> | or whatever hte syntax for that is |
| 23:03 | <Hixie_> | beyond that, i don't really care either way |
| 23:03 | <bholley> | Hixie_: .prototype? or .__proto__? |
| 23:03 | <Hixie_> | whichever is the scary one :-) |
| 23:03 | <Hixie_> | i can never remember how all this works |
| 23:03 | <bholley> | Hixie_: you need to go and I need to sleep - let's leave this as a (?) now in the spec, and see what abarth thinks about the big picture |
| 23:03 | <Hixie_> | k |
| 23:04 | <bholley> | Hixie_: we can sort out this detail afterwards |
| 23:04 | <bholley> | Hixie_: just wrote "Some sort of error (?)" instead of SecurityError |
| 23:04 | <bholley> | Hixie_: feedback+ modulo that |
| 23:04 | bholley | sleeps |
| 23:07 | <gsnedders> | Oh dear god. Netscape 2.0 opens up a modal window *for every single JS syntax error*. |
| 23:08 | <Hixie_> | abarth: when you have a chance, https://www.w3.org/Bugs/Public/show_bug.cgi?id=13154 |
| 23:18 | <Domenic_> | gsnedders: I remember that! Back in the days when browsers didn't let you get away with crappy code... |
| 23:19 | <gsnedders> | Domenic_: I just tried loading Google.com. I may have invoked kill to get out of Modal Hell. |