| 00:59 | <annevk> | Domenic: maybe HTML should simply define svg:image and svg:script directly, if they are to be largely, but not quite, identical |
| 02:27 | <TabAtkins> | annevk: Yeah, that would be nice if we end up not being able to unify, just because they're so complex. Being defined together would reduce the chance of them accidentally diverging. |
| 04:48 | <pikaren> | should i use "no-referrer" or "none" or "never" in the meta referrer tag? |
| 04:49 | <pikaren> | which one is recognized most mainstream browsers |
| 04:49 | <pikaren> | by most |
| 07:33 | <annevk> | pikaren: "never" I suspect |
| 07:34 | <pikaren> | oh |
| 07:34 | <annevk> | pikaren: see https://wiki.whatwg.org/wiki/Meta_referrer for the original spec |
| 07:34 | <annevk> | "spec" |
| 07:34 | <pikaren> | i saw some stackoverflow folks suggest using no-referrer though |
| 07:35 | <pikaren> | do all the newer browsers try to support "never" |
| 07:36 | <annevk> | pikaren: yeah, that's required by https://w3c.github.io/webappsec-referrer-policy/#determine-policy-for-token |
| 07:38 | <pikaren> | oh |
| 07:38 | <pikaren> | nice |
| 07:38 | <pikaren> | thanks |
| 10:38 | <derekjohnson> | Hi, I have a couple of questions about sectioning root. Is this the right place to ask? |
| 11:04 | <tobie> | Are there examples of interfaces holding onto promises similar to ServiceWorkerContainer.ready, but that can cycle through the states multiple time during the object's lifetime (sensor state can go multiple time through the cycle idle -> activating -> active and needs a promise that gets resolved when active). |
| 11:36 | <tobie> | annevk: you mentioned cancellable promises yesterday. What's my best move right now? Return a promise, throw an Abort error on cancellation and retrofit later to cancellable promises or, instead, remove promise for now (they're not critical as there are also statechange events being dispatched) and add them back in once cancellables are a thing? |
| 11:46 | <annevk> | tobie: not sure, ask JakeA / Domenic |
| 11:46 | <annevk> | derekjohnson: yeah, I guess it is, though not sure if there's folks around who can help right now |
| 11:52 | <derekjohnson> | annevk: I'll give it a shot anyway :) First question is why is sectioning root deemed necessary? Second is what is different about the elements that are sectioning root (apart from body) that makes them worthy of having their contents hidden from the main outline? |
| 11:57 | <annevk> | derekjohnson: I think the idea is that if you quote a substantial piece of an article, the headings of that article shouldn't be part of your outline, since they're just part of a quote |
| 12:04 | <derekjohnson> | annevk: kind of weird that if someone uses <figure> for products on an ecommerce site or <details> for a subnav or something that they get treated like a portion of a quoted article. |
| 12:06 | <annevk> | derekjohnson: well, I think similar considerations apply there |
| 12:07 | <annevk> | derekjohnson: you typically don't have "Graph 50: Population growth" in your main outline |
| 12:08 | <derekjohnson> | annevk: agree, but you do have "Bow saw", "Hacksaw", "Chainsaw" in a list of products |
| 12:08 | <annevk> | derekjohnson: a list of products isn't really <details> though, is it? |
| 12:08 | <derekjohnson> | annevk: I should say I use <article> for product lists but I've seen <figure> used a lot |
| 12:09 | <annevk> | derekjohnson: seems spurious, but since outline is so poorly supported, it's no surprise |
| 12:10 | <derekjohnson> | annevk: yeah we're talking about something that doesn't really exist, it interests me though |
| 12:10 | <annevk> | I need to figure out if it will ever get implemented, if it doesn't, we might have to remove it from the specification 😟 |
| 12:28 | <beverloo> | MikeSmith, hi! |
| 12:29 | <beverloo> | MikeSmith, could I be added as a contributor on the push-api w3c repo? |
| 13:11 | <annevk> | smaug____: if https://github.com/WICG/EventListenerOptions/issues/11#issuecomment-198348071 is actually easy, feel free to demonstrate |
| 13:11 | <annevk> | smaug____: I have many doubts |
| 13:11 | <smaug____> | what kind of doubts? |
| 13:11 | <annevk> | smaug____: that it would be easy |
| 13:12 | <smaug____> | what part do you consider hard there? |
| 13:12 | <annevk> | I also don't like that it encourages a different this binding from all other callbacks and calls the callback member "handleEvent" |
| 13:13 | <annevk> | smaug____: afaict you'd have to do what philipj says and write out the whole binding yourself |
| 13:13 | <annevk> | smaug____: again, if you see an easy alternative, please demonstrate, no need to discuss if it's easy |
| 13:14 | <smaug____> | so what is wrong with the approach that there is dictionary EventListenerOpts { boolean passive = false;}; |
| 13:14 | <smaug____> | then eventlistener param is changed to object or any |
| 13:15 | <smaug____> | first you do listener -> dictionary conversion and read the passive value |
| 13:15 | <annevk> | I don't understand what object or any means, how is that not any? |
| 13:15 | <smaug____> | and then you do whatever is happening now |
| 13:16 | <smaug____> | the type of the listener would be object (or any, not sure which one would be better) |
| 13:16 | <annevk> | IDL handles dictionary conversion, I'm not sure how you'd do that in prose |
| 13:16 | <annevk> | Apart from just copying and pasting those algorithms, perhaps creating abstractions, etc. |
| 13:17 | <annevk> | Definitely not easy |
| 13:17 | <smaug____> | we have dictionary conversion in prose elsewhere |
| 13:17 | <smaug____> | in specs |
| 13:17 | <annevk> | No we don't |
| 13:17 | <smaug____> | https://html.spec.whatwg.org/multipage/scripting.html#coerce-context-arguments-for-2d for example |
| 13:17 | <annevk> | That's not a dictionary |
| 13:18 | <smaug____> | https://html.spec.whatwg.org/multipage/scripting.html#canvasrenderingcontext2dsettings is dictionary |
| 13:19 | <annevk> | ew |
| 13:19 | <smaug____> | RenderingContext? getContext(DOMString contextId, any... arguments); and the first any argument is converted to dictionary conditionally |
| 13:19 | <smaug____> | based on the contextID |
| 13:19 | <smaug____> | so we totally do that conversion in prose |
| 13:20 | <annevk> | I guess we do |
| 13:21 | <annevk> | Note that this also means we have to keep more objects alive for each listener |
| 13:21 | <smaug____> | we do? |
| 13:21 | <annevk> | It doesn't seem like a great alternative to me |
| 13:22 | <smaug____> | I don't see any need for more objects |
| 13:22 | <annevk> | smaug____: yeah, because folks will be encouraged to pass in objects that reference a callback, and we can't throw away that object as we can with dictionaries since it's the this value |
| 13:22 | <smaug____> | oh you mean that. not worried about that at all |
| 13:23 | <smaug____> | I don't even see why to worry about that |
| 13:24 | <annevk> | It's also less compatible since if that object already has members we might be changing the semantics of deployed valid code |
| 13:24 | <annevk> | That is, this approach isn't even backwards compatible |
| 13:26 | <smaug____> | that is a risk. but I consider the risk less than what 3rd param approach has |
| 13:27 | <smaug____> | we could reduce the risk by changing the name for passive to something less common |
| 13:30 | <annevk> | The 3rd param approach has no risk for valid existing code |
| 13:30 | <annevk> | I don't think 1-2 year browser upgrade cycle is an actual risk worth caring about. These APIs are with us for the long term. |
| 13:31 | <annevk> | Once we start caring about forward compat we might as well stop |
| 13:31 | <annevk> | As philipj suggested elsewhere we should probably make feature detection easier for dictionaries somehow |
| 13:31 | <annevk> | That's something worth looking into |
| 13:40 | <smaug____> | 3rd param causes the risk for pages being broken for many users. |
| 13:41 | <annevk> | Maybe the risk is a little higher than with a new API, but it's really not that different |
| 13:42 | <annevk> | And at least it doesn't break old content forever |
| 13:42 | <annevk> | Which I think is much worse, since that is far less likely to be fixed |
| 14:51 | <JonathanNeal> | normalize.css v4 is being prepared tonight. if anyone has a minute to look for anything that might have snuck past us on master or in the last pull requests, it helps prevent bugs from making it into 4.0.0. https://twitter.com/jon_neal/status/710840040394530816 |
| 17:02 | <MikeSmith> | beverloo: hi, setting you up now |
| 17:04 | <MikeSmith> | and done |
| 17:05 | <beverloo> | thank you! |
| 17:09 | <annevk> | wanderview: is https://github.com/whatwg/fetch/issues/245 high priority? |
| 17:09 | <annevk> | wanderview: mostly working on Shadow DOM at the moment |
| 17:10 | <wanderview> | annevk: don't think its a top priority no... was just referencing another instance I saw |
| 17:10 | <wanderview> | annevk: maybe we can discuss at the f2f |
| 17:10 | <annevk> | wanderview: thanks, yeah, would be curious to hear what others think |
| 17:10 | <wanderview> | I mean... the people who go to the f2f |
| 17:11 | <annevk> | wanderview: I'd be happy to silently fail and make sure new Request(url, someotherrequest) always works |
| 17:11 | <annevk> | wanderview: while resetting certain state as appropriate, of course |
| 17:11 | <wanderview> | annevk: some kind of "safe url rewrite" function might be more convenient for what people really want, though |
| 17:12 | <annevk> | wanderview: well that's called a redirect |
| 17:14 | <wanderview> | annevk: I guess evt.respondWith(evt.request.redirect(newURL)) will result in the service worker getting entered again, right? |
| 17:14 | <wanderview> | I believe it will |
| 17:19 | <annevk> | yup |
| 17:22 | <wanderview> | and that chromium issue was trying to avoid a bug in chrome, so it wasn't rewriting the url anyway |
| 22:37 | <TabAtkins> | Domenic, annevk: Anything wrong conceptually with letting <video>/<audio>/<picture> inside of <svg> parse as the <html:*> elements? That is, set up the right (HTML) namespace on them? |
| 22:37 | <TabAtkins> | Obvi not possible for the SVG-as-XML syntax, but for the embedded-SVG syntax? |
| 22:41 | <Domenic> | TabAtkins: seems quite reasonable to me. |
| 22:46 | <jsbell> | annevk: any plans to bikeshed Encoding? |
| 22:47 | <jsbell> | Also, has anyone plotted "# spec authoring tools" vs "# spec editors" over time? |
| 22:48 | <TabAtkins> | # of authoring tools has remained approximately flat for a while. Bikeshed rose from the corpse of the "Bert's preprocessor", so a net 0 gain. |
| 22:48 | <TabAtkins> | (Or rather, it quickly cannibalized all uses of Bert's preprocessor as its first victim.) |