| 05:35 | <rniwa> | annevk: yt? |
| 05:35 | <rniwa> | hayato: who works on custom elements spec now? |
| 05:36 | <annevk> | rniwa: about to get out of bed, but not really around for another two hours or so, unless it's something quick? |
| 05:36 | <rniwa> | annevk: fyi, i triaged a bunch of custom elements spec bugs |
| 05:37 | <rniwa> | annevk: and added v1 flags everywhere deemed necessary |
| 05:37 | <annevk> | great, I'll take a look today |
| 05:37 | <rniwa> | annevk: thanks. |
| 05:38 | <rniwa> | annevk: i'm somewhat concerned that custom elements spec hasn't been updated in the past month or two |
| 05:38 | <annevk> | We could maybe start putting it in DOM and HTML now |
| 05:39 | <annevk> | And fix things as we go |
| 05:39 | <rniwa> | annevk: lifecycle callback stuff certainly needs to go to WebIDL |
| 05:39 | <rniwa> | annevk: and DOM needs to enqueue tasks |
| 05:40 | <annevk> | True, it's a holy trifecta |
| 07:01 | <hayato> | rniwa: Yeah, we, google, are aware that it's very unsatisfying situation that custom elements hasn't been updated. |
| 07:24 | <annevk> | hey hayato, good afternoon |
| 07:25 | <hayato> | annevk: hi |
| 07:26 | <annevk> | hayato: still slowly wrapping my head around all the concepts to figure out how to best merge things into DOM/HTML etc. |
| 07:26 | <annevk> | hayato: plan to mostly work on that today |
| 07:26 | <annevk> | (it's still early here) |
| 07:26 | <hayato> | annevk: thanks. I guess that's tough work. |
| 07:29 | <annevk> | hayato: it's a little hard yes, especially figuring out when the various algorithms in Shadow DOM should run |
| 07:29 | <annevk> | hayato: unlike you, I haven't implemented it several times over the past five years 😃 |
| 07:29 | <hayato> | I'll take a look issues filed on the spec later. |
| 07:29 | <annevk> | Thanks |
| 07:30 | <annevk> | I started filing some issues against the HTML Standard too, sort of as a summary of what we should do / what we need to resolve |
| 07:30 | <hayato> | And I'll have yet another section to clarify a lot of things, mentioning iframe, script, title attribute on style, and so on... |
| 07:30 | <annevk> | A lot of decisions of not sharing anything with the shadow DOM breaks the composition use case quite badly |
| 07:31 | <annevk> | I wonder how important the composition use case is, if it's important we should make "open shadow trees" much more similar to normal "document trees" maybe, with <iframe> having history there, etc. |
| 07:34 | <hayato> | I see. Yeah, there has been always a debate between encapsulation vs *open* for better composition. |
| 11:19 | <Ms2ger> | annevk, fyi https://github.com/w3c/web-platform-tests/pull/2639 |
| 11:31 | <erlehmann_> | i just noticed that lists.whatwg.org is offline and there are no redirects put into place |
| 11:31 | <erlehmann_> | for example, https://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-November/033914.html has moved to https://lists.w3.org/Archives/Public/public-whatwg-archive/2011Nov/0186.html |
| 12:21 | <annevk> | http://nolanlawson.com/2016/02/29/high-performance-web-worker-messages/ is sad |
| 12:51 | <Domenic> | PR list is finally looking manageable |
| 12:51 | <zcorpan> | no unread notifications \o/ |
| 12:52 | <zcorpan> | time for a coffee |
| 12:52 | <Domenic> | zcorpan: can you finish up the <link> in body PR for igrigorik maybe? |
| 12:58 | <annevk> | Domenic: https://github.com/tc39/ecmascript_sharedmem/issues/65 might be of interest |
| 13:01 | <zcorpan> | Domenic: yes, it's my currently open tab :-) |
| 13:01 | <Domenic> | \o/ |
| 13:12 | <nox> | Domenic: I wonder if it's because Spring is coming. |
| 13:12 | <nox> | Domenic: Same thing happened to Servo's queue. |
| 13:20 | <jgraham> | jdm happened to Servo's queue |
| 13:22 | <nox> | That. |
| 13:34 | <nox> | Is there some summary of which Exposed combinations there are in the platform? |
| 13:55 | <annevk> | nox: there's 4 globals, workers are usually grouped |
| 13:56 | <nox> | annevk: Yeah I know, just need which combinations are actually used to implement Exposed in Servo. |
| 13:56 | <annevk> | nox: can't make it generic? |
| 13:57 | <nox> | annevk: I could, just don't want to. |
| 13:57 | <annevk> | Anyway, not sure about an exhaustive list of all combinations, best to grep a browser engine I guess |
| 13:59 | <nox> | annevk: Did the Constructor on XMLDocument go away? |
| 13:59 | <annevk> | nox: I don't think it ever had one |
| 13:59 | <nox> | (We have one in Servo but can't find it in DOM. |
| 13:59 | <nox> | Weird. |
| 13:59 | <nox> | Ms2ger: ^ |
| 14:02 | <Ms2ger> | Huh |
| 14:03 | <nox> | Ms2ger: Filing. |
| 15:56 | <annevk> | Domenic: I cannot make much sense of https://mxr.mozilla.org/mozilla-central/source/js/src/vm/StructuredClone.cpp |
| 15:56 | <Domenic> | oh boy |
| 15:57 | <Domenic> | So I ctrl+fed for "error" and didn't seem to find anything specifically prohibiting Error objects, which supports my hypothesis. Looking more... |
| 15:58 | <annevk> | There's a couple other files too, but I cannot make much sense of any of them |
| 15:59 | <Domenic> | https://mxr.mozilla.org/mozilla-central/source/js/src/vm/StructuredClone.cpp#1178 |
| 15:59 | <Domenic> | I think it is keying off of some equivalent of ES5's [[Class]] |
| 15:59 | <Domenic> | So it'll only do own-property cloning on things that return "[object Object]" |
| 15:59 | <Domenic> | which is how it excludes all the other things |
| 16:00 | <annevk> | That does kinda match what HTML used to have |
| 16:00 | <Domenic> | ("returns object Object" is not precise these days because of @@toStringTag. But it seems the engine has some concept similar to that.) |
| 16:00 | <Domenic> | Yeah, ES just totally blew up that infrastructure, lol |
| 16:01 | <annevk> | "any internal slot" seems okay, perhaps with two example objects in a note |
| 16:01 | <Domenic> | Yeah, I think that's probably going to be our best bet |
| 16:02 | <Ms2ger> | I see some GetBuiltinClass |
| 16:02 | <Ms2ger> | 842 * Enumeration describing possible values of the [[Class]] internal property |
| 16:02 | <Ms2ger> | 843 * value of objects. |
| 16:02 | <annevk> | Once we define IDL better we should also fix that integration a bit |
| 16:02 | <annevk> | All in due course I guess |
| 16:02 | <Domenic> | Very interesting how ES just totally removed this piece of infrastructure. Arguably for good reasons, but it does make things rather different. |
| 16:04 | <Domenic> | https://mxr.mozilla.org/mozilla-central/source/js/src/jsfriendapi.cpp#267 is interesting |
| 16:29 | <Domenic> | Whooooo wants to test Safari for me!! https://github.com/whatwg/html/issues/775#issuecomment-190796607 |
| 16:39 | <miketaylr> | Domenic: i can, sec |
| 16:39 | <miketaylr> | Domenic: https://cloudup.com/cACI0kI4fSV |
| 16:39 | <astearns> | https://www.irccloud.com/pastebin/B9sOMoOh/ |
| 16:40 | <miketaylr> | heh, 3rd behavior |
| 16:41 | <Domenic> | wait what |
| 16:41 | <Domenic> | Maybe these don't have constructor names in Safari? |
| 16:41 | <Domenic> | Hmm wait I brought my iPad to work, I can maybe do this |
| 16:43 | <Domenic> | OK yeah |
| 16:45 | <Domenic> | table updated, thanks all |
| 16:57 | <gsnedders> | Hmm. Is "BUT LET'S KISS." inappropriate to have on a slide? |
| 16:58 | <miketaylr> | gsnedders: depends, maybe the slide is a presentation meant for your significant other |
| 16:59 | <jgraham> | In that case it's clearly inappropriate |
| 16:59 | <jgraham> | I mean I'm not a relationship expert |
| 16:59 | <jgraham> | But if you are mainly communicating through powerpoint I think it might be beyond repair |
| 16:59 | <miketaylr> | ^^ |
| 17:00 | <annevk> | gsnedders: with KISS not being the abbreviation? |
| 17:01 | <gsnedders> | annevk: with KISS being the abbreviation |
| 17:01 | <gsnedders> | But it *is* a pun, made unclear by the capitalisation of all of it |
| 17:02 | <miketaylr> | you can pivot to a different pun http://www.post-gazette.com/image/2014/08/19/ca19,13,2172,1391/20140819hokissmag.jpg |
| 17:02 | <miketaylr> | but those guys are pretty gross |
| 17:03 | <miketaylr> | maybe i'm just jealous of that leather armor |
| 17:05 | <gsnedders> | hah |
| 17:09 | <gsnedders> | heh, my SO doesn't see how anyone could have any problem with it, thinking it can't really be construded as objectifying any specific person or group given it makes no statement as to who is being kissed. |
| 17:11 | <miketaylr> | the way to diffuse any potential drama it is to have a picture of kittens kissing in the slide |
| 17:11 | <miketaylr> | aww http://40.media.tumblr.com/tumblr_lxpj8u62Rh1r9z84ho1_500.jpg |
| 17:31 | <annevk> | Domenic: if you find some time, I would love for you to take a look at https://github.com/whatwg/html/pull/323 and figure out how you'd fix it |
| 17:31 | <Domenic> | Hmm OK. |
| 17:31 | <Domenic> | Doing custom elements right now. |
| 17:31 | <annevk> | Domenic: there's no rush at all, I'm just having such a hard time to get my head around it |
| 17:48 | <TabAtkins> | gsnedders: In general, avoid sexualized jokes entirely. |
| 17:48 | <annevk> | TabAtkins: FWIW, it still says [ENCODING] but it does now link to the right place |
| 17:48 | <TabAtkins> | annevk: Yeah, that's intentional. Again, minimum-effort until things are fixed. |
| 17:49 | <TabAtkins> | I want to just rip out the two lines handling this when SpecRef fixes things. |
| 17:49 | <gsnedders> | TabAtkins: see, that's what I would go for, really. |
| 18:06 | <JonathanNeal> | I’m looking for the latest Selectors API. Will #Element.findAll return a collection that extends Array? |
| 18:07 | <annevk> | JonathanNeal: see https://dom.spec.whatwg.org/ |
| 18:07 | <annevk> | JonathanNeal: that's the idea, but it's not reality yet, subclassing is taking its time |
| 18:09 | <JonathanNeal> | Oh, this looks different than what I saw before. Thanks, annevk! I thought .query & .queryAll would return a live collection and .find & .findAll would return a non-live collection. |
| 18:10 | <annevk> | JonathanNeal: find/findAll are gone |
| 18:10 | <TabAtkins> | They were renamed to query/All() because of the conflict with window.find(). |
| 18:10 | <annevk> | JonathanNeal: and new live collections are also gone (mostly, hopefully) |
| 18:12 | <JonathanNeal> | Got it, and Elements being a subclass of Array means it doesn’t inherit changes to Array prototype? |
| 18:12 | <TabAtkins> | No, it *does* mean that. |
| 18:12 | <annevk> | JonathanNeal: I don't know, is that how subclassing is different from proto chaining? |
| 18:12 | <TabAtkins> | Subclass means proto-chaining. |
| 18:13 | <annevk> | Yeah I thought so |
| 18:13 | <JonathanNeal> | So, in a sense, Elements.prototype = new Array()? |
| 18:13 | <TabAtkins> | I think it's closer to Elements.prototype = Object.create(Array.prototype) |
| 18:15 | JonathanNeal | was too old school to remember Object.create. Nods. |
| 18:41 | <Domenic> | No, it's in fact closer to Elements.prototype.__proto__ = Array.prototype |
| 18:41 | <Domenic> | (and Elements.__proto__ = Array) |
| 18:41 | <Domenic> | I seem to be accidentally rewriting the custom elements spec |
| 18:48 | <TabAtkins> | Domenic: Your first line requires *creating* Elements.prototype somehow first; my line does so, by making it an empty object with its proto set to Array.prototype. |
| 18:49 | <TabAtkins> | I did leave out the proto shenanigans of the constructor functions, yeah. |
| 18:49 | <caitp> | those proto shenanigans are important for subclassing |
| 18:50 | <TabAtkins> | I understand. I didn't say that I left it out intentionally. |
| 18:55 | <Domenic> | TabAtkins: your line overrides it. All functions have a .prototype |
| 19:00 | <nox> | https://github.com/whatwg/html/issues/775#issuecomment-190851825 |
| 19:06 | <Domenic> | yeah thanks for saving the day there |
| 19:30 | <TabAtkins> | Welp, I'm an idiot. Just figured out why I was getting 15s processing times on an empty spec. |
| 19:31 | <TabAtkins> | Turns out the invoking the HTML parser on a large CSS file hits some degenerate behavior and makes everything go very slowly. |
| 19:31 | <TabAtkins> | Welp, I'm an idiot. Just figured out why I was getting 15s processing times on an empty spec. |
| 19:32 | <gsnedders> | TabAtkins: so next PyPy and lxml releases should hopefully work together; will be interesting to revisit performance then |
| 19:46 | <rniwa> | dglazkov: yt? |
| 20:13 | <rniwa> | Domenic: yt? |
| 20:13 | <Domenic> | rniwa: yep |
| 20:13 | <rniwa> | Domenic: do you know who is responsible for updating custom elements spec these days? |
| 20:14 | <Domenic> | rniwa: myself and Koji probably; we have a meeting with Hayato to discuss that tomorrow |
| 20:14 | <Domenic> | rniwa: I am about 3/4 of the way through fixing a lot of things |
| 20:14 | <rniwa> | Domenic: okay |
| 20:14 | <rniwa> | Domenic: I'm more than happy to help out |
| 20:14 | <Domenic> | rniwa: I thought I'd do just a quick PR to get your text into the spec and then I kept updating things and now like 60% of the spec is new |
| 20:14 | <rniwa> | Domenic: but it's getting really hard to implement custom elements in WebKit without having anything concrete in the spec |
| 20:14 | <Domenic> | rniwa: that'd be great! |
| 20:15 | <rniwa> | Domenic: okay |
| 20:15 | <Domenic> | rniwa: let's land my PR then it should be easier to implement the remaining problematic parts |
| 20:15 | <rniwa> | Domenic: e.g. I could just start pushing PR for issues that aren't getting much traction |
| 20:16 | <rniwa> | Domenic: also, there is a lot of spec debt now. |
| 20:19 | <nox> | https://github.com/whatwg/html/issues/775#issuecomment-190885243 |
| 20:20 | <nox> | Domenic: Am I still right? |
| 20:20 | <Domenic> | nox: seems likely, attention on custom elements for now... |
| 20:21 | <nox> | Domenic: Good luck. |
| 20:59 | <Domenic> | I am feeling optimistic about integrating custom elements into DOM and HTML now |
| 20:59 | <Domenic> | Except for parsing. I am not optimistic about that. |
| 21:00 | <dglazkov> | I AM HERE!!! |
| 21:00 | <dglazkov> | wait |
| 21:00 | <dglazkov> | everything is solved |
| 21:01 | <Domenic> | I dunno somehow I just cloned the repo and one thing led to another and it just kinda happened |
| 21:02 | <dglazkov> | that's how it always goes. 3 years later you're the HTML spec editor. |
| 21:02 | <Domenic> | so true. so, so true. |
| 21:02 | <nox> | Is it known that for document.createElement(), Safari returns <undefined></undefined>? |
| 21:02 | <nox> | I think I died inside a bit. |
| 21:02 | <Domenic> | that's amazing |
| 21:03 | <nox> | Domenic: :D |
| 21:03 | <Domenic> | I guess Blink only recently fixed our `optional` handling |
| 21:03 | <nox> | Domenic: I was complaining to a friend about that all() thing, |
| 21:03 | <nox> | told me "meh, everything is optional in JS", |
| 21:03 | <nox> | wanted to prove him wrong. |
| 21:03 | <nox> | And then this happened. |
| 21:03 | <nox> | -_- |
| 21:16 | <caitp> | nox: that's since been fixed :x |
| 21:16 | <nox> | caitp: Nice to know. |
| 21:19 | <nox> | Domenic: Btw, GitHub understands language "webidl", if you want to colorise code snippets. |
| 21:19 | <Domenic> | nox: thanks, updated |
| 21:24 | <annevk> | roc: 👋 |
| 21:25 | <roc> | ta |
| 22:18 | <jgraham> | roc: :( |
| 23:53 | <rniwa> | Domenic: nice PR! |
| 23:54 | <rniwa> | Domenic: looking through it and found a few typos and errors |
| 23:54 | <Domenic> | rniwa: awesome, happy to fix up :) |
| 23:54 | <Domenic> | I said no editorial stuff but what I really meant was "no multi-day back and forth waiting for LGTMs over editorial stuff" |
| 23:54 | <rniwa> | Domenic: yeah, let's not do that stuff |
| 23:55 | <rniwa> | Domenic: btw, i think there's one big bug in my original / your PR about HTML constructor |
| 23:55 | <rniwa> | Domenic: which is the way the global object is obtained |
| 23:55 | <rniwa> | or rather Document object |
| 23:55 | <Domenic> | rniwa: I tried to fix that by using current Realm's global, but I didn't think about it as hard as I should have, which is often necessary with "which global object" questions. |
| 23:55 | <rniwa> | Domenic: it's totally reasonable for you create your own document via DOMImplementation or get iframe.contentDocument |
| 23:56 | <rniwa> | Domenic: and extend that document's prototype |
| 23:56 | <rniwa> | Domenic: in that case, we don't want to end up looking up the registry of whatever script realm you happen to be running |
| 23:56 | <Domenic> | hmmmm |
| 23:56 | <rniwa> | Domenic: so instead of doing that, I think we should just get the global object out of the prototype or the constructor object |
| 23:57 | <rniwa> | Domenic: or the global object of [[Prototype]] internal slot of the constructor |
| 23:57 | <rniwa> | Domenic: the latter one in particular should always be in the right(â„¢) document. |
| 23:58 | <Domenic> | Global out of the constructor function seems simplest |
| 23:58 | <rniwa> | Domenic: indeed |
| 23:58 | <rniwa> | Domenic: it's weird for your constructor to be extending another class in a different document anyways |
| 23:58 | <Domenic> | Yeah I'm trying to think if we can detect such mismatches and throw or something |
| 23:58 | <rniwa> | Domenic: but if we're going that rought, we may want to check that early in defineElement as well |
| 23:58 | <rniwa> | Domenic: so that author would catch it early |
| 23:58 | <Domenic> | right |
| 23:59 | <rniwa> | instead of your custom element never getting upgarded |
| 23:59 | <rniwa> | Domenic: oh wait, no |
| 23:59 | <rniwa> | Domenic: in the case you define class MyElement extends MyDocCreatedForHavingASeparateRegistry {} |
