| 00:17 | <apowers313> | does `bikeshed watch` watch more than one file at a time? or just the first .bs file it finds? |
| 01:32 | <MikeSmith> | TabAtkins: ⬆ |
| 09:32 | <smaug> | hmm, setting an enum attribute to a non-valid value doesn't throw? |
| 09:37 | <smaug> | had very much forgotten that |
| 09:54 | <tobie> | annevk, Domenic: I remeber reading a quite detailed proposal of internal slots somewhere. Can't seem to find it. Either of you have a pointer? I'd like to tackle that soonish. |
| 09:55 | <tobie> | I know there's this: https://www.w3.org/Bugs/Public/show_bug.cgi?id=27354 but there was some more recent thinking somehwere |
| 12:42 | <Domenic> | tobie: I don't remember any proposal. I do think this is an area where it'd be good to write up and debate something before starting on the work. |
| 12:52 | <tobie> | Domenic: absolutely |
| 12:53 | <Domenic> | One issue I wonder about is whether internal slots should have types |
| 12:54 | <Ms2ger> | Yes, definitely |
| 12:54 | <Domenic> | Sometimes it's useful, but sometimes you want to store something conceptual in them |
| 12:54 | <Domenic> | And since Web IDL types are "really" type conversions, it's not clear it makes sense to convert twice |
| 12:56 | <Domenic> | so for example a URL record https://url.spec.whatwg.org/#concept-url is not a Web IDL type |
| 12:57 | <Domenic> | So https://html.spec.whatwg.org/#concept-hyperlink-url would not be representable as a slot if we said slots must have types |
| 12:57 | <Domenic> | Similarly https://drafts.csswg.org/cssom/#associated-css-style-sheet |
| 12:58 | <Domenic> | Maybe just a strong convention of `// a <a href="...">CSS style sheet</a>` would make sense |
| 13:00 | <tobie> | Domenic: same kinds of questions here. I was wondering if it would also make sense to allow infra data structures in there. |
| 13:01 | <Domenic> | Yeah that's another common case |
| 13:02 | <Domenic> | My intuition is that typing them in any formal way would not work out |
| 13:02 | <Domenic> | Or at least would make them less useful/used. And thus be confusing: "oh, no, you meant the informal concept of internal slot, not the formal one which is only used sometimes because of these restrictions." |
| 13:03 | <Domenic> | I guess maybe if everything converted to infra it might work |
| 13:03 | <Domenic> | E.g. URL and CSS style sheet would become whatever we name https://github.com/whatwg/infra/issues/21 |
| 13:04 | <tobie> | Well, there a cases where you want to hold on to a webidl type, though. |
| 13:04 | <tobie> | Eg a promise, an instance of something related, etc. |
| 13:05 | <JakeA> | Domenic: I posted concerns at https://github.com/eslint/eslint/pull/7563#issuecomment-266733140 |
| 13:09 | <Domenic> | tobie: yes, but there's no single type system that encompasses Web IDL types + vague spec types. So I think `// a <a href="..."><code>Document</code></a>` would suffice for the Web IDL cases |
| 13:10 | <Domenic> | You can always hold Web IDL type instances without a formal type declaration documenting it. Use actual comments for documentation. |
| 13:10 | <tobie> | Yeah. This was to your point really. |
| 13:10 | <Domenic> | JakeA: I thought it was opt-in already |
| 13:12 | <JakeA> | Domenic: huh, http://eslint.org/docs/rules/no-await-in-loop#when-not-to-use-it makes it sound opt-out. Investigating… |
| 13:13 | <Domenic> | JakeA: http://eslint.org/docs/rules/ |
| 13:13 | <JakeA> | Domenic: ah, you're right |
| 14:03 | <tobie> | Domenic: not sure if my use case is uncommon, but I'd also need the equivalent of class-level slots (static slots?) |
| 14:03 | <Domenic> | tobie: that seems bad; just put them on Window then |
| 14:05 | <tobie> | Domenic: well, they're *really* class-level. E.g.: different instances of the Gyroscope class have a different frequency requirements at which to poll the underlying HW sensor. |
| 14:06 | <Domenic> | tobie: I'm confused, instance-level or class-level? |
| 14:06 | <Domenic> | Every class exists exactly once per Window instance so tying to Window makes more sense. |
| 14:06 | <Domenic> | That doesn't sound like a slot though, more like a constant |
| 14:07 | <tobie> | Domenic: at the class level, we look at all of the requested frequencies, pick the largest one, and use that one to determine at what freq to poll the sensor |
| 14:07 | <tobie> | Domenic: that value is revisited every time a new Gyro instance starts or stops listening to the sensor |
| 14:08 | <Domenic> | tobie: this sounds really confusing to me, so maybe needs to be part of the writeup. I maintain that anything class/static should go on Window instead, but it sounds like this has something to do with instances instead, so I am just confused. |
| 14:13 | <tobie> | Domenic: yeah--the sensor model is quite complex because there are multiple layers in between the JS and the underlying HW which are different per OS and HW. |
| 14:14 | <tobie> | Domenic: I also did a poor job of explaining it above. |
| 14:15 | howdoi | would wait to see finger print scanning, biometrics, SMS and contacts access from web |
| 14:16 | <tobie> | Domenic: Basically you have one HW sensor (e.g. a gyroscope), but you can create lots of instances of the gyroscope class which can all require a different polling frequency of the HW sensor. The HW sensor is then polled at the highest one of those. |
| 14:17 | <tobie> | Domenic: whenever you start or stop one of those gyroscope instance, you change the underlying HW polling frequency accordingly. |
| 14:17 | <Domenic> | OK. So you need some kind of map stored on Window, of which one entry is Gyroscope -> highest polling frequency? |
| 14:17 | <tobie> | Domenic: basically, yes. I hold on to all created instances. |
| 14:17 | <Domenic> | Seems like a GC nightmare, but I'm probably not understanding fully :) |
| 14:18 | <tobie> | Domenic: hopefully the latter. |
| 14:18 | <tobie> | :) |
| 14:26 | <tobie> | Domenic: regardless of these potential GC issues, I could just store the HW polling frequency value instead, but that would still a class-level slot. |
| 14:26 | <tobie> | Domenic: you'd just stick those on window? |
| 14:26 | <Domenic> | yeah |
| 14:27 | <tobie> | What about the naming collision? |
| 14:27 | <Domenic> | Add a prefix if you're worried about it |
| 14:27 | <Domenic> | Seems better than inventing a new parallel concept with different semantics |
| 14:28 | <tobie> | Well, don't we already have static attributes and constants? |
| 14:28 | <Domenic> | yep, which are paralllel concepts with different semantics from instance attributes |
| 14:29 | <Domenic> | (or rather, prototype attributes) |
| 14:32 | <tobie> | Domenic: to be clear, I have no idea whether my particular use case is common or not. If it isn't, there no point in working out a dedicated solution for it. |
| 14:37 | <tobie> | Domenic: how would you handle flags? Turn them into booleans? |
| 14:38 | <Domenic> | Leaving them as flags seems fine? |
| 14:40 | <tobie> | Domenic: if instance.[[flag]] is set, then ... ? |
| 14:41 | <Domenic> | Yeah seems fine |
| 14:44 | <tobie> | Domenic: k |
| 16:06 | <Ms2ger> | Domenic, you asked whether they should have types, not WebIDL types |
| 16:07 | <Domenic> | Ms2ger: I was kind of assuming inventing a new type system was not a project anyone wanted to take on |
| 16:07 | <Ms2ger> | You'd be surprised... |
| 16:08 | <Ms2ger> | However, I'm not sure if we'd be inventing a new type system; all we need is a link to a BS definition, really |
| 17:27 | <innovati> | Hi all! |
| 17:28 | <innovati> | I've been working on a few ideas related to CSS that I think would help with writing HTML and building websites - is this the right spot to get feedback and discuss ideas? |
| 17:47 | <TabAtkins> | tobie: Re "why are non-exported DFNs still displayed in the Terms defined by this specification section?", because they're still terms defined by the specification, just ones intended for internal use. Still useful to have them in the index. |
| 17:48 | <TabAtkins> | apowers313: Re "does `bikeshed watch` watch more than one file at a time? or just the first .bs file it finds?" The documentation should be clear on this <https://tabatkins.github.io/bikeshed/#cli-watch>; |
| 17:50 | <TabAtkins> | JakeA: We're not currently tracking all *links* in Shepherd, tho that's possible (and desired by me). |
| 17:53 | <JakeA> | TabAtkins: good to know! |
| 17:54 | <annevk> | tobie: I was sorta hoping for consolidated types across IDL and Infra, but a good first step might be to start defining slots without being explicit about that |
| 17:54 | <annevk> | tobie: or only being explicit about that part in prose |
| 18:39 | <astearns> | innovati: probably better to start at https://discourse.wicg.io/ - see if anyone's working on something similar, first |
| 18:41 | <innovati> | I'm on there, and one of the ideas seems to have fizzled out, the other has some activity but I'm not sure how to keep the ball rolling! |
| 22:22 | <tantek> | annevk: I'm not seeing the OWFa licensing text in some recent WHATWG spec updates - did those get removed? |
| 22:22 | <tantek> | e.g. I know https://dom.spec.whatwg.org/ used to have it at the top - where did it go? |
| 22:22 | <tantek> | also I'm getting a cert error on https://domparsing.spec.whatwg.org/ |
| 22:23 | <tantek> | yes, at some point OWFa got dropped from all of these specs: https://wiki.mozilla.org/Standards/license#WHATWG |
| 22:24 | <tantek> | that seems like a pretty major regression |
| 22:24 | <tantek> | CC0 is still there at the bottom of the document, but that's not enough |
| 22:24 | <annevk> | tantek: I remember we discussed that when it was done |
| 22:24 | <tantek> | I have no memory of any discussion of dropping OWFa |
| 22:25 | <tantek> | I would have strongly objected |
| 22:25 | <annevk> | tantek: the problem with OWFa is that we didn't actually have signed forms |
| 22:25 | <tantek> | after we had Mozilla's lawyers even provide/approve specific language to dual license CC0 OWFa |
| 22:26 | <annevk> | tantek: I see, file an issue? I can look at that when I'm back |
| 22:26 | <tantek> | that wording was done in such a way not to need separate signatures. that with every commit it was re-acknowledged |
| 22:26 | <tantek> | ok |
| 22:26 | <tantek> | on any particular spec? |
| 22:26 | <tantek> | because it looks like a spec-wide issue |
| 22:27 | <tantek> | the desired language (and markup) is here: https://wiki.mozilla.org/Standards/license#Markup (has been stable for years) |
| 22:31 | <tobie> | TabAtkins: re: ECMAScript throw, it turns out that non "ES throw" has a for="exception" attribute. |
| 22:31 | <tobie> | TabAtkins: today it seems you can omit it, as it's the only dfn called "throw" in the whole spec. |
| 22:33 | <tobie> | TabAtkins: if I move [=es throw|throw=] to [=ECMAScript/throw=], will folks referencing [=exception/throw=] need to move from [=throw=] to [=exception/throw=]? |
| 22:33 | <tobie> | TabAtkins: or does what you explained in PR#250 work for that case too? |
| 22:33 | <TabAtkins> | That's exactly the case I described in #250, I think. |
| 22:36 | <tobie> | TabAtkins: yeah, that's sort of the conclusion I came to as I was writing the last sentence down. |
| 22:36 | <TabAtkins> | hehehe |
| 22:37 | <tobie> | I wish the mental model I have of DFNs actually matched the one you've implemented. |
| 22:37 | <TabAtkins> | It's the same model, basically, as @font-face vs 'font-family'. Which is to say, slightly confusing for people until they finally "get" it. |
| 22:38 | <tobie> | yeah--"finally'"s been taking a while, here. |