| 04:03 | <annevk> | Domenic: I don’t think there is logic to where things are listed in that image |
| 06:02 | <MikeSmith> | Domenic: http://web.archive.org/web/20160411100303/http://w3c.html5-tag.de/W3CTag2012/images/html5-car.jpg |
| 06:06 | <MikeSmith> | https://html5-tag.ict-media.de/the-html5-car/ |
| 06:07 | <MikeSmith> | > |
| 06:07 | <MikeSmith> | The HTML car is consists of 2 parts: a Formula 1 racing car nose and a Ford T tail symbolizing the mix of advanced features and APIs and the often somewhat odd constructs inherited from previous HTML versions and browsers. Stickers visualize examples for both as there are e.g.: CSS3, Javascript, SVG, canvas and video elements, access to the engine via an RJ45 (Web) socket, IE6 and older HTML |
| 06:07 | <MikeSmith> | versions as part of heritage, WHATWG sticker on the on the drive axle, and W3C tires on the rim. Web workers are represented by a bike on the backseat. |
| 06:13 | <annevk> | o_O |
| 06:34 | <MikeSmith> | heh yeah |
| 06:36 | <MikeSmith> | anyway, given that https://html.spec.whatwg.org/multipage/introduction.html#abstract image is basically the very first thing that anybody reading the spec introduction is gonna see, it would seem to be good to have something better there |
| 10:35 | <Ms2ger> | Who knows things about incumbent/... globals besides bz? |
| 10:47 | <annevk> | Domenic! |
| 10:47 | <annevk> | The HTML Standard also has many helpful examples thanks to him |
| 11:47 | <Ms2ger> | Domenic, I wonder if https://webassembly.github.io/spec/js-api/#run-a-host-function (which creates a wasm function that calls a given js function) needs to have the various setup boilerplate |
| 12:49 | <Ms2ger> | EAccessViolation exception: Access violation |
| 12:49 | <Ms2ger> | Backtrace: |
| 12:49 | <Ms2ger> | $000000000048F96A |
| 12:49 | <Ms2ger> | $0000000000401DE4 |
| 12:49 | <Ms2ger> | That's a first (building the html spec) |
| 14:09 | <Domenic> | Ms2ger: oh yeah, definitely needs the setup/teardown stuff. |
| 14:10 | <Ms2ger> | Could you file, please? |
| 14:17 | <annevk> | So the way "session" storage buckets should work is that they are hold alive by browsing session (to be introduced by https://github.com/whatwg/html/issues/5350) I think. And the sessionStorage "session" storage bucket will get copied when a popup is created. So their mechanics can be more or less identical. |
| 14:18 | <annevk> | Also, it seems we had already confirmed somewhere that sessionStorage should not be available in opaque origins. It's a good first issue against the HTML Standard. |
| 14:18 | <annevk> | Unfortunately I found that after I confirmed it (again) myself. |
| 14:20 | <annevk> | Beyond this I haven't really been able to make progress on storage this week, apart from the more high-level write-up at https://github.com/privacycg/storage-partitioning/pull/1 to get everyone aligned on goals. |
| 14:20 | <annevk> | Mek: (perhaps of cursory interest) ^^ |
| 15:23 | <annevk> | Domenic: if it helps, HTML depends on URL, which has https://url.spec.whatwg.org/#url-writing |
| 15:24 | <annevk> | Domenic: HTML adding a bunch of schemes that conflict with that seems bad to me |
| 15:24 | <Domenic> | annevk: are you saying that "asdf1234" was a bad example and I should have used "asdfwasd"? |
| 15:25 | <annevk> | Domenic: no, see the sentence on schemes there and what it references |
| 15:25 | <Domenic> | Oh I see. Interesting. |
| 15:45 | <jgraham> | Is a change of fragement supposed to constitute a load for the purposes of CSP? Specifically I have a test here that loads an iframe to $URL#0 then adds a meta element with some CSP rules and then checks for a securitypolicyviolation event when it naviagtes the iframe to $URL#1 |
| 15:48 | <annevk> | jgraham: maybe, not sure where navigation calls CSP |
| 15:49 | <TabAtkins> | MikeSmith: That website is *haunting* |
| 16:10 | <annevk> | jgraham: CSP has a number of known issues btw so filing a spec issue is a valid out imo |
| 17:25 | <jgraham> | annevk: I'll look a bit later; mostly want this test to not timeout :) |
| 17:33 | <annevk> | Surprising how simple imperative assignment turns out to be |
| 22:32 | <lexer> | Hi there, maybe it's the wrong time of day to poke in asking, but is there anyone familiar with the URL spec able to explain a bit of the background, and in particular why it's written the way it is rather than providing a grammar and writing semantics on top? I filed an issue about it on github and then realized I was misunderstanding the way the |
| 22:32 | <lexer> | doc is written. |
| 22:33 | <lexer> | All I wanted to know is whether a scheme-less URL can be valid (which it clearly can't under STD 66) to ensure some documentation is accurate and according to your spec... I can't tell. |
| 22:37 | <lexer> | In particular, why is there so much weight put on the parser (splitting on special schemes and, apparently from my searching, causing breaking changes when that list of special schemes changes) rather than letting those be post-processing steps? |
| 22:37 | <lexer> | (I'm on webchat on a laptop, so I'll disconnect before I get a reply, likely; I'll check the logs to see what people say and pop back in, though) |
| 22:40 | <lexer> | Also, are there any plans to actually get STD 66 marked as obsoleted? Because one would be forgiven for referring to it today. |
| 23:10 | <TabAtkins> | Ugh, they already disappeared |
