| 00:00 | <Hixie> | how weird |
| 01:42 | <MikeSmith> | Hixie: If you have a couple minutes maybe you can help me understand something about why annevk set up the URL test harness the way he did |
| 01:42 | <MikeSmith> | if you look at https://github.com/w3c/web-platform-tests/blob/master/url/a-element.html#L25 and https://github.com/w3c/web-platform-tests/blob/master/url/a-element.html#L38 |
| 01:45 | <MikeSmith> | rather than just doing var url = new URL(expected.input, expected.base), it's first creating an an <a> element then setting the href attribute on it, then checking the URL attributes from that |
| 01:46 | <MikeSmith> | I know there's a reason why it's necessary to do it that way in a test like this -- instead of just using new URL(...) -- and I should rightly already understand what the reason is, but I'll admit that I don' |
| 01:47 | <MikeSmith> | (I would ask annevk but I'm assuming he's asleep right now) |
| 01:49 | <MikeSmith> | the actual immedidate problem I'm trying to solve right now is, for tests where parsing of the URL is expected to fail, I want the test to actually recognize that it's failed in a spec-conformant way |
| 01:50 | <MikeSmith> | ...which is, per https://url.spec.whatwg.org/#constructors that calling new URL(...) with it should throw |
| 01:50 | <MikeSmith> | a TypeError exception |
| 01:55 | <MikeSmith> | even with the way that the test harness is set up (using a[href]) it should still fail per https://html.spec.whatwg.org/multipage/infrastructure.html#resolve-a-url but I can't tell from that how/where I would be able to catch the failure in that case |
| 02:00 | <MikeSmith> | ... and further, from the relevant referenced part of URL spec for this (non-constructor) case, the URL spec says "return failure" but I don't know how to test that |
| 03:54 | <MikeSmith> | Domenic: I think at the time it was first implemented in gecko as mozRequestAnimationFrame there wasn't any formal spec yet http://robert.ocallahan.org/2010/08/mozrequestanimationframe_14.html (after it was originally proposed by roc in http://robert.ocallahan.org/2009/07/progress_01.html). I'm pretty sure it was never formally specced out anywhere before heycam first wrote it up (http://web.archive.org/ |
| 03:54 | <MikeSmith> | web/20110228051128/http://people.mozilla.org/~cmccormack/anim-timing/Overview.html is the earliest version that hasn't disappeared) |
| 03:55 | <MikeSmith> | http://web.archive.org/web/20110228051128/http://people.mozilla.org/~cmccormack/anim-timing/Overview.html |
| 04:03 | <roc> | what's the context? |
| 04:07 | <Hixie> | MikeSmith: my guess is that not all browsers implement URL |
| 04:10 | <MikeSmith> | roc: comment from Domenic earlier, "was rAF specced elsewhere before?" http://krijnhoetmer.nl/irc-logs/whatwg/20141120#l-18 following Hixie saying even earlier, "ok rAF is specced in HTML now" http://krijnhoetmer.nl/irc-logs/whatwg/20141119#l-927 |
| 04:11 | <Hixie> | oh i missed Domenic's comment |
| 04:11 | <roc> | ah right |
| 04:11 | <Hixie> | yeah rAF was specced in some w3c spec |
| 04:11 | <roc> | sorta-kinda |
| 04:11 | <Hixie> | the editors asked me to move it to html |
| 04:12 | <MikeSmith> | yeah https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/RequestAnimationFrame/Overview.html |
| 04:12 | <Hixie> | so we could integrate it with the event loop |
| 04:13 | <MikeSmith> | oh I guess maybe Domenic maybe didn't know about that other spec at all (I thought he was asking if there was something that came before that spec) |
| 04:13 | <benschwarz> | Hixie: ping |
| 04:15 | <Hixie> | yo |
| 04:20 | <benschwarz> | I was just following the redirects for the dev spe |
| 04:20 | <benschwarz> | spec |
| 04:20 | <benschwarz> | but they lead nowhere :/ |
| 04:21 | <benschwarz> | Hixie: 404 https://html.spec.whatwg.org/dev-index |
| 04:23 | <Hixie> | yeah, the generator is broken |
| 04:23 | <Hixie> | there's some github issue where someone was going to describe exactly what i need to implement iirc |
| 04:24 | <Hixie> | given a specific spec for what to implement i can get this done in a few days |
| 04:24 | <Hixie> | but i don't know what we need |
| 04:24 | <benschwarz> | are you talking about the one that we chatted about? |
| 04:24 | <Hixie> | maybe? |
| 04:24 | <Hixie> | wasn't only you |
| 04:25 | <benschwarz> | https://github.com/benschwarz/developers.whatwg.org/issues/90 |
| 04:25 | <Hixie> | that's the one! |
| 04:48 | <MikeSmith> | benschwarz: thanks for the good karma at cssconf.asia |
| 04:49 | <benschwarz> | MikeSmith: <3 |
| 04:50 | <MikeSmith> | benschwarz: and at the risk of stating the obvious I didn't have anything to do with the choice of speakers for the http://css.w3ctech.com/ event I mentioned in my twitter reply :-) |
| 04:50 | <benschwarz> | :-) |
| 04:50 | <MikeSmith> | benschwarz: I'll tell them they should have you speak there instead next time |
| 04:50 | <benschwarz> | SGTM! |
| 05:59 | <MikeSmith> | Hixie: maybe it'd be good to have https://whatwg.org/style/specification in github somewhere |
| 05:59 | <MikeSmith> | Hixie: in https://github.com/whatwg/resources.whatwg.org I would think |
| 06:30 | <Hixie> | MikeSmith: yeah, probably |
| 09:43 | <annevk> | MikeSmith: I used <a> because new URL() does not have universal support and we need to test <a> too |
| 09:43 | <annevk> | MikeSmith: it would be good to also run them through new URL() though |
| 09:48 | <MikeSmith> | annevk: ok, yeah today I wrote up a separate test using new URL(), so I'll make a PR for that later |
| 09:48 | <annevk> | MikeSmith: cool |
| 09:52 | <MikeSmith> | annevk: for URLs that are expected to fail parsing, it checks for TypeError with the testharness.js assert_throws thing |
| 09:53 | <MikeSmith> | I notice that blink still throws SyntaxError instead; filed a blink bug |
| 10:27 | <zcorpan> | hmm. https://github.com/domenic/Array.prototype.includes/commit/4b6b9534582cb7991daea3980c26a34af0e76c6c |
| 10:27 | <zcorpan> | bad idea to change DOMTokenList#contains i guess? |
| 10:44 | <Ms2ger> | Really |
| 11:21 | <annevk> | We could add an alias, but lets see if this new name sticks first https://twitter.com/jdalton/status/535249955435601924 |
| 12:07 | smaug____ | wonders if requestFullscreen() should work when element is in shadow dom |
| 12:26 | <zcorpan> | "array prototype includes" OR "string prototype includes" -> 148 |
| 12:26 | <zcorpan> | "array prototype includes" OR "string prototype includes" -> 5,296 |
| 12:36 | <zcorpan> | Array.prototype["∋"] |
| 13:07 | <annevk> | jgraham: do you have a reference for "One of A and B" is better than "One of A or B"? |
| 13:07 | <annevk> | jgraham: https://github.com/slightlyoff/ServiceWorker/pull/394#issuecomment-63761704 could use it |
| 13:11 | <annevk> | MikeSmith: thanks for that |
| 13:31 | <jgraham> | annevk: I'm not even sure that's true. Did I say that before? :) |
| 13:31 | <annevk> | jgraham: nah, just wondering |
| 13:32 | <annevk> | "And X is one of A, B, or C" or "And X is one of A, B, and C" |
| 13:32 | <annevk> | the latter reads better to me... |
| 13:33 | <jgraham> | I think the first reads better |
| 13:34 | <darobin> | the first definitely reads better |
| 14:00 | <zcorpan> | Hixie: what should i do with the timestamp? |
| 14:29 | <zcorpan> | hmm, if a script scrolls the viewport twice in the same script, a single scroll event is fired. if a script scrolls the viewport then an element, a scroll event is fired first on document then on the element. flipping the order flips the order of the events |
| 14:30 | <hemanth> | Object.observe on DOM entities, without any intermediate object, anyone? |
| 14:31 | <annevk> | hemanth: ? |
| 14:33 | <hemanth> | annevk, I can't just do a Object.observe on say a input element, right? |
| 14:35 | <hemanth> | yes, there is MutationObserver....but... |
| 15:02 | <annevk> | hemanth: I feel like we had this discussion before |
| 15:05 | <hemanth> | did we! annevk definitely not me. |
| 15:08 | <annevk> | hemanth: maybe not |
| 15:08 | <annevk> | hemanth: http://lists.w3.org/Archives/Public/public-whatwg-archive/2014Aug/0176.html is relevant |
| 15:09 | <annevk> | I actually think we could maybe make this work through my IDL internal slots proposal |
| 15:10 | <hemanth> | Remember that it doesn't work out-of-the-box for getters.....hmm |
| 15:11 | <hemanth> | But if it's not a DOM object, and has getter, it would work fine...right? |
| 15:11 | <annevk> | hemanth: filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=27381 to explore that idea |
| 15:12 | <annevk> | hemanth: note that even with that you still need MutationObserver for actual DOM changes |
| 15:13 | <annevk> | hemanth: but not for <input>.value changes |
| 15:13 | <annevk> | (which is an object change, and not a tree change) |
| 15:14 | <annevk> | heycam|away: I would appreciate prioritization of internal slots |
| 15:15 | <hemanth> | annevk, gave a +1 :) |
| 15:15 | <annevk> | hemanth: heh, this is not the IETF, but thanks |
| 15:16 | <hemanth> | heh heh ^_^ |
| 15:20 | <annevk> | hemanth: and thanks for bringing this subject again, it was rather timely as last Monday we came up with being more formal about internal slots, seems it might have some nice side effects as I was hoping for |
| 15:23 | <hemanth> | annevk, hoping for the best... |
| 15:25 | <smaug____> | annevk: I'm still missing why you'd want to prioritize slots ? |
| 15:25 | <smaug____> | would that help spec writing? |
| 15:25 | <smaug____> | (if so, that is a good reason :) ) |
| 15:26 | <annevk> | smaug____: yes, and it would address a bunch of ambiguous cases now |
| 15:26 | smaug____ | wonders which ambiguous cases |
| 15:26 | <annevk> | smaug____: e.g. we often talk about the value of a certain attribute, while we should be talking about the value of the internal slot it represents |
| 15:26 | <smaug____> | oh, those are just spec bugs |
| 15:26 | <smaug____> | I mean, vague language in them |
| 15:26 | <annevk> | smaug____: because attributes have no values, they have a getter and a setter, and we don't want to invoke those because they could be overridden by script |
| 15:27 | <annevk> | smaug____: yeah, vague language is sometimes known as ambiguous |
| 15:27 | <annevk> | :-) |
| 15:27 | <annevk> | smaug____: and it will help defining creation of objects and their associated objects |
| 15:28 | <annevk> | smaug____: e.g. that if you create a Document object, you also create a DOMImplementation object, what Realm they're both associated with, etc. without language required from the specification |
| 15:29 | <annevk> | smaug____: and for the self-hosting crowd it will make it much clearer what the expected internal representation of an object is supposed to be |
| 15:31 | <zcorpan> | Hixie: https://dvcs.w3.org/hg/csswg/rev/1e907e3ac50c resize and scroll events; MediaQueryList still to be done. |
| 15:32 | <smaug____> | annevk: so what does a slot actually mean |
| 15:32 | <smaug____> | in which case a slot means the object slot points to is in the same realm as the owner of the slot? |
| 15:32 | <annevk> | smaug____: no |
| 15:32 | <annevk> | smaug____: a slot just holds a value |
| 15:33 | <smaug____> | ok |
| 15:33 | <smaug____> | so where does it help with document.implementation Realm ? |
| 15:33 | <annevk> | smaug____: but when IDL needs to create an object, it can look through the object's associated slots to discover if any associated objects need to be created |
| 15:34 | <smaug____> | ok, so need to be careful in the specs to say which all properties are supposed to be created when the object itself is created |
| 15:34 | <annevk> | smaug____: yeah, ideally all through IDL |
| 15:34 | <smaug____> | or all the none-nullable attributes without [NotSlot] would be implicitly created? |
| 15:35 | <annevk> | smaug____: that's my current idea, with default values if they have any set |
| 15:35 | <smaug____> | well, default values are like true/false etc |
| 15:35 | <smaug____> | do those even really belong to a Realm |
| 15:36 | <annevk> | smaug____: no those don't, but it's still useful |
| 15:36 | <annevk> | smaug____: it removes the need for defining things like "canceled flag" and such |
| 15:36 | <smaug____> | sure |
| 15:37 | <smaug____> | just hoping the specs don't end up looking like Promise spec and such |
| 15:37 | <smaug____> | which are hard to read |
| 15:38 | <annevk> | smaug____: I think what's hard to read depends on what you're used to. But if you're used to IDL this would actually move even more logic into IDL, have less prose, and align specifications to be more similar in terms of object descriptions |
| 15:39 | <smaug____> | indeed, idl defining the default behavior sounds good |
| 15:39 | <smaug____> | I'm just worried about the text |
| 15:40 | <annevk> | smaug____: "the text"? |
| 15:40 | <smaug____> | annevk: prose, text, whatever you call it |
| 15:40 | <smaug____> | the non-idl part :) |
| 15:41 | <smaug____> | just have capitalized text for implicit interface member variables |
| 15:41 | <smaug____> | (why they should be called slots?) |
| 15:42 | <smaug____> | and use those in the text |
| 15:42 | <smaug____> | something like that |
| 15:42 | <annevk> | We call them slots because that's the established term from ECMAScript |
| 15:42 | <annevk> | And the idea is to use [[slot]] because that's the established convention |
| 15:43 | <annevk> | I don't think we should try to be different from ECMAScript. It'll help people understand what they are about better |
| 15:44 | <smaug____> | [[]] is in ecma specs, not in w3c/whatwg specs |
| 15:44 | <smaug____> | if we can create easier to read specs, we should |
| 15:44 | <annevk> | I recommend talking to Domenic about changing that style |
| 15:46 | <smaug____> | why |
| 15:47 | <annevk> | Because he might be able to influence it, if anyone |
| 15:47 | <smaug____> | well, I hope I can influence how specs using webidl will be written ;) |
| 15:47 | <smaug____> | Domenic doesn't seem to like webidl anyway |
| 16:20 | <Domenic> | ES uses overly verbose "the [[x]] internal slot of y" but we can shorten to "x@[[y]]" which should help. |
| 16:21 | <Domenic> | A few other tweaks like https://streams.spec.whatwg.org/#conventions and more can be used to improve readability while still maintaining ES spec level precision. (And those are just a starting point.) |
| 16:26 | <TabAtkins> | I use [[foo]] in the Font Loading spec, doesn't seem too hard to read http://dev.w3.org/csswg/css-font-loading/#fontface-interface |
| 17:03 | <annevk> | I missed that Accept-Charset has now been removed from WebKit and Chromium as well |
| 17:03 | <annevk> | User-Agent and Accept are still bloated |
| 17:21 | <Hixie> | annevk: imho slots is a poor way to describe what's going on |
| 17:21 | <Hixie> | annevk: it implies that something could have slots from two different classes and act like both |
| 17:22 | <Hixie> | zcorpan: ignore the timestamp, probably |
| 17:22 | <annevk> | Hixie: I'm not sure what you're saying |
| 17:22 | <annevk> | Hixie: slots is exactly what is happening under the hood |
| 17:22 | <Hixie> | annevk: under the hood there are wrappers for C++ classes |
| 17:23 | <annevk> | Hixie: yes, IDL objects that have variables ("slots") that hold IDL values |
| 17:23 | <Hixie> | ? |
| 17:23 | <Hixie> | there's no such thing as an IDL object or IDL value in the real world :-) |
| 17:24 | <Hixie> | those are just exposition |
| 17:24 | <Hixie> | there are real JS objects, there are real C++ objects |
| 17:24 | <Hixie> | there are JS objects that wrap C++ objects |
| 17:25 | <annevk> | yeah |
| 17:25 | <annevk> | in spec land we call the latter IDL thingies |
| 17:25 | <annevk> | in Servo they're typically backed by some Rust |
| 17:29 | <annevk> | Hixie: it sounds like you're confusing slots with branding |
| 17:29 | <annevk> | Hixie: perhaps |
| 17:31 | <Hixie> | i have no idea what branding is |
| 17:31 | <annevk> | https://tools.ietf.org/html/draft-davies-idntables ... |
| 17:32 | <Hixie> | my point is that you can't have an object that has both a Promise's slots and an ArrayBuffer's slots. or an HTMLElement's slots and a WebSocket's slots. |
| 17:32 | <Hixie> | and therefore slots are a poor way to explain what's going on |
| 17:32 | <Hixie> | because there's nothing implicit in the definition of slots that would prevent that |
| 17:32 | <Hixie> | and indeed you can totally imagine someone speccing an object that has both a Promise's slots and an ArrayBuffer's slots. |
| 17:33 | <Hixie> | in other news, does anyone know of a case where we invoke the HTML fragment parsing algorithm without a context node? |
| 17:33 | <annevk> | In this proposal they would be scoped to the object |
| 17:33 | <Hixie> | what does that mean? |
| 17:33 | <annevk> | That the slot represents the private state of the object |
| 17:35 | <Hixie> | if it's private, why do we need to document it? |
| 17:40 | <annevk> | Hixie: I explained this in the bug |
| 17:40 | <annevk> | Hixie: and in this channel |
| 17:43 | <annevk> | I wonder if http://www.bbc.com/news/technology-30121159 will help in the WebRTC requiring TLS discussion |
| 17:43 | <Hixie> | i don't see anything in the bug that explains _why_ you want this |
| 17:43 | <Hixie> | you just say it should exist |
| 17:43 | <Hixie> | assuming you mean https://www.w3.org/Bugs/Public/show_bug.cgi?id=27354 ? |
| 17:44 | <Ms2ger> | Hixie, dunno about "slots", but being cleared about the internal state would be nice |
| 17:44 | <Ms2ger> | clearer |
| 17:44 | <Hixie> | clearer how? |
| 17:44 | <Hixie> | the current state of specs seems pretty clear to me |
| 17:45 | <Hixie> | is there an example of what's not clear that i could look at? |
| 17:45 | <Ms2ger> | I think having types could be useful when first reading a spec |
| 17:46 | <annevk> | Hixie: the main driver is defining the associated Realm of objects, and better defining how objects are created in general |
| 17:46 | <Hixie> | well, realms in general are a mistake |
| 17:46 | <Hixie> | so... |
| 17:46 | <annevk> | Hixie: they're just another name for the window object |
| 17:46 | <annevk> | so... |
| 17:46 | <Hixie> | no, they're not |
| 17:46 | <Hixie> | and they fail around document.domain |
| 17:47 | <annevk> | What do you mean, fail? |
| 17:47 | <Hixie> | the vat/realm/global modal doesn't match the web's security model |
| 17:47 | <annevk> | And how are they not another name for the global object? |
| 17:47 | <annevk> | Nobody is talking vats |
| 17:47 | <Hixie> | global objects and realms are not the same thing, just look in the ES spec |
| 17:48 | <annevk> | This is just about cases such as window2.Document.prototype.createElement.call(window3.document, ...) being run in window1 |
| 17:48 | <annevk> | And what that means for the Element that is created and its associated objects |
| 17:49 | <annevk> | Hixie: afaik Realm is just some bookkeeping object for a global and they're 1:1 |
| 17:50 | <annevk> | Per http://people.mozilla.org/~jorendorff/es6-draft.html#sec-code-realms that looks to be true |
| 17:51 | <Hixie> | so in your understand what is a global environment record ? |
| 17:54 | <annevk> | Hixie: properties not on the global object but nevertheless in scope |
| 17:54 | <Hixie> | so you're saying JS has three objects that are always 1:1:1 ? |
| 17:56 | <annevk> | Hixie: afaict |
| 17:56 | <Hixie> | yeah, i go back to, "realms in general are a mistake". We don't need three objects here. We only need one. In any case, we don't need to define anything to do with realms if they're 1:1 with globals, we just have to define the associated globals. And that's not a problem that requires any new IDL to solve as far as I can tell. |
| 17:58 | <annevk> | Hixie: bz and I reached a different conclusion |
| 17:58 | <Hixie> | apparently; that's why i'm trying to find out why :-) |
| 17:59 | <Hixie> | but you keep just saying "i explained it already" without explaining it :-) |
| 18:00 | <annevk> | Hixie: are you subscribed to public-script-coord? |
| 18:00 | <Hixie> | i don't follow any of the w3c lists anymore, they're full of crazy |
| 18:00 | <annevk> | Hixie: we had an email exchange there and based on that filed bugs |
| 18:01 | <annevk> | Hixie: if I have to explain every decision we come to on W3C lists again to you, I'm going to be seriously annoyed |
| 18:01 | <Ms2ger> | Seems like you already are :) |
| 18:01 | <annevk> | Well, it's not the first time |
| 18:01 | <Hixie> | well if you keep making decisions that affect me without my input, I'm going to be seriously annoyed too :-) |
| 18:02 | <Hixie> | but here all i'm asking for is a pointer, if there is one |
| 18:02 | <Hixie> | i did read the bug and it had nothing |
| 18:02 | <annevk> | Hixie: http://lists.w3.org/Archives/Public/public-script-coord/2014OctDec/thread.html#msg156 |
| 18:02 | <annevk> | Hixie: is what the bug pointed to |
| 18:03 | <Hixie> | ah, yes, i did actually read the start of that thread when it happened, but it wasn't going anywhere useful |
| 18:03 | <annevk> | Hixie: I copy you on many threads and there's not often a reply |
| 18:04 | <annevk> | Hixie: but I can try to copy you on more I guess |
| 18:04 | <Hixie> | where in this thread is the slots stuff? |
| 18:04 | <Hixie> | the start of that thread is just bogus |
| 18:04 | <Hixie> | which is why i ignored it |
| 18:04 | <Hixie> | it says "we have to define what the global is" |
| 18:04 | <Hixie> | the answer to that is simple |
| 18:04 | <Hixie> | just define what the global is |
| 18:04 | <Hixie> | done |
| 18:04 | <Hixie> | how do we get from that to slots? |
| 18:04 | <annevk> | Hixie: http://lists.w3.org/Archives/Public/public-script-coord/2014OctDec/0180.html |
| 18:04 | <Hixie> | or realms? |
| 18:05 | <annevk> | Hixie: realms are globals |
| 18:05 | <Hixie> | they're not, but whatever |
| 18:05 | <annevk> | Hixie: pointer? |
| 18:05 | <Hixie> | (e.g. CreateRealm() creates a realm without a global) |
| 18:06 | <Hixie> | http://lists.w3.org/Archives/Public/public-script-coord/2014OctDec/0180.html doesn't explain why we need slots |
| 18:06 | <Hixie> | it just says we need slots |
| 18:06 | <annevk> | but that's not exposed... |
| 18:06 | <Hixie> | neither are realms... |
| 18:06 | <annevk> | which is why they're globals |
| 18:06 | <Hixie> | they're not globals... |
| 18:06 | <Hixie> | they're some internal state that shouldn't exist in the first place |
| 18:07 | <Hixie> | and that other specs shouldn't need to ever mention |
| 18:07 | <caitp> | one of these days, all of the different spec editors should go bowling or something and sort this stuff out |
| 18:07 | <Hixie> | i mean the most obvious way to see that these are not needed is that ES3 didn't have them yet nothing changed in the semantics here |
| 18:07 | <Hixie> | anyway |
| 18:07 | <Hixie> | that's not the argument i care about |
| 18:07 | <Hixie> | i'm just trying to understand why we're trying to solve the problem of "define the global for an object" by adding IDL syntax |
| 18:08 | <Hixie> | IDL syntax that, in particular, doesn't match realty |
| 18:08 | <annevk> | the idea is to let IDL define the globals, including for objects associated with a particular object |
| 18:09 | <annevk> | as the stuff around multiple globals is way too hard on spec authors |
| 18:09 | <Hixie> | i don't understand what is ambiguous about globals |
| 18:10 | <Hixie> | all the objects we create come from a global or an object that itself comes from a global, directly or indirectly. |
| 18:10 | <Hixie> | can you give me a concrete example of something that's not defined? |
| 18:11 | <annevk> | "This is just about cases such as window2.Document.prototype.createElement.call(window3.document, ...) being run in window1" |
| 18:11 | <annevk> | "And what that means for the Element that is created and its associated objects" |
| 18:13 | <Hixie> | "The global associated with an method call is the global object of the object on which the method was invoked (the 'this' value of the method call)" |
| 18:13 | <Hixie> | done. solved it for you. |
| 18:14 | <Hixie> | (maybe make my grammar better) |
| 18:15 | <Hixie> | is there some reason that's not enough? |
| 18:15 | <Hixie> | i really don't understand what is hard here |
| 18:15 | <Hixie> | i mean we have to define which Document that calls works on too, regardless of the global object |
| 18:15 | <Hixie> | and once you've defined that, the global object issue solves itself |
| 18:16 | <annevk> | That doesn't define it for objects associated with the Element |
| 18:16 | <Hixie> | (and solving the global object issue doesn't solve the "which Document" issue) |
| 18:16 | <Hixie> | how do you mean? |
| 18:16 | <Hixie> | if an object is associated with an Element, then by definition they're associated with an object that has a global |
| 18:16 | <Hixie> | every object has an associated global, it's the global on which the prototypes find themselves |
| 18:18 | <annevk> | What I mean is that if you create an element, it would be good if it's properly defined what the global associated with that element's NodeList is for instance |
| 18:18 | <annevk> | Or with ImageData's data |
| 18:18 | <Hixie> | there's only one sane answer, yes? |
| 18:18 | <Hixie> | the same global as the element? |
| 18:18 | <annevk> | I don't know, in implementations that's not always the case |
| 18:18 | <Manishearth> | Hixie: can the DOM3 events spec be fixed, or is it frozen? |
| 18:18 | <Hixie> | Manishearth: no idea |
| 18:19 | <Hixie> | Manishearth: if it's frozen, it's dead |
| 18:19 | <Manishearth> | I guess we should cc the relevant person on the bug? |
| 18:19 | <Manishearth> | hah |
| 18:19 | <Hixie> | Manishearth: so hopefully it's either being maintained, or there's some other spec that's replaced it |
| 18:19 | <Hixie> | Manishearth: but in general, key and mouse events have not found anyone who wants to do a real spec for them :-( |
| 18:19 | <Hixie> | Manishearth: so i suspect the answer is that DOM3 Events isn't frozen per se, but is also not interested in correctly and fully speccing key and mouse events |
| 18:20 | <Hixie> | annevk: when is an Element going to have a different global than its childNodes NodeList? |
| 18:21 | <Hixie> | annevk: adoptNode doesn't change the prototypes, does it? |
| 18:23 | <annevk> | Hixie: that is the plan, actually |
| 18:23 | <Hixie> | does anyone do that currently? |
| 18:23 | <annevk> | Hixie: Gecko |
| 18:23 | <Hixie> | just gecko? |
| 18:23 | <Manishearth> | Hixie: after filing https://www.w3.org/Bugs/Public/show_bug.cgi?id=27337 annevk told me something similar and said that I would be probably asked to write the spec myself :p |
| 18:23 | <annevk> | Hixie: and Safari does it but less deterministic |
| 18:24 | <Hixie> | annevk: ok so why aren't we going towards the saner "don't change prototypes half way through an object's lifetime" model that more browsers implement? |
| 18:24 | <annevk> | Manishearth: Travis and some people are working on DOM Level 3 Events |
| 18:24 | <Hixie> | since it would be way simpler and not require any of this stuff? |
| 18:25 | <annevk> | Hixie: that's not what's motivating this |
| 18:25 | <Hixie> | and anyway, even if you did change that, you still wouldn't need this slots stuff. Just have adoptNode() update the prototypes you care about. |
| 18:25 | <Hixie> | so what _is_ motivating this? |
| 18:25 | <Manishearth> | annevk: yeah, I moved the bug over to DOM3 and Travis |
| 18:25 | <Hixie> | dude i'm just trying to understand why you're trying to do this |
| 18:25 | <annevk> | Hixie: I tried to explain, but you don't think it's a problem |
| 18:25 | <Hixie> | why do you think it's a problem? |
| 18:25 | <Hixie> | why am i wrong? |
| 18:27 | <annevk> | Hixie: I think it would be better if internal slots were better formalized as currently specs often make a mess about how to talk about private state; and it seems it would help defining associated globals as well as creation of objects |
| 18:27 | <annevk> | Hixie: and then once that's done it seems we can maybe build things on top, such as Object.observe |
| 18:28 | <annevk> | baby steps... |
| 18:31 | <Hixie> | wait, what has Object.observe() got to do with anything. you haven't brought this up before. |
| 18:31 | <annevk> | Hixie: that's what started the discussion about internal slots today... |
| 18:34 | <Hixie> | hm? |
| 18:34 | <Hixie> | i thought i started it |
| 18:34 | <Hixie> | i don't see anything about Object.observe() in our conversation? |
| 18:39 | <SimonSapin> | annevk: was it deliberate to drop the error handling mode here? it’s not mentioned in the commit message or the bugs linked from there https://github.com/whatwg/url/commit/f7ab990492ff6f6f69b557b7693149f42bba6bd8#diff-bb9242250d394d9ad4dc0019a1dfe4aeL1921 |
| 18:39 | <SimonSapin> | annevk: If so, how should failure be handled? (Since "fatal" is the default for encode.) |
| 18:40 | <annevk> | Hixie: it's in the backlog |
| 18:41 | <SimonSapin> | (This is in the application/x-www-form-urlencoded serializer) |
| 18:41 | <annevk> | SimonSapin: I don't think it is for the algorithm it calls |
| 18:41 | <annevk> | SimonSapin: unless I'm linking to the wrong one |
| 18:41 | <Hixie> | i paged through it but didn't see anything relevant. i found the bug though. looks like i am not the only one with concerns on that one. |
| 18:41 | <Hixie> | bbiab |
| 18:42 | <SimonSapin> | annevk: I don’t understand that sentence. What is it? |
| 18:42 | <annevk> | SimonSapin: https://encoding.spec.whatwg.org/#encode |
| 18:43 | <SimonSapin> | URL links to #encoding |
| 18:44 | <annevk> | <span data-anolis-spec=encoding>encode</span> was in that commit |
| 18:44 | <annevk> | SimonSapin: if that regressed please file a bug? |
| 18:44 | <SimonSapin> | the latest version links to #encoding. Maybe it got changed accidentally in the bikeshed conversion? |
| 18:44 | <annevk> | SimonSapin: I suspect it might be the bikeshed conversion |
| 18:45 | <SimonSapin> | annevk: also, I’ve said it before, but I think it’s very error-prone to have terms with very close names (encode vs encoder) and subtly different behavior |
| 19:08 | <annevk> | TabAtkins: why does the "encode" link under https://url.spec.whatwg.org/#concept-urlencoded-serializer not go to "encode"? |
| 19:09 | <TabAtkins> | Ahahaha, interesting. It's because Bikeshed's being too smart for its own good. |
| 19:10 | <annevk> | SimonSapin: seems hard to avoid, "encoding" and "encoder" are close too |
| 19:10 | <TabAtkins> | It understands English conjugation enough to recognize that "encode" and "encoding" are the same word. I'll have to see how to tweak this so it doesn't do corrections if the exact word is around. |
| 19:13 | <Ms2ger> | I wonder if I ever received an email whose subject started "I have a proposal" that wasn't spam |
| 19:13 | <SimonSapin> | TabAtkins: too much magic? |
| 19:14 | <TabAtkins> | SimonSapin: Yeah. It also doesn't help that, originally, Bikeshed only had the auto-correction on link texts. Mike West added it to definition texts, but the implementation isn't quite right. |
| 19:15 | <SimonSapin> | TabAtkins: but yeah, preferring exact matches over fuzzy matches sounds good |
| 19:49 | <TabAtkins> | annevk: Actually, the problem is that "encode" doesn't show up in the linking database at all, so there's nothing to exact-match against. Fuzzy-matching then leads to Bikeshed concluding that you probably meant "encoding", which it knows about. |
| 19:49 | <TabAtkins> | (The fact that this didn't error out is probably why it's not in the custom anchors block.) |
| 21:29 | <TabAtkins> | Yay, fun times finding bugs in the Python stdlib! |
| 21:45 | foolip | reads http://intertwingly.net/blog/2014/11/20/WHATWG-W3C-Collaboration |