| 00:57 | <Jasper> | I'm seeing: Content-Type: image/jpeg;charset=UTF-8 |
| 00:57 | <Jasper> | in the wild |
| 00:57 | <Jasper> | Can someone tell me what this means? |
| 00:57 | <Jasper> | In the sense of "do browsers treat this differently from Content-Type: image/jpeg" |
| 01:53 | <Domenic> | I don't think browsers use the content-type header for images, Jasper |
| 01:54 | <Jasper> | Alright. |
| 01:54 | <Domenic> | (They sniff the first few bytes) |
| 01:54 | <Jasper> | Oh, wait, really? |
| 01:54 | <Jasper> | So you're saying I can send text/plain for images and browsers could still understand it |
| 01:54 | <Domenic> | Yep |
| 01:55 | <Domenic> | https://mimesniff.spec.whatwg.org/#matching-an-image-type-pattern |
| 01:55 | <Jasper> | does that only work in <img> / <picture> / whatever context or would it also work for navigation |
| 01:56 | <Domenic> | I think only subresources |
| 01:56 | <Jasper> | ah |
| 01:56 | <Domenic> | (and not script subresources if they are served with X-Content-Type-Options: nosniff or whatever that header is) |
| 05:35 | <annevk> | Navigation too to some extent |
| 07:00 | <MikeSmith> | annevk: about the outline feature in the checker, I jus tnow restored it to conformance with the HTML spec |
| 07:01 | <MikeSmith> | by changing it back to now showing headings for sectioning roots, as the spec requires |
| 07:02 | <MikeSmith> | it shows them in the “Heading-level outline”, which is a different thing that doesn’t intend to conform to the outline algorithm |
| 07:03 | <MikeSmith> | but it doesn’t now show them in the “Structural outline”, which is the one intended to show users what the spec says the structure of their document looks like (per the outline algorithm) |
| 07:04 | <MikeSmith> | JakeA: I had not read your article til yesterday but after reading it, I agree with everything you wrote there |
| 07:05 | <MikeSmith> | it seems like the people advocating for <h> don’t understand (or don’t care) that it’s no going to eliminate the need for the outline algorithm |
| 07:07 | <MikeSmith> | instead as far as I can see <h> would pretty much enshrine the outline algorithm (if browsers ever implemented <h>, which I think there is almost no chance of them ever doing) |
| 07:09 | <annevk> | Well, I hope so, but Firefox still landed limited longdesc support after a UX developer got harassed |
| 07:09 | <MikeSmith> | sure but <h> would not be any solution for the accessiblity problem |
| 07:10 | <MikeSmith> | given that problem is due to browsers not having implemented the outline algorithm for exposing the heading to AT the right way |
| 07:11 | <MikeSmith> | JakeA points that out in his article pretty clearly, so dunno why others would have a hard time understanding that |
| 07:12 | <MikeSmith> | anyway until I read JakeA’s article I didn’t know the checker feature was linked to in it |
| 07:13 | <MikeSmith> | but after reading it I can the checker feature is useful for letting people compare the heading outline to the outline-algorithm outline |
| 07:14 | <MikeSmith> | especially for a case like https://checker.html5.org/?showoutline=yes&doc=https://output.jsbin.com/wulimo |
| 07:15 | <MikeSmith> | so now it’s back to being that |
| 07:16 | <annevk> | Hmm, https://api.csswg.org/bikeshed/ is returning a 400 for Travis |
| 07:16 | <annevk> | At least for XMLHttpRequest |
| 07:18 | <MikeSmith> | annevk: just tried in on a test file locally and it worked fine |
| 07:18 | <MikeSmith> | with curl |
| 07:18 | <MikeSmith> | curl https://api.csswg.org/bikeshed/ -F file=@./bikeshed/tests/pre001.bs |
| 07:19 | <annevk> | MikeSmith: https://travis-ci.org/whatwg/xhr/builds/204867728 |
| 07:20 | MikeSmith | looks |
| 07:20 | <ondras> | Domenic: I used jsdom for the very first time yesterday. It "just worked" OOTB, including "location" and "XMLHttpRequest" APIs. So "thank you!" :-) |
| 07:32 | <annevk> | It's consistently failing it seems, so I guess that means we can't land any standard changes today |
| 07:32 | <annevk> | TabAtkins: I guess you're asleep, but if not, https://api.csswg.org/bikeshed/ is returning 400s when accessed from Travis |
| 07:35 | <TabAtkins> | annevk: I'll bug plinss |
| 07:46 | <annevk> | TabAtkins: ta |
| 08:01 | <JakeA> | MikeSmith: is the intent for the headings inside the section roots to be completely lost? Feels like we need to find out Hixie's intent behind some of this stuff. |
| 08:02 | <MikeSmith> | JakeA: I don’t know what the intent was but that is what the spec requires |
| 08:03 | <MikeSmith> | specifically, per the outline algorithm, the sectioning-root headings do not get added the (abstract) outline at all |
| 08:03 | <MikeSmith> | they just get completely skipped |
| 08:03 | <MikeSmith> | I mean, so it’s not just about whether they get shown in some rendered view of the outline |
| 08:04 | <MikeSmith> | but as far as figuring out the intent of sectioning roots, it was never documented anywhere that I could find |
| 08:04 | <MikeSmith> | it was just added to the spec, with no but cited and no discussion I could find in the mailing-list archives |
| 08:05 | <JakeA> | Feels like a bug doesn't it? I'll bug Hixie and see if I can find out what got him there |
| 08:05 | <MikeSmith> | yeah it might be worthwhile to ask him |
| 08:06 | <MikeSmith> | but I don’t think it’s an unintended bug. It’s by design |
| 08:06 | <JakeA> | Naively it feels like the heading level should be +1 the parent section's heading, so it'd be good to know why it's as complicated as it is. |
| 08:07 | <MikeSmith> | there are a number of things about that outline algorithm that aren’t intuitive at all |
| 08:08 | <MikeSmith> | and in my personal experiences in talking with Ian about it have not been super enlightening for me |
| 08:08 | <MikeSmith> | so I kind of gave up on asking |
| 08:08 | <MikeSmith> | but maybe you’ll have more luck |
| 08:10 | <zcorpan> | isn't the idea that you would run an outline on the sectioning root? |
| 08:10 | <MikeSmith> | maybe that was the idea |
| 08:10 | <zcorpan> | so if you have a <blockquote>, headings in there are not part of the outer outline. but the <blockquote> can have its own outline |
| 08:11 | <MikeSmith> | so what do you do with the blockquote outline, in the context of the document? |
| 08:12 | <MikeSmith> | that’s another problem with the spec, it doesn’t say anything about how to expose outlines |
| 08:12 | <MikeSmith> | other than the accessibility-related requirements |
| 08:15 | <zcorpan> | possibly the concept of sectioning roots and multiple outlines doesn't map well to anything that users interact with |
| 08:17 | <MikeSmith> | yeah I think that’s probably the source of some of the confusion |
| 08:23 | <JakeA> | I don't really understand the difference (for a11y) between a section and a section root |
| 08:27 | <zcorpan> | JakeA: if you expose the "sections", you wouldn't want to include every <blockquote> or <td> there. but if they have headings inside, they are in their own islands to not "mess up" the sections on the outside |
| 08:30 | <JakeA> | zcorpan: Ahh, so sectioning elements are sectioning roots + exposure? |
| 08:31 | <JakeA> | I haven't seen a lot to suggest that the exposure of sections is valuable. Maybe that's what we're getting stuck on. |
| 08:32 | <zcorpan> | JakeA: sectioning elements are treated differently from sectioning roots in the outline also in that an explicit sectioning element closes implied sections, but sectioning roots do not |
| 08:33 | <zcorpan> | JakeA: run this is https://checker.html5.org/ with "outline" checked |
| 08:33 | <zcorpan> | <!DOCTYPE html><title>Test</title><h1>h1</h1><h2>h2</h2><h3>h3</h3><section><h4>h4</h4></section><h3>h3</h3> |
| 08:33 | <zcorpan> | then compare to |
| 08:33 | <zcorpan> | <!DOCTYPE html><title>Test</title><h1>h1</h1><h2>h2</h2><h3>h3</h3><blockquote><h4>h4</h4></blockquote><h3>h3</h3> |
| 08:34 | <JakeA> | *penny drops* |
| 08:35 | <JakeA> | zcorpan: cheers! |
| 08:35 | <zcorpan> | np :-) |
| 10:06 | <mathiasbynens> | ok, Cloudbleed is my new favorite “HTML parsing is hard” example |
| 10:07 | <annevk> | mathiasbynens: do we know the exact bug yet? |
| 10:07 | <annevk> | mathiasbynens: they implemented from the HTML Standard I believe... |
| 10:08 | <mathiasbynens> | we don’t, but Tavis’s guess sounds reasonable: https://bugs.chromium.org/p/project-zero/issues/detail?id=1139#c5 |
| 10:23 | <mathiasbynens> | “For the avoidance of doubt: the bug is not in Ragel itself. It is in Cloudflare's use of Ragel. This is our bug and not the fault of Ragel.” — https://blog.cloudflare.com/incident-report-on-memory-leak-caused-by-cloudflare-parser-bug/ |
| 10:25 | <annevk> | Well, good to know it's not a bug in the HTML Standard |
| 11:25 | <annevk> | MikeSmith: do you want me to work on https://github.com/w3c/web-platform-tests/pull/4801? |
| 11:31 | <jgraham> | Seems like an example of a "writing low level code not in Rust is hard" bug, as much as a "parsing HTML is hard" bug |
| 11:37 | <nox> | Domenic: With https://github.com/whatwg/html/pull/2353, if If E's type is beforeunload and but E is *not* a BeforeUnloadEvent object, can return value ever be false in the "Otherwise" block? |
| 11:40 | <annevk> | nox: return value is set in step 3 for the first time |
| 11:41 | <nox> | annevk: "The event handler IDL attribute's type is OnBeforeUnloadEventHandler, and the return value will therefore have been coerced into either the value null or a DOMString." |
| 11:41 | <nox> | annevk: Even if E is not a BeforeUnloadEvent, OnBeforeUnloadEventHandler is still used and thus it means return value is a string, no? |
| 11:41 | <nox> | (or null) |
| 11:43 | <annevk> | nox: yeah, I guess that's true |
| 11:43 | <annevk> | nox: I wonder if that got tested |
| 11:43 | <nox> | annevk: Thanks for confirming. |
| 11:43 | <nox> | annevk: No idea, implementing it in Servo. |
| 11:47 | <annevk> | nox: http://software.hixie.ch/utilities/js/live-dom-viewer/saved/4907 suggests the algorithm is correct |
| 11:47 | <nox> | annevk: Cool. |
| 11:58 | <csarven> | Any "real world" issues w/ using id-attribute starting with 0-9 in XHTML5? Would I be cutting corners if I went for it? |
| 11:59 | <tobie> | in `new Promise(r => setTimeout(r, 10)).then(f)`, is f called in the same event turn as r? |
| 12:05 | <ondras> | I think that f is called in the next event turn (compared to r) |
| 12:05 | <zcorpan> | freenode.org uses cloudflare (see global notice) |
| 12:09 | <jyasskin> | JakeA: If you're thinking about how the outlining algorithm affects accessibility, pull in aboxhall. |
| 12:12 | <annevk> | csarven: only problem is addressing them through CSS requires escapes |
| 12:13 | <zcorpan> | as does mozilla.org but not bugzilla.mozilla.org |
| 12:17 | <csarven> | Didn't know about CSS... I thought it was primarily the XML toolchain. |
| 12:18 | <csarven> | annevk Escaping as in wrapping the value in quotes? |
| 12:18 | <annevk> | csarven: #\39 or some such |
| 12:18 | <annevk> | csarven: haven't worked with CSS in a while so I don't quite remember |
| 12:18 | <zcorpan> | csarven: https://mothereff.in/css-escapes |
| 12:19 | <zcorpan> | [id="1"] works as well but has different specificity |
| 12:20 | <tobie> | ondras: are you sure? |
| 12:20 | <ondras> | tobie: no. I just think that. |
| 12:21 | <tobie> | ondras: not to be confused with: new Promise(r => r()).then(f) where you'd be right (afaik) |
| 12:21 | <annevk> | MikeSmith: it seems the problem is specific to XMLHttpRequest somehow |
| 12:21 | <annevk> | MikeSmith: I can reproduce by running make deploy locally |
| 12:21 | <annevk> | MikeSmith: something with the request is wrong |
| 12:21 | <csarven> | "\31 " <-- this is just insanity. |
| 12:22 | <annevk> | MikeSmith: but it's weird as the script is identical to that for Fullscreen where things do work |
| 12:32 | <mathiasbynens> | csarven: CSS.escape() helps |
| 12:33 | <annevk> | MikeSmith: I think the problem is a Bikeshed change |
| 12:40 | <annevk> | MikeSmith: https://github.com/tabatkins/bikeshed/issues/936 |
| 12:40 | <annevk> | TabAtkins: ^^ |
| 12:49 | <JakeA> | jyasskin: already got a thread going with aboxhall & other a11y folks. May bring it to a more general list though. Trying to figure out why we never implemented. |
| 12:49 | <jyasskin> | Cool |
| 12:50 | <tobie> | jyasskin: I've been having excessive memory usage issues handling the WG21 ref list for specref |
| 12:51 | <tobie> | jyasskin: I haven't precisely identified what the problem is yet, |
| 12:51 | <tobie> | jyasskin: but would you possibly be able to provide the data in a format I can more easily stream? |
| 12:52 | <jyasskin> | tobie: I haven't been paying a lot of attention to that—it's more jfbastien and wash—but I'll ask them. |
| 12:52 | <tobie> | jyasskin: ty |
| 15:43 | <TabAtkins> | annevk: Yup, saw it. Will look at in while I'm on the train in a few minutes. |
| 16:46 | <tobie> | annevk, Domenic: is there syntax outside of the ES bindings to get at the value of an interface attribute (like there is for infra types and now for dictionaries, records, sequences, etc.)? |
| 16:48 | <tobie> | annevk, Domenic: use case is to describe creating a dictionary from the values of an interface for custom JSON serialization in a `toJSON` operation. |
| 16:49 | <tobie> | annevk, Domenic: so it feels like this ties into the slots conversation we had late last year. |
| 16:51 | <tobie> | annevk, Domenic: context is Im trying to rewrite the serializer examples (https://heycam.github.io/webidl/#example-eaac10fb) in terms of toJSON operations returning a dictionary. |
| 17:25 | <Domenic> | tobie: If I understand correctly, what you need to do in that case is get the corresponding internal slot values, or "associated" values, that back each attribute. |
| 17:28 | <Domenic> | So you'd introduce something like "Assume each of the attributes (`from`, `to`, `amount`, ...) is backed by an associated value of the same, so that each attribute's getter returns the corresponding associated value." |
| 17:28 | <Domenic> | Then you could reference "this `Transaction`'s associated from value" |
| 17:31 | <annevk> | Note that this only works if they're actually backed by internal slots. Wouldn't work for innerHTML. |
| 17:50 | <tobie> | Domenic: Thanks. That's exactly what I was looking for. |
| 17:51 | <tobie> | annevk: agree. Given this is for a made-up example anyway, we can just decide they are. |
| 18:00 | <miketaylr> | Domenic: i guess option 1 from your comment is probably the simpest way forward... i still wonder if magic e.returnValue = '' actually solves any real user-facing problems |
| 18:00 | <miketaylr> | (or that is, is required for compat) |
| 18:01 | <miketaylr> | unfortunately i didn't find much when doing archeology when beforeload was added to gecko |
| 18:05 | <Domenic> | miketaylr: yeah, I dunno, I think it kind of depends on how much appetite cdumez has for churn, and everyone else has for the potential back-compat risks of removing window.BeforeUnloadEvent |
| 18:06 | <Domenic> | His latest comment does indeed seem to lean toward preserving BeforeUnloadEvent |
| 18:06 | <miketaylr> | tbh, i have no personal interest in event.returnValue, but might as well get 'er done |
| 18:07 | <miketaylr> | (meaning, i don't know any any single site that breaks in Firefox w/o it) |
| 20:40 | <wanderview> | JakeA: after writing this clients.matchAll() focus order test... I think i can say our currently spec'd behavior is weird |
| 20:47 | <JasperNL> | Hi :) I've got a question about the javascript "fetch" function |
| 20:47 | <JasperNL> | Is it better to use fetch or XMLHttpRequest for now? I don't care about people who use outdated browsers. |
| 20:48 | <JakeA> | wanderview: hah, yeah |
| 20:48 | <wanderview> | JakeA: look at these test expectations: https://hg.mozilla.org/try/rev/8cedfb066814f8dc7e199efd998e392412f554f5#l2.381 |
| 20:49 | <wanderview> | I dunno... just felt ridiculous as I wrote out why it was in this strange order |
| 20:50 | <wanderview> | JakeA: I also found that since windows tend to get focused when created, the only time creation order really comes into play is with iframes |
| 20:50 | <wanderview> | although I suppose in practice the user could have a bunch of tabs restored on browser start, but not focus them |
| 21:02 | <Domenic> | JasperNL: fetch()! unless you need to cancel the fetch, which isn't possible yet. |
| 21:04 | <JasperNL> | Thought so already :) Thanks |
| 22:28 | <wanderview> | JakeA: it may not be possible to write a WPT test for this focus stuff |
| 22:53 | <tobie> | TabAtkins: think you could pull in https://wg21.link/specref.json directly into Bikeshed? |
| 22:54 | <tobie> | TabAtkins: it's for the C++ folks |
| 22:54 | <tobie> | TabAtkins: it currently goes through Specref |
| 22:54 | <tobie> | TabAtkins: but there's no point having it there |
| 22:55 | <tobie> | TabAtkins: and it's causing plenty of grief |