| 01:16 | <MikeSmith> | botie, forget context |
| 01:16 | <botie> | MikeSmith: I forgot context |
| 01:21 | <MikeSmith> | TabAtkins: Domenic thanks for the tip on <{link/rel/serviceworker}>, will update the https://github.com/whatwg/html/pull/2517#issuecomment-293070580 PR right now |
| 01:22 | <MikeSmith> | Bikeshed rocks |
| 01:24 | Domenic | 's entry settings object alarm goes off (re: wanderview's link) |
| 01:24 | <wanderview> | Domenic: that error message was written based on old spec text I believe |
| 01:25 | <wanderview> | and we haven |
| 01:25 | <wanderview> | we haven't implemented the new spec text yet for the multi-global tests you wrote |
| 04:37 | <HTH-GG> | 有人吗？ |
| 04:37 | <HTH-GG> | anyone there？ |
| 05:12 | <annevk> | aklein: we waited for two years on TC39 not looking at the problem much ourselves |
| 05:13 | <annevk> | aklein: when we then started looking after third state et al failed we found several things that could be tightly coupled in a rather nice way |
| 05:14 | <annevk> | aklein: and would not have been possible with the TC39 proposals |
| 05:16 | <annevk> | aklein: and then a subset of that functionality got extracted as a set of base classes since it turned out we did want it in multiple places |
| 05:16 | <annevk> | aklein: that last one was rather recent |
| 05:17 | <annevk> | wanderview: nothing I can help with right? I believe we removed all the exception "footguns" |
| 06:39 | <MikeSmith> | https://github.com/Fyrd/caniuse/issues/885#issuecomment-293136872 |
| 06:40 | <MikeSmith> | https://caniuse.com/ 🎉 |
| 08:46 | <annevk> | It seems really slow |
| 09:03 | <MikeSmith> | yeah |
| 09:04 | <MikeSmith> | same here |
| 09:04 | <MikeSmith> | loads slow |
| 10:48 | <hsivonen> | MikeSmith: do you still care about the HTML4 validation modes in v.nu code? |
| 10:50 | <MikeSmith> | hsivonen: nope |
| 10:50 | <hsivonen> | MikeSmith: thanks |
| 10:50 | <MikeSmith> | planning to yank them? |
| 10:50 | <MikeSmith> | if so, happy to help |
| 10:50 | <hsivonen> | MikeSmith: very possibly |
| 10:50 | <MikeSmith> | OK |
| 10:51 | <hsivonen> | I'm currently trying to make the parser go faster, and I'm wondering if I should keep the HTML4-related flags on the attribute names |
| 10:51 | <MikeSmith> | ah |
| 10:51 | <MikeSmith> | yeah especially if it would be a performance gain, no reason to keep them |
| 10:58 | <hsivonen> | good times. the parser knows about https://msdn.microsoft.com/en-us/library/ms533706(v=vs.85).aspx Can't even remember why. |
| 11:01 | <hsivonen> | apparently because HTML 4.01 reserves it for future use! |
| 11:02 | <annevk> | dataformatas I always read that as "data formatas", not "data format as" |
| 11:02 | <hsivonen> | me too |
| 11:03 | <hsivonen> | veryverythickmathspace |
| 11:39 | <annevk> | Domenic: your definition of "agent" was wrong too |
| 11:39 | <annevk> | Domenic: a user agent is allowed to have one event loop for all its browsing contexts |
| 11:40 | <annevk> | Domenic: do we just want to make that disallowed since it cannot be observed if a user agent does that or do we actually want to work around it some other way? |
| 12:02 | <annevk> | Domenic: what ECMAScript calls the "executing thread" is what we call the event loop |
| 13:04 | <wanderview> | annevk: right, I was just mentioning it hit a relatively large site unfortunately |
| 13:04 | <wanderview> | and I guess asking JakeA if they had plans to impl the footgun fixes |
| 13:06 | <JakeA> | I'll chase it |
| 13:08 | <wanderview> | maybe its fixed in canary? I only tested in release chrome... although I don't remember seeing a chromium issue for it |
| 14:04 | <annevk> | Reminder to self: don't volunteer for seemingly trivial tasks |
| 14:14 | <annevk> | JakeA: I have more detailed nits on the Abort stuff I think from a quick skim, but I'll wait a bit for more high-level feedback first |
| 14:14 | <annevk> | JakeA: overall though it seems ready enough to me to determine implementation interest and write tests |
| 14:15 | <JakeA> | annevk: Cool. I just pushed some more to the fetch branch. Will fix the nits |
| 14:17 | <annevk> | JakeA: I guess I would like to have it explained why we normalize to FetchSignal |
| 14:17 | <annevk> | JakeA: not in spec, here or in a comment on the PR is fine |
| 14:18 | <JakeA> | annevk: I was worried that devs might write code expecting request.signal to be a particular type, and get caught out when it turns out to be another type for a rare code path |
| 14:19 | <JakeA> | I guess the signal doesn't have methods though |
| 14:19 | <JakeA> | But if they expect .priority to be there & be a number |
| 14:20 | <annevk> | JakeA: if they don't pass one in themselves it'll just be null, no? |
| 14:20 | <annevk> | JakeA: and if they pass one in themselves it should be somewhat clear what they get |
| 14:20 | <JakeA> | annevk: I was thinking of cases where they get the request object from elsewhere |
| 14:21 | <annevk> | JakeA: yeah okay, I guess it's okay |
| 14:21 | <JakeA> | annevk: should I remove FetchController? |
| 14:22 | <JakeA> | I guess we don't need it |
| 14:22 | <annevk> | JakeA: you cannot get a FetchSignal otherwise and that would mean you always get an allocation each time you invoke fetch() with a signal |
| 14:22 | <JakeA> | Hah, although if we start with FetchSignal without .priority, developers are going to have to test for its existence anyway |
| 14:22 | <annevk> | JakeA: good point |
| 14:23 | <annevk> | JakeA: maybe just drop it entirely then |
| 14:23 | <JakeA> | annevk: agreed, I'll remove the casting |
| 14:23 | <JakeA> | pffft wish I'd figured that out early |
| 14:24 | <annevk> | Well, you've learned something I'm sure |
| 14:24 | <JakeA> | \o/ |
| 14:47 | <MikeSmith> | the only way Artur Janc could have a cooler name is if his first name were Antti |
| 16:04 | <Domenic> | annevk: I think it might be time to disallow that because SABs make it observable |
| 16:04 | <Domenic> | It seems related to how I had to delete the sequential consistency guarantee from early in the spec |
| 16:39 | <annevk> | Domenic: 1) apparently an Agent is not an event loop, but maybe SAB still makes it observable somehow? If so, that seems bad? |
| 16:39 | <Domenic> | I am still pretty sure an agent is an event loop. |
| 16:39 | <annevk> | Domenic: I just talked at length with lth in jslang and he told me that was wrong |
| 16:40 | <Domenic> | yeah i think he is wrong :) |
| 16:40 | <annevk> | sigh |
| 16:40 | <Domenic> | i know :-/ |
| 16:40 | <Domenic> | it was very surprising to wake up to find out the creator of agents thinks they are just redundant with realms |
| 16:40 | <annevk> | Domenic: 2) I noticed that JavaScript has consistency requirements for Agent clusters and when I ported that requirement over to HTML WebKit folks blocked it |
| 16:41 | <Domenic> | yeah, those were unilaterally added by lth without cross-browser agreement i guess |
| 16:41 | <Domenic> | we should probably raise that in tc39 |
| 16:41 | <annevk> | Domenic: in particular, those agent cluster requirements would apply to when you kill workers and such |
| 16:41 | <Domenic> | since i don't think the jsc folks realized what was being put in the spec |
| 16:41 | <Domenic> | and they should talk to their webkit teammates |
| 16:41 | <annevk> | more sigh |
| 16:42 | <annevk> | If someone wants to introduce a new platform feature they should really work it through all the way |
| 16:42 | <annevk> | We should try to make that a requirement of sorts, you can't just land something in ecma262 and call it a day |
| 16:42 | <annevk> | At least not something with obvious Host implications |
| 16:47 | <aklein> | annevk: re: cancellation. hypothetically, had ES shipped some cancellation thing a year ago, would fetch use it? or would you have said "no, we need this to mesh well with events"? |
| 16:47 | <annevk> | aklein: I suspect we would have used it |
| 16:48 | <annevk> | aklein: but a year ago we also had a pretty poor understanding of what this could look like |
| 16:48 | <annevk> | aklein: so we might have just gone down the fastline of adding cancelation since folks are waiting on that (and have been for over two years now) |
| 16:50 | <aklein> | annevk: oh, other question from yesterday. you said "observables are gone"...what was that in reference to? |
| 16:51 | <annevk> | aklein: I forgot who I got that from, but I got the distinct impression that it didn't have sufficient interest from implementers and the only host consumer might be events, and we could also solve events on our own |
| 16:52 | <annevk> | aklein: I got the impression there was not sufficient need to add it as a primitive to the core language |
| 16:52 | <annevk> | aklein: and so browsers wouldn't ship it |
| 16:53 | <aklein> | annevk: huh, I wonder if that's what you took away from our conversation |
| 16:53 | <annevk> | aklein: could be or maybe from Domenic, my memory is not super clear on it so maybe I'm just wrong |
| 16:54 | <aklein> | annevk: myself, as an implementer, I'm certainly cautious to add new core things to the language. but I think there is still interest in the committee, including at least one implementer |
| 16:54 | <annevk> | (not that memory is ever clear...) |
| 16:55 | <annevk> | aklein: okay, I have been blocking a bit on it in DOM as well as earlier indications TC39 might do some event thing (that was long ago though), but nothing materialized thus far and it does seem nice to make the event API a little better soonish |
| 16:56 | <annevk> | aklein: we got most of jQuery covered |
| 16:56 | <aklein> | annevk: Jafar is the person to talk to about whether it's dead or not. he hasn't been able to make it to the last few meetings, so it keeps getting dropped off the agenda. |
| 16:57 | <aklein> | annevk: but this cancellation is indeed an interesting place to re-raise the event question |
| 17:06 | <annevk> | aklein: it's somewhat problematic that stuff needs to be actively lobbied through a committee and host concerns are generally not cared much for |
| 17:09 | <annevk> | I guess that's too unspecific, but I've noticed this with jobs, SharedArrayBuffer (see what's an agent?), and maybe also things like observables |
| 17:09 | <annevk> | You really can only make a case when you're in the room or have someone in the room that knows the full argument |
| 17:27 | <annevk> | Domenic: I guess the silver lining is that even though I based things on settings objects, what I wrote down is easily convertible and more accurate in the worker edge cases (I think!) |
| 17:28 | <annevk> | Domenic: but with awb's comment I'm becoming somewhat surprised I've led myself be deluded that much, since I was involved in a bunch of the previous discussions |
| 17:37 | <Domenic> | annevk: awb's comment seems about right to me. In particular the "The realms in the set are private to the Agent and may not be accessible to any other agent." seems to break the 1:1ness |
| 17:37 | <Domenic> | (as I expected) |
| 17:46 | <annevk> | Domenic: yeah, I guess I just thought when lth told me that they revamped the whole concept somehow |
| 17:46 | <annevk> | Domenic: anyway, glad I filed the bug |
| 17:47 | <Domenic> | yeah, agreed |
| 17:48 | <annevk> | Domenic: I also like awb's suggestions of actually defining the internals in much more detail |
| 17:48 | <Domenic> | yeah honestly i thought at least some of those were already defined but i guess i haven't read the agents spec recently |
| 17:48 | <smaug> | it sounds like people have great misunderstanding about passive listeners |
| 17:49 | <smaug> | that they somehow magically make performance good everywhere |
| 17:50 | <Domenic> | I wonder what the source on https://twitter.com/antimattur/status/851850917662117888 is |
| 17:53 | <annevk> | smaug: oh my, not totally unexpected, but still |
| 17:58 | <annevk> | Domenic: let me know when you find it |
| 18:04 | <aklein> | annevk: I don't think there's any general fix here. cross-cutting concerns are cross-cutting. this comes up in plenty of places other than ES <-> HTML/DOM |
| 18:52 | <aklein> | annevk: in this case, I suspect that Lars's "document" just doesn't match your concept of "document". need to go catch up on the thread |
| 19:52 | <annevk> | aklein: I recommend reading the jslang backlog, we discussed it in depth |
| 20:01 | <aklein> | annevk: yeah, I see that this conversation is split across several media |
| 20:12 | <aklein> | annevk: having read all that, still seems like this is a miscommunication, not a fundamental flaw. hopefully the github issue will help sort out the communication issues |
| 20:13 | <Domenic> | yes, i am also leaning toward miscommunication |
| 21:57 | <Domenic> | TabAtkins or anyone: is there no default "W3C" boilerplate? In particular I am pretty sure CC0/OWFa is not correct when I put "Group: W3C" |
| 21:57 | <TabAtkins> | There is not, no. |
| 21:58 | <TabAtkins> | So you're just getting the default boilerplate with that group. |
| 21:58 | <Domenic> | hmm so if i want to write a spec without a group i need to submit a bikeshed PR for that group adding all the boilerplate? :-/ |
| 21:58 | <TabAtkins> | (There's no such thing as a generic W3C spec; everything's produced under a group.) |
| 21:59 | <Domenic> | s/"without a group"/for a group that isn't in Bikeshed's tree yet |
| 21:59 | <TabAtkins> | Nah, you can add the boilerplate locally in your spec folder. |
| 21:59 | <Domenic> | Well OK, that's slightly better, but still a lot of yak-shaving |
| 21:59 | <Domenic> | I guess I don't have any better suggestion though, just complaints |
| 21:59 | <TabAtkins> | It's... the minimum amount to actually publish a valid W3C spec? |
| 22:00 | <Domenic> | I guess the issue is I don't want to publish a valid W3C spec at this point, I just want to publish something that isn't under a license that'll get me in trouble. |
| 22:00 | <Domenic> | (in trouble when I do want to go through all the work of actually publishing, that is) |
| 22:00 | <TabAtkins> | Swap out the copyright.include locally, then. Just put in an "all rights reserved" or something for now. |
| 22:00 | <jyasskin> | Domenic: Which group is it in? Can you use WICG? |
| 22:00 | <TabAtkins> | Always easy to loosen things. |
| 22:00 | <Domenic> | jyasskin: web payments |
| 22:00 | <Domenic> | TabAtkins: copyright.include, roger roger. |
| 22:01 | <TabAtkins> | Domenic: And you can do that actually inside your spec. |
| 22:01 | <TabAtkins> | <div boilerplate=copyright>All rights reserved</div> should work. |
| 22:07 | <Domenic> | Seem to be in good shape. Thanks as always for the help. |
| 22:12 | <Domenic> | TabAtkins: wasn't there a way to tell Bikeshed how much indentation I plan on using? Can't find it searching for "indent" in the docs |
| 22:53 | <TabAtkins> | Domenic: Ah, hm, it's not documented. It's "Indent: <integer>" |
| 23:06 | <weinig> | Domenic: have a moment for a question or two about the new extended attributes on types in WebIDL? |
| 23:06 | <weinig> | might be the wrong dominic :( |
| 23:07 | <weinig> | nope, got it right! |
| 23:09 | <weinig> | basically, the question is, int the case of something like |
| 23:09 | <weinig> | [Clamp] attribute long foo; |
| 23:10 | <weinig> | should the [Clamp] be in annotated type of foo |
| 23:11 | <weinig> | The https://heycam.github.io/webidl/#idl-type-extended-attribute-associated-with algorithm stiplilates that is should for union, argument, dictionary and typedef productions, but not for attributes |
| 23:12 | <weinig> | tobie: perhaps you know |
| 23:27 | <Domenic> | weinig: back from dinner! Let's see |
| 23:27 | <weinig> | Domenic: hi there |
| 23:27 | <Domenic> | weinig: so the idea is that that is now an error since [Clamp] cannot be used except on types. We need to go update all the specs to do attribute [Clamp] long foo; |
| 23:27 | <Domenic> | I'm sorry we didn't do that immediately :( |
| 23:28 | <weinig> | Domenic: ok, I’m not sure there are any |
| 23:28 | <Domenic> | I think there might be some for [TreatNullAs], but yeah, I guess it is kind of rare in general |
| 23:28 | <weinig> | Domenic: I couldn’t immediately find any use like that in real use, only our tests |
| 23:28 | weinig | nods |
| 23:28 | <Domenic> | The more common case is [X] optional Y -> optional [X] Y |
| 23:28 | <Domenic> | in arguments lists |
| 23:29 | <weinig> | yes, is that still allowed? |
| 23:29 | <Domenic> | No, optional is an annotation on the type, so it needs to become optional [X] Y |
| 23:29 | <tobie> | Domenic was too fast for |
| 23:29 | <tobie> | me. |
| 23:29 | <tobie> | :) |
| 23:30 | <weinig> | Domenic: oh i see, so step 4 of https://heycam.github.io/webidl/#idl-type-extended-attribute-associated-with, is only refereing to the non-optional variant of the argument production |
| 23:30 | <weinig> | ok |
| 23:31 | <Domenic> | Yeah, I guess "within" is ambiguous between "directly within" and "within after expanding the grammar" |
| 23:31 | <weinig> | Domenic: I was a bit confused :) |
| 23:32 | <Domenic> | Let me file an issue and fix over the next day or two |
| 23:32 | <weinig> | Domenic: thanks |
| 23:34 | <Domenic> | https://github.com/heycam/webidl/issues/341 |
| 23:35 | <weinig> | the other question was what step 3 of that algorithm is trying to do, does it mean that for something like [Clamp] long or DOMString) , the longs annotated type might have [Clamp]? |
| 23:35 | <weinig> | or am I reading that totally wrong |
| 23:36 | <Domenic> | I think the intention is that [Clamp] (long or double) means that the long has a [Clamp] associated with it |
| 23:36 | <weinig> | Domenic: ok, |
| 23:36 | <Domenic> | I hope the parens are required when defining union types... |
| 23:36 | <weinig> | oh damn, I forgot a ( |
| 23:36 | <Domenic> | ah yes they are, phew |
| 23:36 | <weinig> | Domenic: they are, I just mistyped :( |
| 23:36 | <Domenic> | It'd be good to add examples to each of these steps, actaully |
| 23:37 | <weinig> | I am unclear how that doesn’t lead to an error case however, since the [Clamp] would get added to double as well, which is not allowed |
| 23:37 | <Domenic> | Oh, I forgot where clamp is allowed |
| 23:38 | <Domenic> | OK, integer types only, so I guess... there is no good example for clamp at least |
| 23:38 | <weinig> | Domenic: just integers |
| 23:38 | <Domenic> | Yeah and you can't put two integers in a union I am pretty sure |
| 23:38 | <weinig> | right, or two strings |
| 23:39 | <Domenic> | so i guess that step is pretty much dead code given the current set of extended attributes applicable to types |
| 23:39 | <weinig> | I guess, maybe in the future, there will be an extended attribute useful on all types :) |
| 23:39 | <Domenic> | But it will be very important for [AllowShared] |
| 23:39 | <Domenic> | Because then [AllowShared] (ArrayBuffer or Uint8Array or ...) will work |
| 23:39 | <Domenic> | We will likely typedef that to SharedBufferSource |
| 23:39 | <weinig> | cool beans |
| 23:39 | <weinig> | thanks, this really helped clarify things |
| 23:40 | <Domenic> | Awesome, glad to help. I'll do my best to reflect these things back into the spec ASAP. (And also update specs to use the new syntax.) |
| 23:54 | <MikeSmith> | howdy weinig! |
| 23:55 | <weinig> | hi MikeSmith! |
| 23:55 | <weinig> | MikeSmith: gotta run though :) |