| 00:00 | <annevk> | are you using Safari on Mac? |
| 00:00 | <annevk> | doesn't download for me |
| 00:00 | <GPHemsley> | except Safari |
| 00:01 | <annevk> | ah okay, by "No" you indicated agreement with my observations? |
| 00:01 | <GPHemsley> | yeah; I was disagreeing with your interop statement |
| 00:01 | <annevk> | what statement? |
| 00:02 | <GPHemsley> | how do I check the type/headers in Safari? |
| 00:02 | <GPHemsley> | [18:40:21] <annevk> GPHemsley: fwiw, displaying as "text/plain" versus offering a download dialog does seem like a potential interoperability issue and something we should tackle, though it's not really clear to me that's the case here |
| 00:02 | <annevk> | well yeah, it's not the case here, but why would you disagree with that in general? |
| 00:02 | <GPHemsley> | agreeing/disagreeing |
| 00:02 | <GPHemsley> | blame the English language |
| 00:02 | <annevk> | bedtime, it seems :) |
| 00:02 | <GPHemsley> | :) |
| 00:04 | <GPHemsley> | I think we do need to come up with a metric for deciding what needs to go in the mimesniff spec and what can be elsewhere |
| 00:40 | <GPHemsley> | hmm... cache manifest is going to be a little complex to handle in the current styling, given the allowance of an optional BOM |
| 00:41 | <GPHemsley> | oh, same with WebVTT |
| 00:41 | <GPHemsley> | hmm |
| 00:51 | <Yuhong> | <annevk> Yuhong: I want IE to drop support for EOT in the end |
| 00:52 | <Yuhong> | Actually, they do sometimes do things like this, but notice they disabled it by default only in the Internet zone and allow it to be reenabled: |
| 00:52 | <Yuhong> | http://blogs.msdn.com/b/ie/archive/2012/06/04/legacy-dx-filters-removed-from-ie10-release-preview.aspx |
| 06:43 | <sangwhan> | ls |
| 06:43 | sangwhan | oops |
| 06:55 | <karlcow> | aha |
| 07:54 | <zcorpan> | http://www.alvestrand.no/pipermail/idna-update/2012-November/007482.html |
| 08:08 | <MikeSmith> | zcorpan: wow |
| 08:35 | <zcorpan> | MikeSmith: indeed |
| 08:49 | <annevk> | GPHemsley: you don't take BOM into account for HTML? |
| 09:39 | <zcorpan> | heycam: <p><div></div></p> is actually <p></p><div></div><p></p> |
| 09:44 | <zcorpan> | annevk: http://krijnhoetmer.nl/irc-logs/whatwg/20121118#l-136 doesn't seem right. |
| 09:44 | <zcorpan> | <input required value> is valid, afaict |
| 09:57 | <annevk> | zcorpan: didn't realize he was talking about the validator |
| 09:57 | <zcorpan> | ah |
| 09:57 | <annevk> | happy b-day btw |
| 09:57 | <zcorpan> | thanks |
| 10:15 | <zcorpan> | should it be possible to create a DataTransfer object from script? |
| 10:17 | <zcorpan> | the DragEvent constructor seems a bit pointless without being able to use custom DataTransfer |
| 10:19 | <zcorpan> | https://www.w3.org/Bugs/Public/show_bug.cgi?id=20004 |
| 10:26 | <annevk> | zcorpan: can't you still test your drag & drop code with custom events even if there's no DataTransfer object? arguably you can't test all of it then, but still a bit |
| 10:27 | <zcorpan> | you can't test the dataTransfer aspects |
| 10:27 | <zcorpan> | which seems like the useful ones |
| 10:28 | <annevk> | zcorpan: that whole idna-update thread is full of wow |
| 10:29 | <zcorpan> | yeah. but this email seemed like a level above the rest |
| 10:33 | <annevk> | http://iutf.org/wiki/Main_Page can't help but read "intelligent design" |
| 10:33 | <annevk> | http://wiki.whatwg.org/wiki/URL#IDNA has my IDNA notes |
| 10:38 | <zcorpan> | nice |
| 10:40 | <annevk> | the not so nice thing is that e.g. thus far I've heard no interest from WebKit in doing anything, IE apparently has not moved either even though Windows 8 reportedly supports IDNA2008, and Gecko seems to be planning on moving forward still? https://bugzilla.mozilla.org/show_bug.cgi?id=479520 |
| 10:41 | <annevk> | well, and Opera did something, but thus far it's not very clear whether Gecko plans on matching that |
| 10:54 | <annevk> | https://github.com/jclark/microxml-er/blob/master/recovery.md seems to match what I had defined more or less, minus DOCTYPEs |
| 11:18 | <zcorpan> | and the multiple roots case |
| 11:18 | <zcorpan> | and </> |
| 11:20 | <annevk> | oh it supports multiple roots? how would the result still match element then? |
| 11:21 | <zcorpan> | "If at this point we do not have a single element, wrap everything in an element named #doc." |
| 11:21 | <annevk> | ooh |
| 11:21 | <annevk> | how is that streaming? |
| 11:21 | <zcorpan> | means it can't be streaming :-( |
| 11:22 | <annevk> | that's kinda contrary to an earlier stated goal |
| 11:22 | <annevk> | weird |
| 11:22 | <zcorpan> | where are the goals stated? |
| 11:23 | <annevk> | oh |
| 11:23 | <annevk> | "The tokenization phase is also designed to be allow for a streaming implementation, whereas the tree-building phase is not." |
| 11:23 | <annevk> | misremembered |
| 11:23 | <annevk> | seems silly |
| 11:24 | <jgraham> | You just start streaming with a QuantumStartTag which is ina superposition of the present and not present states. Reaching the end of the input is like collapsing the wavefunction so you end up in a concrete state. |
| 11:25 | <annevk> | right |
| 11:25 | <jgraham> | (Man I feel bad for such a hideous use of pseudo-physics. Although like all great pseudo-physics it doesn't actually work) |
| 11:26 | <jgraham> | (next up: how to use the endless cycling of Working Group debates to generate infinite energy) |
| 11:26 | <annevk> | in the new bond movie they have a lot of pseudo-computery-stuff |
| 11:26 | <annevk> | aside from that it was pretty decent |
| 11:38 | <odinho> | Yeah, had the same feeling. Had to look away quite a bit. |
| 11:38 | <odinho> | Don't understand why they do that. |
| 11:39 | <odinho> | Even Helene (my gf) felt bad because of it. |
| 12:05 | <zcorpan> | i totally overlooked the pseudo-computer stuff. i guess i'm used to it |
| 12:07 | <annevk> | I think I might have done that too but it was pointed out to me and then I couldn't stop noticing it |
| 12:28 | <annevk> | AryehGregor_: basically, I'm unsure of all changes to ranges :-) |
| 12:29 | <annevk> | AryehGregor_: not sure what it is exactly, I feel like I don't quite grasp them or something |
| 12:30 | <annevk> | AryehGregor_: anyway, will fix that bug shortly |
| 12:33 | <AryehGregor_> | annevk, thanks. |
| 13:56 | <annevk> | hmm |
| 13:56 | <annevk> | Chrome supports http://[2::%5d/ |
| 13:58 | <annevk> | and stuff like http://[3%3a:1:0:0:0:0]/ |
| 13:59 | <annevk> | Safari does not reject http://[3%3a:1:0:0:0:0%]/ |
| 13:59 | <annevk> | Safari does reject %5d instead of ] |
| 13:59 | <annevk> | man |
| 13:59 | <annevk> | is there nothing that just works? |
| 13:59 | <zcorpan> | you must be new here |
| 14:03 | <annevk> | I guess I'll go with RFC 3986 which puts [, :, and ] in reserved and has them as part of the syntax of IP literals and therefore using them in percent-encoded fashion should result in a syntax error |
| 14:04 | <annevk> | Opera just gives me illegal URL for http://[3a::1:0:0:0:0]/test btw |
| 14:04 | <annevk> | not sure what is up with that |
| 14:08 | <MikeSmith> | "The rank of an hgroup element is the rank of the highest-ranked h1–h6 element descendant of the hgroup element, if there are any such elements, or otherwise the same as for an h1 element (the highest rank)." is not very friendly to streaming processing to generate an outline. |
| 14:10 | <zcorpan> | MikeSmith: just defer creating the outline item for the hgroup until the element is closed |
| 14:11 | <zcorpan> | or heading, i guess |
| 14:11 | <MikeSmith> | hmm yeah true |
| 15:36 | <GPHemsley> | annevk: BOM seems to be handled in a haphazard way. For sniffing, it is used as the signature for text/plain. AFAICT, if an HTML file has a BOM, it will be sniffed as text/plain by the unknown type sniffer. But if a HTML file as a BOM, it will be properly handled to determine if it is a feed.... >_> |
| 15:42 | <annevk> | GPHemsley: I guess if that's what implementations do it's okay |
| 15:42 | <GPHemsley> | IDK, I'll have to check |
| 16:08 | <MikeSmith> | per the outline algorithm, what text should be used as the heading for <hgroup>foo<h2>bar</h2><h3>baz</h3></hgroup> in an outline? |
| 16:09 | <MikeSmith> | just "foo"? or "foo bar"? or just "bar"? |
| 16:13 | <jgraham> | Just bar I think, although it is unclear |
| 16:20 | <MikeSmith> | jgraham: yeah |
| 16:21 | <MikeSmith> | the three existing outliner implementations I tried all emit just "bar" for that case |
| 16:22 | <MikeSmith> | which makes sense intuitively I guess |
| 16:22 | <MikeSmith> | but I can't see where the spec makes it clear that's what it should be |
| 16:23 | <MikeSmith> | or also why the should be any different handling for <h1>foo<h2>bar</h2><h3>baz</h3></h1> |
| 16:24 | <MikeSmith> | it seems to me the outline algorithm requires both of the cases to be handled exactly the same |
| 16:24 | <MikeSmith> | because hgroup and h1 are both "heading content" |
| 16:25 | <jgraham> | Well you can't get that out of the parser (h2 as a child of h1) |
| 16:25 | <MikeSmith> | but the existing outliner implementations don't handle them the same -- they handle the <h1>foo<h2>bar</h2><h3>baz</h3></h1> case by making nested sections for the h2 and h3 elements |
| 16:25 | <MikeSmith> | ah |
| 16:25 | <MikeSmith> | yeah OK |
| 16:26 | <MikeSmith> | so that part makes sense at least |
| 16:39 | <dglazkov> | good morning, Whatwg! |
| 16:40 | <Ms2ger> | Good night |
| 16:42 | <GPHemsley> | annevk: What was that pseudo-server you recommended for testing, again? |
| 16:43 | <annevk> | GPHemsley: someone might have recommended https://bitbucket.org/annevk/simpleserver I suppose? not sure I did though |
| 16:43 | <Ms2ger> | I think I mentioned it |
| 16:43 | <GPHemsley> | oh |
| 16:43 | <GPHemsley> | well, thanks nonetheless :) |
| 16:44 | <annevk> | you gonna test HTTP stuff? |
| 16:44 | <GPHemsley> | yeah |
| 16:44 | <GPHemsley> | I figured I'd write a script that builds all the test files automatically |
| 16:44 | <GPHemsley> | so I can finally make some progress |
| 16:45 | <GPHemsley> | hmm... what was the one that Mozilla uses? |
| 16:45 | <GPHemsley> | where you put headers in a separate file? |
| 16:45 | <GPHemsley> | (or is that custom?) |
| 16:46 | <Ms2ger> | That's custom |
| 16:47 | <GPHemsley> | oh, hmm... |
| 16:47 | <GPHemsley> | annevk: This would have to be modified to do what I want |
| 16:48 | <GPHemsley> | Maybe it'd be easier to just generate .htaccess files alongside the tests |
| 16:49 | <GPHemsley> | it's OK (or even good) if I include the tests and the generator script in the mimesniff repo, right? |
| 16:50 | <Ms2ger> | Sure |
| 17:13 | <TabAtkins> | GPHemsley: Was I *supposed* to inform you of pending mimetype requests? |
| 17:14 | <GPHemsley> | TabAtkins: No, we were just discussing it in here. :) |
| 17:14 | <GPHemsley> | the 'font' type specifically |
| 17:16 | <TabAtkins> | annevk: Yeah, an independent object for setting a query would be useful. It's a separable piece. |
| 17:17 | <TabAtkins> | annevk: While Maps don't set to a list, there's nothing that says your own implementation of the methods can't do that internally. The point is just to provide same-named methods with similar functionality, such that they can be used interchangeably. |
| 17:18 | <annevk> | TabAtkins: sure, I think that's already done more or less |
| 17:18 | <annevk> | TabAtkins: but apart from some missing stuff |
| 17:18 | <TabAtkins> | annevk: delete(key, val) might run into identity problems. Best think about what concept of identity you want - the tc39 guys have strong opinions about what they've gotten wrong in the past with, for example, Array#contains. |
| 17:18 | <annevk> | TabAtkins: but that seems different than what's suggested on the list |
| 17:18 | <annevk> | TabAtkins: identify problem? |
| 17:18 | <annevk> | ty* |
| 17:20 | <TabAtkins> | annevk: For example, whether NaN is equal to NaN, +0 to -0, etc. |
| 17:21 | <annevk> | key/val are converted to DOMString first |
| 17:21 | <TabAtkins> | Oh, then you're fine. No worries. |
| 17:21 | <TabAtkins> | Forgot about the type coercion. |
| 17:21 | <annevk> | it's still not really clear to me if what you're saying and what David/Boris are discussing is the same |
| 17:22 | <annevk> | and I have a hard time following terms like "subclassing" |
| 17:22 | <annevk> | does that involve me talking to heycam or does it mean to just make it look kinda the same? |
| 17:23 | <TabAtkins> | It just means that (a) it should ducktype as a Map, and (b) (new URLQuery) instanceof Map should be true. |
| 17:23 | <TabAtkins> | The latter just does prototype comparisons. |
| 17:24 | <TabAtkins> | (take proto of both sides, then walk the proto chain of lhs until you find a match or hit the root) |
| 17:24 | <annevk> | hmm, so I guess that means talking to heycam |
| 17:24 | <annevk> | heycam|away, ^^ |
| 17:24 | <TabAtkins> | Hmm, maybe. If Map was already defined in WebIDL, it would be no problem, obviously - you'd just extend it. |
| 17:29 | <annevk> | no, you can't extend it and change argument types |
| 17:45 | <TabAtkins> | You can't override methods that come from the extended interface? |
| 17:46 | <annevk> | no |
| 17:47 | <TabAtkins> | Well that's just silly. |
| 17:47 | <TabAtkins> | In that case, yeah, bug heycam for hooks. |
| 17:47 | <TabAtkins> | It would be great to have the ability to declare something as a Map or Set in the platform. |
| 17:47 | <TabAtkins> | The same way we're gradually rationalizing things to be Arrays. |
| 17:48 | <annevk> | not sure how much things are actually Arrays in the platform |
| 17:48 | <TabAtkins> | Not as much as they should be. |
| 17:48 | <annevk> | they have the same basic problem with not being tied to some underlying concept |
| 17:48 | <TabAtkins> | Hm? |
| 17:49 | <annevk> | so e.g. you get an array of path segments, then start modifying it or "copying" it around and then modifying, do you expect the URL to be modified? |
| 17:49 | <TabAtkins> | Oh, that. |
| 17:50 | <Ms2ger> | Who cares |
| 17:50 | <TabAtkins> | I'm still not sure why that's supposed to be a problem. You return an Array subclass, not a plain array. The subclass manages (in IDL prose) the necessary mutations. |
| 17:50 | <Ms2ger> | Just toss a coin |
| 17:50 | <annevk> | "gradually rationalizing" and "oh that" make me not convinced this is really a solved problem |
| 17:50 | <TabAtkins> | Bah, that was a dismissive "oh that". |
| 17:51 | <annevk> | there's no such thing as subclass |
| 17:51 | <TabAtkins> | ... |
| 17:51 | <annevk> | have you talked to heycam? |
| 17:51 | <TabAtkins> | Dude. Bro. A subclass is simply something for which "object instanceof superclass" is true. |
| 17:52 | <Ms2ger> | Sis? |
| 17:52 | <TabAtkins> | No, Anne's my bro. |
| 17:52 | <annevk> | apparently it also magically handles mutations in prose? is there any example of such an array in the platform today? |
| 17:52 | <TabAtkins> | Uh, whatever object you just talked about? |
| 17:53 | <annevk> | that was a hypothetical for something I might introduce one day if there's hooks |
| 17:55 | <TabAtkins> | So, I'm unsure what the problem is here. What do you think is weird about this? I've done precisely this kind of thing in JS code before (subclassing an array), and it's fine. |
| 17:55 | <jgraham> | Hmm, having magic internal state does sound like it has the possibility to invalidate supposed invariants of the base clas API if you're not very careful |
| 17:55 | <jgraham> | Or rather magic internal algorithms |
| 17:55 | <TabAtkins> | jgraham: You can always invalidate supposed invariants. Just... don't do it? |
| 17:56 | <jgraham> | That's supposedly easier said than done. If you believe all these "A square is not a rectangle" type articles |
| 17:56 | <Ms2ger> | Say what? |
| 17:56 | <TabAtkins> | That's cool if you're really into type safety. This is JS, man. |
| 17:57 | <TabAtkins> | Ms2ger: Strictly, a mutable square is *not* a subclass of mutable rectangle, due to the violation of implicit contracts. Immutables are, though. |
| 17:57 | <TabAtkins> | (The main contract being that you can independently mutate the width and height without affecting the other.) |
| 17:58 | <jgraham> | Ms2ger: Part of the internet is fascinated with the idea that *in OO software* a square is not a subclass of rectangle because squares impose extra invariants on the relationship between width and height |
| 17:59 | <TabAtkins> | Here in reality land, if it acts mostly the same, you're good. Just be aware of where things are different. ^^_ |
| 18:03 | <TabAtkins> | You're welcome: http://heeeeeeeey.com/ |
| 18:13 | <Stevef> | mikesmith: as per the required acc API implementation in the spec it would be <h2>foo bar baz</h2> for AT users |
| 18:16 | <MikeSmith> | Stevef: OK |
| 18:20 | <annevk> | TabAtkins: just wondering how to do it in spec language |
| 18:20 | <annevk> | TabAtkins: although an example in JS might also help |
| 18:24 | <TabAtkins> | annevk: awb just responded in that vein. |
| 18:33 | <annevk> | TabAtkins: yeah, noticed, but not the spec part, which is more important |
| 18:34 | <TabAtkins> | Yeah, if you want WebIDL, there's not a good solution yet, and you need heycam. |
| 18:35 | <TabAtkins> | If you're willing to define it in JS (I wouldn't recommend it), you can just use AWB's code. |
| 18:35 | <annevk> | so reading http://html5.org/tools/web-apps-tracker?from=7509&to=7510 it seems we're open to XSS there |
| 18:35 | <annevk> | only XSS From Hixie though |
| 18:36 | <Hixie> | (oops, that reminds me i forgot to escape those <s) |
| 18:36 | <Hixie> | why are we open to XSS? |
| 18:38 | <Hixie> | on another note |
| 18:38 | <Hixie> | annevk: are URLUtils' members going to be unforgeable on HTMLAnchorElement? |
| 18:38 | <Hixie> | annevk: or are they only to be unforgeable on Location? |
| 18:38 | <annevk> | Hixie: oh if you forgot to escape them maybe we aren't :) |
| 18:39 | <annevk> | Hixie: only on Location I think, I'm not sure how to deal with that, I tried to raise that issue when it came up, not sure if heycam|away took it into account |
| 18:39 | <Hixie> | http://html5.org/tools/web-apps-tracker?from=7510&to=7511 |
| 18:39 | <Hixie> | annevk: k |
| 18:39 | <Hixie> | heycam|away: ping |
| 18:40 | <Ms2ger> | The </pre>? |
| 18:40 | <annevk> | Hixie: worst case scenario is that you define the IDL attributes as unforgeable and just say they behave the same as on URLUtils other than IDL differences |
| 18:40 | <Hixie> | k |
| 18:40 | <Hixie> | that's what i'm currently doing wit the UAE attributes or whatever they're called |
| 18:42 | <annevk> | I was hoping we could get away with one interface somehow so whenever we upgrade it we don't have to change Location too |
| 18:42 | <Hixie> | yeah |
| 18:43 | <annevk> | oh, maybe if we really need it this way and heycam|away doesn't give another shortcut I could create LocationURLUtils as an exact duplicate which is implemented only by Location |
| 18:43 | <annevk> | or just do a partial thingy for Location |
| 18:43 | <annevk> | so whoever ends up maintaining URL (if it's not me) will take that into account |
| 18:45 | <Hixie> | UnforgeableURLUtils |
| 18:45 | <Hixie> | or partial, yeah |
| 18:46 | <Ms2ger> | Maybe we should do the unforgeable interface after all |
| 18:49 | <annevk> | Ms2ger: I guess I was in favor of that, not sure if I stressed that |
| 18:50 | <matjas> | polyglot.gif http://lists.w3.org/Archives/Public/public-markdown/2012Nov/0019.html |
| 18:56 | <Hixie> | i'm not at the office -- anyone got IE handy? |
| 18:57 | <Hixie> | http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1916 - hit the Navigate button then the Compare button and tell me what gets logged |
| 18:57 | <Ms2ger> | I've got a VM with some version |
| 18:58 | <Ms2ger> | Hixie, false |
| 18:58 | <Hixie> | cool, thanks |
| 18:58 | <Hixie> | (which version?) |
| 18:59 | <Ms2ger> | IE10 |
| 18:59 | <Hixie> | k |
| 18:59 | <Hixie> | can you try removing the doctype? |
| 18:59 | <Ms2ger> | Still false |
| 18:59 | <Hixie> | k |
| 18:59 | <Hixie> | wtf |
| 19:05 | <Hixie> | bholley: sorry, didn't notice you were here either :-) |
| 19:05 | <bholley> | Hixie: hm, interesting. Did you try mwobensmith's tests? |
| 19:05 | <bholley> | Hixie: those were the ones I tested, in a VM. Let me try again |
| 19:05 | <Hixie> | i didn't test them in IE, no |
| 19:06 | bholley | boots vmware |
| 19:06 | <Hixie> | they were scary long :-) |
| 19:06 | <bholley> | Hixie: ok, so first of all, looks like I've got IE9 |
| 19:06 | <Hixie> | does it log true on my test? |
| 19:07 | <Hixie> | that'd be interesting ifso |
| 19:07 | <bholley> | Hixie: checking |
| 19:07 | <Hixie> | in particular because changing the doctype didn't change the result |
| 19:07 | <Hixie> | though maybe it's the iframe's doctype that matters |
| 19:07 | <Hixie> | and we didn't try changing that |
| 19:07 | <bholley> | Hixie: it does log true |
| 19:07 | <Hixie> | ho ho ho |
| 19:07 | <Hixie> | interesting |
| 19:08 | <Hixie> | huh |
| 19:08 | <Hixie> | i bet they tried to implement the spec and just assumed it was right and didn't push back because for some reason they think it's ok to have different behaviours in different modes |
| 19:08 | <Hixie> | good times |
| 19:09 | <Hixie> | what's gecko's behaviour been, historically? |
| 19:09 | <bholley> | Hixie: on this issue? One Location object per Window |
| 19:09 | <Hixie> | and the motivation to change is what? security bugs? |
| 19:09 | <bholley> | Hixie: yes |
| 19:10 | <bholley> | Hixie: 16.0.1, 16.0.2 |
| 19:10 | <Hixie> | basically the difficulty of "inspect the js stack"? |
| 19:10 | <Hixie> | the way the spec has it, it should be the same kind of security check as for Document's members |
| 19:11 | <bholley> | Hixie: well, there are two issues with the spec |
| 19:11 | <Hixie> | more than two, but go ahead :-) |
| 19:11 | <bholley> | Hixie: the part that appears to be pure fiction is that Location describes the Document |
| 19:11 | <Hixie> | yeah that needs to change regardless |
| 19:11 | <Hixie> | dunno what i was testing there |
| 19:11 | <Hixie> | should be the active document of the document's browsing context |
| 19:12 | <bholley> | Hixie: so once it gets changed so that Location describes the active Document in the browsing context |
| 19:12 | <bholley> | Hixie: then we have this weirdness where the security characteristics of Location don't match everything else in its scope |
| 19:12 | <bholley> | Hixie: which is wacky for Gecko's compartment model |
| 19:12 | <bholley> | Hixie: I think we're pretty safe now TBH, because in 16.0.2 I just hardcoded the checks in C++. But that's not where security checks in Gecko are supposed to live |
| 19:13 | <Hixie> | same security model as Window, no? |
| 19:13 | <bholley> | Hixie: No, it's different |
| 19:13 | <Hixie> | what's the difference? |
| 19:13 | <bholley> | Hixie: WindowProxy |
| 19:13 | <bholley> | Hixie: that's the identity object in question, and we transplant it between compartments |
| 19:13 | <Hixie> | ah |
| 19:13 | <bholley> | Hixie: effectively, what I've been pushing to do for Location |
| 19:14 | <Hixie> | that sounds incredibly scary |
| 19:14 | <bholley> | Hixie: you could say having a LocationProxy |
| 19:14 | <bholley> | Hixie: why? |
| 19:14 | <bholley> | Hixie: the WindowProxy is just a tiny wrapper around the Window anywaty |
| 19:14 | <Hixie> | mostly because i don't understand the implications or how to spec it |
| 19:14 | <bholley> | Hixie: well, it's already specced right for Window |
| 19:14 | <bholley> | Hixie: and WindowProxy |
| 19:15 | <Hixie> | the way the spec has it, the security on WindowProxy is actually specced on Window |
| 19:15 | <bholley> | Hixie: right |
| 19:15 | <Hixie> | the Proxy aspect could be removed without affecting the security |
| 19:15 | <bholley> | Hixie: and the same would hold for Location |
| 19:15 | <bholley> | Hixie: oh, hm. Well, not in Gecko |
| 19:16 | <bholley> | Hixie: well, hm |
| 19:16 | <bholley> | Hixie: my basic beef with our current implementation is that Location wants to be two different things |
| 19:16 | <Hixie> | http://www.whatwg.org/specs/web-apps/current-work/#security-2 is how Window security is specced |
| 19:16 | <Hixie> | for Location, seems to me the simplest fix is just to make it work the same as that -- but there's no Proxy needed to do that |
| 19:16 | <bholley> | Hixie: it wants to be resolved like Document, but operate on the WIndowProxy |
| 19:16 | <Hixie> | you just need to compare the script's security context to the active document's |
| 19:17 | <Hixie> | why is it hard for an object to operate on the active document in gecko? |
| 19:17 | <Hixie> | History works like that, more or less, no? |
| 19:18 | <Hixie> | as specced, the History objects from all of the Documents in a browsing context basically act the same as each other |
| 19:18 | <bholley> | Hixie: sure. But they don't do security checks, right? |
| 19:19 | <Hixie> | they don't do "can you access this member" checks, but they do check whether the URL you're pushing is the same origin as the URL of the active document |
| 19:19 | <Hixie> | otherwise you could load a bank site and change its URL to something else |
| 19:19 | <bholley> | Hixie: the issue for us is that "can you access this member" checks are best implemented at compartment boundaries |
| 19:20 | <bholley> | Hixie: and this generally works, because for everything but Location, you can infer an object's security characteristics from its scope |
| 19:20 | <Hixie> | what's a compartment, in gecko? |
| 19:20 | <Hixie> | i don't think the spec has that concept |
| 19:20 | <bholley> | Hixie: it doesn't |
| 19:21 | <bholley> | Hixie: we have a separate JS heap for each scope |
| 19:21 | <bholley> | Hixie: and we enforce security invariants at the border between heaps |
| 19:21 | <Hixie> | how does that work with document.domain? |
| 19:22 | <bholley> | Hixie: cross-compartment access is done with special wrapper objects, which we can enumerate |
| 19:22 | <bholley> | Hixie: when someone sets document.domain, we recompute all those wrappers |
| 19:22 | <Hixie> | yikes |
| 19:22 | <bholley> | Hixie: the wrappers contain static security policy |
| 19:22 | <bholley> | Hixie: no, it's awesome! |
| 19:23 | <bholley> | Hixie: we can compute our security policy statically, when computing the wrapper |
| 19:23 | <bholley> | Hixie: all accesses after that are super fast, because there's no dynamic check needed |
| 19:23 | <bholley> | Hixie: if the security relationship ever changes, like with document.domain, we just recompute |
| 19:23 | <bholley> | Hixie: it's orthogonal enough to what everyone else does that it doesn't belong in the spec. But it's really awesome for us |
| 19:24 | <bholley> | Hixie: this also ties into document.domain revocation |
| 19:24 | <bholley> | Hixie: it's what our system does naturally, but is very difficult for WebKit to do |
| 19:24 | <Hixie> | document.domain revocation? |
| 19:25 | <bholley> | Hixie: I sent a spec proposal a while back. Basically, if some page grabs stuff from a same-origin page and then sets document.domain to something else, whether those references are revoked or not |
| 19:25 | <Hixie> | they should not be |
| 19:25 | <Hixie> | right? |
| 19:25 | <bholley> | Hixie: I proposed they should |
| 19:26 | <Hixie> | oh |
| 19:26 | <Hixie> | ew |
| 19:26 | <Hixie> | nooo |
| 19:26 | <Hixie> | if you have an object, why make it stop working? |
| 19:26 | <Hixie> | that's just confusing |
| 19:26 | <bholley> | Hixie: because it's not same-origin anymore! |
| 19:26 | <Hixie> | it's bad enough that we had to do that for document.storage |
| 19:26 | <bholley> | Hixie: and it's now exposed to all kinds of malicious stuff |
| 19:26 | <bholley> | Hixie: that it never agreed to |
| 19:27 | <bholley> | Hixie: from a security perspective, I think it would be what people would expect |
| 19:27 | <Hixie> | well i agree document.domain is a sandtrap, but this doesn't make things particularly safer. I mean, the other side now has access to your origin insofar as sending requests to your server goes, the game is more or less lost if you didn't want that. |
| 19:28 | <bholley> | Hixie: well, consider this |
| 19:28 | <Hixie> | i mean, you can just import the script you're worried about. |
| 19:29 | <Hixie> | or create an iframe that emulates the page you want access to. |
| 19:29 | bholley | CCs hixie on a bug |
| 19:29 | <bholley> | Hixie: bug 655649 comment 0 |
| 19:30 | <bholley> | Hixie: this was from abarth actually |
| 19:30 | <bholley> | Hixie: the thing is, revocation is currently specced |
| 19:30 | <Hixie> | only for storage |
| 19:30 | <bholley> | Hixie: but _only_ if you happen to touch the Window object |
| 19:31 | <bholley> | Hixie: because per spec that's the only thing that does security checks |
| 19:31 | <Hixie> | that's not revocation per se, that's just, right, where the checks are |
| 19:31 | <bholley> | Hixie: but those checks use the effective script orogin |
| 19:31 | <bholley> | *origin |
| 19:31 | <bholley> | Hixie: well, if you have a reference to a Window, then it is revocation, because it stops working |
| 19:31 | <bholley> | Hixie: but if you have a reference to a DOM node, it doesn't stop working |
| 19:32 | <bholley> | Hixie: and you can waltz your way around the DOM, so long as you avoid touching any of the objects that will reexamine the script origin |
| 19:32 | <bholley> | Hixie: it's totally unintuitive |
| 19:32 | <Hixie> | i agree it's pretty silly, but hey, it's the web. document.domain is a bad feature, and people shouldn't use it. but it's far too late to start changing how it works, IMHO. |
| 19:33 | <bholley> | Hixie: well, Opera and Gecko ship full revocation |
| 19:33 | <bholley> | Hixie: against the spec |
| 19:33 | <Hixie> | :-( |
| 19:34 | <jwalden> | and note that Gecko didn't ship full-revocation until semi-recently |
| 19:34 | <jwalden> | so the position in the spec here is not particularly important for the web |
| 19:34 | <Hixie> | anyway as far as Location goes, it'd be nice to have a solution that is both implementable in Gecko's model and implementable in the spec's model without introducing more crazy stuff like the WindowProxy object |
| 19:35 | <bholley> | Hixie: yeah. I agree that we should spec align on security stuff. But fixing this requires would require me adding a bunch of goop to our security code to specifically waive security checks in this particular situation, which never seems like an attractive thing to spend my time on |
| 19:35 | <Hixie> | yeah this whole part of the platform isn't particularly fun to work on :-) |
| 19:35 | <Hixie> | either in code or in the spec, let me assure you |
| 19:36 | <bholley> | Hixie: :-)I |
| 19:36 | <Hixie> | how do you handle giving scripts access to Document objects but not any properties of Document objects? |
| 19:37 | <Hixie> | for cross-origin Documents |
| 19:37 | <bholley> | Hixie: they just get an opaque wrapper |
| 19:37 | <bholley> | Hixie: that allows no property access |
| 19:37 | <bholley> | Hixie: actually, _all_ cross-origin references use the same wrapper |
| 19:37 | <bholley> | Hixie: er, same policy |
| 19:38 | <bholley> | Hixie: which just does this: http://mxr.mozilla.org/mozilla-central/source/js/xpconnect/wrappers/AccessCheck.cpp#155 |
| 19:38 | <bholley> | Hixie: (when trying to access properties on it) |
| 19:40 | <bholley> | Hixie: to be honest, depending on how much work it is for WebKit to reuse its WindowProxy logic, it might be easier for us to align with WebKit than the reverse |
| 19:40 | <Hixie> | so basically your problem is you don't have a good way to get "the entry script's effective script origin" for the purpose of comparing to other origins? |
| 19:41 | <bholley> | Hixie: no, we can do that. And I actually did that, for 16.0.2 |
| 19:41 | <bholley> | Hixie: it just runs contrary to the way everything else works |
| 19:42 | <Hixie> | can it be localised enough that you can just but big "here by dragons, don't copy this code into newer APIs" warnings around it or something? |
| 19:42 | <Hixie> | if it's not much work for you to do that, i'm definitely leaning towards that kind of approach rather than a proxy |
| 19:43 | <Hixie> | mostly because i don't have a good handle on how to reason about the security of a proxy |
| 19:43 | <Hixie> | and thath scares me |
| 19:43 | <bholley> | Hixie: we can do that, sure. But I'd like to convince you that the proxy isn't actually scary |
| 19:43 | <Hixie> | nobody's managed that yet for WindowProxy, but i'm definitely open for you trying :-) |
| 19:44 | <bholley> | Hixie: well, do you find WindowProxy scary? |
| 19:44 | <Hixie> | i consider WindowProxy to be one of the most horrific things in the web platform :-) |
| 19:44 | <Hixie> | it gives me headaches whenever i try to understand what a test should do |
| 19:45 | <Hixie> | i got the security for it working mostly by making the security not involve the proxy |
| 19:45 | <bholley> | Hixie: exactly |
| 19:45 | <bholley> | Hixie: the same would apply for Location |
| 19:45 | <bholley> | Hixie: all I'm proposing is that we say that window.location returns a LocationProxy rather than a Location |
| 19:45 | <bholley> | Hixie: that has the same behavior as WindowProxy |
| 19:46 | <bholley> | Hixie: the security isn't affected from a spec level. It just lets us implement it the way we want |
| 19:46 | <bholley> | Hixie: basically, saying that LocationProxy === WindowProxy.location, whatever that may be at the moment |
| 19:46 | <Hixie> | so why is this not a problem for History? |
| 19:47 | <Hixie> | because the security checks are in the members, not the accessing of the members? |
| 19:47 | <bholley> | Hixie: Yes. Again, we can (and did!) just stick C++ security checks in the getters/setters |
| 19:48 | <bholley> | Hixie: but then, for example, those properties can be enumerated, which they aren't in the current world |
| 19:48 | <Hixie> | (i understand that you can do both but one is nicer, i'm just trying to work out why you're not going to later say we should have HistoryProxies) |
| 19:48 | <bholley> | Hixie: also, history is simple because it's not cross-origin accessible |
| 19:51 | <bholley> | Hixie: I think speccing this stuff isn't that hard. IMO the biggest issue is that it's hard from WebKit to implement, and abarth says he isn't likely to do it |
| 19:51 | <bholley> | which is understandable |
| 19:51 | <bholley> | Hixie: given the testing we did, jst decided that we should just align with Presto/Trident for the time being |
| 19:52 | <bholley> | Hixie: since it makes things nicer for us, and we're not really close to spec consensus at this point |
| 19:52 | <Hixie> | that's definitely a concern, though not one which i give much more weight than your opinion regarding the complexity it adds to your code |
| 19:52 | <Hixie> | that=abarth's comments about webkit |
| 19:52 | <bholley> | Hixie: but the IE10 thing is interesting |
| 19:52 | <Hixie> | yeah the IE10 thing definitely puts more spice into the discussion |
| 19:52 | <bholley> | Hixie: if Gecko were the only engine that did things our way, I'd align with the spec |
| 19:52 | <bholley> | Hixie: I don't think the same is true for WebKit |
| 19:52 | <annevk> | Ms2ger or Ms3ger: can we make Anolis match on both word plus trailing "s" and word minus trailing "s"? |
| 19:53 | <abarth> | bholley: it's just a cost benefit issue. the engineering you're asking for is highly non-trivial |
| 19:53 | <annevk> | Ms2ger or Ms3ger: because that would save a lot of typing (and fixing) |
| 19:53 | <Hixie> | bholley: i don't give much weight to arguments along the lines of "even if we're the only ones left, we'll never change!", because i feel that's more like hostage taking than negotiation. |
| 19:53 | <Hixie> | bholley: but i don't think that's what webkit peeps are saying |
| 19:53 | <Hixie> | oh hey, a wild abarth appears! |
| 19:54 | <bholley> | abarth: I understand, and am not blaming you |
| 19:54 | <bholley> | abarth: we'd do it because the engineering on our side would likely be simpler |
| 19:54 | <abarth> | bholley: if you wrote a patch that implement the behavior, i'd be happy to review it. I'm just being honest and telling you that the folks with the expertise to make such a change aren't likely to see enough benefit to outweigh the other things they could spend their time on |
| 19:54 | <Hixie> | bholley: ignoring implementation complexity for now, since it seems that argument can be drawn in all directions (especially given IE10), it does seem like from an author's perspective the proxy thing would be net worse than having different Location objects for each Document |
| 19:55 | <bholley> | Hixie: how come? |
| 19:55 | <Hixie> | bholley: well, say you have a Document, and you grab it's Location and decide you're going to shim in support for anne's new methods |
| 19:56 | <Hixie> | bholley: and then later you navigate that iframe to a different page on the same origin |
| 19:56 | <Hixie> | bholley: suddenly your shims are gone |
| 19:56 | <Hixie> | bholley: but it's the "same object" |
| 19:56 | <Hixie> | bholley: then the user hits back, and your shims are suddenly back |
| 19:56 | <Hixie> | bholley: i think it'd be really confusing |
| 19:56 | <bholley> | Hixie: no, they're not back |
| 19:56 | <Hixie> | they'd be back if it worked like Window |
| 19:56 | <Hixie> | but if tehy're not back that's even more confusing :-) |
| 19:56 | <bholley> | Hixie: my proposal was to clear expandos on each navigation, which seemed the most sane |
| 19:57 | <Hixie> | i meant changes to the Location interface object, not the instance |
| 19:57 | <bholley> | Hixie: oh, the interface object would stay, yeah |
| 19:57 | <Hixie> | permanently clearing the properties set on the object seems bad too, though |
| 19:58 | <bholley> | Hixie: welll... |
| 19:58 | <bholley> | Hixie: currently, if you go back/forward, whether your properties persist on Window or not depends on whether the page persisted |
| 19:59 | <bholley> | Hixie: though I guess in this case we're only discussing the persisted case |
| 20:00 | <Hixie> | bholley: having the Window object's prototype chain change when you navigate is weird enough, having a Location object change when you navigate seems even worse |
| 20:00 | <Hixie> | bholley: if it wasn't for implementation ease, do you agree that we wouldn't design the API this way? |
| 20:02 | <bholley> | Hixie: well, I think the current spec language is the sanest way to design the API |
| 20:02 | <bholley> | Hixie: once we're stuck with the constraint that the object operates on the active browsing context…iunno |
| 20:02 | <bholley> | Hixie: but I am not the expert on that part |
| 20:03 | <Hixie> | i think officially i'm supposed to be, but hell if i know |
| 20:03 | <bholley> | Hixie: (API design for web authors) |
| 20:04 | <Hixie> | i think i'm leaning towards the webkit model, but i hope you don't feel i'm ignoring your feedback here. it just seems that the arguments are slightly in that direction. |
| 20:05 | <Hixie> | i'll respond to the thread in more detail this afternoon. |
| 20:05 | <bholley> | Hixie: I don't feel that way. I'm probably not the best person to be thinking about this from a spec level though. Can we send mail and let bz weight in? |
| 20:05 | <bholley> | Hixie: ok great |
| 20:05 | <Hixie> | definitely always want more input from bz :-) |
| 20:06 | <Hixie> | ok i gotta go. bbl. thanks for walking me through this. |
| 20:06 | <bholley> | Hixie: no problem - thanks for your help/interest here :-) |
| 20:09 | <annevk> | oh browsers, y u silly |
| 20:09 | <annevk> | input http://%80 |
| 20:10 | <annevk> | Chrome: fatal error, nonetheless modifies input to http://%EF%BF%BD/ |
| 20:10 | <annevk> | Safari: no problem, but outputs host as � (presumably trying to decode byte using utf-8) |
| 20:11 | <annevk> | Firefox: no problem, outputs host as %80 |
| 20:11 | <annevk> | Opera: fatal error, with its usual weird opera:illegal-url-* bullshit |
| 20:12 | <annevk> | I suspect Internet Explorer does something else, but who knows |
| 20:21 | <annevk> | but if input is http://%80† |
| 20:22 | <annevk> | Opera: no problem, xn--%80-mp0a |
| 20:22 | <annevk> | Safari: no problem, but same problem, outputs xn--�-mp0a |
| 20:23 | <annevk> | Chrome: fatal error, same problem, http://%EF%BF%BD%E2%84%A2/ |
| 20:23 | <annevk> | oops, http://%EF%BF%BD%E2%80%A0/ |
| 20:23 | <annevk> | Firefox: no problem, outputs xn--%80-mp0a |
| 20:24 | <a-ja> | IE10: This page can't be displayed (for http://%80 ) |
| 20:26 | <annevk> | a-ja: ah yeah, you need to use some kind of inspector thingie in the DOM for results |
| 20:27 | <a-ja> | IE10: Windows cannot find 'http://%80†'. Check the spelling and try again.....in an Address Bar popup |
| 20:30 | <annevk> | a-ja: use http://dump.testsuite.org/url/inspect.html |
| 20:33 | <annevk> | a-ja: the URLs themselves don't resolve in this case, the question is more what happens with them in the DOM and what kind of DNS lookup might happen in the end |
| 20:33 | <a-ja> | tool wont take addy with † |
| 20:34 | <annevk> | not sure what you mean? |
| 20:36 | <a-ja> | using that tool with http://%80† url typed in gives me nada |
| 20:37 | <annevk> | ah okay, thanks |
| 21:01 | <annevk> | hmm, Opera's display of IDNA versus non-display of IDNA leaks into the DOM |
| 21:02 | <annevk> | %C3%A0 becomes é and %C3%A0% becomes xn--%-rfa |
| 21:03 | <annevk> | oh, but %41% is an invalid URL |
| 21:03 | <annevk> | wtf Opera |
| 22:03 | <annevk> | looks like denying U+FFFD might be http://tools.ietf.org/html/rfc3454#appendix-C.6 |
| 22:03 | <annevk> | which is via various references part of IDNA2003 |
| 22:18 | heycam | must be missing some context because he doesn't know what annevk and TabAtkins were talking about earlier re arrays, maps, and things |
| 22:19 | <heycam> | Hixie, pong |
| 22:19 | <annevk> | heycam: for ES6 Map, have a way to subclass that including overriding argument types |
| 22:20 | <annevk> | heycam: for ES Array, have a way to subclass that in similar manner, so you can e.g. do url.segments[2] = "partOfPath" (which will get some pre-processing on setting and affects the url object) |
| 22:20 | <heycam> | annevk, we do? |
| 22:21 | <heycam> | oh sorry, I accidentally a word |
| 22:21 | <heycam> | the whole thing with subclassing arrays, I was kind of waiting for the ES spec to make that possible before trying something like that |
| 22:22 | <annevk> | heycam: http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Nov/0235.html |
| 22:22 | <annevk> | heycam: I see, TabAtkins tells me it's already possible... |
| 22:22 | <heycam> | I am out of date then! |
| 22:22 | <annevk> | well or TabAtkins is in the future |
| 22:22 | <heycam> | ha |
| 22:23 | heycam | wonders what it would mean to call the proto's get/set on a subclassed map |
| 22:24 | <annevk> | I'm a little sceptic there's a lot of value to be gained here, but who knows |
| 22:24 | <heycam> | what API is this wanted for btw? |
| 22:25 | <annevk> | Map is wanted for URLQuery: http://url.spec.whatwg.org/#urlquery |
| 22:25 | <annevk> | Array might be wanted for non-existing URLSegments or some such |
| 22:27 | <annevk> | heycam: oh, and if you're short on things to do, there's a question on "throw" in https://www.w3.org/Bugs/Public/show_bug.cgi?id=19110 and one on optional arguments versus dictionaries in https://www.w3.org/Bugs/Public/show_bug.cgi?id=19646 |
| 22:27 | <heycam> | annevk, would URLQuery.set do some validation on the value you pass in? so it doesn't contain a "&" character or something? |
| 22:27 | <heycam> | shorrt on things to do, right :) |
| 22:28 | <annevk> | heycam: it would probably transform certain characters |
| 22:28 | <annevk> | heycam: percent encode them or some such |
| 22:28 | <heycam> | so I am wondering whether subclassing is the right relationship for the URLQuery, if we want to prevent certain characters from getting into the map without being transformed |
| 22:29 | <heycam> | we probably want to use the same interface as Map, but not be a subclass of Map -- more like we want to wrap an internal map that you can't get to |
| 22:30 | <heycam> | sorry to do this to you, but would you mind mailing or filing a bug about the Map thing? |
| 22:31 | heycam | will work on a few webidl bugs later this week -- I'll put the above bugs 19110 and 19646 on my list to do |
| 22:31 | <annevk> | heycam: yeah can do (I'm not really sure subclassing Map is the right solution either, maybe I'll post to the whatwg list about it again with some of the requirements and see if that makes it still a good approach) |
| 22:31 | <annevk> | heycam: ta |
| 22:32 | <heycam> | yeah if you can tease those things out first before I plunge into doing Map stuff in the spec, that would be good |
| 22:44 | <TabAtkins> | heycam: The reason to subclass Map is to, well, have a Map. So people with code that expects to take a Map can do the obvious test (foo instanceof Map) and have it work correctly. |
| 22:44 | <TabAtkins> | heycam: AWB has JS code on the thread in WHATWG about how you would do it in ES5 or in ES6-with-classes. |
| 22:44 | <TabAtkins> | heycam: It's pretty trivial. |
| 22:45 | <heycam> | does it matter that calling Map.__proto__.set on the subclassed map will subvert the argument checking? |
| 22:45 | <heycam> | er |
| 22:45 | <heycam> | Map.prototype.set |
| 22:46 | <TabAtkins> | I recommend *actually* setting a hidden internal Map, so it's safe from outside manipulation. |
| 22:46 | <heycam> | TabAtkins, ok. but we would still have the outer one being a real Map, even though it doesn't use its Map-ness? |
| 22:47 | <TabAtkins> | Yes. The Map-ness is used for type checks, mostly. |
| 22:47 | <TabAtkins> | Or only, I guess. |
| 22:47 | <heycam> | so I could imagine code that expects, if it is "instanceof Map", that calling Map.protoype.get on it will do something useful |
| 22:47 | <TabAtkins> | But still, when I need to distinguish code-paths by type, I use instanceof checks. Having DOM types pass the most appropriate basic ES type is useful. |
| 22:48 | <TabAtkins> | ...why would anyone do that, rather than just calling get on the object itself? |
| 22:48 | <heycam> | well I don't know, but it seems like something that should work if an object "is a Map" |
| 22:48 | <heycam> | I guess it comes down to what you think "instanceof Map" implies |
| 22:49 | <TabAtkins> | That sort of thing only makes sense in general if you are *actually* a Map, not a subclass of. |
| 22:49 | <TabAtkins> | You must assume that subclasses have overridden the methods with something useful. |
| 22:49 | <TabAtkins> | instanceof implies that Map's prototype is *somewhere* in your object's prototype chain. |
| 22:50 | <heycam> | sure, but that doesn't mean that calling .get() on the object will do you want either |
| 22:50 | <heycam> | it *probably* will... |
| 22:50 | <TabAtkins> | If it doesn't act more-or-less like a Map, then you've obviously broken the type contract and deserve pain. |
| 22:51 | <TabAtkins> | URLQuery does indeed act like a Map. It just coerces its key and value to strings first. |
| 22:51 | <heycam> | I guess I was thinking that calling Map.prototype.get on it is something that is part of the contract |
| 22:51 | <TabAtkins> | That seems like a silly thing to expect. ^_^ It basically assumes that the object never overrides any of the superclass's methods. |
| 22:52 | <TabAtkins> | It's true if you subscribe to the very strictest idea of when it is appropriate to "subclass" (when the subclass is *literally indistinguishable* from the superclass, using operations that the superclass provides), but not in most of the real world. |
| 22:53 | <heycam> | right, that is how I was thinking about it |
| 22:53 | <TabAtkins> | Normal people don't think about it that way. ^_^ |
| 22:53 | <heycam> | ha |
| 22:54 | <heycam> | to me, it feels like you want to state that URLQuery implements a Map interface, and that the JS Map object is actually a concrete class |
| 22:54 | <heycam> | but that's not really how JS works |
| 22:54 | <TabAtkins> | That's an acceptable definition of "subclass" in JS terms. |
| 22:55 | <TabAtkins> | If you pretend that objects can only have a single interface. ^_^ |
| 22:55 | <TabAtkins> | (A proper interface system would be very welcome, but doesn't exist as of yet.) |
| 22:55 | <heycam> | the end result of this is that you need to be careful about defining what happens when you do call the super methods on your subclassed object |
| 22:55 | <heycam> | but if that's the way things are, ok |
| 22:58 | <heycam> | TabAtkins, it does seem a bit funny to subclass Map only to not use its Mapness, but to have a hidden Map instance that it forwards calls to though |
| 22:58 | <TabAtkins> | If JS had a better way to type-check (or rather, interface-check), I'd advocate that, instead of overloading subclassing to achieve it. :/ |
| 22:58 | TabAtkins | is partial to branding with Symbols. |
| 22:59 | <heycam> | yeah it's kind of a hack to inherit from Map just to make your own object look like a Map |
| 23:01 | <TabAtkins> | We should probably ping es-discuss explicitly about this, actually. |
| 23:01 | <TabAtkins> | So we're not just making decisions based on what I think is best. |
| 23:01 | <heycam> | :) |
| 23:01 | TabAtkins | goes to do it. |
| 23:01 | <heycam> | cool |
| 23:08 | <zewt> | duck typing tends to make more sense than actual inheritance, unless the interface is actually meant as a base class |
| 23:09 | <zewt> | i guess that depends on whether you care about having messing around with the prototype of Map work here too |
| 23:09 | <Hixie> | heycam: so Location has a bunch of members that need to be [Unforgeable], but Anne is planning on providing me an interface that I am to import using "Location implements ..." that also need to be unforgeable. |
| 23:10 | <Hixie> | heycam: do you wish to support this natively in webidl or should we just put the annotation on each attribute? |
| 23:10 | <TabAtkins> | zewt: Yeah, that's what I'm typing up in this question to es-discuss. |
| 23:10 | <heycam> | Hixie, so all the members on this imported interface are unforgeable? or just some? |
| 23:10 | <heycam> | Hixie, and are they meant to be unforgeable on one object but not another? |
| 23:12 | <Hixie> | yeah, they'll be forgeable on HTMLAnchorElement |
| 23:12 | <Hixie> | annevk: ^ |
| 23:12 | <Hixie> | annevk: are they all unforgeable? |
| 23:13 | <heycam> | Hixie, so maybe you need a way on the implements statement to indicate which (or that all) of them are unforgeable |
| 23:13 | <heycam> | [Unforgeable] Location implements Blah; or [Unforgeable=foo1,foo2] Location implements Blah; |
| 23:13 | <Hixie> | could do that, yeah |
| 23:14 | <annevk> | Hixie: I thought there was some requirement for them to all be unforgeable? |
| 23:14 | <annevk> | Hixie: but I don't know the specifics |
| 23:15 | <Hixie> | ok let's assume it's all of them |
| 23:15 | <Hixie> | and all on Location, too |
| 23:15 | <Hixie> | as well as valueOf |
| 23:15 | <annevk> | TabAtkins: URLQuery has get/getAll(), might want add(), and set() does something special with the value |
| 23:16 | <heycam> | if that's the case then we could just stick [Unforgeable] on interface Location and make that mean all its members are, even if they're from an "implements" |
| 23:16 | <TabAtkins> | heycam: Sent the email. |
| 23:16 | <Hixie> | heycam: i think it'd be better to just have it on the Location interface and have it mean that everything is unforgeable, including any "implements"-imported members |
| 23:16 | <heycam> | TabAtkins, great! |
| 23:16 | <Hixie> | heycam: right |
| 23:16 | <heycam> | :) |
| 23:16 | <Hixie> | heycam: ok |
| 23:16 | <Hixie> | heycam: i'll assume that then. thanks. :-) |
| 23:16 | <heycam> | Hixie, there are still other attribute-specific [Unforgeable] things yes? |
| 23:16 | <annevk> | TabAtkins: get/getAll() probably need to do something special with the argument too |
| 23:16 | <heycam> | so we can't get rid of that? |
| 23:17 | <Hixie> | heycam: yeah, e.g. in particular Document.location :-) |
| 23:17 | <heycam> | ha yes ok :) |
| 23:17 | <annevk> | TabAtkins: to deal with percent-encoding and such |
| 23:17 | <TabAtkins> | annevk: Yeah, whatever we do for set() should have similar implications for the other methods. |
| 23:18 | <annevk> | TabAtkins: I just wonder what the benefit is of it being a subclass at that point |
| 23:18 | <TabAtkins> | The fact that it massages its inputs doesn't change the fact that it acts just like a Map, and most generic Map-manipulating functions would be able to use it without trouble. |
| 23:18 | <TabAtkins> | And if that's the case, you want it to be reasonably robust against type-checking. |
| 23:19 | <annevk> | doesn't the get/getAll thing make it not like a map? |
| 23:19 | <TabAtkins> | Nope, if you interact solely through the Map methods, it's just like a normal Map. |
| 23:19 | <annevk> | and that the underlying string is an ordered list of key/value pairs which can have duplicate keys? |
| 23:20 | <annevk> | the duplicate keys are significant |
| 23:20 | <heycam> | Hixie, do we have anything currently that requires toString and/or valueOf to be unforgeable on Location? |
| 23:21 | <TabAtkins> | annevk: Yeah, that's fine. Generic Map-manipulating functions will probably not see the duplicate entries, but that's okay. |
| 23:21 | <annevk> | then they can't handle typical <form> scenarios... |
| 23:22 | <TabAtkins> | annevk: That's fine. No duplicate keys is also common, after all. It's fine to have some cases fail when passed to generic code. |
| 23:22 | <annevk> | I see |
| 23:22 | <annevk> | well, heycam, still want that email? |
| 23:22 | <annevk> | I guess you do |
| 23:23 | annevk | will write it later |
| 23:23 | <heycam> | yeah. thanks. |
| 23:23 | <TabAtkins> | Hopefully ES will sprout a core MultiMap soonish (after impls get Map implemented), so URLQuery can change to being that instead. |
| 23:23 | <TabAtkins> | (with MultiMap being a subclass of Map) |
| 23:25 | <heycam> | Hixie, https://www.w3.org/Bugs/Public/show_bug.cgi?id=20008 for the [Unforgeable] thing |
| 23:35 | <annevk> | heycam: fwiw, you already reached that conclusion before: http://lists.w3.org/Archives/Public/public-script-coord/2012JulSep/0153.html |
| 23:36 | <heycam> | man what a short memory I have |
| 23:36 | <heycam> | but a consistent one at least? :) |
| 23:36 | <annevk> | I think that's why I never replied to that thread to say we need it for URLUtils |
| 23:37 | <annevk> | heycam: hopefully this time it ends up in the spec :p |
| 23:37 | <heycam> | yeah. unfortunately I don't have a page like Hixie's showing which mails to the list I've dealt with yet. (although I would reply on the thread when I have...) |
| 23:42 | <Hixie> | heycam: you mean does the spec say that yes? if so, not to my knowledge. |
| 23:42 | <Hixie> | s/yes/yet/ |
| 23:43 | <heycam> | Hixie, ok. seems in that mail annevk linked to I already said that should be implied by [Unforgeable] on the interface. |
| 23:43 | <Hixie> | annevk: that time, heycam thought he'd be able to remove the one on members as well |
| 23:43 | <Hixie> | annevk: this time, we're talking about just adding a new feature, leaving the old one |