| 00:00 | <jyasskin> | Hi HTML folks. aboxhall is working on AOM, and part of that seems to be reflecting ARIA attributes into WebIDL properties. Some "boolean" ARIA attributes have 3 states, true, false, and not-present. For example, <elem aria-expanded="false"> is semantically different from <elem>. Our current guess for how to express this is to make ariaExpanded a `boolean?` attribute on Element, where 'null' means the attribute is |
| 00:00 | <jyasskin> | not-present. What do the reflection experts think? annevk, Domenic |
| 00:03 | <aboxhall> | also note that <elem aria-expanded> is not valid |
| 00:03 | <aboxhall> | at least as currently specced. |
| 00:14 | <jyasskin> | aboxhall: We'll need to specify the value of the property when the attribute has an empty value. I'm inclined to follow https://html.spec.whatwg.org/multipage/common-microsyntaxes.html#keywords-and-enumerated-attributes, pretending that the ARIA attributes are enumerated between "true", "false", and missing. Then ARIA's defined default value is the missing value default, and that's what's used for the invalid "" |
| 00:14 | <jyasskin> | value. |
| 00:58 | <Domenic> | jyasskin: aboxhall: I would reflect as a DOMString. The fact that some of the states use the English words "true" or "false" should not mislead you into thinking they are booleans. |
| 00:58 | <aboxhall> | sgtm |
| 00:59 | <Domenic> | I was also told some of them use more than those two states (+missing) so that factors into it |
| 01:01 | <jyasskin> | Domenic: 'k. |
| 01:23 | <TabAtkins> | Learn from CSS's rule: NO BOOLEANS |
| 01:23 | <TabAtkins> | else be haunted by the specter of `enum { "true", "false", "file_not_found" }` |
| 03:55 | <MikeSmith> | https://bugs.webkit.org/show_bug.cgi?id=181778 webkit adding deprecation warning for documens that use appcache |
| 03:56 | <MikeSmith> | > ApplicationCache is deprecated. Please use ServiceWorkers instead |
| 04:10 | <aboxhall> | @TabAtkins I think the ship sailed on that one already |
| 04:11 | <TabAtkins> | At least they're Boolean strings right now. 😀 |
| 04:14 | <aboxhall> | some of them :) |
| 04:14 | <aboxhall> | https://www.w3.org/TR/wai-aria-1.1/#aria-invalid |
| 05:26 | <annevk> | It's somewhat unfortunate ARIA never addressed my feedback on those types back when it was still feasible |
| 05:26 | <annevk> | Anyway, strings indeed seem better than nullable booleans |
| 05:32 | <annevk> | MikeSmith: yeah, though multiple <main> is three times as high as <main> in <form>, but I guess it might still be worth looking what the actual usage is like |
| 05:39 | <MikeSmith> | annevk: ok later today I can bundle up all the logs and then run them through `sort` and `uniq` on them |
| 05:39 | <MikeSmith> | maybe after it’s been collecting for a full 24 hours |
| 05:40 | <MikeSmith> | to account for getting a range of local differences and what across a whole day |
| 05:40 | <MikeSmith> | it’s at around the 14 hours mark now |
| 05:41 | <annevk> | MikeSmith: can you share the URLs later too? |
| 05:41 | <MikeSmith> | yeah that’s what I mean actually |
| 05:41 | <annevk> | MikeSmith: okido |
| 05:41 | <MikeSmith> | yeah, that’s what’s in the logs that’s not on the stats page |
| 05:45 | <MikeSmith> | also by 24 hours it will have collected data for nearly a million requests (there are 5 separate instances of backend running, each handling 8000+ requests an hour) |
| 05:50 | <MikeSmith> | annevk: in other news, dunno if you looked at https://stackoverflow.com/questions/47158940/include-authorization-header-using-fetch-api-post-method but if/when you do, been wondering if you might have any insight |
| 05:55 | <annevk> | MikeSmith: added a comment, seems like an impl bug |
| 05:57 | <MikeSmith> | k |
| 05:57 | <MikeSmith> | thanks |
| 08:50 | <annevk> | MikeSmith: HTML build just reported "Error: Could not find or load main class nu.validator.client.SimpleCommandLineValidator" |
| 08:51 | <annevk> | MikeSmith: it also says wattsi is out of date |
| 08:51 | <annevk> | MikeSmith: https://travis-ci.org/whatwg/html/builds/330258050 |
| 09:14 | <MikeSmith> | OK |
| 09:14 | <MikeSmith> | will get it fixed asap |
| 09:30 | <annevk> | thanks |
| 09:33 | <tobie> | annevk: looking at whatwg/html#3370. How can I help? |
| 09:35 | <annevk> | tobie: I guess there's two questions; how to best go about a [LegacyNonObjectIsNull] for this argument |
| 09:35 | <annevk> | tobie: and if you've seen the other requests about a method that takes dictionaries of various types and the type depends on some other argument of the method |
| 09:35 | <annevk> | tobie: I vaguely recall the permissions API needing that |
| 09:36 | <annevk> | tobie: and some other API having a similar pattern |
| 09:36 | <tobie> | annevk: that definitely rings a bell |
| 09:36 | <annevk> | tobie: it might be time to start thinking about an abstraction? |
| 09:36 | <tobie> | annevk: in the form of an abstract operation specs could call? |
| 09:39 | <tobie> | annevk: I haven't thought this through, but that doesn't seem trivial to organize in a way that's generic enough and yet still easier on the editor than writing the thing from scratch |
| 09:39 | <MikeSmith> | annevk: pushed new jar to https://sideshowbarker.net/nightlies/jar/vnu.jar so maybe restart the build |
| 09:39 | <MikeSmith> | annevk: as far as the message about the wattsi version, dunno why that would happen |
| 09:40 | <MikeSmith> | but in teh travis log I see: |
| 09:40 | <MikeSmith> | Step 3/18 : ADD wattsi /whatwg/wattsi |
| 09:40 | <MikeSmith> | ---> Using cache |
| 09:40 | <MikeSmith> | ---> 0bb32c4da856 |
| 09:40 | <MikeSmith> | Step 4/18 : RUN cd /whatwg/wattsi && /whatwg/wattsi/build.sh |
| 09:40 | <MikeSmith> | ---> Using cache |
| 09:40 | <MikeSmith> | ---> ca6e77bba158 |
| 09:40 | <MikeSmith> | “using cache”, not sure what that means |
| 09:44 | <annevk> | MikeSmith: k, I'll restart the build |
| 09:45 | <annevk> | tobie: I was thinking of associating the arguments somehow |
| 09:46 | <annevk> | tobie: you make it accept a union of dictionaries or some such, but only if the dictionaries contain a value that another argument needs to be for them to be used |
| 09:47 | <tobie> | annevk: I dread to think of which algorithms you need to touch to enable that. |
| 09:48 | <tobie> | annevk: but it's certainly doable |
| 09:48 | <tobie> | annevk: … if you got a twisted mind and a knack for complexity. |
| 09:49 | <annevk> | tobie: yeah, maybe prose is better, I just noticed that in https://w3c.github.io/permissions/#permissions-interface it actually depends on a dictionary member |
| 09:51 | <tobie> | annevk: yeah that was my concern, the "thing that helps pick the type" might have too many different shapes to allow for a simple enough solution |
| 10:46 | <annevk> | MikeSmith: fancy reviewing https://github.com/whatwg/wattsi/pull/67 if it's not too late? |
| 10:58 | <annevk> | foolip: could you otherwise review it? And do you know that if we land it, would it be picked up by the HTML build process immediately? |
| 12:12 | <foolip> | annevk: changes in wattsi will be automatically used by html-build, yes |
| 12:13 | <foolip> | annevk: is it the extra commit you want review of, or all of it? |
| 12:36 | <annevk> | foolip: the complete PR as it is now would be best |
| 12:42 | <annevk> | foolip: thanks, that comment can be addressed, but is more tricky than you might have thought as later on there is also a conditional for a span element that does something else |
| 12:42 | <annevk> | foolip: so I'd have to bring that up a bit |
| 12:42 | <annevk> | foolip: but I'll see about doing that |
| 13:03 | <annevk> | foolip: that too longer than desired... |
| 13:03 | <annevk> | foolip: verifying results now |
| 13:04 | <annevk> | foolip: please take another look |
| 13:05 | <foolip> | annevk: yes, that isn't what I thought would happen :) |
| 13:06 | <foolip> | annevk: oh, so it's a huge if-else branch and that change made the second branch unreachable? makes sense, did we have tests to catch that? |
| 13:07 | <foolip> | annevk: reviewed |
| 13:07 | <annevk> | foolip: we don't have tests around wattsi other than running html-build |
| 13:08 | <annevk> | foolip: this is the main thing why I don't like not committing the output in Git somewhere as it's unclear when we regress something |
| 13:09 | <annevk> | foolip: I haven't tried running the code though where that second branch would be unreachable as I had already read ahead at some point and knew I'd have to change that |
| 13:10 | <foolip> | annevk: we could commit all output to the whatwg.org repo and deploy from that, but we'd only look at it after things have broken |
| 13:11 | <annevk> | foolip: I would not particularly mind such a setup |
| 13:12 | <annevk> | foolip: can also help catch bikeshed regressions |
| 13:12 | <annevk> | (if we do it for everything) |
| 13:16 | <annevk> | foolip: it's weird that the build log claims wattsi is out-of-date, despite it using the latest wattsi |
| 14:48 | <tobie> | WebIDL says: "The global environment that a given platform object is associated with can change after it has been created." When does that happen? |
| 14:57 | <nox> | tobie: window.open can do that, I think. |
| 14:58 | <nox> | Err, document.open, sorry. |
| 15:00 | <tobie> | nox: thanks (I've never used document.open iirc, have to look it up) |
| 15:01 | <nox> | tobie: I implemented part of it in Servo, my opinion is that the less you know about it, the better your life will be. |
| 15:01 | <benjamingr_> | Hmm, I need to respond to a fetch from the main window, do I just postMessage everything back and forth or is there any ETA on being able to create a stream and transfer it? |
| 15:01 | <tobie> | nox: the problem is this can pretty much be said about all parts of WebIDL |
| 15:05 | <jgraham> | I think document.open is pretty special in that way |
| 15:07 | <tobie> | jgraham: in the way of being a net negative to your quality of life? |
| 15:07 | <tobie> | jgraham: or in the way its mucks around with realms? |
| 15:07 | <tobie> | jgraham: or maybe both |
| 15:09 | <annevk> | FWIW, only Firefox replaces the global for document.open() |
| 15:09 | <annevk> | I'm no longer convinced that's the best way forward |
| 15:10 | <annevk> | Though I also haven't done enough research into the other implementations to make that go away |
| 15:11 | <annevk> | benjamingr_: https://github.com/whatwg/streams/issues/244 and https://github.com/whatwg/streams/issues/276 seem to touch on that |
| 15:12 | <annevk> | benjamingr_: ricea might know if there's anything recent on transferable streams |
| 15:12 | <benjamingr_> | Thanks, I saw those but wasn't sure if those were the most recent |
| 15:14 | <benjamingr_> | It would really make our lives easier, we're (re)building a large product on top of ServiceWorkers that intercept video requests and deliver them over WebRTC DataChannels instead of over HTTP |
| 15:14 | <annevk> | benjamingr_: can't find anything else and that repo would be the place to have the discussion I think |
| 15:16 | <benjamingr_> | Of course, WebRTC on the service worker would be even better, but that's a much bigger thing to request and it looks like it didn't progress a lot since it was last asked 2 years ago. |
| 15:43 | <Ms2ger> | tobie, both |
| 15:48 | <tobie> | So looking at https://heycam.github.io/webidl/#es-interface, and in particular: |
| 15:48 | <tobie> | "The result of converting an IDL interface type value to an ECMAScript value is the Object value that represents a reference to the same object that the IDL interface type value represents." |
| 15:52 | <tobie> | Boy, I'm so confused about what the above implies, I can't even formulate a question |
| 15:55 | <tobie> | Does that imply that the "platform object" is an underlying object that both WebIDL and ES bindings talk to? |
| 16:03 | <tobie> | Or put differently: If I were to specify an abstract operation "create a platform object" that could be called from a WebIDL constructor, how would there be ES objects mapping these WebIDL-created platform objects that could be used in the conversion process quoted above? |
| 16:24 | <Ms2ger> | So I guess there's two ways to approach it |
| 16:24 | <Ms2ger> | One is that the platform object is something separate from the JS Object value, and there's bidirectional pointers between them |
| 16:25 | <Ms2ger> | The other is that a platform object is "just" a JS Object with some extra [[Slot]]s |
| 16:25 | <Ms2ger> | Not sure which would be best |
| 16:47 | <tobie> | Ms2ger: so when a spec says: "create a new Foo object" (where Foo is a WebIDL interface) what *is* the object created? |
| 16:47 | <tobie> | Ms2ger: "an interface type value"? |
| 16:47 | <Ms2ger> | Both? :) |
| 16:49 | <tobie> | you mean both an interface type value AND an JS "platform object" are created? |
| 16:49 | <Ms2ger> | I think that's a reasonable way to spec it |
| 16:49 | <tobie> | Ms2ger: or do you mean a single object that is both these things is created? |
| 16:49 | <tobie> | Ms2ger: oh, the former. |
| 16:50 | <Ms2ger> | Well, that depends on which of my two approaches you pick |
| 16:50 | <tobie> | Ms2ger: are you saying the WebIDL spec currently is ambiguous about that? |
| 16:51 | <Ms2ger> | Yes |
| 16:52 | <Ms2ger> | But it doesn't really matter which way you go; they should be indistinguishable from outside |
| 16:53 | <tobie> | Ms2ger: I'd want to be consistent with the rest of the spec |
| 16:53 | <tobie> | Ms2ger: and when I read something like: https://heycam.github.io/webidl/#idl-objects |
| 16:53 | <tobie> | Ms2ger: I'm quite confused. |
| 16:54 | <tobie> | Ms2ger: this really seems to describe platform objects as the ES stuff |
| 16:55 | <tobie> | Ms2ger: but then it's not in the bindings section |
| 16:55 | <Ms2ger> | I think the problem is that WebIDL doesn't really know how it wants to approach this |
| 16:56 | <tobie> | Ms2ger: note this is the same for the {{object}} WebIDL type |
| 16:56 | <tobie> | Ms2ger: which remains somewhat of a mistery to me |
| 16:57 | <tobie> | Ms2ger: and feels more like: "I couldn't use a dictionary or a record here, so fuck it." |
| 17:01 | <tobie> | Ms2ger: looking at https://heycam.github.io/webidl/#es-platform-objects it really seems platform objects designate the JS objects and not the WebIDL ones |
| 17:02 | <tobie> | Ms2ger: so this feels like we need on one hand a "create a interface type value" abstract op |
| 17:02 | <tobie> | Ms2ger: and on the other, and "create platform object" abstract op that takes an interface type value and a realm as argument |
| 17:03 | <tobie> | s/and/a/ |
| 17:04 | <Ms2ger> | But what realm would you use? I think you always want to define the realm at the point where you'd use the "create a interface type value" abstract op |
| 17:07 | <Ms2ger> | I guess my question is: what is the benefit of having both algorithms be distinct |
| 17:08 | <tobie> | Ms2ger: well, if you want to be able to create a new Foo object in the constructor of Foo, then what you want to be playing with is a WebIDL object, and not a Es object, no? |
| 17:08 | <tobie> | Ms2ger: in a spec, that is. |
| 17:10 | <Ms2ger> | But you haven't clearly defined the difference between those two yet :) |
| 17:11 | <Ms2ger> | I think you either need to say that a WebIDL object "is a" JS object or a WebIDL object "has a" JS object |
| 17:12 | <Ms2ger> | And then your "create a platform object" algorithm either creates an object that is both, or it creates two objects and associates them with each other |
| 17:12 | <Ms2ger> | However, I need to run |
| 17:12 | <Ms2ger> | Good luck :) |
| 17:13 | <tobie> | Ms2ger: :D see you |