| 01:21 | <karlcow> | annevk, MikeSmith: do you accept lurkers on that meeting? https://github.com/w3c/WebPlatformWG/blob/gh-pages/meetings/18-03-Web-components.md |
| 01:27 | <MikeSmith> | annevk: I would think you would be very welcome to attend |
| 01:28 | <MikeSmith> | just need to ask kochi probably |
| 01:28 | <MikeSmith> | not sure who will be the formal chair for the meeting |
| 01:30 | <kochi> | We already invited people from framework developers, so I think anyone is welcome to join. |
| 01:30 | <MikeSmith> | cool |
| 01:31 | <kochi> | probably what we need is just follow w3c's code of conduct. https://www.w3.org/Consortium/cepc/ |
| 01:31 | <kochi> | I haven't done setup for registration form kind of thing, for building security badge etc., and catering planning |
| 01:55 | <karlcow> | MikeSmith, kochi: thanks! |
| 01:56 | <karlcow> | I'm living in Japan. And my interest is more on the side of implementation differences in between browsers (webcompat hat). And I'm happy to stay silent for the full meeting. :) |
| 03:15 | <domfarolino> | Should the loading of a environment-matching style sheet requested by a <link> in <body> block the rendering of the page? |
| 06:48 | <shout-user501> | hi, over at https://html.spec.whatwg.org/multipage/webappapis.html#handler-onload I see "The following are the event handlers (and their corresponding event handler event types) that must be supported by all HTML elements other than body and frameset elements" |
| 06:48 | <MikeSmith> | shout-user501: yeah? |
| 06:48 | <shout-user501> | included in this list is onload - but I thought onload was only for certain elements? |
| 06:49 | <shout-user501> | see e.g. https://stackoverflow.com/questions/4057236/how-to-add-onload-event-to-a-div-element |
| 06:54 | <MikeSmith> | shout-user501: I guess it comes down to what “must be supported” means there |
| 06:54 | <MikeSmith> | that statement isn’t actually requiring any processing behavior |
| 06:55 | <shout-user501> | so it means supported as in adding it doesn't break anything? is this type of language common in the spec? admittedly I'm not well-versed in it |
| 06:57 | <MikeSmith> | adding onload to an element that the load event is never fired at isn’t going to break anything |
| 06:57 | <MikeSmith> | it’s just never going to have any effect |
| 06:57 | <MikeSmith> | as far as that type of language being common, not really |
| 06:58 | <MikeSmith> | arguably it’s a deficiency in the spec that it doesn’t make unambiguous what it means by “must be supported by all HTML elements” there |
| 07:02 | <shout-user501> | I was kind of looking for where the spec defines how it works precisely and which elements it applies to, but the section I found which describes that says it is "non-normative" https://html.spec.whatwg.org/multipage/indices.html#events-2 |
| 07:03 | <shout-user501> | nvm, I'm looking at a single page of the multipage version |
| 07:05 | <MikeSmith> | OK |
| 07:06 | <MikeSmith> | yeah, for the elements the load event actuall gets fired at, the spec explicitly states in each case, “Fire an event named "load"...” |
| 07:07 | <MikeSmith> | or some wording close to that |
| 07:07 | <shout-user501> | nice, i see that now :) |
| 07:11 | <shout-user501> | I noticed the comment "While these attributes apply to all elements, they are not useful on all elements. For example, only media elements will ever receive a volumechange event fired by the user agent" at one spot - aware of a good list which matches the events to the relevant elements? |
| 07:12 | <shout-user501> | took a look at MDN and it's not clear that they do - I guess maybe this is out of scope for the spec itself but it seems like it could be a handy reference thing for spec folks too |
| 07:15 | <annevk> | shout-user501: onload on body is special |
| 07:15 | <annevk> | shout-user501: it's actually tied to the Window object, iirc |
| 07:15 | <shout-user501> | yep, it's also special on embed and various other tags too |
| 07:16 | <shout-user501> | MikeSmith helped me out a fair bit already on that |
| 07:16 | <annevk> | shout-user501: I don't think it's special on embed? |
| 07:16 | <shout-user501> | "fired at an element containing a resource (e.g. img, embed) when its resource has finished loading" |
| 07:17 | <annevk> | That doesn't make the attribute special |
| 07:18 | <shout-user501> | seems to be fired on link, style, etc |
| 07:18 | <shout-user501> | well it's only fired on a small handful of elements, so it's special |
| 07:18 | <annevk> | Sure, but fired on is a different concept from the attribute |
| 07:18 | <annevk> | They're not really related |
| 07:18 | <shout-user501> | for me, if it's useful at all that makes it special |
| 07:18 | <annevk> | You can manually fire events of any type to anything that's an event target |
| 07:19 | <shout-user501> | since it technically is "supported" on all HTML elements |
| 07:19 | <shout-user501> | it's fired by the browser on a very small handful of elements |
| 07:19 | <annevk> | The attribute is; but that doesn't mean the event is dispatched by the UA on all of them |
| 07:19 | <shout-user501> | it is dispatched by the UA for embed and link tho, as well as body |
| 07:19 | <annevk> | No, I don't think it's dispatched on body |
| 07:20 | <annevk> | It's dispatched on the global, and the onload attribute on body gets actually registered there |
| 07:20 | <annevk> | That's why _that_ attribute is special |
| 07:21 | <shout-user501> | hmm, OK - ultimately the word special doesn't have much meaning anyway.. |
| 07:21 | <annevk> | Well, it has different behavior from what the attribute normally has |
| 07:21 | <shout-user501> | I think you might be coming at it from a spec / implementation perspective, whereas I am coming at it from an app development perspective |
| 07:21 | <annevk> | Normally it just registers a listener on the object it's associated with |
| 07:22 | <annevk> | I'm not sure how that matters |
| 07:22 | <shout-user501> | well, as an app developer it is fired when the resource loads - and the body is similar to an embed in that respect |
| 07:22 | <shout-user501> | not really special at all, just different types of resources |
| 07:23 | <shout-user501> | from a technical perspective, the fact that it ties into Window makes it seem more special? |
| 07:23 | <annevk> | Again, you're conflating events and event handlers |
| 07:30 | <shout-user501> | the UA does fire certain events which can only be captured against certain event handlers, right? I mean sure I can fire it in my app code but that seems like an antipattern |
| 07:31 | <shout-user501> | long-run I'd be personally be happy to see a system for warnings or errors on something like that |
| 07:32 | <shout-user501> | the non-normative explanation of load says "Fired at the Window when the document has finished loading; fired at an element containing a resource (e.g. img, embed) when its resource has finished loading" |
| 07:32 | <shout-user501> | to me those use cases seem quite similar, but you're saying they are conceptually quite differnet? |
| 07:34 | <shout-user501> | maybe you mean it's different because you can listen with window.onload as well as the body attribute |
| 07:35 | <annevk> | I'm saying that event handlers and events are different. E.g., if you registered an event listener on body for load using addEventListener() it would never trigger since the event isn't dispatched there. The event handler (onload) would trigger since it actually ends up registering a listener on window. |
| 07:36 | <annevk> | That's what makes that event handler special, whereas the others are pretty normal. You're right some objects are special in that the UA dispatches events on them, but that's not always closely correlated to the event handlers. |
| 07:36 | <shout-user501> | oh, interesting, that seems a bit unfortunately confusing |
| 07:56 | <annevk> | MikeSmith: I think we might have been measuring the wrong thing |
| 07:56 | <MikeSmith> | oh? |
| 07:56 | <annevk> | MikeSmith: you've only been looking at parents, not nearest ancestor article, nav, section, aside |
| 07:57 | <annevk> | MikeSmith: unless the caption is wrong |
| 07:58 | <annevk> | MikeSmith: either way, it'd be good to look through a sample of those multiple <h1>s |
| 08:08 | <MikeSmith> | annevk: right yeah I can change it to look at ancestors |
| 08:15 | <annevk> | MikeSmith: cool; I hope those numbers would line up a bit more with the 3% usage |
| 08:16 | <annevk> | MikeSmith: although on the other hand if they don't the change would not make much of an impact and is therefore fairly safe... |
| 11:26 | annevk | missed that Ms2ger eventually pushed more tests |
| 11:26 | <Ms2ger> | So, yeah, r? :) |
| 11:27 | <annevk> | Yeah looking now, though might take a while since I'm getting hungry |
| 11:59 | <annevk> | Ms2ger: hmm so what if a Blob is a WebM resource? |
| 11:59 | <annevk> | The specification for createImageBitmap() was really quite bad |
| 11:59 | <annevk> | Well, still is |
| 12:00 | <Ms2ger> | Per spec, it's not an image, so not supported, I guess |
| 12:00 | <annevk> | I guess that's fine |
| 12:02 | <annevk> | Ms2ger: although Safari added MPEG support to <img> so... |
| 12:02 | <annevk> | Without really defining what that means... |
| 12:02 | <Ms2ger> | I donno, man |
| 13:00 | <annevk> | surma: are you interested in creating a better test suite for structured cloning? |
| 13:01 | annevk | is looking at the current mess |
| 13:36 | <surma> | annevk: Seems like that might be in order, huh? |
| 13:41 | <annevk> | surma: yeah, we can then also add tests for Symbol throwing |
| 13:41 | <annevk> | surma: there's tests in webmessaging/ and in html/ in various folders |
| 13:41 | <annevk> | surma: html/browsers/history/the-history-interface and html/infrastructure/safe-passing-of-structured-data |
| 13:42 | <annevk> | surma: also workers/semantics/structured-clone |
| 13:44 | <annevk> | surma: my thinking is that we'd want a JavaScript resource that sets up various test scenarios and expectations and that's imported into various wrappers for the different APIs |
| 13:44 | <surma> | annevk: Alright. I’ll take a stab. Should I create a re-usable set of tests than can be used for all methods that use structured(De)Serialize under the hood? |
| 13:44 | <surma> | Ha! |
| 13:44 | <surma> | annevk: sg :) |
| 13:44 | <annevk> | much appreciated \o/ |
| 13:50 | <annevk> | surma: FWIW, stuff that'd be nice to be able to test include things like postMessage(Symbol(), "*", [new ArrayBuffer(2)]) throwing and not detaching the buffer (want to be able to test the order things happen in) |
| 13:51 | <surma> | annevk: Ah good one. |
| 13:52 | <surma> | I’ll go through the spec and see what I come up with :) |
| 13:52 | <annevk> | cool; once you have a framework I'm happy to help out filling it out for various objects |
| 16:29 | <Domenic> | shout-user501: another useful thing is that you can do e.g. body.ondragexit = ... and catch bubbled dragexit events. That is part of why those are defined on all elements. |
| 17:50 | <annevk> | Domenic: are records perhaps always passed by reference? |
| 17:50 | <annevk> | Domenic: in that case my pointer comment can be disregarded |
| 17:51 | <Domenic> | annevk: yeah I think everything in specs is, generally. I am going to check the PR soon, but my impression seeing it in my email was that it's not an issue. |
| 17:51 | <annevk> | kk |
| 17:52 | <annevk> | if this works it'd be a pretty sweet simplification |
| 18:14 | <annevk> | HTML has an interesting defense against -0: |
| 18:14 | <annevk> | > If sign is "positive", return value, otherwise return the result of subtracting value from zero. |
| 18:14 | annevk | is trying to find +0/-0 issues |
| 18:37 | <annevk> | Domenic: as I update https://github.com/whatwg/html/pull/3437, shall I keep it two distinct commits? |
| 18:37 | <annevk> | Domenic: or would you prefer a fixup commit? |
| 18:38 | <annevk> | Domenic: (I might not get to doing it until tomorrow, but would like to know how) |
| 18:38 | <Domenic> | Oh I didn't notice the two commits hmm |
| 18:38 | <Domenic> | annevk: can you remove the placeholder without the other change, or does it depend on the bugfix first? |
| 18:39 | <annevk> | Domenic: I think it can be done separately |
| 18:39 | <Domenic> | Hmm OK, then separate seems good. I'll try to understand better how that's possible... |
| 18:39 | <Domenic> | Maybe reorder so that goes first, if it's not extra work. |
| 18:41 | <annevk> | Domenic: let me try it in a new PR |
| 18:41 | <Domenic> | awesome |
| 18:41 | <annevk> | I have a bit of time |
| 18:42 | Domenic | keeps banging my head against is="" |
| 18:42 | <annevk> | I do not envy you |
| 18:42 | <Mek> | hmm, why does `bikeshed update` claim local data is already up-to-date, while showing me a timestamp from 3 days ago... did really nothing change between now and then? |
| 19:30 | <Mek> | hmm, DOM defines a Document's URL as being a URL record. Which would mean that if it's a blob: URL the url would contain that blob as its object, which from reading the spec means that for example location.reload() should work on a document created from a blob URL even after the blob URL is revoked (since it just passes the already parsed URL on to navigate/fetch...) |
| 19:30 | <Mek> | I wonder if any browser actually implements it like that... |
| 19:53 | <annevk> | Domenic: if instead of uninitialized value we use an empty record? Would that work? How is it different? |
| 19:55 | <Domenic> | annevk: I don't think so? The issue is you're changing only what memory[transferable] points to. But lots of other places, inside _serialized_ now point to the placeholder/uninitialized value, which don't get updated. |
| 19:56 | <Domenic> | annevk: I guess if you set it to an empty record and then instead of creating dataHolder, just updated all the fields of it, that would work |
| 19:56 | <Domenic> | Although records traditionally have a more fixed set of fields |
| 19:58 | <annevk> | Domenic: we already violate that with transfer steps |
| 19:58 | <annevk> | Domenic: although we could fix that |
| 19:58 | <Domenic> | No I mean once you create a record you don't change its fields |
| 19:58 | <Domenic> | Oh, yeah, we do |
| 19:59 | <annevk> | Domenic: I have an idea of how to fix both, but breaks downstream transferables if any |
| 19:59 | <Domenic> | Hmm |
| 19:59 | <Domenic> | Unsure if worth it, at least for transfer steps |
| 20:09 | <annevk> | Ok, we can consider that separately then |
| 20:11 | <Domenic> | I think the placeholder thing is not so bad, now that it's all defined in terms of lists and records at least. |
| 20:11 | <Domenic> | It was bad when it was within a graph of JS objects; it was like, how do you traverse such a graph? Does it trigger getters? Ugh. But now it makes sense. |
| 20:12 | <Domenic> | That said something like discussed above is probably more efficient, in the event implementers are anywhere close to verbatim following our algorithms. |
| 23:05 | <TabAtkins> | Mek: Because my computer at work auto-restarted while I'm in Sydney, and that's what runs the update script. I should be able to run it manually today. |
| 23:06 | <Mek> | TabAtkins: ah, okay, thanks |
| 23:52 | <TabAtkins> | Mek: Ran it manually now. |