| 07:49 | <zcorpan> | zewt: please give rationale |
| 07:51 | <Ms2ger> | marcosc, squash, not squish ;) |
| 07:51 | <marcosc> | Ms2ger: should be "squished" |
| 07:52 | <marcosc> | it's much cutter and sounds less mean |
| 08:05 | <SimonSapin> | zcorpan: Errors should not pass silently |
| 08:06 | <zcorpan> | SimonSapin: ...because? |
| 08:06 | <SimonSapin> | zcorpan: Code that "works" and eg. looks for id="undefined" will be harder to debug than one that just throws with an explicit error |
| 08:07 | <zcorpan> | ok, so what do you think should happen for CSS.escape(window) ? |
| 08:07 | <SimonSapin> | This brings the symptom of the error closer to the source |
| 08:07 | <SimonSapin> | does window have .toString? |
| 08:07 | <zcorpan> | yes |
| 08:08 | <zcorpan> | it usually stringifies to [object Window] |
| 08:09 | <SimonSapin> | I don’t know, this case is less clear-cut |
| 08:09 | <SimonSapin> | is the convention to strictly only accept strings, or anything that can be converted to a string? |
| 08:10 | <zcorpan> | the latter |
| 08:10 | <zcorpan> | except for undefined, which is different for different APIs |
| 08:11 | <SimonSapin> | In that case I suppose CSS.escape(window) would be "\\[object\\ Window\\]" |
| 08:11 | <annevk> | zcorpan: seems like it should be undefined |
| 08:11 | <annevk> | SimonSapin: and it is |
| 08:11 | <annevk> | SimonSapin: that's how ToString works |
| 08:11 | <annevk> | JavaScript doesn't do type checking, it just does type coercions all over |
| 08:11 | <zcorpan> | SimonSapin: so how is it different from undefined from the being-in-error and debug-ability point of view? |
| 08:12 | <SimonSapin> | but undefined may be a common enough source of errors that it’s worth a special case |
| 08:12 | <annevk> | o_O |
| 08:12 | <SimonSapin> | IMO |
| 08:12 | <SimonSapin> | you’re less likely to accidentally end up with window instead of a string than undefined |
| 08:14 | <zcorpan> | is it less likely to accidentally end up with anything other than a string and undefined compared to undefined? |
| 08:15 | <SimonSapin> | I think so, but I may be wrong |
| 08:15 | <SimonSapin> | I don’t write that much JS |
| 09:40 | <annevk> | bholley: we'd have to narrow the case where the adopt would throw as otherwise many operations that route through adopt would not work, which would suck |
| 09:40 | <bholley> | annevk: can you explain a bit more? |
| 09:41 | <annevk> | bholley: e.g. whenever you appendChild, adopt is used |
| 09:41 | <bholley> | annevk: yes, I'm aware - that's the whole issue, really |
| 09:41 | <bholley> | annevk: people rarely adopt just to adopt |
| 09:41 | <annevk> | bholley: if the glabal object is the same, there doesn't seem to be an issue |
| 09:41 | <bholley> | annevk: oh, adopt happens even for same-global? |
| 09:41 | <annevk> | bholley: so we should limit throwing for custom elements only if the global object changes |
| 09:41 | <bholley> | annevk: right |
| 09:41 | <bholley> | annevk: that was my intention, sorry |
| 09:42 | <bholley> | annevk: I thought that the adopt was only triggered in the cross-global case |
| 09:42 | <bholley> | annevk: well, technically cross-document |
| 09:42 | <bholley> | annevk: are there significant ways in which those cases differ? |
| 09:42 | <annevk> | bholley: no, adopt does things like changing the document and removing from parent |
| 09:42 | <bholley> | annevk: ie document fragment? |
| 09:42 | <annevk> | bholley: yeah, createDocument |
| 09:42 | <annevk> | bholley: and HTML imports |
| 09:42 | <annevk> | bholley: and new Document() once we have that |
| 09:43 | <bholley> | annevk: ok, sure |
| 09:43 | <bholley> | annevk: that's fine with me |
| 09:43 | <bholley> | annevk: assuming we do that, do you think throwing would be ok? |
| 09:44 | <annevk> | have to think about that some more |
| 09:45 | <annevk> | kinda depends on where we want to steer the whole thing I think |
| 09:45 | <annevk> | treat sync access between multiple globals as a bug, or embrace it and make it work |
| 09:45 | <annevk> | should prolly be discussed on es-discuss |
| 09:46 | <annevk> | or public-script-coord |
| 09:46 | <bholley> | annevk: ugh, I feel like that's not going to really go anywhere |
| 09:46 | <bholley> | annevk: because if we abstract this into a more vague discussion of values, it will devolve again into the specific considerations |
| 09:46 | <bholley> | annevk: and then we're back at this bug |
| 09:47 | <bholley> | annevk: moreover, we can always spec that something throws and then change it later |
| 09:47 | <bholley> | annevk: whereas we can't unsupport something we decide to support |
| 09:48 | <annevk> | bholley: sure, throwing seems safe for now, but I also think we should have the larger discussion |
| 09:49 | <annevk> | bholley: as it'll impact other APIs to come |
| 09:49 | <bholley> | annevk: I'm also not totally clear which high-level outcome results in which course of action here - can you elaborate on your thinking? |
| 09:53 | <annevk> | bholley: the main goal of involving more people would be to create better shared understanding and push towards a common goal; be that reducing memory leaks at all costs or making multiple globals work in the best way possible somehow |
| 09:54 | <annevk> | bholley: I'm pretty sure we'll keep revisiting this if we don't reach out to the wider community around JavaScript |
| 09:55 | <bholley> | annevk: FWIW, I kind of feel that fixing up the prototypes _is_ "making multiple globals work in the best way possible somehow" |
| 09:55 | <bholley> | annevk: it's not just about memory leaks |
| 09:55 | <bholley> | annevk: though that's my primary concern |
| 09:55 | <jgraham> | To the extent that they differ, it's not clear that either of those is the correct goal |
| 09:55 | <bholley> | annevk: it's also about the API making sense |
| 09:55 | <annevk> | I think it makes a lot of sense for trees, though Brendan didn't like that bug much, though he may not have studied the details |
| 09:56 | <bholley> | annevk: trees? |
| 09:56 | <jgraham> | I mean, if there is an option that makes it reasonably easy to avoid memory leaks but also provides the features that people want that's better than either |
| 09:56 | <annevk> | bholley: that nodes share the same global |
| 09:57 | <bholley> | annevk: I still don't follow |
| 09:58 | <bholley> | annevk, jgraham: in my mind, the fundamental issues is that bindings are per-document. It's kind of non-sensical to pull a binding out of a document in that context |
| 09:58 | <bholley> | the only options are to (a) strip the binding, or (b) not allow them to leave the document |
| 09:58 | <annevk> | bholley: I think it makes sense to prototypes. People in TC39 seemed to have reservations about that bug which is why I'd like to discuss it with them |
| 09:58 | <annevk> | to change prototypes* |
| 09:58 | <bholley> | annevk: ok |
| 09:58 | <bholley> | (a) is apparently tricky due to the reasons that Dominic described |
| 09:59 | <annevk> | I think it's important to have TC39 on board, as they'll be diving into the multiple global territory and we don't want to revisit this each year. |
| 10:00 | <annevk> | Anyway, back in a bit, need to get some yoghurt from the office... |
| 10:00 | <bholley> | annevk: but |
| 10:00 | <bholley> | annevk: will JS ever have a concept of adopt? |
| 10:00 | <bholley> | annevk: if it doesn't, then the issue is moot |
| 10:03 | <annevk> | I don't know, anyway, biab |
| 10:04 | <jgraham> | zcorpan: Since someobject.propertyThatDoesntExist is undefined in js foo(undefined) is a way easier bug to have than foo(window) |
| 10:04 | <jgraham> | And throwing tells you what the error is right away rather than getting a nonsense result much later in the code |
| 10:05 | <bholley> | annevk-cloud: ok |
| 10:06 | <zcorpan> | jgraham: yeah, it seems plausible that undefined is a more common error |
| 10:08 | <zcorpan> | jgraham: still, encodeURIComponent(undefined) doesn't throw and seems to be in the same position as CSS.escape(undefined) |
| 10:13 | <jgraham> | zcorpan: It depends how important you think it is to be consistent with poor design decisions in the stdlib vs how important you think it is to be consistent with the DOM and provide a useful API |
| 10:19 | <annevk> | Treating undefined as "undefined" is what we do everywhere for DOMString. |
| 10:19 | <annevk> | The only case you could make is making the argument optional, but there doesn't seem to be much of a reason for that. |
| 10:20 | <Ms2ger> | And when you make it optional, then you have the question of the default |
| 10:20 | <annevk> | Simple test: .<script>document.body.innerHTML = undefined</script> |
| 10:22 | <zcorpan> | annevk: innerHTML isn't a method, and CSS.escape() doesn't have its argument optional (currently) |
| 10:22 | <jgraham> | Well if it's consistent with everything on the platform I guess we have to do that. But oh boy is that a sucky design |
| 10:22 | <annevk> | zcorpan: innerHTML is a getter and setter, same thing |
| 10:22 | <annevk> | zcorpan: but find a method that takes a DOMString and you'll find out how IDL works |
| 10:23 | <zcorpan> | it's not consistent with everything else. document.getElementById(undefined) throws (per spec, at least) |
| 10:23 | <Ms2ger> | Eh? |
| 10:24 | <Ms2ger> | Doesn't seem to |
| 10:24 | <jgraham> | I think the IDL spec changed at some point |
| 10:24 | <Ms2ger> | Only for optional arguments |
| 10:25 | <zcorpan> | ah, i thought it made undefined mean omitted even for non-optional argument |
| 10:26 | <Ms2ger> | I'm pretty sure it didn't |
| 10:27 | <zcorpan> | ok so CSS.escape() throws TypeError but CSS.escape(undefined) gives "undefined" (per current spec) |
| 10:27 | <Ms2ger> | sgtm |
| 10:31 | <jgraham> | For those following at home, that is *also* inconsistent with escape() and encodeURIComponent() |
| 10:32 | <zcorpan> | yep |
| 12:50 | <Domenic_> | CSS.escape(undefined) MUST be the same as CSS.escape() |
| 12:50 | <Ms2ger> | Nah |
| 12:51 | <Ms2ger> | WebKit used to do that, it's stupid |
| 12:51 | <Domenic_> | O_o |
| 12:51 | <Domenic_> | That is just ... how JS works... when you don't pass an argument, it's undefined ... |
| 12:51 | <Domenic_> | Anything else is MEGA surprising. |
| 12:59 | <jgraham> | Domenic_: Is this something that causes you lots of problems with every other DOM function? |
| 13:00 | <Domenic_> | jgraham: yes!! |
| 13:01 | <Domenic_> | it breaks transparent composability |
| 13:01 | <Domenic_> | you need to do function (x, y) { if (y === undefined) { domFunc(x); } else { domFunc(x, y); } } |
| 13:02 | <jgraham> | I am failing to understand the problem |
| 13:02 | <Domenic_> | it creates a combinatorial explosion every time you want to forward arguments to a DOM function |
| 13:02 | <jgraham> | You can't use undefined like a None type here anyway |
| 13:03 | <jgraham> | Since it is stringified |
| 13:03 | <Domenic_> | We're talking about the general case right now |
| 13:03 | <jgraham> | Sure |
| 13:04 | <Domenic_> | Forwarding arguments should be as simple as function (x, y, z, w) { domFunc(x, y, z, w); } |
| 13:04 | <jgraham> | But in general you can't use undefined like a None type |
| 13:04 | <Domenic_> | Sure you can, with normal JS functions |
| 13:04 | <jgraham> | How? |
| 13:04 | <Domenic_> | With the rules that make undefined and omitted different, you need ifs |
| 13:04 | <Ms2ger> | Nah, it should be function(...arguments) { domFunc(...arguments) } |
| 13:04 | <jgraham> | If there is magic type conversion |
| 13:04 | <Domenic_> | Ms2ger: OK, please extend my example to be slightly more complicated, e.g. transforming y to y + 1 |
| 13:05 | <Domenic_> | jgraham: there's nothing magic about it. If undefined goes into my function, it should go into the DOM function |
| 13:05 | <Domenic_> | gtg commute to work... be back later |
| 13:06 | <jgraham> | If undefined goes into your function and it is going to call the DOM function with the wrong number of arguments, there is a bug in your code |
| 13:06 | <Domenic_> | this combinatorial explosion avoidance is the main reason default parameters in ES use undefined as the default value trigger, BTW. |
| 13:06 | <jgraham> | I don't understand why you want to make that hard to notice |
| 13:06 | <Domenic_> | there is no such thing as "wrong number of arguments" |
| 13:06 | <Domenic_> | the number of arguments is not actually something functions care about |
| 13:06 | <zcorpan> | Domenic_: your example doesn't invoke domFunc without arguments, so i don't see the problem |
| 13:06 | <Domenic_> | there are some arguments that have values, and the rest of them have undefined, out to infinity |
| 13:06 | <Domenic_> | aggh really got to go ttyl |
| 13:07 | <jgraham> | That's an ironic point of view given Function.length |
| 13:07 | <annevk> | I think Domenic_'s point is better discussed at the IDL-level and not for this individual method |
| 13:07 | <annevk> | And therefore public-script-coord⊙wo is prolly a better fora than here |
| 13:08 | <gsnedders> | annevk: public-script-coord is a single forum. |
| 13:08 | <jgraham> | annevk: The discussion is already happening on public-script-coord |
| 13:08 | <jgraham> | But I don't see why you are trying to shut down discussion here |
| 13:08 | <annevk> | Shut down? Relax man, I just said prolly ;-) |
| 13:09 | <gsnedders> | Is the problem not deeper than this? Is this not caused by the fact that WebIDL (and the DOM generally) relies on overloads, and hence different numbers of arguments must have different meanings, and somehow the callee must recognize the number of arguments given? |
| 13:10 | gsnedders | doesn't know if he's even subscribed to public-script-coord now |
| 13:10 | <jgraham> | gsnedders: Script libraries do that too of course |
| 13:10 | <jgraham> | There's nothing to stop a js library from throwing with no argument but not throwing with undefined |
| 13:11 | <jgraham> | Or doing something totally different for the two cases |
| 13:12 | <zcorpan> | i guess webidl does what Domenic_ wants when there are optional arguments. |
| 13:13 | <annevk> | Treating () and (undefined) the same seems feasible given that WebKit has done it for a long time. Just need more eyeballs to measure to impact. |
| 13:14 | <zcorpan> | feasible, sure. desired? not so clear. this has been discussed and resolved to what webidl has now, some time ago (although i can't find the relevant thread now) |
| 13:17 | <annevk> | Well yeah, "some time ago" we also decided undefined and omitted arguments would be different. I think it's pretty clear what the answer would be now. |
| 13:18 | <zcorpan> | annevk: you mean for optional arguments? |
| 13:19 | <annevk> | Right, we already fixed optional arguments. |
| 14:04 | <zewt> | <Domenic_> That is just ... how JS works... when you don't pass an argument, it's undefined ... <- that's irrelevant; the function *itself* can do whatever it wants with the argument (such as throwing a TypeError if an argument that's supposed to be one thing isn't) |
| 14:05 | <zewt> | for example, new Event() throws, it doesn't create an event with a name of "undefined", which would be useless and make what is definitely a programming error harder to notice |
| 14:06 | <annevk> | though new Event(undefined) doesn't throw and also makes what's likely an error hard to notice |
| 14:06 | <annevk> | dunno if that carries much weight |
| 14:07 | <annevk> | Having types in general would make debugging much better, but it seems unlikely JS will get them. |
| 14:07 | <annevk> | Having required arguments be part of the language might be feasible however. |
| 14:08 | <Domenic_> | if the argument is required, both undefined and missing should give a TypeError |
| 14:08 | <Domenic_> | if it is optional, both undefined and missing should trigger the default |
| 14:08 | <annevk> | That seems reasonable |
| 14:09 | <zewt> | no objections there |
| 14:09 | <jgraham> | I would totally support that |
| 14:09 | <Domenic_> | I would rather more arguments be optional than are currently, but am willing to delay that battle indefinitely in favor of fixing the mega-WTF of separate undefined/missing behavior. |
| 14:09 | <Domenic_> | OK cool, sudden agreement :D |
| 14:09 | <annevk> | Nah, you made a better proposal :-) |
| 14:09 | <jgraham> | Well not really, because WebIDL says that explicit undefined is coerced |
| 14:10 | <Domenic_> | jgraham: so, agreement between everyone excepting WebIDL? :P |
| 14:10 | <jgraham> | Something like that :) |
| 14:10 | <annevk> | Shall I file a bug? |
| 14:11 | annevk | files a bug |
| 14:11 | <zewt> | xhr open() seems to be another one |
| 14:11 | <zewt> | (throws TypeError if there's no argument) |
| 14:11 | <zewt> | afk, work |
| 14:13 | <annevk> | https://www.w3.org/Bugs/Public/show_bug.cgi?id=23532 |
| 15:00 | <zewt> | hmm, webidl does seem to throw TypeError for missing (not undefined) arguments (4.5.1.1), but that doesn't seem like what most APIs do (unless I'm missing something in WebIDL, which is likely) |
| 15:01 | <jgraham> | I don't know about "most", but at the least "many" do |
| 15:01 | <zewt> | yeah it seems to vary |
| 15:01 | <jgraham> | At least in Gecko. And in presto (although it was some weird custom error) |
| 15:01 | <zewt> | webgl does |
| 15:01 | <zewt> | or maybe I'm just confused by the earlier conversation |
| 15:02 | <jgraham> | getElement[s]By*() do |
| 15:02 | <zewt> | (which was "what? you can't make CSS.escape() throw instead of returning "undefined", that's crazy!") |
| 15:05 | <jgraham> | So I think the tension arises from the fact that the javascript stdlib doesn't throw for missing arguments |
| 15:06 | <jgraham> | (or, depending on your point of view, that javascript doesn't have a concept of missing arguments, even though it clearly exposes information about which arguments were passed and which weren't) |
| 15:12 | <Domenic_> | it only does that through the arguments object, which is being slowly killed |
| 15:12 | <Domenic_> | e.g. if you use any ES6 features in your function parameters, like defaults or spread or destructuring, you get no arguments object. |
| 15:16 | <annevk> | Domenic_: do those also nullify arguments.length? |
| 15:17 | <annevk> | Domenic_: sorry, Function.length |
| 15:17 | <annevk> | Domenic_: see e.g. http://lists.w3.org/Archives/Public/public-script-coord/2013JulSep/0724.html |
| 15:17 | <Domenic_> | no, function.length is still defined, and still as useless as ever. |
| 15:18 | <Domenic_> | but there's no way inside a function that uses ES6 features to determine whether undefined was passed or that argument was omitted |
| 15:21 | <TabAtkins> | Yeah, Function.length is static for the function - it doesn't depend on the number of arguments passed. |
| 15:21 | <Domenic_> | (why do people keep capitalizing Function.length, it's not a property of the Function constructor...) |
| 15:21 | <TabAtkins> | Function#length |
| 15:22 | <TabAtkins> | Because typing out Function.prototype.length is annoying. ^_^ |
| 15:22 | <Domenic_> | Well it's not on the prototype either |
| 15:22 | <TabAtkins> | Close enough. |
| 15:22 | <annevk> | What's the way to refer to instances? |
| 15:22 | <TabAtkins> | Point being, "Foo" is sometimes used informally as a stand-in for "an arbitrary instance of Foo". |
| 15:22 | <Domenic_> | function.length or functionInstance.length |
| 15:23 | <Domenic_> | myFunction.length |
| 15:23 | <annevk> | that's kinda sad notation-wise but okay |
| 15:23 | <Domenic_> | I mean you wouldn't say Document.createElement |
| 15:23 | <annevk> | yeah, what TabAtkins says, though I'm not very consistent about it |
| 15:24 | <annevk> | Domenic_: I guess I try to go with Document.prototype.createElement these days |
| 15:24 | <jgraham> | document is a singleton (ish), so that's easier |
| 15:24 | <Domenic_> | true |
| 15:24 | <Domenic_> | anyway this is silly, didn't mean to spawn extended discussion on capitalization of a single character :P |
| 15:25 | <TabAtkins> | Domenic_: To be fair, it might be two or three characters, if the class name is multi-word. |
| 15:26 | <Domenic_> | hahaha |
| 15:30 | <bholley> | annevk: ping |
| 15:30 | <annevk> | bholley: hey |
| 15:31 | <bholley> | annevk: as noted in the thread, I believe that we should disallow freezing dom objects |
| 15:31 | <annevk> | bholley: I think that's already the case per IDL |
| 15:31 | <bholley> | annevk: ok, great |
| 15:31 | <bholley> | annevk: WebIDL specs this? |
| 15:32 | <annevk> | bholley: "Platform array objects cannot be fixed; if Object.freeze, Object.seal or Object.preventExtensions is called on one, the function MUST throw a TypeError." |
| 15:32 | <bholley> | annevk: great! |
| 15:32 | <annevk> | oh wait, that's array |
| 15:32 | <annevk> | hmm |
| 15:32 | <annevk> | also goes for "Platform objects implementing an interface that supports indexed or named properties cannot be fixed" |
| 15:33 | <annevk> | doesn't say anything that would apply to Node |
| 15:33 | <annevk> | bholley: so no... |
| 15:33 | <bholley> | annevk: ok |
| 15:34 | <bholley> | annevk: I'll file a bug on WebIDL |
| 15:34 | <bholley> | annevk: which tracker is it? w3? |
| 15:34 | <annevk> | bholley: there's a link at the top of the spec |
| 15:34 | <bholley> | annevk: ok, cool |
| 15:34 | <annevk> | bholley: https://www.w3.org/Bugs/Public/enter_bug.cgi?product=WebAppsWG&component=WebIDL |
| 15:34 | <bholley> | annevk: do you agree, btw? |
| 15:34 | <annevk> | bholley: don't really care about those ES5 features |
| 15:35 | <bholley> | annevk: so you don't mind just rejecting them for the DOM to give us more flexibility? |
| 15:35 | <annevk> | bholley: they have strange names and don't really do what you expect them to be doing and half of TC39 seems to shrug at them |
| 15:35 | <annevk> | bholley: right, I don't mind |
| 15:35 | <bholley> | annevk: k |
| 15:42 | <Domenic_> | you can't stop Object.seal |
| 15:42 | <Domenic_> | You can stop preventExtensions |
| 15:42 | <Domenic_> | and thus stop that part of the freezing process |
| 15:42 | <Domenic_> | but you can always make a property non-configurable/non-writable, even proxies can't prevent that |
| 15:43 | <Domenic_> | annevk: ^ |
| 15:43 | <annevk> | Domenic_: seems false in implementations |
| 15:43 | <Domenic_> | as in, DOM objects are not implementable with proxies? |
| 15:44 | <annevk> | In Gecko Object.seal(window) throws |
| 15:44 | <annevk> | Does not seem to throw in Chrome though |
| 15:47 | <Domenic_> | no i lied, you could make a proxy with a throwing defineOwnProperty trap |
| 15:47 | <Domenic_> | A bit unfortunate all platform objects would have to become proxies with overriden defineOwnProperty traps though |
| 15:48 | <annevk> | bholley: maybe you should request a hook for it, so we'd only use it on Node |
| 15:49 | <annevk> | well, and all the objects Node can hold, such as DOMTokenList |
| 15:49 | <annevk> | bholley: seems like this would be problematic once <input type=file>.files becomes an actual JS Array |
| 15:50 | annevk | shakes fist at multiple globals |
| 15:52 | <Domenic_> | from what i'm reading you just want Node to be a proxy with a throwing preventExtensions trap? |
| 15:52 | <Domenic_> | that would allow its proto to be changed later |
| 15:52 | <annevk> | Domenic_: not just Node, but everything attached to Node too |
| 15:52 | <Domenic_> | right :( |
| 15:52 | <annevk> | Domenic_: so there's no references to the other global |
| 15:56 | <annevk> | Yeah, browser engineering is pretty much sad times all the time. Fortunately the web is full of cats tripping themselves. |
| 15:57 | <zewt> | hard to take anyone seriously when they say "we talked about this before, read the notes from the f2f" |
| 16:00 | <annevk> | Well you can't really expect past stuff to be explained over and over again |
| 16:01 | <jgraham> | No, but saying "we discussed this in a meeting and you weren't invited" is pretty much like saying "fuck you" |
| 16:01 | <jgraham> | Even if there are notes |
| 16:01 | <Domenic_> | arv ^ |
| 16:02 | <annevk> | jgraham: every JS decision I've seen is backed by plenty of mailing list debate which is open to all |
| 16:02 | <annevk> | jgraham: they should just move to async-decisions entirely, but the way the thing works it's pretty much async |
| 16:03 | <jgraham> | I agree that anyone can join in on the mailing list. But I stand by my point |
| 16:04 | <annevk> | jgraham: e.g. decision on promises was just reiterating what was already said async and then we moved on |
| 16:05 | <gsnedders> | annevk: Plenty of things around TC 39 are effectively finalized in F2F meetings, often with some arguments going totally unaddressed. |
| 16:05 | <zewt> | should I really be surprised that it's 2013 and browsers still apparently don't support resuming downloads? |
| 16:06 | <annevk> | gsnedders: if you notice that happening please raise it |
| 16:06 | <annevk> | gsnedders: that seems suboptimal |
| 16:06 | <gsnedders> | zewt: I thought they did? Just many servers don't support partial requests. |
| 16:06 | <jgraham> | "ReferenceError: undefined_variable is not defined" |
| 16:07 | <gsnedders> | annevk: I haven't read es-discuss in ages, and don't really care nowadays. |
| 16:07 | <zewt> | downloading from nginx, which definitely does |
| 16:07 | <annevk> | gsnedders: okay, so things might have changed for the better |
| 16:07 | <gsnedders> | zewt: Are you sure the browser can tell the resource is unchanged? |
| 16:08 | <gsnedders> | annevk: At least stuff like Object.prototype.__proto__ was effectively decided in F2F until more or less overnight all JS engines went against the decision. |
| 16:08 | <zewt> | not entirely, but it does have a correct Last-Modified |
| 16:08 | <zewt> | no ETag or cache headers though |
| 16:08 | <gsnedders> | annevk: And that was a year and a half ago or so? |
| 16:08 | <gsnedders> | zewt: Are resources cachable by default? I forget. |
| 16:09 | <annevk> | gsnedders: my experience is about five months :-) |
| 16:09 | <zewt> | i forget too, it's probably something akin to must-revalidate |
| 16:09 | <annevk> | (and I'm going to miss what would've been my third meeting) |
| 16:10 | <gsnedders> | annevk: es-discuss takes too much time having to consider PL theory, at least before. Maybe as we're close to final it's not so much now. |
| 16:10 | <gsnedders> | annevk: And I attended no meetings, not working for a member. :) |
| 16:12 | <bholley> | annevk: why can't we do it on any IDL-defined type? |
| 16:12 | <annevk> | bholley: so Domenic_ and others care for the ability to express platform APIs fully in terms of JS |
| 16:13 | <annevk> | bholley: overriding what Object.seal() and such do requires the usage of JS proxies to do that |
| 16:13 | <annevk> | bholley: JS proxies should really be a last resort in API design and not really used for anything that doesn't actually need it |
| 16:14 | <bholley> | annevk: can DOM objects as they stand be implemented without proxies? |
| 16:14 | <bholley> | annevk: like nodes |
| 16:15 | <bholley> | annevk: as in - would this added requirement move it from possible to impossible? |
| 16:15 | <gsnedders> | bholley: Most of the DOM cannot. Some Nodes cans, others cannot. |
| 16:16 | <annevk> | bholley: so e.g. HTMLFormElement requires a proxy for sure, I'm not sure about Element in general, I don't think it does, though there are some things about branding that are not fully explained yet |
| 16:16 | <Domenic_> | gsnedders: which nodes cannot? The only thing I can think of is document.all |
| 16:16 | <Domenic_> | gsnedders: oh nevermind misread |
| 16:16 | <annevk> | bholley: there's a couple of proof of concepts of how branding (type checks) can be done through WeakMap, but not fully worked out afaik |
| 16:16 | <gsnedders> | Domenic_: My grammar is terrible. :) |
| 16:17 | <bholley> | annevk: basically, my feeling is that if we disallow freezing for Nodes and for Window, we've disallowed it for a good chunk of the DOM |
| 16:17 | <Domenic_> | annevk: I think it's pretty fully worked out |
| 16:17 | <bholley> | annevk: at which point we should just disallow it for everything |
| 16:18 | <annevk> | bholley: well, consider e.g. my <input type=file>.files thing that will return a regular JS Array |
| 16:18 | <annevk> | bholley: or ele.query() which will return an JS Array subclass |
| 16:19 | <annevk> | bholley: the lines are blurring |
| 16:19 | <bholley> | annevk: hm |
| 16:19 | <bholley> | annevk: it's true that they are |
| 16:20 | <annevk> | (btw, <input type=file> adoption could maybe just clear .files) |
| 16:20 | <annevk> | (and create a fresh array) |
| 16:20 | <bholley> | annevk: yeah. Are there any other cases where reparenting could theoretically involve reparenting a non-node? |
| 16:20 | <bholley> | I guess .style |
| 16:21 | <annevk> | also .classList |
| 16:21 | <annevk> | and .relList etc. |
| 16:21 | <Domenic_> | Wait isn't classList on the prototype |
| 16:21 | <Domenic_> | i.e. it's a getter that returns an internal representation |
| 16:21 | <bholley> | annevk: I would be opposed to leaving those things in the old scope |
| 16:21 | <bholley> | annevk: and just generating new ones |
| 16:21 | <bholley> | annevk: I don't think identity matters |
| 16:21 | <bholley> | annevk: er, sorry |
| 16:21 | <bholley> | annevk: _wouldn't_ be opposed |
| 16:22 | <annevk> | bholley: k |
| 16:22 | <annevk> | Domenic_: it returns an actual object though, and getting it twice will give you the same, but what bholley says can be done here |
| 16:22 | <annevk> | bholley: same could be done for .style and friends |
| 16:22 | <Domenic_> | right, what i think i was getting at (still wrapping my head around this) is that the internal object would change |
| 16:23 | <Domenic_> | i should go prototype this in JS with weakmaps etc. |
| 16:23 | <annevk> | Domenic_: that'd be cool |
| 16:23 | <jgraham> | So I haven't followed this enough and so should maybe not jump in here, but why can't adoption just be a clone operation that copies all the internal state into a new object? |
| 16:23 | <Domenic_> | ^ yeah that sounds nice |
| 16:24 | <Domenic_> | but similar haven't-followed-this problems |
| 16:24 | <annevk> | jgraham: newDoc.appendChild(eleFromOldDoc); eleFromOldDoc.innerHTML = ... |
| 16:25 | <annevk> | Domenic_: ^ |
| 16:25 | <jgraham> | annevk: You will have to elaborate a bit |
| 16:25 | <Domenic_> | what is that code supposed to illustrate, yeah... |
| 16:26 | <jgraham> | Oh I see |
| 16:28 | <jgraham> | Although you can imagine fixing that up with some sort of hack. Not that I'm advocating that or anything |
| 16:28 | <annevk> | That you cannot change identity |
| 16:28 | <Domenic_> | ahhh |
| 16:29 | <Domenic_> | what about if you threw when trying to adopt nodes that were extension-prevented |
| 16:29 | <Domenic_> | i.e. what if you just did Object.setPrototypeOf(ele.fromOldDoc, thisWindow.Element) and if that threw an exception, just let it bubble so that appendChild fails |
| 16:30 | <Domenic_> | ReturnIfAbrupt, as they say ;) <-- funny only to me |
| 16:35 | <annevk> | bholley: ^ |
| 16:37 | <bholley> | annevk, Domenic_: there are other cases when we need to munge the prototype... |
| 16:37 | <bholley> | XBL/WebComponents |
| 16:37 | <bholley> | for example |
| 16:37 | <Domenic_> | sure, but presumably whatever operation needs to munge can just throw if the prototype is un-mungeable |
| 16:38 | <bholley> | potentially for document.open, but hopefully not |
| 16:38 | <bholley> | Domenic_: well, if we decide to reparent things with document.open, we can't really make document.open throw, I don't think |
| 16:39 | <bholley> | plugins |
| 16:39 | <Domenic_> | bholley: really? You think that there's some web code out there that (a) does Object.preventExtensions on a DOM node; (b) uses document.open? |
| 16:40 | <bholley> | Domenic_: I don't know, tbh. In Gecko, we mostly ignore preventExtensions on DOM nodes for the time being ;-) |
| 16:40 | <gsnedders> | Domenic_: It tends to be a good theory that there is, however stupid the thought it. Actually, especially if it is stupid. |
| 16:42 | <bholley> | Domenic_: I'd kind of rather not deal with C++ proto sets being fallible in a script-triggerable fashion. But I'm willing to consider it |
| 16:42 | <jgraham> | Is EvalScript trident thing? |
| 16:42 | <Domenic_> | bholley: what is a C++ :P |
| 16:42 | <bholley> | it just seems like the DOM is hard enough to implement as-is |
| 16:43 | gsnedders | very much wants JS to be able to implement the DOM |
| 16:44 | <jgraham> | YOu can't really ignore the fact that the DOM has a real implentation complexity. The more time that browser vendors spend chasing theoretical wins in self-hosting, the less time they have to spend on other things like performance or features |
| 16:45 | <bholley> | jgraham: my knight in shining armor |
| 16:47 | <gsnedders> | jgraham: Depends on how much gain performance would have by having the DOM all in JS and being able to be inlined. |
| 16:47 | <gsnedders> | s/would/we would/ |
| 16:57 | <annevk> | bholley: what's bad about routing the prototype sets through script? |
| 16:59 | <bholley> | annevk: there are places in which we need to munge prototypes where we cannot fail |
| 16:59 | <bholley> | annevk: for example, if we fail midway through reparenting, there's no way to recover |
| 16:59 | <bholley> | annevk: we have to crash |
| 17:00 | <annevk> | bholley: could you elaborate in the bug? I have to go :/ |
| 17:00 | <bholley> | annevk: so historically, we haven't been able to let script just decide that certain prototypes are unmungeable |
| 17:00 | <bholley> | annevk: ok |
| 17:02 | <annevk> | jgraham: as a closing note, I think nailing down the architecture in a way that everyone thinks is a win for the future is worth some time. What we decide here impacts how you architect your browser for decades to come. And hopefully many revisions to DOM implementations will be made over those decades. |
| 17:37 | <zewt> | man, time warner around here has the most bizarre problem: it randomly corrupts packets in a way that causes them to have the correct IP checksum |
| 17:38 | <zewt> | not like it's corrupting lots of packets and a couple happen to match (that would kill throughput); it just occasionally shuffles bytes around in a packet, which checksums won't detect |
| 17:39 | <zewt> | and tons of protocols just assume TCP streams are never corrupted, so it causes all kinds of weirdness |
| 17:41 | <Hixie_> | wow |
| 17:41 | <Hixie_> | that's messed up |
| 17:42 | <zewt> | it's so messed up that when we call the ISP and they send a guy out, he just goes "???" |
| 17:49 | <Hixie_> | "???" as in, "what's wrong", or as in, "wtf this makes no sense" ? |
| 17:49 | <zewt> | he just had no idea |
| 17:49 | <Hixie_> | no idea what you meant, or what the cause was? |
| 17:50 | <Hixie_> | there's two kinds of confusion possible here :-) |
| 17:50 | <zewt> | he understood the problem after I explained it long enough, but he had no idea why it was happening |
| 17:50 | <Hixie_> | aah ok |
| 17:50 | <zewt> | it's bizarre, since if it was just lots of packet corruption and once in a while one matched the checksum, it'd kill the connection completely |
| 17:51 | <Hixie_> | i'm on a business plan for my cable, it's pretty awesome, the slightest complaint and they roll a truck within 4 hours and fix things until it works |
| 17:51 | <Hixie_> | i was like "it seems we get occasional dropouts" at about 9pm, and by 11pm they'd rewired the entire building basically. |
| 17:51 | <smaug____> | slightlyoff: we really need webidl spec for ServiceWorker (https://github.com/slightlyoff/ServiceWorker/issues/99#issuecomment-26440824) |
| 17:52 | <smaug____> | sooner than later |
| 17:52 | <Hixie_> | (not even _that_ much more expensive than residential service, it's pretty crazy) |
| 17:52 | <smaug____> | or JSIDL and some tool which converts JSIDL to WebIDL |
| 17:52 | <zewt> | this is business too (it's our office), but it's one of those problems that always hides when a tech is on site |
| 17:52 | smaug____ | doesn't understand this JSIDL stuff |
| 17:52 | <Hixie_> | oh the problem was gone by the time the tech got here in our case |
| 17:52 | <Hixie_> | he just rewired it all just in case |
| 17:52 | <zewt> | also, this has happened in every time warner installation i've used: my home cable, and business cable in two different offices |
| 17:53 | <Hixie_> | btytes shifted around pretty much has to be their back-end, right? |
| 17:53 | <Hixie_> | i mean, it's not like a bad cable is gonna cause that |
| 17:53 | <MikeSmith> | smaug____: what is TS+tests? |
| 17:54 | <MikeSmith> | and is anybody actually working on making a JSIDL? |
| 17:54 | <zewt> | seems like it has to be hardware and not cabling, yeah, seems like weird firmware in a cable modem is as likely a cause as a bad router though |
| 17:54 | <sgalineau> | IP checksums changing in flight? I'd call the NSA, not Time Warner :) |
| 17:54 | <zewt> | (which is to say, all equally unlikely) |
| 17:54 | <MikeSmith> | (I mean JSIDL at all for anything, as an alternative to WebIDL) |
| 17:54 | <zewt> | sgalineau: no, worse: the packet data is being corrupted, but in a way that results in the same IP checksum, so IP doesn't drop the packet |
| 17:54 | <smaug____> | TS is ...that odd format to describe classes or interfaces |
| 17:54 | <Hixie_> | zewt: try swapping out the router for another? |
| 17:54 | <smaug____> | MikeSmith: yeah, I haven't see anything concrete on JSIDL |
| 17:55 | <zewt> | Hixie_: i meant their routers (it could be anywhere in their stack) |
| 17:55 | <Hixie_> | zewt: well yeah, but you have control over one of them :-) |
| 17:56 | <zewt> | the only router we have is the one built into the cable modem :) (and yeah, getting a different router is one thing to try, though I suspect it's further up the chain) |
| 17:57 | <sgalineau> | zewt: man, that is twisted |
| 17:57 | <Hixie_> | get a replacement cable modem, swap it in, if it doesn't solve it, send it back :-) |
| 17:57 | <MikeSmith> | smaug____: seems pretty odd to be going ahead with implementations without the interface actually being documented or even without an actual spec |
| 17:57 | <zewt> | sgalineau: i wget'd a test file over http containing "0123456789" repeated, it downloaded without error and you'd see "0123546789" or something randomly |
| 17:58 | <smaug____> | MikeSmith: very much so |
| 17:58 | <smaug____> | MikeSmith: TS == http://en.wikipedia.org/wiki/TypeScript |
| 17:58 | <MikeSmith> | ah that |
| 17:58 | <zewt> | if IP used CRC's it'd catch it, but IP is ... old |
| 17:58 | <MikeSmith> | TypeScript looks kind of nice |
| 18:00 | <Hixie_> | zewt: time to use https for everything :-P |
| 18:07 | <zewt> | Hixie_: i do--that's what led to me earlier wondering about browsers not resuming downloads |
| 18:07 | <zewt> | https will kill the connection on error, but it won't automatically recover |
| 18:07 | <Hixie_> | ah |
| 19:26 | <smaug____> | Ms2ger: thanks |
| 21:01 | <annevk> | MikeSmith: JSIDL lacks resources, so we'll continue to work on IDL and address the ES6 requirements there |
| 21:02 | <annevk> | MikeSmith: as I understand it heycam|away managed to get a couple of months just for IDL so we should start seeing some progress there soonish |
| 21:02 | <annevk> | MikeSmith: including moving the thing to GitHub and such |
| 21:07 | <annevk> | slightlyoff: cool cool, sounds good |
| 21:07 | <annevk> | slightlyoff: I'll post updates once I've integrated Fetch into XMLHttpRequest |
| 21:24 | <smaug____> | annevk: is it still very much unclear to me what is wrong with webidl and what jsidl will change |
| 21:27 | <annevk> | smaug____: I think the primary change would be to describe the platform in terms of JavaScript rather than IDL types |
| 21:27 | <smaug____> | well, that doesn't say much about how the APIs would change in practice |
| 21:28 | <annevk> | smaug____: I don't think the intent is to change APIs other than encourage new APIs to follow better patterns, but that goal is shared with IDL I think |
| 21:30 | <smaug____> | "better patterns" tends to be vague |
| 21:30 | <smaug____> | there needs to be some reasoning to do Foo and not Bar |
| 21:31 | <annevk> | smaug____: again, the high-level reason is describing the entire platform in terms of JavaScript and making it self-hostable |
| 21:31 | <annevk> | smaug____: we don't necessarily need new IDL for that, but some people think they can convey their ideas better with a fresh start, although obviously they haven't found the time yet to write it out... |
| 21:33 | <smaug____> | I guess the question I have is that how does that help users of the APIs or implementors |
| 21:33 | <smaug____> | webidl is kind of a nice abstract layer above raw JS |
| 21:34 | <annevk> | smaug____: the idea is that APIs become more extensible than they are now |
| 21:34 | <annevk> | smaug____: e.g. classes become subclassable, just like built-ins are in ES6 |
| 21:34 | <annevk> | smaug____: the other small benefit might be that we can use a somewhat better syntax, though that's discussed for IDL too |
| 21:35 | <smaug____> | hmm, hard to say much about better syntax without seeing any proposals |
| 21:35 | <annevk> | smaug____: for implementers it's mostly a cost I suppose, because the ES6-style world with subclassing is vastly more complex |
| 21:36 | <annevk> | smaug____: yeah, I can only say so much because I'm familiar with some of the ideas, having something concrete would indeed be way better |
| 21:37 | <zcorpan> | http://blog.paciellogroup.com/2013/10/using-html5-section-element/ ... why would a screen reader say "region" for each <section>? isn't that just annoying? and wrong, given that it's semantically equivalent to drop all <section>s and use h1-h6 |
| 21:37 | <annevk> | smaug____: one change, which we're planning on making in IDL too, is to have distinction between class and interface |
| 21:37 | <zcorpan> | and i don't understand the recommendation to use aria-labelledby |
| 21:38 | <annevk> | smaug____: and IDL will adopt ES6-style classes and such, so I suspect most of the changes to happen in IDL unless JSIDL suddenly gets a bunch of resources |
| 21:38 | <smaug____> | right |
| 21:39 | <smaug____> | annevk: this all comes mainly from ServiceWorker stuff |
| 21:39 | <smaug____> | implementors implementing API which doesn't exist |
| 21:39 | <annevk> | smaug____: jdm worked out some IDL for ServiceWorker |
| 21:39 | <smaug____> | good |
| 21:40 | <annevk> | smaug____: if I had not been traveling I might have been more productive and actually done some work there, for now I'm occupied with correcting people on the internet and Fetch / XHR / URL |
| 21:40 | <annevk> | smaug____: less travel is one of my 2014 goals now |
| 21:40 | <smaug____> | ha |
| 21:49 | <zcorpan> | what's your knee-jerk reaction to renaming DOMRectReadOnly to DOMRectRead? (since the UA can mutate the object, it's supposedly not actually read *only* ....) |
| 21:49 | <Hixie_> | sounds weird |
| 21:49 | <Hixie_> | how about DOMRectView or something like that? |
| 21:50 | <Hixie_> | or DOMRect and MutableDOMRect |
| 21:51 | <zcorpan> | the mutable one needs the short name since it has a constructor, so that's the name people are going to write in their code |
| 21:52 | <zcorpan> | unless we do something magic like have a constructor for one interface that returns an object of the other, but that's really weird |
| 21:53 | <Hixie_> | then i'd go with DOMRect and DOMRectReadOnly |
| 21:53 | <Hixie_> | it's read-only, even if it can change |
| 21:54 | <Domenic_> | O_o |
| 21:54 | <Hixie_> | look at the readonly attributes in the DOM |
| 21:54 | <Hixie_> | most of them can change too |
| 21:54 | <Domenic_> | O__o |
| 21:55 | <Hixie_> | like firstChild |
| 21:55 | <Hixie_> | that's a readonly attribute |
| 21:55 | <Hixie_> | but if you change the DOM, it returns a different object |
| 21:55 | <Hixie_> | or NodeList.length |
| 21:55 | <Domenic_> | it sounds like a getter, not something that's read-only. |
| 21:55 | <Hixie_> | or formElement.validationMessage |
| 21:55 | <Domenic_> | since obviously it's being written. |
| 21:56 | <Hixie_> | i'm just saying that the IDL for these attributes reads "readonly attribute ..." |
| 21:56 | <Domenic_> | Right, and to that I say O__o |
| 21:56 | <Domenic_> | ^ things JSIDL could fix |
| 21:57 | <Hixie_> | a readonly text field can change even while it's readonly |
| 21:57 | <Domenic_> | O___o |
| 21:57 | <Hixie_> | readonly doesn't mean "immutable", it means "can't be changed by you" |
| 21:57 | <Domenic_> | read only means you can only read it |
| 21:57 | <Hixie_> | right |
| 21:57 | <Hixie_> | YOU can only read it |
| 22:01 | <smaug____> | yeah, no need to use JSIDL for anything here. it is pretty clear what readonly means in, webidl |
| 22:01 | <Domenic_> | it means we are in crazy magic land where you can write things that are read-only |
| 22:02 | <Hixie_> | "readonly" doesn't mean what you think it means, in pretty much any platform i've ever seen the term used in |
| 22:02 | <annevk> | Domenic_: <input readonly> can be written too... |
| 22:03 | <annevk> | Domenic_: Mark and apparently you seem to have a strange notion of readonly; I don't quite get it |
| 22:03 | <Domenic_> | I just don't understand how you can write something that is read only |
| 22:04 | <Domenic_> | but if there is precedence in other platforms and this isn't just some weird thing that WebIDL and <input> do, I guess that is my failing. |
| 22:04 | <annevk> | Domenic_: it seems kinda normal I can hand you an object that's readonly for you, but not me |
| 22:05 | <Domenic_> | i think of readonly as a property of the object, not of the object+person who's touching it pair |
| 22:05 | <annevk> | Domenic_: i.e. you're getting a readonly view of the situation |
| 22:05 | <annevk> | Domenic_: I see |
| 22:05 | <smaug____> | readonly is not const |
| 22:06 | <annevk> | Yeah, it seems immutable or const would be what you're after Domenic_ |
| 22:06 | <Hixie_> | Domenic_: what would you call an object that can change value but that you are not allowed to directly change yourself? |
| 22:06 | <Hixie_> | such as the examples above? |
| 22:07 | <Domenic_> | Hixie_: you're describing two things here, an object, and a person with access to the object. Or, as Anne puts it, a view on the object. Typically I would not have a name for such an object, and say I have a getter to access the object. |
| 22:08 | <Domenic_> | Let me admit though that it seems clear the weight of the computer field is against my understanding here, so thanks for humoring me. |
| 22:08 | <Hixie_> | Domenic_: properties can have getters and setters, or just a getter, or just a setter. What keyword would you use in a WebIDL-analogue to indicate that a property has only a getter? |
| 22:12 | <Domenic_> | get |
| 22:15 | <Hixie_> | Domenic_: so you'd have like, "get attribute" and "get set attribute" ? |
| 22:22 | <Domenic_> | Yeah |
| 22:24 | <zcorpan> | ok thanks, sent http://lists.w3.org/Archives/Public/public-script-coord/2013OctDec/0125.html |
| 22:25 | <annevk> | I think get set name makes sense |
| 22:26 | <Hixie_> | delphi uses "property name: type; read reader; write writer;" so read-only ones are just "property name: type; read reader;" |
| 22:26 | <Hixie_> | which pretty much makes the term "read-only" obvious. :-) |
| 22:26 | <Hixie_> | basically, "read" seems to be a synonym for "get" |
| 22:27 | <Hixie_> | so "read only" is the same as "get only" |
| 22:28 | <Domenic_> | That does help conceptualize what I was missing, thanks :) |
| 22:28 | <annevk> | smaug____: that reminds me, one change I've heard people suggest is having get/set properties as everything in IDL is now, but also have data properties as JavaScript has |
| 22:29 | <Hixie_> | can anyone figure out a way to have a zero-width image in an img? |
| 22:30 | <Hixie_> | (not img width:0 so width=0) |
| 22:30 | <Hixie_> | s/so/or/ |
| 22:30 | <zcorpan> | Hixie_: svg? |
| 22:30 | <Hixie_> | hm, interesting idea |
| 22:32 | <Hixie_> | data:text/xml,<svg xmlns="http://www.w3.org/2000/svg"; viewbox="0 0 0 0"><circle fill="red" cx="0" cy="'0" r="10"/></svg> |
| 22:33 | <Hixie_> | s/'/// |
| 22:33 | <Hixie_> | -/ |
| 22:33 | <Hixie_> | odd, chrome doesn't render svg in img? |
| 22:33 | <smaug____> | annevk: use cases, use cases, please :) |
| 22:33 | <zcorpan> | Hixie_: you need image/svg+xml for <img> |
| 22:34 | <Hixie_> | oh |
| 22:34 | <Hixie_> | well that's lame |
| 22:34 | <Hixie_> | thanks |
| 22:35 | <Hixie_> | weird, firefox treats it as 300x150 |
| 22:35 | <Hixie_> | chrome too |
| 22:35 | <Hixie_> | viewBox maybe |
| 22:36 | <Hixie_> | that made it disappear but didn't change the dimensions |
| 22:36 | <Hixie_> | weirder and weirder |
| 22:36 | <zcorpan> | might be how CSS sizes replaced elements without intrinsic size or something |
| 22:36 | <zcorpan> | dunno if svg says that 0 means no intrinsic size though |
| 22:37 | <Hixie_> | ah, width= and height= maybe |
| 22:37 | <annevk> | smaug____: I'll defer to Domenic_, but e.g. if we're going to subclass built-ins, we need to be able to express what they have |
| 22:37 | <Hixie_> | ok, in firefox that worked |
| 22:37 | <Hixie_> | <svg ... width=0 height=0> |
| 22:39 | <annevk> | I should really go to bed, but I just had an idea. What if JavaScript's standard library was defined in terms of an IDL that could also be used downstream... Instead of "moaning" they could be leading the way ;P |
| 22:43 | <Hixie_> | annevk: that would be ideal imho |