| 04:58 | <zcorpan> | Hixie: https://www.w3.org/Bugs/Public/show_bug.cgi?id=20212 was closed (by mat) |
| 05:22 | <arpitab__> | Hi! anyone around who could help with a user account creation? I wanted to modify the meta extensions wiki and need a whatwg account for doing the same. |
| 05:23 | <MikeSmith> | arpitab__: yeah, just let me know you e-mail address and what user name you want. either here or DM if you prefer |
| 05:24 | <arpitab__> | Tx MikeSmith! shall DM |
| 05:25 | <MikeSmith> | hai |
| 08:13 | <annevk> | How would https://www.w3.org/Bugs/Public/show_bug.cgi?id=26517 even work in the async/await world? |
| 08:14 | <annevk> | try { await thing() } catch(...) { ... } |
| 08:14 | <annevk> | What would it mean for thing() to throw synchronously? |
| 08:14 | <annevk> | Domenic: happy to change XMLHttpRequest's serialization |
| 08:15 | <annevk> | Domenic: sort of hoping Ms2ger can sort out what that should be though |
| 09:33 | <JakeA> | annevk: In an async/await world that example would behave the same regardless of sync/async throw |
| 10:31 | <annevk> | JakeA: so how do you do things like Promise.all() in async/await? let x = await y(); let z = await a(); if(x && z) ...? |
| 10:32 | <JakeA> | annevk: var results = await Promise.all(a(), b(), c()); |
| 10:32 | <JakeA> | annevk: var results = await Promise.all([a(), b(), c()]); even |
| 10:33 | <annevk> | Hmm, so promises are not completely abstracted out |
| 10:33 | <JakeA> | Nah, not if you want a() b() and c() in parallel |
| 10:34 | <JakeA> | Well, you could do: |
| 10:35 | <JakeA> | let x = y(); let z = a(); x = await x; z = await z; |
| 10:37 | <JakeA> | annevk: I'm doing parallel without Promise.all in http://jakearchibald.com/2014/es7-async-functions/#this-time-with-es7-async-functions |
| 10:44 | <benjamingr> | I never got why you'd need/want the word 'function' after the word 'async' in the spec. |
| 10:45 | <benjamingr> | I mean, what's bad with `async loadStory(){`? Not that it matters too much, I'm quite content with generators. |
| 11:27 | smaug____ | cries http://drafts.csswg.org/css-scoping/#selectordef-deep |
| 11:28 | <smaug____> | all the shadow dom stuff is getting so wrong |
| 11:33 | <annevk> | >>> lol |
| 11:34 | <annevk> | but clever |
| 11:35 | <smaug____> | since we end up exposing shadow dom to the outside world in all sorts of ways, couldn't we like just remove the 'shadow' part? |
| 11:35 | <smaug____> | grr |
| 11:36 | smaug____ | is getting more and more the feeling XBL2 would have been better approach |
| 12:01 | <annevk> | smaug____: yeah, it's not really a shadow DOM at this point |
| 12:01 | <annevk> | smaug____: it's more some kind of special descendants |
| 12:01 | <annevk> | smaug____: node tree -> composed node tree |
| 12:05 | <smaug____> | scoped tree |
| 12:06 | <MikeSmith> | well it's not it currently means "invisible DOM". but it's not really a shadow either |
| 12:06 | <smaug____> | hmm, no, usually one can't get easily from global scope to the inner scopes, for the sake of encapsulation |
| 12:06 | <MikeSmith> | regardless it's still a better name than ServiceWorker |
| 12:07 | <smaug____> | composed is perhaps fine. It doesn't hint anything about encapsulation |
| 12:07 | <jgraham> | I thought it was "shadow" as in "shadow of it's former self" |
| 12:07 | <MikeSmith> | isn't it always a documentFragment |
| 12:07 | <jgraham> | s/'// |
| 12:08 | <MikeSmith> | time to revivi "island" |
| 12:10 | <zcorpan> | <xml> |
| 12:11 | <zcorpan> | memories |
| 12:13 | karlcow | starts to imagine the shadow of the invisible man and wonders how it is supposed to work |
| 12:13 | <karlcow> | or is it just light gravitationally bended around the object. |
| 12:13 | <karlcow> | hmm |
| 12:14 | <karlcow> | gravitational lens DOM |
| 12:15 | <karlcow> | maybe just the blackhole DOM. Not visible but you know it's here through its effects on the surrounding |
| 12:15 | <karlcow> | so much emotion for today. |
| 12:16 | jgraham | calls dibs on writing the caustic spec for gravitationally lensed DOMs |
| 12:17 | <Ms2ger> | If only we had someone with a PhD in astrophysics... |
| 12:17 | jgraham | points at karlcow |
| 13:03 | <annevk> | Domenic: so now http://heycam.github.io/webidl/#initializing-objects-from-iterables exists, what is put in IDL? |
| 15:30 | <Domenic> | annevk: I dunno, not terribly important to me. Maybe Constructor(AddMapElementsUsing("set") iterable) or something? |
| 15:31 | <annevk> | Domenic: wfm |
| 15:40 | <wilhelm> | Do any browser vendors have data on how many users have changed the default font size and/or zoom level in their browser? |
| 16:45 | <Hixie> | zcorpan: I never understood that bug anyway, so... |
| 16:45 | <Hixie> | annevk: what's the difference between Foo[] and sequence<Foo> again?? |
| 16:46 | <annevk> | Hixie: the former cannot be used as method argument |
| 16:46 | <annevk> | Hixie: and should generally be avoided as nobody really wants it |
| 16:46 | <Hixie> | what are they, concretely? |
| 16:47 | <Hixie> | is Foo[] an actual Array? |
| 16:47 | <Hixie> | or a read-only array? |
| 16:47 | <Hixie> | or some other thing? |
| 16:47 | <TabAtkins> | sequence<Foo> as an argument means the object passed in will be iterated over and copied into a fresh array for use by the algorithm defining the function. As a return value it's an Array. |
| 16:47 | <TabAtkins> | I dunno what Foo[] does. |
| 16:48 | <Hixie> | so, if i have a FooEvent object and it has an attribute of type Foo[], do i not want the initFooEvent() method to take a Foo[] so the attribute can just be set to the same object as it was given? |
| 16:48 | <TabAtkins> | As soon as I was assured of which option gave me a normal Array, I immediately forgot about everything else. |
| 16:49 | <Hixie> | wow, yeah, Foo[] is not an Array but sequence<Foo> is |
| 16:49 | <Hixie> | that's confusing |
| 16:50 | <tantek> | I pity the Foo[] |
| 16:50 | <Hixie> | so presumably attributes can't be sequence<Foo>, right? |
| 16:51 | <TabAtkins> | smaug____: The point of shadow dom was never to 100% hide it from the outside world. (We need that ability eventually, to explain some built-ins, but not for normal stuff.) It's to hide stuff from *unintentional* access, which is the main problem with today's frameworks. |
| 16:51 | <Hixie> | since they'd have to return a new value each time |
| 16:51 | <Hixie> | TabAtkins: i think opinions vary on that, fwiw |
| 16:52 | <TabAtkins> | Hixie: I think you can do [SameObject] for it? But honestly, I have no fucking clue, becasue the entire array part of WebIDL is a terrible mishmash of things influenced by the older impulses for Java-compat. |
| 16:52 | <jgraham> | I think oopinions vary on whether that's an accurate portrayal of the history |
| 16:52 | <TabAtkins> | Hixie: That was definitely *our* original opinion, when we started working on "a new XBL, but have it make sense this time". |
| 16:53 | <TabAtkins> | It was literally "jQuery components are cool, but let's fix their flaws". |
| 16:53 | <Hixie> | TabAtkins: right, but given that "a new XBL" was the ~fifth iteration of that particular problem space, it's hardly the first set of opinions. :-) |
| 16:53 | <TabAtkins> | Right. I can't speak to previous iterations, just the one that I was a founding member of. ^_^ |
| 16:54 | <Hixie> | i wouldn't even say it was "ours". i mean, i was a founding member of this stuff too, if you count my many conversations with dglazkov when he was getting started as founding |
| 16:54 | <smaug____> | TabAtkins: once you add /deep/, accessing shadow dom accidentally becomes just as easy as with normal dom without /deep/ |
| 16:54 | <Hixie> | and i don't think i'd agree with that |
| 16:55 | <TabAtkins> | Hixie: We talked a good bit over this before you even got roped in. |
| 16:55 | <Hixie> | i think we were talking about this before you got hired, but ok :-) |
| 16:55 | <TabAtkins> | smaug____: "Accidentally" meaning "without invoking shadow-dom stuff". |
| 16:56 | <TabAtkins> | Yes, using /deep/, you can do more than you intend, but you'll never touch shadow things if you dont' use shadow combinators. |
| 16:56 | <smaug____> | sure, but you may access not-yours shadow doms |
| 16:56 | <smaug____> | just like without /deep/ you may access not-ours dom subtrees |
| 16:56 | <TabAtkins> | Using descendant combinators, you can do more than you intend. That doesn't mean we need to only allow child combinators. |
| 16:57 | <TabAtkins> | Hah, we hit the same metaphor. |
| 16:57 | <TabAtkins> | Well, simile. |
| 17:01 | <smaug____> | TabAtkins: so, if /deep/ is allowed, what is the point with shadow dom ? |
| 17:02 | <smaug____> | you now get access easily to all the shadow dom, unintentionally, and break things |
| 17:02 | <smaug____> | some encapsulation would be nice |
| 17:07 | <TabAtkins> | I'm not sure how you define encapsulation if "didn't show up in the normal tree at all, requiring special operations to access" doesn't qualify. |
| 17:10 | <smaug____> | well, /deep/ let's you poke any shadow dom. I would at least hope some specific "I want to access these shadow doms.". So ShadowRoot would need to have identifier, perhaps some kind of component class, like my-company-super-widget |
| 17:10 | <smaug____> | then deep("my-company-super-widget") |
| 17:10 | <smaug____> | something which forces dev to think which shadow dom to access |
| 17:11 | <smaug____> | and lets one to create inaccessible shadow dom (by not defining the component class) |
| 17:15 | <TabAtkins> | We definitely want to add more controls of visibility. |
| 17:16 | <smaug____> | stuff should be hidden by default |
| 17:16 | <smaug____> | and exposing opt-in |
| 17:16 | <TabAtkins> | Starting with the simplest form now (just hidden from normal access) because it's the most general and shuts our the fewest use-cases. |
| 17:19 | <TabAtkins> | We don't yet have a coherent proposal for what it means to "hide" a shadow DOM further, because there are multiple possibilities and it's actually quite complex |
| 17:19 | <Hixie> | haha, i've found a way to read a bit of information cross-origin on chrome |
| 17:19 | <TabAtkins> | The current behavior is at least coherent - all shadows are hidden from view unless you ask for them. |
| 17:19 | <Hixie> | the bit is "does this <embed> contain an image/svg+xml image" |
| 17:20 | <smaug____> | - bugs |
| 17:20 | <smaug____> | like exposing shadow dom during script execution in shadow dom |
| 17:21 | <TabAtkins> | Of course. |
| 17:21 | <TabAtkins> | Abutter coherent behavior is "totally sealed away forever", like UA stuff does, but that's very complicated to describe and honestly not a good default |
| 17:21 | <smaug____> | (not that scripts should be executed in shadow dom at all per specs, but again, bugs) |
| 17:22 | <smaug____> | why it is not a good default? |
| 17:22 | <TabAtkins> | There's probably a coherent middle ground, or even a slightly incoherent but useful one, but we haven't found it yet, and didn't want to hang ourselves in waiting for it. |
| 17:22 | <Hixie> | (seems like a pretty good default to me) |
| 17:23 | <TabAtkins> | smaug____: Totally sealed sounds good until you actually use it |
| 17:23 | <Hixie> | it's what we use every day with web controls |
| 17:23 | <Hixie> | what's wrong with it? |
| 17:24 | <TabAtkins> | We have relatively few, and relatively simple, shadows in the platform so far. Customizability is still a major issue |
| 17:24 | <TabAtkins> | Making things untouchable by default as shadows explode on number and complexity is very bad for usability. |
| 17:25 | <Hixie> | i disagree, but probably mostly because i have a different view of how the customisation should happen |
| 17:25 | <Hixie> | imho bindings should have two parts, the logic, and the presentation |
| 17:25 | <Hixie> | and most people should just overrride the presentation part of the binding |
| 17:26 | <Hixie> | each logic binding would define a "protocol" for how its presentation should be implemented |
| 17:26 | <TabAtkins> | I'm at lunch now, and I'll get on a plane afterwards, so I can't continue this convo today. |
| 17:26 | <Hixie> | this would let you arbitrarily restyle UA controls |
| 17:26 | <Hixie> | and the same would work with people's custom controls |
| 17:28 | <Hixie> | in other news, wtf browsers. |
| 17:28 | <Hixie> | anyone got IE? I need a tie-breaker. http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=3101 |
| 17:29 | <Hixie> | safari: getSVGDocument() only returns a Document if the MIME type was image/svg+xml _and_ the root namespace is the SVG namespace |
| 17:30 | <Hixie> | chrome: getSVGDocument() returns a Document if the MIME type of the currently loaded document is image/svg+xml |
| 17:31 | <Hixie> | but safari and chrome both are willing to load any MIME type in <embed> |
| 17:32 | <Hixie> | firefox: returns "NS_ERROR_FAILURE: on line 114" if the MIME type was image/svg+xml and the namesapce isn't SVG, and won't load other MIME types |
| 17:32 | <Hixie> | but if you navigate to an HTML doc from the non-svg svg doc, then get SVGDocument() returns the Document fine??? |
| 17:32 | <Hixie> | interop rating: 0.0 |
| 17:33 | <smaug____> | hmm, NS_ERROR_FAILURE is surprising |
| 17:41 | <Hixie> | better test http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=3102 |
| 17:43 | <Hixie> | ok, new info. safari requires the current document to have been loaded as image/svg+xml, and returns null for cross-origin accesses. |
| 17:45 | <Hixie> | chrome also requires the current document to have been loaded as image/svg+xml, but throws an exception for cross-origin accesses that would otherwise return a document. |
| 17:46 | <Hixie> | firefox returns the current Document regardless of MIME type, except that if it was opened as image/svg+xml, it tries to get an SVGDocument, and fails with NS_NOINTERFACE if it's actualy not an SVGDocument |
| 17:47 | <Hixie> | except if it's a data: URL, in which case it's NS_ERROR_FAILURE? |
| 17:47 | <Hixie> | and firefox follows the spec in terms of refusing to load non-SVG no-plugin MIME types |
| 17:47 | <Hixie> | but safari and chrome just treat the embed as an iframe if they support the type |
| 17:50 | <Hixie> | all the browsers look at what the current loaded doc is, though, not what the original doc was (not that it matters for firefox) |
| 17:54 | <Hixie> | guess i'll go with the safari behaviour for getSVGDocument(), and the firefox behaviour for loading. |
| 19:49 | <Hixie> | what exactly does the JS spec mean when it uses the term "abstract operation"? |
| 19:51 | <Hixie> | it just means "internal spec function", right? not "abstract" in the normal sense? |
| 19:54 | <Hixie> | man, i thought i'd be better able to understand the module loading system now, but i was wrong |
| 19:55 | <Hixie> | the whole of 15.2.* baffles me still |
| 20:53 | <Domenic> | Hixie: yes, internal spec function. although "function" has its own connotations that don't apply |
| 22:32 | <Hixie> | jorendorff: so despite my best efforts, i can't really figure out what happens when you have an "import" statement still |
| 22:33 | <jorendorff> | Hixie: import is a directive to the loader. It means "before you even think about running this code, |
| 22:33 | <Hixie> | i mean at a very concrete level |
| 22:33 | <jorendorff> | Hixie: load *that* module and its dependencies." |
| 22:33 | <Hixie> | involved loader records and all that |
| 22:33 | <Hixie> | involving |
| 22:34 | <Hixie> | does it involve CreateLoaderRecord()? |
| 22:34 | <Hixie> | nothing seems to call CreateLoaderRecord except Reflect.Loader(), which i assume isn't directly invoked by the spec |
| 22:35 | <jorendorff> | Hixie: I don't have time to explain in detail just now, but can we talk tomorrow? |
| 22:35 | <Hixie> | sure |
| 22:35 | <jorendorff> | Hixie: in short, CreateLoaderRecord shouldn't exist, those should be internal slots of the Loader object. It's just the Loader, that's all. |
| 22:36 | <Hixie> | "shouldn't" as in you disagree with the spec, as in the spec will be changed, or as in i should be ignoring that part of the spec? |
| 22:37 | <jorendorff> | i think the spec is unnecessarily complex, but and you should think of those as internal slots of the Loader object because that's what they are in practice |
| 22:37 | <jorendorff> | Hixie: the spec doesn't explicitly create a Loader; it specifies that one exists at startup, details to be supplied by the embedding |
| 22:37 | <jorendorff> | i'll be around tomorrow |
| 22:37 | <Hixie> | the spec is definitely unnecessarily complex, but it's the spec, so... :-( |
| 22:37 | <Hixie> | k |
| 22:42 | <Hixie> | gah i don't get this spec |
| 22:42 | <Hixie> | it has all these dangling definitions |
| 22:42 | <Hixie> | 26.4 The System Object |
| 22:42 | <Hixie> | The System object is the Loader Object instance associated with the Realm of the current global object. |
| 22:43 | <Hixie> | first of all, "Loader Object instance"? surely you can't have an instance of an object, objects _are_ instances |
| 22:43 | <Hixie> | secondly, the term "System Object" doesn't get mentioned anywhere else except that one sentence. |
| 22:44 | <Hixie> | 8.2 Code Realms "A Realm is specified as a Record with the fields specified in Table 20:" [...] "[[loader]]" [...] "The Loader object that can associate ECMAScript code with this Realm" |
| 22:44 | <caitp> | over 50% of implementors should be able to figure it out! [[snerk]] |
| 22:45 | <Hixie> | the term "[[loader]]" isn't mentioned anywhere else either |
| 22:45 | <Hixie> | 6.1.7.4 Well-Known Intrinsic Objects "Well-known intrinsics are built-in objects that are explicitly referenced by the algorithms of this specification and which usually have Realm specific identities." [...] "%Loader%" (no definition) |
| 22:46 | <Hixie> | %Loader% is only used twice: "The initialize value of Reflect.Loader is the %Loader% intrinsic object" and "The initial value of Reflect.Loader.prototype.constructor is the built-in %Loader% constructor" |
| 22:46 | <Hixie> | so, looks like we have three separate realm-specific Loader objects. but. none of them are used to load anything. |
| 22:48 | <Hixie> | does anyone implement any of this stuff? |
| 22:48 | <caitp> | i recall there was a bug for it on mozilla's tracker, dunno the status of it |
| 22:51 | <caitp> | and by "it" I really mean realms, because it's kind of a blocker for the rest of that I think? |
| 22:53 | <Hixie> | browsers have implemented realms for years (implicitly) |
| 22:53 | <Hixie> | i meant the Loader thing |
| 22:53 | <caitp> | is not Loader related to modules? |
| 22:54 | <caitp> | anyways, there's no bug found for "es6 loader" |