| 00:47 | <littledan__> | Bterlson made the same point at the meeting about grapheme breaks being locale-independent |
| 03:09 | <duper> | wind 10 |
| 07:15 | <annevk> | jyasskin: guess you're asleep? |
| 07:19 | <annevk> | jyasskin: actually, I thought I had a comment on your proposal, but I don't think I do anymore |
| 07:34 | <tobie> | annevk: re OpenEndedDictionary, what's the requirement around keys being unique? |
| 07:34 | <annevk> | tobie: how would you create one where they are not? |
| 07:37 | <tobie> | annevk: yeah. Let me rephrase that: given you're targeting URL params and HTTP headers, which both allow for multiple values per key, why is a dictionary the right construct? |
| 07:39 | <tobie> | annevk: or are you planning something like: dictionary<DOMString or sequence<DOMString>>? |
| 07:40 | <annevk> | tobie: the common case is key-value |
| 07:41 | <annevk> | tobie: for the uncommon case there's sequence<sequence<ByteString>> |
| 07:42 | <annevk> | tobie: I guess we could maybe do (x or sequence<x>), hmm, or for Headers we could allow "," in the value, which we probably need to allow anyway |
| 07:42 | <annevk> | tobie: so many options |
| 07:42 | <tobie> | annevk: so {"foo": "bar"} or [["foo", "bar"], ["foo", "baz"]] but not {"foo" : ["bar", "baz"]}? |
| 07:43 | <annevk> | tobie: that's the status quo |
| 07:43 | <annevk> | tobie: although I'm not sure how many implemented sequence<sequence<x>> here |
| 07:43 | <Ms2ger> | I think Gecko does |
| 07:47 | <tobie> | annevk: It's interesting to see what common JS libraries tend to do here. |
| 07:47 | <tobie> | annevk: unsurprisingly, they're super lenient in what they accept. |
| 07:48 | <tobie> | annevk: So they'll even accept things like: [{foo: "bar"}, {foo: "baz"}] |
| 07:50 | <tobie> | annevk: what's your take on how Web APIs should handle options like that? Does leniency belong in the Web APIs themselves or in JS libraries built on top? |
| 07:50 | <tobie> | annevk: I would argue for the former, but— |
| 08:08 | <annevk> | tobie: it depends a bit on the tradeoffs involved I suppose |
| 08:10 | <annevk> | tobie: in general I'm not opposed, but perf, complexity, extensibility, etc. are also things we need to take into account |
| 08:17 | <tobie> | annevk: sure. |
| 10:14 | <annevk> | astearns: I looked, and it's filed btw: https://github.com/w3c/uievents/issues/23 |
| 10:14 | <annevk> | astearns: just ignored for 2+ years |
| 10:40 | <MikeSmith> | is Gary not actually working on the UI Events spec any more? |
| 10:43 | <Ms2ger> | Has anyone ever really worked on the UI events spec? |
| 10:47 | <MikeSmith> | I thought Gary K was working on it at one time actually |
| 10:48 | <MikeSmith> | and he was at TPAC so it’s not like he isn’t around |
| 10:50 | <annevk> | We discussed UI events at TPAC |
| 10:50 | <annevk> | This exact issue even |
| 10:50 | <annevk> | It still seemed as new to those involved as it was two years ago |
| 10:50 | <annevk> | I'm not really getting my hopes up |
| 12:55 | <gsnedders> | I so totally don't understand SVG paths. |
| 13:10 | <ondras> | aren't they rather similar to canvas paths? |
| 13:11 | <gsnedders> | I don't know. I'm pretty sure I've never used canvas paths :) |
| 13:13 | <annevk> | gsnedders: study the WHATWG logos |
| 13:13 | <annevk> | gsnedders: it's relatively straightforward once you play around with it a bit |
| 13:14 | ondras | agrees |
| 13:16 | <gsnedders> | I think I'm just not understanding how arcs are computed, more than anything else |
| 13:16 | <ondras> | arcs are indeed the most complex part of it |
| 13:16 | <gsnedders> | and are, sadly, what I need :( |
| 13:17 | <ondras> | gsnedders: seen https://developer.mozilla.org/en-US/docs/Web/SVG/Attribute/d#Arcto ? |
| 13:18 | <gsnedders> | ondras: yeah |
| 13:18 | <ondras> | gsnedders: generally speaking, you define the ellipse whose arc is to be drawn. |
| 13:19 | <ondras> | gsnedders: so you have an ellipse, an implied starting point and an end point. an arc is drawn from the starting point to the end point. |
| 13:19 | <gsnedders> | and then it's closed by the implied straight line from the starting point to the end point? |
| 13:20 | <ondras> | no, no closing |
| 13:20 | <ondras> | the "A" command just draws an arc segment |
| 13:21 | <gsnedders> | sorry, the fill area is bounded by that line |
| 13:21 | gsnedders | has no idea what the proper terminology is here :) |
| 13:22 | <ondras> | well if you fill that shape, than yeah, but I suppose no straight stroke line is drawn? |
| 13:22 | <gsnedders> | yeah |
| 13:25 | <gsnedders> | what decides the intrinsic width and height of an inline SVG element? |
| 13:26 | <annevk> | gsnedders: when inside HTML? CSS |
| 13:27 | <gsnedders> | annevk: I guess I mean what does width/height: auto compute to when there's no width/height attributes on the SVG element |
| 13:28 | <annevk> | gsnedders: I think it tries to go for widest these days? max-content or so. But best to try |
| 13:28 | <annevk> | Used to follow the 300x150 rule |
| 13:29 | <gsnedders> | where does the 300x150 rule come from tho? |
| 13:29 | <gsnedders> | Some UAs seem to still do this |
| 13:32 | <annevk> | gsnedders: replaced elements |
| 13:32 | <annevk> | gsnedders: maybe that's still what you have to do if there's no aspect ratio either |
| 13:32 | <annevk> | gsnedders: (aspect ratio is derived from viewBox) |
| 13:32 | <annevk> | gsnedders: that's very plausible; as you can tell, it's been a while since I played with this |
| 13:34 | <gsnedders> | :) |
| 13:34 | <gsnedders> | You still have more idea than I! |
| 14:56 | <annevk> | jyasskin: https://github.com/whatwg/html/pull/1831#issuecomment-250490825 |
| 14:56 | <annevk> | tobie: that comment might also be interesting to you, although we should probably not make that part of IDL for now |
| 14:57 | <annevk> | jyasskin: I remember you were thinking about this problem |
| 14:57 | <annevk> | jyasskin: I was wondering if you had any further thoughts |
| 14:57 | <annevk> | jyasskin: it might be time to start an issue for it in whatwg/html or somewhere else and maybe sketch a few things |
| 14:59 | <jyasskin> | annevk: Yes. I'd been thinking in terms of named parallel threads, but named parallel event loops make equal sense. The wrinkle I found was that I wanted certain steps to complete totally asynchronously (generally because they're calls out to the OS or another device), while other steps should run on the event loop, so we'll need a way to say that. |
| 14:59 | <jyasskin> | HTML seems to have our threading model, so there seems fine for the issue. I'll try to file it today. |
| 15:02 | <annevk> | jyasskin: it might actually be beneficial to introduce new terminology for this such as "thread" and "job" (hey JavaScript!) |
| 15:02 | <annevk> | jyasskin: that way nobody will get it confused with stuff observable from JavaScript (tasks / microtasks) |
| 15:03 | <jyasskin> | Worklets also live in a similar construct, so maybe they have some terminology we can use. |
| 15:03 | <annevk> | jyasskin: so yeah, not "job" 😊 |
| 15:03 | <annevk> | jyasskin: worklets don't really have a concept of a queue I think |
| 15:04 | <jyasskin> | annevk: https://drafts.css-houdini.org/worklets/#the-event-loop |
| 15:05 | <annevk> | jyasskin: that looks a little weird |
| 15:06 | <annevk> | jyasskin: also, microtask is only mentioned once in the document, right there |
| 15:08 | <jyasskin> | One of the worklet specs actually has postMessage, but I don't remember which. But yeah, the worklet specs aren't necessarily the right inspiration, just another place to look. |
| 15:10 | <jyasskin> | https://github.com/WebAudio/web-audio-api/wiki/AudioWorklet-IDL-Proposal maybe. |
| 15:12 | <annevk> | Yeah, Paul mentioned that they wanted postMessage |
| 15:12 | <annevk> | But he could never explain how that would work |
| 15:12 | <annevk> | Maybe they figured it out by now |
| 15:14 | <annevk> | Although that looks like the typical approach of IDL-first-model-later-maybe-never |
| 15:15 | <annevk> | jyasskin: anyway, agreed that we should look there too |
| 15:15 | <tobie> | annevk: yeah, I might have introduced raciness in the sensor spec because of "in parallel." Here again, some non-normative help section would be useful. |
| 15:15 | <annevk> | jyasskin: and maybe tell them to fix a few things |
| 15:17 | <annevk> | tobie: makes sense, once there is something to write something non-normative about 😊 |
| 15:17 | <tobie> | annevk: heh |
| 15:20 | <annevk> | jyasskin: but yeah, named threads with a message queue, message passing between those and the event loop world, system calls that return promises? |
| 15:20 | <annevk> | jyasskin: and message passing between named threads of course |
| 15:21 | <annevk> | jyasskin: can we assume threads last for the lifetime of the system from a spec perspective or do we need to define that too? |
| 15:22 | <jyasskin> | Yep, that sounds about right. I might have the system calls be "Asynchronously" blocks, which the main thread waits for, but I'll have to think more about it. |
| 15:23 | <annevk> | jyasskin: the system calls could even be sync as long as they're called from a named thread (and you could use a new named thread to make them async from your perspective...) |
| 15:23 | <jyasskin> | We might need a way to identify a collection of algorithms, and wait for that collection to complete. I think we don't want folks creating new threads in their algorithms. |
| 15:24 | <annevk> | I'm not sure I quite follow that yet, but the names for the threads need to be reserved somehow |
| 15:26 | <annevk> | jyasskin: the main way I view this concept of "threads" is a mechanism for us to state invariants |
| 15:26 | <annevk> | as a* |
| 15:27 | <annevk> | jyasskin: so using many of them is okay, if many if your things can run in parallel |
| 15:27 | <annevk> | jyasskin: a UA doesn't have to use as many threads (or threads at all) to implement your algorithm |
| 15:29 | <jyasskin> | annevk: We could have my "asynchronously" blocks be "Start a thread to run the following steps, resolving |promise|." |
| 15:30 | <annevk> | jyasskin: yeah, having shorthands sounds good |
| 15:31 | <annevk> | jyasskin: I'm excited now, this might not even be that hard to define |
| 15:31 | <jyasskin> | annevk: Yeah, it's sounding coherent. |
| 16:00 | <jyasskin> | https://html.spec.whatwg.org/multipage/infrastructure.html#dom-event-istrusted seems to have lost its data-noexport="", even though that appears in `source`. Did something change in the generation script? |
| 16:01 | <annevk> | jyasskin: Domenic dropped noexport from some things recently |
| 16:01 | <annevk> | jyasskin: maybe you need to run git pull? |
| 16:02 | <jyasskin> | This isn't one of them; the <dfn> in HTML just says that DOM defines it. |
| 16:02 | <annevk> | jyasskin: rationale was that noexport was the default |
| 16:03 | <annevk> | jyasskin: I think it might have been, but cannot check at the moment |
| 16:03 | <jyasskin> | NM, it is one of them. Somehow that's causing Shepherd to think it's exported. TabAtkins |
| 16:08 | <Domenic> | I'm surprised {{Event/isTrusted}} could get confused, |
| 16:08 | <Domenic> | HTML does not have the appropriate dfn type or for |
| 16:09 | <annevk> | Domenic: maybe logic based on ID? |
| 16:14 | <annevk> | TabAtkins: ^^ |
| 16:20 | <annevk> | TabAtkins: jyasskin: https://heycam.github.io/webidl/#Exposed has an explanation |
| 16:20 | <annevk> | Still a bit confused |
| 16:24 | <jyasskin> | annevk: I intentionally didn't mention the exact issue in my first tweet because it wasn't about that issue in particular: we should just always make sure it's clear how to fix any error message. Tab wasn't sure from the bugzilla discussion what fix to link to, so he pushed back. "https://heycam.github.io/webidl/#example-eafd180b"; is probably sufficient |
| 16:24 | <jyasskin> | (with a better id) because it explains to a spec-writer how to decide what to put in the attribute. |
| 16:26 | <annevk> | I don't disagree, just unclear why #whatwg was even mentioned or why it was unclear what to suggest |
| 17:10 | <Domenic> | I thought of it as flattering. When you have a spec question, this is the place to go ^_^ |
| 17:24 | <caitp> | even when it's an ecma262 question? |
| 17:26 | <gsnedders> | there's normally someone who has a clue here |
| 17:28 | <caitp> | usually my questions are actually implementation related, and there isn't anywhere good to ask :( |
| 17:29 | gsnedders | is mostly too far out of the ES game nowadays to be be much use :\ |
| 17:33 | <annevk> | Domenic: heh |
| 18:31 | <Wes666> | evening gents. is there any difference in behavior between Node.textContent and CharacterData.data ? |
| 18:33 | <Wes666> | called on a CharacterData object, of course |
| 18:39 | <jyasskin> | Wes666: https://dom.spec.whatwg.org/#dom-node-textcontent says no. |
| 18:39 | <jyasskin> | Wes666: Also, note that not everyone here is a "gent". |
| 18:40 | <jyasskin> | I recommend "folks" instead. :) |
| 18:40 | <Wes666> | ah right, it's 2016 |
| 18:40 | <Wes666> | forgive me :P |
| 18:41 | <Wes666> | thank you very much for the help |
| 18:43 | <TabAtkins> | annevk: Yeah, it's flattering. ^_^ My problem is that, if an error message says "interfaces need to have an [Exposed=...] extended attribute", spec authors not intimately clued into this subject won't know what to put in there. |
| 18:44 | <TabAtkins> | Even that example in WebIDL isn't great - it explains how to interpret different values, but not *why* a given interface is exposed in Window vs Worker. How should a spec author decide what to put there? |
| 18:44 | <TabAtkins> | Right now the answer is "go ask in #whatwg, they'll help you figure it out". |
| 18:45 | <jyasskin> | TabAtkins: This probably belongs in a spec design guideline, rather than WebIDL. |
| 18:45 | <TabAtkins> | So a paragraph or two of guidance for what kinds of APIs should be exposed in Window vs Worker vs Worklets would be useful. |
| 18:45 | <TabAtkins> | jyasskin: Yes, that's exactly what it is. I don't care if it lives in WebIDL or elsewhere, I just want it somewhere public that I can point to, before I start dropping fatal errors on innocent spec authors. |
| 18:47 | <jyasskin> | https://w3ctag.github.io/design-principles/ |
| 18:47 | <jyasskin> | (Doesn't have it yet, but it's probably the right place.) |
| 18:48 | <TabAtkins> | Yeah, that seems appropriate. |
| 19:47 | <jyasskin> | TabAtkins: Did something change in Bikeshed that might be causing <h3 dfn-type=interface> to lose the dfn-type when it's generated? |
| 19:48 | <jyasskin> | TabAtkins: https://github.com/WebBluetoothCG/web-bluetooth/blob/master/index.bs#L2176 has it, but https://api.csswg.org/bikeshed/?url=https://raw.githubusercontent.com/WebBluetoothCG/web-bluetooth/master/index.bs#bluetoothdevice doesn't. |
| 19:55 | <annevk> | TabAtkins: jyasskin: ❤️ |
| 21:21 | <TabAtkins> | jyasskin: Yes, accidental change where I was assuming a list of selectors was a list of tagnames. Should be fixed now. |
| 21:21 | <jyasskin> | Thx |
| 21:22 | <TabAtkins> | Turns out W3C HTML is an amazing stress-test for Bikeshed, and I'm trying to cut down on the biggest slow points for them. Did a big refactor of the cleanupHTML function from being 20 or so different applications of "run a selector, loop over results" to just being a single tree-walk that tests each element to see if the cleanup applies. |
| 21:25 | <jyasskin> | TabAtkins: If Bikeshed renders W3C HTML in less time than my browser renders html.spec.whatwg.org, you've won. ;) |
| 21:27 | <gsnedders> | :) |