| 00:09 | <Domenic> | botie: ask zcorpan if he has any estimate for the <img> stuff? Maybe I should just work around it, for img.decode()? |
| 00:09 | <botie> | will do |
| 00:48 | <Domenic> | What a fun discovery https://github.com/whatwg/html/pull/2384 |
| 01:53 | <JonathanNeal> | TabAtkins: i did not grok that sectioning roots just mean "they can reasonably have headings". What about the non-contributing part of their description? Related: https://github.com/w3c/html/issues/806 |
| 02:02 | <TabAtkins> | JonathanNeal: That just means they're not appropriate to include into the document outline. That's a separate concept entirely. |
| 02:03 | <JonathanNeal> | How does that (separate concept) work? Is it translatable in terms of ATs and heading levels? |
| 02:27 | <MikeSmith> | JonathanNeal: FWIW I plan to change this outline implementation in the HTML checker to not treat anything except <body> as a “sectioning root” |
| 02:28 | <MikeSmith> | specifically <blockquote>, <details>, <fieldset>, <figure>, <td> |
| 03:06 | <MikeSmith> | JonathanNeal: https://github.com/validator/validator/commit/0789dc8b03bee75ba82f12af20b9785a161557bc |
| 03:06 | <MikeSmith> | and pushed to https://checker.html5.org and https://validator.w3.org/nu/ |
| 03:08 | <MikeSmith> | https://checker.html5.org/?showoutline=yes&doc=https://output.jsbin.com/wulimo |
| 03:19 | <Domenic> | MikeSmith: this is not the "document outline" feature that is supposed to follow the spec, right? Just the "heading level outline" feature that is supposed to follow ATs? |
| 03:51 | <MikeSmith> | Domenic: no, both |
| 03:52 | <Domenic> | :/ |
| 03:54 | <MikeSmith> | well I have not seen a convincing explanation of the rationale for hiding headings in “sectioning roots” in the outline |
| 03:54 | <MikeSmith> | nor have I seen any record of it ever having been discussed before it was added to the spec |
| 03:54 | <MikeSmith> | it is not intuitive to authors |
| 03:55 | <Domenic> | Just seems bad to mismatch the spec and any other outlining tools that are following it |
| 03:55 | <MikeSmith> | there is already a mismatch there |
| 03:55 | <Domenic> | Might be good to stop linking to the spec's document outline definition and call it Mike's outline instead then |
| 03:55 | <MikeSmith> | maybe so |
| 03:55 | <MikeSmith> | maybe other tools should do that too |
| 03:56 | <MikeSmith> | since nobody has ever implemented a conforming implementation of it |
| 03:56 | <MikeSmith> | among other things the other tools do not handle <hgroup> correctly at all |
| 03:57 | <MikeSmith> | because of the bad guidance that was in the spec about it all this time |
| 03:57 | <MikeSmith> | this is another checker feature that has cost me a lot of time without clear benefit |
| 03:57 | <MikeSmith> | and resulted in a lot of user confusion |
| 03:58 | <MikeSmith> | due to the lack of spec clarity around it |
| 03:59 | <MikeSmith> | I tried in good faith to implement it per spec |
| 03:59 | <MikeSmith> | and I also tried to get other implementors of it to fix their broken implementations |
| 04:00 | <MikeSmith> | at this point I am fatigued with it |
| 04:00 | <MikeSmith> | maybe it would be best if I just yanked it from the checker entirely and just kept the heading outline |
| 04:01 | <Domenic> | :(. But yeah, I'm not sure what people would be using it for if not to see what the spec says the semantics of their headings are. |
| 05:09 | <JonathanNeal> | JakeA: ^ |
| 05:36 | <annevk> | MikeSmith: maybe wait a bit for JakeA to finish investigating what our options are? |
| 05:48 | <MikeSmith> | annevk: ok |
| 06:06 | <JakeA> | MikeSmith: have you seen https://jakearchibald.com/2017/do-we-need-a-new-heading-element/? |
| 06:47 | <botie> | zcorpan, at 2017-02-23 00:09 UTC, Domenic said: if he has any estimate for the <img> stuff? Maybe I should just work around it, for img.decode()? |
| 06:49 | <zcorpan> | Domenic: sorry, lost track of it. Currently looking into webvtt tests. yeah, can work around it and fixup after. |
| 08:15 | <zcorpan> | I realized now that "update the image data" can end up parsing the URL twice. is that a problem? |
| 08:17 | <zcorpan> | specifically for: var img = new Image(); img.src = "not-in-cache"; step 5.1, then step 11 |
| 08:35 | <annevk> | zcorpan: yeah, it breaks blob URLs |
| 08:36 | <zcorpan> | annevk: suspected that :-( filing an issue... |
| 08:41 | <zcorpan> | annevk: i guess this is an issue for a lot of things? do we need to store the parsed URL everywhere for reuse later? |
| 08:42 | <annevk> | zcorpan: yeah, that's the theoretical model, most things are fine I think, but there might be some lurking here and there |
| 08:43 | <annevk> | zcorpan: we've been slowly cleaning it up |
| 09:28 | <annevk> | zcorpan: ping https://github.com/w3c/web-platform-tests/pull/4911 |
| 09:43 | <zcorpan> | annevk: reviewed and merged. |
| 12:26 | <annevk> | JakeA: your understanding of event listeners, tasks, and state is correct |
| 12:27 | <annevk> | JakeA: that's basically how readyState on XMLHttpRequest works |
| 12:27 | <annevk> | JakeA: and many other such constructs |
| 12:29 | <JakeA> | annevk: service worker state too. Cheers. Will update the proposal. |
| 13:32 | <JonathanNeal> | annevk: what options are being investigated? |
| 13:32 | <annevk> | JonathanNeal: getting it implemented |
| 13:33 | <JonathanNeal> | annevk: and by it we mean the outline algorithm as written whih MikeSmith just removed part of from the validator? |
| 13:34 | <JonathanNeal> | s/whih/which |
| 13:34 | <annevk> | JonathanNeal: he did? I thought he was going to wait |
| 13:34 | <JonathanNeal> | https://github.com/w3c/html/issues/806 https://github.com/validator/validator/commit/0789dc8b03bee75ba82f12af20b9785a161557bc |
| 13:35 | <annevk> | JonathanNeal: that commit doesn't remove the outline algorithm |
| 13:35 | <JonathanNeal> | > just removed part of |
| 13:35 | <JonathanNeal> | the sectioning root part |
| 13:35 | <JonathanNeal> | > as written |
| 14:27 | wanderview | wonders if he can fix his SW spec PR while mickey mouse clubhouse plays in the background... |
| 14:37 | <wanderview> | hmm... tpac in february? https://twitter.com/kasie/status/834771607801442304 |
| 14:58 | <wanderview> | JakeA: you around? |
| 14:59 | <JakeA> | wanderview: yep! |
| 14:59 | <wanderview> | JakeA: so I'm trying to implement the "order Clients.matchAll() by focus order" thing and ran into a couple corner cases |
| 15:00 | <wanderview> | JakeA: if a nested iframe is focused, does that also mark the parent window focused in terms of "focus time"? were they focused at the same time? |
| 15:00 | <wanderview> | JakeA: if the parent window was already focused when the nested iframe is focused, does it update the parent window focus time in that case? |
| 15:00 | <wanderview> | I can write a github issue for this stuff... just curious if you had any thoughts |
| 15:01 | wanderview | wonders why nothing is ever easy... |
| 15:02 | <JakeA> | haha you're right there |
| 15:02 | <JakeA> | investigating… |
| 15:03 | <wanderview> | JakeA: I am assuming if the nested iframe is focused the .focused attribute should be true for both the frame Client and the parent window Client |
| 15:03 | <wanderview> | JakeA: does chrome implement this ordering yet? |
| 15:04 | <JakeA> | wanderview: I'm not sure. Digging into how the html spec defines focusing… |
| 15:04 | <wanderview> | thanks |
| 15:08 | <wanderview> | JakeA: in gecko we map Client.focused attribute to Document.hasFocus() |
| 15:08 | <JakeA> | wanderview: is it just me, or does https://html.spec.whatwg.org/multipage/interaction.html#has-focus-steps not account for window visibility? |
| 15:09 | <JakeA> | or window focus |
| 15:09 | <wanderview> | JakeA: I'm still trying to figure out what a "control group" is |
| 15:09 | <JakeA> | I must be missing something |
| 15:10 | <JakeA> | wanderview: I'm stuck on step 2 |
| 15:10 | <JakeA> | wanderview: seems like it returns true if the document is top-level, regardless of focus |
| 15:11 | <JakeA> | That's not how Chrome behaves |
| 15:11 | <wanderview> | JakeA: yea... that seems like a spec bug |
| 15:11 | <wanderview> | annevk: ^^^ |
| 15:11 | <wanderview> | this is what we do: https://dxr.mozilla.org/mozilla-central/source/dom/base/nsDocument.cpp#3246 |
| 15:11 | <JakeA> | Isn't how Firefox behaves either. I'll file it |
| 15:13 | <JakeA> | wanderview: based on Firefox's code, it should give the ancestors a focus time. Ugh I guess they get the same focus time |
| 15:14 | <wanderview> | JakeA: is that what a web dev would expect? |
| 15:14 | <wanderview> | setting the same focus time means the parent window will always be first in the list because it was necessarily created first |
| 15:15 | <wanderview> | JakeA: oh, but also I filed this: https://github.com/w3c/ServiceWorker/issues/1078 |
| 15:16 | <wanderview> | so maybe you could create a detached iframe, open a window, then add the iframe to the window? depends what "creation time" means I guess... |
| 15:19 | <wanderview> | I should watch Shrek while working all the time... this is way better |
| 15:19 | <JakeA> | wanderview: I think we need to look at this ordering again :/ The goal is to present the most-recently-interacted-with window first. Feels like, if the focus time is the same, it should be creation time descending |
| 15:21 | <wanderview> | JakeA: right now its creation time ascending? (or maybe it doesn't specify ascending or descending right now) |
| 15:21 | <wanderview> | JakeA: I'm also happy to make the ordering time just for the specific document focused... not for all ancestors of the focused document |
| 15:22 | <JakeA> | wanderview: I would assume ascending if not otherwise stated. But yeah, I'd kinda hope the deepest-focused would appear first. |
| 15:22 | <JakeA> | wanderview: I think we should stick with how hasFocus() defines it |
| 15:23 | <JakeA> | but that's broken :D |
| 15:23 | <wanderview> | JakeA: I'll write a spec issue |
| 15:24 | <JakeA> | wanderview: write the service worker one, I'll do the html one |
| 15:24 | <JakeA> | ~~teamwork~~ |
| 15:24 | <wanderview> | JakeA: sounds good... I try to avoid html |
| 15:31 | <annevk> | wanderview: focus handling has various issues unfortunately |
| 15:39 | <wanderview> | JakeA: https://github.com/w3c/ServiceWorker/issues/1080 |
| 15:40 | <JakeA> | wanderview: and https://github.com/whatwg/html/issues/2391 :D |
| 15:41 | <wanderview> | thanks |
| 18:45 | <Domenic> | annevk: you may want to look at https://github.com/WebAssembly/design/issues/989 |
| 18:47 | <annevk> | Domenic: o_O |
| 18:48 | <TabAtkins> | YUP |
| 18:48 | <Domenic> | TabAtkins appears to be fighting the good fight but I'm kind of confused about this issue... |
| 18:48 | <TabAtkins> | Basic summary is: Andreas is being a butt, for stupid reasons. |
| 18:49 | <TabAtkins> | I've been getting some backstage support for this, too. |
| 18:49 | <Domenic> | Omg I just got to the part where he's saying "we should support diversity, like latin1" |
| 18:51 | <TabAtkins> | Note that, while Unicode is codepoint-compatible with Latin1, it's not byte-compatible with the U+80-U+ff range. |
| 18:51 | annevk | adds a modest comment |
| 18:54 | <Domenic> | I wonder what non-modern environments have plans to implement wasm. |
| 18:55 | <TabAtkins> | IBM mainframes from 1980, obviously. |
| 18:55 | <TabAtkins> | And all those embedded EBCDIC mini-linuxes. |
| 19:04 | <terinjokes> | i'm sad that Google Chrome doesn't support decoding EBCDIC (even when i set the content-type header) |
| 19:05 | <Domenic> | I'm sad that Google Chrome still supports decoding UTF-32 |
| 19:05 | <TabAtkins> | I'm happy I specifically removed the old EBCDIC support CSS once mandated. ^_^ |
| 19:06 | <terinjokes> | wat |
| 19:06 | <Domenic> | wat |
| 19:06 | <TabAtkins> | (At least, it had a table of how to recognize the @charset declaration in various encodings, including ebcdic.) |
| 19:07 | <TabAtkins> | https://www.w3.org/TR/CSS2/syndata.html#charset |
| 19:08 | <terinjokes> | oh, does CSS still support GSM 7-bit? |
| 19:08 | <TabAtkins> | No, it absolutely doesn't. ^_^ |
| 19:09 | <terinjokes> | so much for "one web" |
| 19:09 | terinjokes | trolls |
| 19:09 | <TabAtkins> | https://drafts.csswg.org/css-syntax/#input-byte-stream |
| 19:09 | <TabAtkins> | Now it just detects an encoding per the Encoding standard, defaulting to utf-8. |
| 19:10 | <terinjokes> | TabAtkins: all my CSS will now be in IBM886 |
| 19:12 | <TabAtkins> | Have fun with that. |
| 19:12 | <terinjokes> | i hear cyrillic is cool |
| 22:15 | <wanderview> | JakeA: focus stuff really makes me want to go play video games |
| 22:15 | <wanderview> | or anything other than work, tbh |
| 22:16 | <JakeA> | wanderview: rocket league!! |
| 22:16 | <wanderview> | JakeA: sadly I haven't played that much lately... although my kids like to drive in circles every night |
| 22:16 | <wanderview> | well, circles would be an advanced move for them |
| 22:19 | <wanderview> | JakeA: trying to write a test for this ordering... discovered we can only programmtically focus() a frame if an ancestor window is already focused... |