| 01:45 | <MikeSmith> | cabanier: so I reckon if I keep helping with preparation for this 2dcontext LCWD it's likely to end up costing me a full day of time I'd rather have spent working on other things that I actually care about |
| 02:04 | <cabanier> | MikeSmith: sorry... |
| 08:36 | <hsivonen> | oh the annoyance of running irssi and bugzilla on the same host an a naive bugzilla installation being so prone to DoS |
| 09:01 | <zcorpan> | woah https://www.w3.org/Bugs/Public/show_bug.cgi?id=25478#c15 |
| 09:02 | <zcorpan> | MikeSmith: are you ok? |
| 09:07 | <MikeSmith> | zcorpan: yeah. sorry about that comment |
| 09:08 | <zcorpan> | if you refuse to implement the change in v.nu that seems like a useful data point, but it was a bit hidden behind the rage :-P |
| 09:10 | <zcorpan> | what happened with http://static.guim.co.uk/sys-images/Guardian/About/General/2011/7/14/1310661708437/LulzSec-logo-001.jpg ? :-) |
| 09:18 | <MikeSmith> | zcorpan: point taken :) |
| 09:20 | <MikeSmith> | zcorpan: I was experimenting with trying out my alternate "rage persona" |
| 09:20 | <zcorpan> | MikeSmith: ok, that's cool |
| 09:20 | <zcorpan> | i'm not complaining i was just surprised |
| 09:20 | <MikeSmith> | but I think we can agree the experiment failed |
| 09:23 | <tobie> | darobin not being around, would appreciate review/comments for my pull request adding MapClass support to the WebIDL parser: https://github.com/darobin/webidl2.js/pull/10. Anyone? |
| 09:25 | <MikeSmith> | tobie: I can look at it in 4 hours or so, if nobody gets to it first. On my mobile now |
| 09:25 | <tobie> | ^ ty MikeSmith |
| 09:31 | <annevk> | mathiasbynens: not sure APIs for encodings are suitable for base64 |
| 09:43 | <JonathanNeal> | Hello! |
| 09:46 | <mathiasbynens> | annevk: i meant separate APIs |
| 09:46 | <mathiasbynens> | one like atob/btoa for base64{en,de}coding ASCII or octets in “binary strings” |
| 09:47 | <mathiasbynens> | and then something like TextEncoder to turn any plain Unicode string into such “binary strings” |
| 09:47 | <mathiasbynens> | or does that not make sense? |
| 10:00 | <annevk> | mathiasbynens: does |
| 10:01 | <annevk> | mathiasbynens: well, TextEncoder is scalar values to bytes |
| 10:02 | <mathiasbynens> | annevk: did you see http://esdiscuss.org/topic/native-base64-utility-methods? |
| 10:02 | <annevk> | mathiasbynens: yes |
| 10:02 | <mathiasbynens> | the counter-argument there seems to be that base64('any string') should work |
| 10:03 | <mathiasbynens> | but if you encode the string first, atob/btoa seem sufficient |
| 10:03 | <annevk> | atob and btoa are not going anywhere |
| 10:03 | <annevk> | mathiasbynens: I don't understand "(but it requires ArrayBuffer / Uint8Array)" |
| 10:06 | <mathiasbynens> | annevk: good point, that’s not an issue at all (i didn’t realize these things were now defined in the ES draft rather than a separate document) |
| 10:14 | <MikeSmith> | https://www.w3.org/Bugs/Public/show_bug.cgi?id=24382#c22 is interesting |
| 10:28 | <tobie> | MikeSmith: yeah, that lets broadcasters easily add targeted HTML overlays and the like. Good thing I don't watch TV. |
| 13:12 | <zcorpan> | Hixie: would it be worthwhile to set up a hook for regenning the spec and committing in svn whenever my `source` changes? |
| 13:51 | <annevk> | Where did zcorpan go? |
| 13:55 | <annevk> | Domenic_: what was the proper way to talk again about an initial property value in ECMAScript |
| 13:55 | <annevk> | Domenic_: e.g. you want to invoke the Event() constructor, but not one overwritten by a page |
| 14:39 | <Domenic_> | annevk: well, the "proper" (Allen-style) way is to define a per-realm %Event% intrinsic and refer to that instead. But I think "using the initial value of the Event constructor for this realm [or top-level browsing context]" seems good. |
| 14:40 | <Domenic_> | The intrinsics approach is kind of nice for implementers, I would imagine, as it gives them a clear list of things that need to be saved away for use later. |
| 14:40 | <annevk> | heh, one day once IDL is maintained we should just make it have a good <dfn> for that |
| 14:40 | <Domenic_> | I'll add it to the jsidl issue just so I don't forget it... |
| 14:52 | <annevk> | Domenic_: cool |
| 15:21 | <JonathanNeal> | Any movement happening on query and queryAll? http://dom.spec.whatwg.org/#dom-parentnode-query |
| 15:23 | <Domenic_> | Implementations need to support ES6 subclassing first |
| 15:23 | <Domenic_> | BUT I think they could just return arrays for now |
| 15:23 | <Domenic_> | Also: https://github.com/barberboy/dom-elements |
| 15:24 | <arunranga> | Hi Domenic_ :) In your opinion, in lieu of AbortableProgressPromise for operations like move, what should be used? http://w3c.github.io/filesystem-api/Overview.html#the-directory-interface |
| 15:25 | <Domenic_> | arunranga: just Promise seems fine... |
| 15:26 | <arunranga> | That’s what I thought. |
| 15:27 | <JonathanNeal> | Domenic_: what do you mean by subclassing? Are you referring to the live-ness of query/All? |
| 15:27 | <zewt> | mathiasbynens: there was discussion already for using TextEncoder/TextDecoder for base64 on the list, seems like the right thing to do |
| 15:27 | <Domenic_> | JonathanNeal: no, not at all. I mean support for subclassing implementation-provided classes. In particular, ES6 Symbol.create support is necessary. |
| 15:27 | <arunranga> | Next question, and sorry if I’ve missed past communication about this, but is https://dvcs.w3.org/hg/streams-api/raw-file/tip/Overview.htm the new-and-better/more recent flavor of https://github.com/whatwg/streams ? |
| 15:28 | <JonathanNeal> | Domenic_: wow, no idea what those are. Things to learn. |
| 15:28 | <Domenic_> | It's in my blog post queue... Symbol.create and the subclassable built-ins it enables are my favorite thing, but it needs more publicity. |
| 15:29 | <Domenic_> | arunranga: nope, other way around. |
| 15:29 | <arunranga> | Domenic_ ahh, ok. The “date” on the editor’s draft at the w3.org URL is probably just auto-updated then. |
| 15:29 | <Domenic_> | arunranga: oh interesting |
| 15:30 | <Domenic_> | yeah I guess so, huh. https://dvcs.w3.org/hg/streams-api/ |
| 15:30 | <arunranga> | I think respec.js has a date updater, and this makes it look like the w3.org spec is updated as of today-ish. |
| 15:30 | <arunranga> | OK well, I’m glad I asked :-) |
| 15:30 | <Domenic_> | :) |
| 16:01 | <mathiasbynens> | zewt: “the list” meaning es-discuss? |
| 16:29 | <tyoshino____> | Right. Sorry for confusing. W3C version is suspended. I'm a co-editor for it. We are working together with Domenic_ at WHATWG github now. |
| 16:29 | <tyoshino____> | re: Streams |
| 17:00 | <zewt> | mathiasbynens: whatwg or webapps |
| 17:19 | <Hixie> | zcorpan: the problem with such a hook is that it would jam in my half-complete changes as well :-) |
| 17:19 | <Hixie> | zcorpan: however if you ever make changes that aren't reflected within 24 hours, ping me |
| 17:27 | <jgraham> | Hixie: Surely the solution to that is to have your thing create a copy of his input, and his thing use the last copy rather than the current file |
| 17:27 | <jgraham> | Er |
| 17:27 | <jgraham> | Your thing create a copy of your input |
| 17:28 | <Hixie> | it does. |
| 17:28 | <Hixie> | but sometimes i do this: |
| 17:29 | <Hixie> | 1. create edit |
| 17:29 | <Hixie> | 2. regen |
| 17:29 | <Hixie> | 3. edit the edit, but it's in a poorer state now (e.g. bad markup) |
| 17:29 | <Hixie> | 4. go to sleep |
| 17:29 | <Hixie> | if zcorpan triggers a thing then, then you either blow away my step 1 changes, or inject my step 3 changes |
| 17:30 | <Hixie> | i guess i could make a copy of the copy when i regen |
| 17:30 | <Hixie> | i'll have to add something like that when i get to that part of my new pipeline |
| 17:30 | <Hixie> | right now i'm still just building the HTML parser :-) |
| 17:30 | <Hixie> | (only doing it in my free time, so...) |
| 17:31 | <Domenic_> | rebuilding Git on top of svn, one step at a time. |
| 17:33 | <jgraham> | Yeah, it does seem like yor problem would be solved by correct use of a VCS |
| 17:33 | <jgraham> | But in the absence of that, I don't understand why making a copy duing step 2 wouldn't work |
| 17:34 | <jgraham> | If zcorpan caused a new build it would be based on the step 2 copy |
| 17:35 | <SamB> | Hixie: What, no test instance or anything? |
| 17:35 | <Hixie> | i like to live on the edge, man! |
| 17:35 | <Hixie> | jgraham: yeah, it could work |
| 17:42 | <Hixie> | anyone know Frederik S (fs⊙oc)'s last name? |
| 17:42 | <Ms2ger`> | "W3C Invites Implementations of W3C DOM4" |
| 17:42 | <Ms2ger`> | Hixie, presumably "S" |
| 17:44 | <Hixie> | well that's always possible i guess |
| 17:44 | <mathiasbynens> | Hixie: Fredrik Söderquist |
| 17:45 | <Hixie> | thanks! |
| 17:54 | <Hixie> | MikeSmith: you around? |
| 18:33 | <TabAtkins> | Hixie: Yeah, drop @global. (I saw you already have, just supporting the decision.) If we need something like it, we'll define it in Scoping ourselves. |
| 18:33 | <Hixie> | k. thanks. |
| 18:55 | <Hixie> | uh |
| 18:55 | <Hixie> | can someone come up with a demo that shows firefox setting FocusEvent.relatedTarget to something other than 'null'? |
| 18:57 | <Ms2ger`> | Hixie, initFocusEvent? :) |
| 19:02 | <Ms2ger`> | But smaug____ can probably find a case |
| 19:05 | <tobie> | Is [Constructor((Foo or [EnsureUTF16] DOMString))] valid WebIDL. I think not from reading the spec. Can someone confirm? http://heycam.github.io/webidl/#EnsureUTF16 |
| 19:06 | <smaug____> | Hixie: focusin/focusout events |
| 19:07 | <Hixie> | smaug____: wow, only for those? not focus/blur? |
| 19:08 | <smaug____> | er |
| 19:08 | <smaug____> | hmm |
| 19:08 | <smaug____> | sorry |
| 19:08 | <smaug____> | Hixie: in FF focusin/out aren't implemented, and so aren't .relatedTarget setting |
| 19:09 | smaug____ | looks at the code still |
| 19:10 | <Hixie> | i haven't specced focusin/focusout either |
| 19:10 | <Ms2ger`> | tobie, isn't, you forgot the argument name </unhelpful> |
| 19:10 | <smaug____> | well, some of it is in D3E |
| 19:11 | <smaug____> | Hixie: but yeah, FF doesn't set .relatedTarget to anything useful yet in case of focusevent |
| 19:11 | <smaug____> | known bug |
| 19:11 | <tobie> | Ms2ger`: might be helpful, actually. Let me check. |
| 19:15 | <tobie> | Ms2ger`: so no, that's actually not the issue. |
| 19:16 | <tobie> | So is the following WebIDL construct valid? [Constructor((Foo or [EnsureUTF16] DOMString) str)] |
| 19:18 | <Ms2ger`> | I suspect not |
| 19:19 | <Domenic_> | JakeA: for service worker caches, can you explain why there are so many overloads? Overloads always scare me. |
| 19:20 | <JakeA> | Domenic_: can only think of URLs vs requests off the top of my head |
| 19:20 | <tobie> | JakeA: |
| 19:20 | <JakeA> | But have been drinking so may be forgetting others |
| 19:21 | <tobie> | ^ sorry, silly irc client. |
| 19:21 | <Hixie> | smaug____: fascinating |
| 19:21 | <JakeA> | tobie: s'ok, made me feel popular |
| 19:22 | Hixie | is trying to spec relatedTarget, but it's not clear what exactly it should point to |
| 19:22 | <tobie> | JakeA: having issues with an probably invalid WebIDL construct in SW |
| 19:22 | <smaug____> | Hixie: that part is something D3E tries to spec, to some extent |
| 19:24 | <tobie> | JakeA: turns out it's in the cache Domenic_ was just mentioning: https://slightlyoff.github.io/ServiceWorker/spec/service_worker/index.html#cache |
| 19:24 | <Hixie> | smaug____: the extent of their speccing relatedTarget durin 'blur' is "event target receiving focus" |
| 19:24 | <Hixie> | smaug____: which is great except with iframe and dialog and so on there could be multiple elements in multiple browsing contexts :-) |
| 19:24 | <Hixie> | smaug____: so... not so helpful in practice |
| 19:24 | <JakeA> | tobie: hmm, will need to check to see if that's up to date, proposed a lot of change to that API recently |
| 19:25 | <smaug____> | yup, that is still unclear |
| 19:25 | <smaug____> | must not reveal nodes from other domains |
| 19:25 | <tobie> | JakeA: [EnsureUTF16] can be applied to an argument apparently not to a type. |
| 19:25 | smaug____ | wonders if webkit or blink does that |
| 19:25 | <tobie> | JakeA: (if I read the WebIDL spec correctly, which frankly, would surprise me.) |
| 19:25 | <smaug____> | given that they don't have any security checks there based on the JS wrappers |
| 19:29 | <Hixie> | smaug____: they seem to only reveal elements from the same document |
| 19:29 | <Hixie> | e.g. the blur when you blur an element to focus one outside an iframe doesn't have a relatedTarget |
| 19:30 | <Hixie> | i wonder what to do with the one fired at non-elements |
| 19:30 | <Hixie> | make it Event, like in webkit? make it FocusEvent with no relatedTarget? |
| 19:31 | <Hixie> | as in, null |
| 19:31 | <Hixie> | what if you move focus from one dialog to another... there's two focus/blur pairs, one for the control in the first dialog and the control in the second dialog, and one for the dialogs |
| 19:31 | <Hixie> | should the relatedTarget of the controls be null? and the relatedTarget of the dialogs be the dialogs? |
| 19:31 | <Hixie> | what's the use case for relatedTarget? |
| 19:32 | <Domenic_> | JakeA: ah you're right it got better since I last looked. Still don't quite understand how such different objects can be used. Is it just a convenience for cache.whatever(req.url, ...)? |
| 19:35 | <smaug____> | Hixie: use case is to know where the focus is moving from/to |
| 19:35 | <smaug____> | use case is fine |
| 19:36 | <zewt> | may be more useful to know from/to when you're eg. an event listener on document rather than the control itself, and you want to do an animation from the old thing to the new thing or something like that |
| 19:42 | <Hixie> | smaug____: that's what it gives you, but i mean the use case. Like, why would you use that information. |
| 19:42 | <JakeA> | Domenic_: a url will be converted to a basic GET request. The defaults are defined by the Request constructor. Feedback on this API is very welcome though! |
| 19:42 | <Hixie> | zewt: hmm, animating from one to the other is an interesting idea |
| 19:43 | <Hixie> | zewt: though you could do that by just listening to focus events and tracking where you last went |
| 19:43 | <zewt> | contrived, not sure i've needed to use relatedTarget myself |
| 19:43 | <Hixie> | in the case of a dialog you'd probably not want to animate away from one control to the other when changing dialogs |
| 19:43 | <Hixie> | you'd presumably want a per-dialog animation state |
| 19:43 | <zewt> | what if nothing is focused for a while, then the user focuses something, and you only want to animate for a transition, and not do the animation from something that was focused earlier |
| 19:43 | <Hixie> | so that argues for relatedTarget staying within its most local scope |
| 19:44 | <Hixie> | zewt: there's always _something_ focused |
| 19:44 | <zewt> | you'd need to add a timer to try to guess whether it was a direct transition or if there was some delay, which seems to be the main thing relatedTarget gives you |
| 19:44 | <Domenic_> | JakeA: hmm well I trust you guys have found it important to have a convenient way of doing that, i.e. the convenience of using url instead of `new Request({ url: ... })` outweighs the implicitness. |
| 19:45 | <Domenic_> | JakeA: but I like that there is such an equivalence, i.e. Requests are the "real" keys and URLs are just sugar; I was afraid that caches had two kinds of keys |
| 19:47 | <zewt> | Hixie: it seems like there's nothing focused if I click on text |
| 19:47 | <Hixie> | the browsing context is focused, at least |
| 19:47 | <zewt> | (the window has a focus message, but window focus/blur seems independent of element focus/blur) |
| 19:47 | <zewt> | (which is confusing) |
| 19:48 | <Hixie> | it's all the same algorithm per the spec these days |
| 19:48 | <Hixie> | http://www.whatwg.org/specs/web-apps/current-work/#focus-update-steps |
| 19:48 | <zewt> | it looks distinct from testing in chrome, at least |
| 19:48 | <zewt> | that is, i get focus/blur messages for window, and focus/blur messages for my <input type=text>, and i can get focus for both at the same time |
| 19:49 | <Hixie> | yeah, it's a hieararchy of focus |
| 19:49 | <Hixie> | hierarchy even |
| 19:49 | <zewt> | i guess i can see that |
| 19:50 | <zewt> | that means that if you were trying to track focus yourself (to emulate relatedTarget), you'd need to maintain a stack, which would be brittle |
| 19:51 | <Hixie> | maintaining it yourself would be a huge pain |
| 19:51 | <Hixie> | since it can cross iframe boundaries and so on |
| 19:51 | <Hixie> | ok i think the logical thing to do is to only set relatedTarget for the outermost thing that receives the focus/blur events, and then only set it if it's an Element |
| 19:51 | <Hixie> | outermost things |
| 19:52 | <Hixie> | the last entry in old chains and new chains |
| 19:52 | <Hixie> | after step 1 has pruned the end of the lists |
| 19:53 | <zewt> | weird, no focus event for the iframe itself if focus is inside the iframe (haven't needed that, it's just what i expected to happen) |
| 19:55 | <Hixie> | yeah teh iframe and its Document are kinda treated as one |
| 19:56 | <zewt> | i have a capturing listener on window, and if I focus an iframe inside it, the window just gets a blur |
| 19:56 | <Hixie> | hm actully... |
| 19:56 | <zewt> | i'd have thought i'd get a focus with a target of the iframe |
| 19:56 | <Hixie> | that may have been one of the things i'm trying to change with that new algorithm |
| 19:56 | <zewt> | like how mouseover works |
| 19:57 | <zewt> | https://zewt.org/~glenn/foo1.html |
| 19:57 | <zewt> | fwiw |
| 20:03 | <SamB> | Hixie: didn't you keep notes on that? |
| 20:04 | <Hixie> | the spec is my notes :-) |
| 20:04 | <Hixie> | it's easy enough to figure out just by reading the spec, i just didn't read the spec in response to zewt's comment :-) |
| 20:11 | <marcosc> | Hixie: with the <link rel=manifest> thing, I need to say that the user agent is not required to "obtain the resource" until needed, if ever (e.g., for the purpose of bookmarking). However, the link element has text about delaying the load event of a document until the resource being pointed to is obtained. Clearly, we don't want to delay the load event (as the manifest may never get loaded by the UA). I'm wondering, do we need in HTML a special exte |
| 20:11 | <marcosc> | rnal link that is low priority (may never be loaded) and that doesn't block the document load event from firing? The same could apply to <link rel=icon> - as those resources may never be loaded by the browser until needed. |
| 20:14 | <Hixie> | marcosc: the spec doesn't say that it delays the load event until the resource is obtained |
| 20:14 | <Hixie> | marcosc: it says it delays the load event "until all the attempts to obtain the resource and its critical subresources are complete" |
| 20:14 | <Hixie> | marcosc: if you don't begin an attempt, the load event isn't delayed |
| 20:15 | <marcosc> | ah |
| 20:15 | <Hixie> | indeed the very same paragraph explicitly says: |
| 20:15 | <Hixie> | "Resources that the user agent has not yet attempted to obtain, e.g. because it is waiting for the resource to be needed, do not delay the load event." |
| 20:15 | <Hixie> | it's literally the next sentence |
| 20:16 | <marcosc> | Sorry, got stuck on that sentence |
| 20:16 | <Hixie> | see http://www.whatwg.org/specs/web-apps/current-work/#link-type-stylesheet for wording for how to trigger that stuff |
| 20:16 | <marcosc> | ok, awesome, then I think we are good. |
| 20:16 | <Hixie> | interestingly, rel=icon doesn't ever say to obtain anything, heh |
| 20:17 | <marcosc> | yeah |
| 20:17 | <marcosc> | I noticed that |
| 20:17 | <marcosc> | :) |
| 20:18 | <marcosc> | manifest and icon are pretty much the same |
| 20:39 | <arunranga> | hi abarth, we’re trying to nail down the origin of blob: URLs and data: URLs (that’s https://www.w3.org/Bugs/Public/show_bug.cgi?id=24998 but specifically http://lists.w3.org/Archives/Public/public-webapps/2014JanMar/0682.html). |
| 20:39 | <abarth> | hi |
| 20:39 | <abarth> | ok |
| 20:40 | <abarth> | have you nailed down the syntax of blob URLs? |
| 20:40 | <arunranga> | Yes, the syntax of a blob: URL is probably nailed down. |
| 20:40 | <arunranga> | Currently we’ve pegged the origin of the blob: URL to the origin of the incumbent settings object |
| 20:40 | <arunranga> | But we can’t gather that *from* the blob: URL alone. |
| 20:42 | <arunranga> | If you’ve got opinions on how we should fix this, and whether we should do the same thing for data: URLs as for blob: URLs, either of those two (email or bug) would be good places to weigh in :-) |
| 20:50 | <abarth> | what does a blob URL look like? |
| 20:50 | <abarth> | can you give me an example of one? |
| 20:51 | <abarth> | I ask because last time I studied this problem, different browsers used different syntax for blob URLs |
| 20:51 | <abarth> | which made the more complex problems intractable |
| 20:51 | <zewt> | well, you inherently can't get the origin of a blob url if it's revoked |
| 20:52 | <zewt> | abarth: though, since blob URLs have no meaning and there should never be any blob URLs stored anywhere, it might be possible to change that (even though the feature is already out there) |
| 20:52 | <zewt> | (not that that's necessarily the right thing to do) |
| 20:53 | <abarth> | zewt: those statements depend on the syntax of blob URLs |
| 20:53 | <zewt> | there is no syntax, right? it's just blob: + undefined data (that usually looks random) |
| 20:53 | <SamB> | abarth: there is none! what you see is an ill-uu-u-u-sion |
| 20:54 | <zewt> | since the data has no meaning to scripts, you could change that to "blob: + origin + arbitrary data" (or blob: + sha1(origin) + data" or something) without breakage |
| 20:55 | <abarth> | zewt: right, it's the "undefined data" part that's problematic |
| 20:55 | <arunranga> | well, there is a syntax in that we do blob: + schemeid with schemeid typically being a UUID |
| 20:55 | <SamB> | who does that? |
| 20:55 | <abarth> | i'm happy to discuss a security model for blobs once folks agree on a syntax for blob URLs |
| 20:55 | <abarth> | that doesn't involve leaving platform-visible strings as implementation-defined |
| 20:55 | <zewt> | arunranga: individual implementations might have some pattern (like always looking like a UUID), but hopefully nobody's embedding info the web might be depending on |
| 20:56 | <abarth> | zewt: that hope seems wildly optimistic to me |
| 20:56 | <zewt> | abarth: maybe, but I'm not sure I can contrive a way people might be depending on that |
| 20:56 | <arunranga> | (Chrome annotates the blob: URL sometimes so that it looks like this — blob:http://google.com[uuid] |
| 20:56 | <arunranga> | ) |
| 20:56 | <zewt> | yuck |
| 20:56 | <tobie> | slightlyoff: which file am I supposed to edit to modify the WebIDL in SW? |
| 20:56 | <arunranga> | Not sometimes/ all the time |
| 20:56 | <arunranga> | I don’t like it :( |
| 20:56 | <SamB> | indeed yuck |
| 20:56 | <abarth> | hence the ability to get the origin of a revoked blob URL |
| 20:56 | <arunranga> | And I wish they didn't |
| 20:57 | <tobie> | slightlyoff: and in which branch? |
| 20:57 | <abarth> | wishing and ponies |
| 20:57 | <arunranga> | Fx doesn’t do it |
| 20:57 | <SamB> | that's a terrible syntax |
| 20:57 | <zewt> | that's not necessarily a bad way to do it, but it's bad to put data inside blob URLs that people might look at and go "hey, I can parse info out of that", if only one vendor is doing it |
| 20:57 | <SamB> | you should standardize a different syntax just to spite them |
| 20:57 | <abarth> | zewt: this has all been discussed before |
| 20:57 | <SamB> | one with a : in it |
| 20:57 | <SamB> | after the origin |
| 20:57 | <abarth> | and each vendor appears entrenched in their position |
| 20:57 | <zewt> | abarth: that's nice :) |
| 20:58 | <arunranga> | abarth, zewt: what if this was what it looked like: http://dev.w3.org/2006/webapi/FileAPI/#DefinitionOfScheme |
| 20:58 | <arunranga> | If we agreed on that (big if) could you suggest an origin ? |
| 20:58 | <abarth> | there is no such thing as an opaque string |
| 20:58 | <abarth> | strings in JavaScript are not opaque |
| 20:58 | <abarth> | they're sequences of characters |
| 20:58 | <abarth> | hence the lie |
| 20:59 | <arunranga> | abarth, the idea was unguessable. |
| 20:59 | <abarth> | the participants in the working group did not agree on a syntax |
| 20:59 | <abarth> | which is why the spec is vague |
| 20:59 | <abarth> | and why this area of the platform is a mess |
| 20:59 | <arunranga> | abarth, agreed |
| 20:59 | <Ms2ger`> | Yay, consensus |
| 20:59 | <SamB> | I assume "opaque" means something like "the meaning is not in the characters" |
| 21:00 | <abarth> | SamB: that's not what it means |
| 21:00 | <zewt> | "opaque" should mean at least "there's nothing users can try to parse out of this" |
| 21:00 | <abarth> | anyway, as I wrote above, I'm happy to talk with you about a security model after you get folks to agree on a syntax for the URLs |
| 21:00 | <arunranga> | abarth, on syntax: is UUID a bad idea ? |
| 21:00 | <zewt> | which blob:http://google.com fails at |
| 21:00 | <abarth> | arunranga: I'm not the person you need to convince about the syntax |
| 21:00 | <abarth> | I don't care at all beyond that it needs to be interoperable |
| 21:00 | <zewt> | that said, i'm not sure why the origin would be in the URL |
| 21:00 | <abarth> | the current situation isn't remotely interoperable |
| 21:00 | <arunranga> | abarth, the history of this is that Darin didn’t want a restriction to UUID |
| 21:01 | <abarth> | darin -> fishd ? |
| 21:01 | <zewt> | you have a live registry somewhere of blob URLs -> blobs; store it in there (means you can't get the origin after the blob URL is revoked, but that shouldn't matter) |
| 21:01 | <arunranga> | abarth, yep :( But Hixie’s formulation effectively made it UUID |
| 21:01 | <abarth> | yes, the history is that people did not agree on a syntax |
| 21:01 | <abarth> | that does not match reality |
| 21:02 | <arunranga> | abarth, OK. I’ll file bugs to not make claims that are misleading like “opaque” but if we insisted on UUID, so that it was something like blob:UUID, would we be better off? |
| 21:04 | <zewt> | arunranga: won't help unless chrome people can be convinced to get the origin out of the URLs |
| 21:05 | <arunranga> | I think we should roll up the sleeves and try and sort this out. It’s hard, but that’s why I’m pestering abarth |
| 21:05 | <SamB> | hmm, won't that make debugging harder? |
| 21:05 | <arunranga> | :-) |
| 21:05 | <zewt> | i don't think it's necessarily bad to put the origin in there like that, it's just bad that one vendor decided to do that |
| 21:06 | <abarth> | zewt: I don't think you're going to get very far in this discussion if you use biased language like that |
| 21:06 | <zewt> | sounds like this whole discussion upsets you, but that's not my fault :) |
| 21:07 | <arunranga> | abarth, actually the thinking was that since the blob: URL is never *seen* and only passed around, what it actually looked like wasn’t important. |
| 21:08 | <arunranga> | abarth, I tended to agree with that thinking, but it’s clear that if we want to evolve an origin concept for blob:, we need more syntax clarity |
| 21:09 | <zewt> | arunranga: only if the origin comes by parsing the URL, but since blob URLs have a live registry, is that really the case? |
| 21:09 | <arunranga> | abarth, the question is: is there a really good implementation reason for “tagging” the blob:UUID model with more info, such as some implementations do? If not, we could stick to something like blob:UUID. |
| 21:09 | <arunranga> | But this is probably not a convo solved in IRC alone, so I’ll take it to the lists! |
| 21:22 | <sicking> | arunranga, abarth: I think syntax for blob: depends on what we decide about origins for blob: |
| 21:23 | <sicking> | if blob: URIs have an implicit origin, like http: does, and unlike data:, then I think it might be valuable to stick that origin inside the URI |
| 21:23 | <sicking> | but if blob: act more like data:, then obviously that does not make sense |
| 21:24 | <sicking> | so I think our first step here is to figure out a good story for data: |
| 21:24 | <sicking> | since without that I don't think we can answer the question of "should blob: act like data:" |
| 21:27 | <slightlyoff> | Tobie: spec/service_worker/index.html in master |
| 21:28 | <tobie> | slightlyoff: with all the crazy inline urls and such? |
| 21:28 | <tobie> | slightlyoff: I'd want to edit some of the WebIDL |
| 21:28 | <abarth> | (sorry, had to run off---back now) |
| 21:28 | <tobie> | slightlyoff: and it seems like it's generated from something. |
| 21:28 | <slightlyoff> | Going to fix via the framework shortly |
| 21:29 | <slightlyoff> | Hand rolled |
| 21:29 | <abarth> | arunranga: blob URLs are exposed to web sites, which mean we can't have them be implementation-defined |
| 21:29 | <tobie> | oh, my, |
| 21:29 | <tobie> | What about using a tool that already works? |
| 21:29 | tobie | hides |
| 21:30 | <abarth> | sicking: in chrome, a blob URI is bound to an origin |
| 21:30 | <sicking> | abarth: in gecko too |
| 21:30 | <Ms2ger`> | tobie, nah, not cool |
| 21:30 | <abarth> | the difference is just that chrome writes that origin in the syntax of the blob URI |
| 21:30 | <sicking> | abarth: we just don't stick that origin in the actual URI. It's just kept in an internal hash |
| 21:30 | <tobie> | Ms2ger`: the hiding part? |
| 21:30 | <sicking> | right |
| 21:30 | <tobie> | :P |
| 21:31 | <marcosc> | seriously, slightlyoff, just use Respec or Anolis. You will spend just as long rolling out your own spec generation thing as you will on the spec. |
| 21:31 | <abarth> | I never understood why it's problematic to write that origin in the URI |
| 21:31 | <marcosc> | slightlyoff: It also makes it easier for people to contribute/review the spec. |
| 21:31 | <Hixie> | all the coolest spec editors roll their own infrastructure |
| 21:31 | <sicking> | abarth: i'm happy to go with the chrome approach if we do decide that blob:s should have a bound origin (which I think it should) |
| 21:32 | <Ms2ger`> | tobie, existing tools |
| 21:32 | <sicking> | abarth: i'm slightly uncomfortable with the "nested URI" aspect of it. But that is probably solvable |
| 21:32 | <arunranga> | abarth, sicking: here’s a real world example. This is exactly what Chrome does (I coined it in the dev console) blob:http%3A//aaww.org/9efd7ba9-b707-4262-ab0d-6a395be173f1 |
| 21:32 | <abarth> | yeah, I wanted to base64 encode it or something |
| 21:32 | <abarth> | but there was some reason why someone didn't want to do that |
| 21:33 | <abarth> | if you don't put the origin in the syntax |
| 21:33 | <arunranga> | sicking, are you uncomf because of information leak? |
| 21:33 | <abarth> | you have to decide what happens when someone outside your origin tries to use the URI |
| 21:33 | <sicking> | arunranga: no, just implementation issues |
| 21:33 | <abarth> | if its in the syntax, you can just reject it syntatically |
| 21:34 | <tobie> | slightlyoff: so is editing those by hand worthwhile at present? |
| 21:34 | <marcosc> | Hixie: don't encourage him |
| 21:34 | <arunranga> | (of course, Fx follows the spec exactly — here’s a blob: URL minted in Fx’s console): blob:2b87eebc-d9ef-954f-a61f-7263e17fba4d) |
| 21:35 | <Hixie> | imho editors should work with whatever infrastructure they are most comfortable with |
| 21:35 | <Hixie> | if that means rolling your own, then why not? |
| 21:35 | <Hixie> | i mean, there's a reason so many of us have done this |
| 21:35 | <arunranga> | Hixie, crap. I always knew I wasn’t cool. I just used rberjon’s infrastructure |
| 21:36 | <Hixie> | arunranga: if that's what makes you the most productive, seems good to me |
| 21:36 | <sicking> | abarth: anyhow, I think the first step here is to figure out security model for data:. I think what we discssued last time has a lot of potential. We should let Anne know about it |
| 21:36 | <Hixie> | i used to use bert's |
| 21:36 | <Hixie> | now i use gsnedders' |
| 21:36 | <Hixie> | soonish i'll use mine :-) |
| 21:37 | <sicking> | abarth: once we've figured out data:, we can figure out if we want to reuse that for blob: (I think we won't want to) |
| 21:37 | <arunranga> | sicking, abarth: why not just formalize what Chrome is doing, since we think there’s merit in origin extraction from the URL syntax? |
| 21:38 | <sicking> | arunranga: if you can convince anne that that's the right thing to do, then i'm all for it |
| 21:38 | <abarth> | sicking: if you want to wait for data to be sorted out, you're going to have to wait a long time :( |
| 21:39 | <tobie> | Hixie: it's a common tradeoff: either favor external contributions or personal speed. |
| 21:39 | <abarth> | sicking: it's just a lot of engineering to change Blink to support a different security model for data |
| 21:39 | <arunranga> | sicking, abarth, convincing annevk takes a long time sometimes too |
| 21:39 | <abarth> | arunranga: or maybe just a few beers :) |
| 21:40 | arunranga | knew the pros had a trick up their sleeves |
| 21:40 | <sicking> | abarth: If you don't think we'll settle data: for a long time, that's enough of an argument for me that we shouldn't use the same thing for blob: |
| 21:41 | <sicking> | arunranga: so I think that means that we should spec the Chrome behavior |
| 21:42 | <abarth> | I believe the chrome behavior is as follows: |
| 21:42 | <sicking> | though people should feel free to fight things out about the syntax (%3A vs. : vs. whatever) |
| 21:42 | <Hixie> | tobie: imho editors should never accept contributions in the form of patches, they should make sure they've written all the text themselves so that they're intimately familiar with it. so i don't think it's that much of a trade-off. |
| 21:42 | <Hixie> | tobie: the infrastructure doesn't affect contribution speed in the form of bug reports. |
| 21:42 | <abarth> | 1) you're only allowed to kick off requests for blob URIs that syntatically have the origin of the incumbent script |
| 21:43 | <abarth> | 2) when loading a blob URI in a browsing context, the origin of the new document is the origin that's syntatically embedded in the URI |
| 21:43 | <sicking> | abarth: does 1) apply even in sitatuions where you normally can do cross-origin loads? Like for <img>? |
| 21:43 | <abarth> | yes |
| 21:43 | <sicking> | cool |
| 21:43 | <sicking> | sounds good to me |
| 21:43 | <sicking> | ship it! |
| 21:43 | <sicking> | this is same as what gecko does, just different syntax |
| 21:44 | <sicking> | but i like chrome's syntax more |
| 21:44 | <abarth> | the syntax is important in our implementation because the decision can all be made locally |
| 21:44 | <abarth> | without race conditions or global synchronization |
| 21:44 | <sicking> | right |
| 21:44 | <sicking> | which is why I like it :) |
| 21:45 | <arunranga> | abarth, 1) matches the spec today absent syntax but 2) seems a bit laxer |
| 21:45 | <tobie> | agreed if that's your modus operandi. I drank the forking kool-aid, so patches just seem like a much more natural (and polite) way of interacting. |
| 21:46 | <arunranga> | Uhh, no. I take that back. |
| 21:46 | <arunranga> | The only thing is syntax |
| 21:46 | <sicking> | abarth: out of curiosity, is there a reason that for filesystem: you do filesystem:http://example.com/whatnot, but for blob: you do blob:http%3Aexample.com/whatnot? |
| 21:47 | arunranga | ^^ good question |
| 21:47 | <sicking> | abarth: not ':' vs '%3A' after the http |
| 21:47 | <sicking> | note* |
| 21:48 | <abarth> | dunno, that seems a bit crazy |
| 21:48 | <Hixie> | tobie: right. like i said, editors should use whatever they prefer. If they want something that enables them to take patches easily, then obviously they should bear that in mind in their infrastructure selection. |
| 21:48 | <abarth> | sicking: I suspect we could change the blob one to match filesystem |
| 21:49 | <sicking> | abarth: I *think* there might be URL-parser-sanity reasons to pick one over the other. I don't know which is preferable though |
| 21:49 | <sicking> | i guess you guys would have a harder time changing filesystem:? |
| 21:49 | <sicking> | :( |
| 21:51 | <abarth> | I bet there's content that does "filesystem:" + location.origin + "/path/to/my/file" |
| 21:51 | <sicking> | yeah |
| 21:51 | <abarth> | it matches what gecko does for jar |
| 21:51 | <sicking> | you'll have to add + "temporary/" in there though |
| 21:52 | <sicking> | yeah, though jar handling has been a source of a lot of complexity |
| 21:52 | <sicking> | i'd like to avoid having that get onto the web |
| 21:53 | <SamB> | jar handling is a good example of, um, something that has had to be rethought because of, um, unforeseen implications? |
| 22:04 | <arunranga> | does %3A vs : make that big a difference? Maybe only for clarity. |
| 22:06 | <sicking> | arunranga: I don't know. I suspect that it doesn't make a big difference but we should check if it matter parsing-wise |
| 22:07 | <arunranga> | OK |
| 22:07 | <arunranga> | the filesystem:http://dot.com/foo system is more legible, and I have a slight preference for it |
| 22:28 | <zewt> | it would need to work for the pattern abarth gave above, and if it needs to work anyway, may as well output it too? |
| 23:38 | <caitp> | who wants to clarify something for me so that I don't have to dig through specs to find an answer? |
| 23:38 | <caitp> | is a worker supposed to resolve urls from the same base as the context which created the worker, or does it have its own base based on its url |
