| 07:34 | <hsivonen> | https://source.chromium.org/chromium/chromium/src/+/master:third_party/blink/renderer/core/html/parser/html_meta_charset_parser.h;l=58 indeed looks a lot like Chromium is using the real HTML tokenizer. But not the real tree builder: https://source.chromium.org/chromium/chromium/src/+/master:third_party/blink/renderer/core/html/parser/html_meta_charset_parser.h;l=58 |
| 07:35 | <hsivonen> | Can anyone think of bad Web compat consequences from using the real tree builder algorithm for figuring out where body starts? |
| 07:36 | <hsivonen> | That is, running the tree builder in the scripting enabled mode without actually executing scripts during the meta prescan? |
| 07:37 | <hsivonen> | Oops. The second link was supposed to be https://source.chromium.org/chromium/chromium/src/+/master:third_party/blink/renderer/core/html/parser/html_meta_charset_parser.h;l=58 |
| 07:37 | <hsivonen> | What |
| 07:38 | <hsivonen> | https://source.chromium.org/chromium/chromium/src/+/master:third_party/blink/renderer/core/html/parser/html_meta_charset_parser.cc;l=88 |
| 07:38 | <hsivonen> | Something weird going on with how the copypasteable URL updates. |
| 07:41 | <hsivonen> | AFAICT, the biggest risk is probably meta inside script in a manner that should be honored for compat. Need to write tests... |
| 09:05 | <Sam Sneddon [:gsnedders]> | AFAICT, the biggest risk is probably meta inside noscript), if we could get away this from a compat POV |
| 09:07 | <Sam Sneddon [:gsnedders]> | I don't know the origins of why Hixie spec'd it as allowing it, though… |
| 09:07 | <Ms2ger> | Compat is nice and all, but sometimes I understand why people wanted to burn it all to the ground |
| 09:13 | <Sam Sneddon [:gsnedders]> | I guess it's somewhat difficult to avoid the actual parser changing encoding from document.write, and probably practically unacceptable :( |
| 09:14 | <jgraham> | Compat is nice / but compat can stop you / from doing all the things in life you'd like to. |
| 09:16 | <jgraham> | (also I think to quote The Smiths these days, one need to pretend that Morrissey doesn't exist and it's all Johnny Marr) |
| 09:16 | <Ms2ger> | Who are The Smiths? |
| 09:18 | Sam Sneddon [:gsnedders] | gets inspired to put on a far more acceptable band, The Jesus and the Mary Chain |
| 09:23 | <hsivonen> | I don't know the origins of why Hixie spec'd it as allowing it, though… |
| 09:24 | <Sam Sneddon [:gsnedders]> | I thought Hixie specced it the way it's specced in order to imitate IE6. However, I could be wrong and maybe the spec is creative in ways it shouldn't have been. <script> for the sake of keeping the prescan as simple as possible? |
| 09:24 | <hsivonen> | Also possible. |
| 09:32 | <Sam Sneddon [:gsnedders]> | If I'm reading the Chromium code correctly, it's running the tokeniser with scripting disabled, which means the prescan would pick up <noscript><meta charset=…> |
| 09:32 | <hsivonen> | Fun |
| 09:33 | <hsivonen> | What would be a simple way for the page to self-diagnose whether there was a charset reload? |
| 09:33 | <Sam Sneddon [:gsnedders]> | write in localStorage? though I guess that depends on how it deals with committing things there |
| 09:34 | <hsivonen> | I guess local-storage would involve having to edit a test-specific key into each test. |
| 09:34 | <Sam Sneddon [:gsnedders]> | I guess it's somewhat difficult to avoid the actual parser changing encoding from document.write for the parser would be to change the confidence to certain before executing any script; I wonder how often that would change things… |
| 09:35 | <hsivonen> | Pretty sure that would break the Web. |
| 09:35 | <Sam Sneddon [:gsnedders]> | I can find very little evidence for sites using document.write("<meta charset=…>") at least, but yeah, I suspect it would break the web due to sites having the meta after a first script |
| 09:36 | <Sam Sneddon [:gsnedders]> | even just changing changing it to certain on a document.write call would I expect break things :( |
| 09:36 | <Andreu Botella (he/they)> | Wouldn't that have to be document.write("<meta ch" + "arset=...")? |
| 09:36 | <Sam Sneddon [:gsnedders]> | to avoid the prescan? yes |
| 09:37 | <Sam Sneddon [:gsnedders]> | my hypothesis is few sites are deliberately trying to avoid the prescanner 🙃 |
| 09:42 | <hsivonen> | That WebKit/Blink got away with https://hsivonen.com/test/moz/meta/after-head-after-1kb.htm goes against my intuition of the Web. |
| 09:43 | <hsivonen> | Too bad that for TLS reasons, it's very annoying to test IE6 these days. |
| 09:43 | <Ms2ger> | Please leave your intuition at the door as well? |
| 09:44 | <Sam Sneddon [:gsnedders]> | is that another difference with the prescanner? (after </head>) |
| 09:44 | <hsivonen> | Looking for the end of head is a WebKit/Blink difference from the spec. The one that I'm trying to resolve in Gecko. |
| 09:47 | <hsivonen> | Specifically, I'm trying to make Gecko load https://hsivonen.com/test/moz/meta/after-1kb.htm like WebKit/Blink without reloading. (With this test the reload is so fast that you don't notice.) |
| 09:49 | <hsivonen> | (As for why not just go ahead and do exactly what Chrome does: That would involve introducing the capability of the tokenizer to have different kinds of token sinks in Gecko. Also, if using the tree builder works, the prescan process could yield speculative loads.) |
| 09:54 | <Sam Sneddon [:gsnedders]> | the only difference then would be the prescan running without scripting? |
| 09:54 | <Sam Sneddon [:gsnedders]> | (v. the "real" parser) |
| 12:20 | <hsivonen> | the only difference then would be the prescan running without scripting? document.write. That is, it could be a speculative real parse. |
| 12:30 | <hsivonen> | So far, noscript is the only case where using the real tree builder would differ from Chrome: https://hsivonen.com/test/moz/meta/ |
| 12:45 | <hsivonen> | Another difference between Chrome and the real tree builder: https://hsivonen.com/test/moz/meta/in-template-after-1kb.htm |
| 20:09 | <dg12> | I noticed that on the introduction page ( html.spec.whatwg.org/multipage/introduction.html ) the section :"Design Notes" includes a paragraph stating: Authors can create plugins and invoke them using the embed element. This is how Flash works. Since the announcement of Adobe ending support of Flash Player on December 31, 2020, should this be revised to provide a different example? |
| 20:12 | <Andreu Botella (he/they)> | Good point. It's no longer true that authors can create plugins, since the after the death of Flash the spec's sections about plugins are being slimmed down to only leave things that are relevant to PDF viewers. |
| 20:13 | <dg12> | Andreu, can you submit an issue? |
| 20:14 | <Andreu Botella (he/they)> | I'll file a pull request |
| 20:14 | <dg12> | Thansk |
| 20:15 | <dg12> | when you do can you please let me know where it is filed. |
| 20:30 | <Andreu Botella (he/they)> | dg12: https://github.com/whatwg/html/pull/6867 |
| 21:28 | <Andreu Botella (he/they)> | dg12: Do you want me to add you to the acknowledgments section? |
| 22:14 | <Ian Hickson> | hey folks, long time no see |
| 22:14 | <hober> | hi ian! |
| 22:14 | <hober> | i hope you're well |
| 22:14 | <sideshowbarker> | whoah |
| 22:14 | <sideshowbarker> | Howdy Ian |
| 22:15 | <Ian Hickson> | i figured i would pop in because i've been working on a vector graphics format for flutter and thought y'all might be a good audience to get feedback from :-) |
| 22:15 | <Ian Hickson> | flutter.dev/go/vector-graphics is the doc, it's mostly a discussion on the use cases and requirements and such, but there's a proposal at the bottom |
| 22:17 | <sideshowbarker> | Ian Hickson: incidentally, one thing that surprised me when I read this before was the “Flutter explicitly does not support vertical text” part |
| 22:17 | <sideshowbarker> | for developing apps for Japanese users, seems like a pretty big limitation |
| 22:19 | <Ian Hickson> | yeah, that was a decision we made really early on, because we knew that if we had to support vertical text it would increase the complexity hugely, since it's really not something you can bolt on the side |
| 22:19 | <sideshowbarker> | yup |
| 22:19 | <Ian Hickson> | we tried to use the "pay as you go" model for most of our design, and we couldn't see a way to do vertical text in that model |
| 22:20 | <Ian Hickson> | (pay as you go, as in, if you don't need a feature, you don't have any overhead from it. like, in HTML, even if you never use padding, you still have to pay the cost for parsing padding in CSS, laying it out, etc. but in flutter if you never use padding, all the code for it is literally not in your binary.) |
| 22:21 | <Ian Hickson> | (same's true of bidi, but there's a bigger portion of people who need that.) |
| 22:21 | <sideshowbarker> | right yeah it makes sense but certainly I would think that choice is going to limit Flutter adoption in Japan vs the alternatives |
| 22:21 | <Ian Hickson> | yeah |
| 22:21 | <Ian Hickson> | definitely |
| 22:22 | <sideshowbarker> | yeah vertical text is very exceptional in that it really isn’t needed outside Japan, while however it’s really needed in Japan |
| 22:22 | <sideshowbarker> | anyway, I had another meta-comment about the WVG part |
| 22:23 | <sideshowbarker> | …which is, why you prefaced it with This is presented as a proof of concept, not a formal proposal |
| 22:24 | <sideshowbarker> | that somewhat gives me the impression that maybe I should avoid avoid looking at the spec in much detail, because maybe it’s all just gonna change… or something |
| 22:29 | <Ian Hickson> | oh it'll definitely change, yeah |
| 22:29 | <Ian Hickson> | right now it's just a strawman intended to trigger discussion |
| 22:29 | <Ian Hickson> | i want to see if people are like "this entire approach is absurd" |
| 22:30 | <Ian Hickson> | or if they're like "omg this is awesome ship it now" |
| 22:30 | <Ian Hickson> | or something in between |
| 22:30 | <Ian Hickson> | and if nobody says its absurd, the next step is to remove the thing saying its just a proof of concept, and threaten to implement it, maybe that'll get people to say it's absurd. :-) |
| 22:31 | <sideshowbarker> | hahaha |
| 22:33 | <Ian Hickson> | i've definitely never found a good solution to the problem of getting feedback on an early proposal. there seems to be no step between "everyone ignores it because it doesn't matter" and "everyone freaks out because they think you're deploying a fait accompli" |
| 22:34 | <Alan Stearns> | I’ll wait until v3 to say it’s absurd, because by then it will inevitably be so. |
| 22:34 | <Karl> | The vector format is interesting - especially the lack of support for text and strokes. The former I can understand; text is awfully complex, and probably isn't too important for the listed use-cases. The latter seems potentially more controversial; have you made any prototypes using representative images to see what the benefit is of converting all of these to fills, and if it is worth the added complexity to the overall image? |
| 22:34 | <Ian Hickson> | alan: careful, if it's a format i'm designing it's not gonna be versioned :-P |
| 22:35 | <Ian Hickson> | karl: yeah that's definitely one of the things i'm most curious about. |
| 22:36 | <Ian Hickson> | karl: it's based on the desire to be able to implement the whole format in graphics shaders, where strokes are a lot harder to do than fills (apparently, i'm basing this on feedback i got from graphics library implementors, not personal experience) |
| 22:36 | <Ian Hickson> | i haven't tried converting a stroke-based image to fills |
| 22:36 | <Ian Hickson> | that would definitely be a good thing to try |
| 22:36 | <Ian Hickson> | the tiger image in particular has a lot of strokes and is one i would love to test |
| 22:38 | <Ian Hickson> | you lose the ability to do hairline strokes of course |
| 22:46 | <sideshowbarker> | at the broadest level, I would want this optimized for implementation in browser engines |
| 22:46 | <sideshowbarker> | I say that because while I’d be glad for y’all if you end up with a format that works well in Flutter, I would be much gladder if it also were to become something that web developers could use on the web — as an alternative to needing to use SVG |
| 22:47 | <Ian Hickson> | yeah, web support is definitely something i would love to see |
| 22:47 | <Ian Hickson> | (that's why i called it WVG :-) ) |
| 22:47 | <Domenic> | Yeah, SVG has some cool uses, like interactive diagrams in the HTML spec where it cross-links to the relevant definitions and algorithms... but for vector icons etc., something nice and simple would be great. |
| 22:47 | <sideshowbarker> | yeah |
| 22:47 | <Ian Hickson> | flutter being a fork of chrome and using the same skia backend, i suspect anything we do for flutter will work fine for the web |
| 22:48 | <Ian Hickson> | but that's definitely on my mind |
| 22:48 | <Domenic> | I guess I had trouble reading the spec because it's all about the binary format. I was able to get a high-level view that it only supports a few primitives and was able to tell what it omits. But I'd be curious about the authoring-friendly pre-compilation format and what that would look like. I enjoy the hackability of SVG. |
| 22:49 | <Ian Hickson> | there's a link somewhere to sample images which show the format i used to create them |
| 22:49 | <Domenic> | Or maybe from another angle: I'd be interested in what the abstract model for such a file is, with the binary format being just one serialization of that model. |
| 22:50 | <Ian Hickson> | here's an example: https://github.com/google/ui-exp-dg/blob/e9416c6bb836b0b0e412ea71d8164feefcf0e047/wvg/handcrafting/samples/action-info.wvgtxt |
| 22:50 | <Domenic> | Seems like it's something like "has metadata, has matrices, has shapes, has gradients, has paint somethings, has composition somethings" but it's all defined in terms of the binary blocks |
| 22:50 | <Ian Hickson> | or a more elaborate one: https://github.com/google/ui-exp-dg/blob/e9416c6bb836b0b0e412ea71d8164feefcf0e047/wvg/handcrafting/samples/slider.wvgtxt |
| 22:50 | <Domenic> | Which is probably great for interoperable implementations but just makes it hard to read |
| 22:51 | <Domenic> | Oh those examples do help |
| 22:51 | <Ian Hickson> | but yeah that's good feedback, i should add an intro section that talks about the abstract model |
| 22:52 | Ian Hickson | makes a note |
| 22:53 | <Domenic> | Also I can't quite tell where WVG comes down on this but I do think one killer advantage a new format might have is properly accounting for high-gamut and HDR colors. (Are those the same thing? Different? Color spaces? I dunno.) It seems like the web is going through a very slow and painful transition process to allow better colors and I imagine SVG getting that will be years down the line, after canvas and CSS and <img> etc. |
| 22:53 | <Ian Hickson> | currently this is all just 32bit color |
| 22:53 | <Ian Hickson> | srgb |
| 22:53 | <Ian Hickson> | though i guess i don't actually say srgb anywhere |
| 22:54 | <Domenic> | I don't know if anyone is clamoring for HDR icons but it seems like a good idea to allow them in the abstract |
| 22:55 | <Ian Hickson> | what would the format need to support to allow for it? |
| 22:56 | <Domenic> | I am like 60% confident that it would want some notion of color space, plus the ability for colors to be more than 32 bits. (I think 16 bits x 4 channels was mentioned somewhere). But it's better to ask someone who actually knows things :) |
| 22:57 | <Ian Hickson> | color space would be easy to add |
| 22:57 | <Ian Hickson> | more than 32 bits per color would be a new format, heh |
| 22:57 | <Ian Hickson> | this format is basically built around 32 bits as the unit of data |
| 22:57 | <Ian Hickson> | (it can certainly be 64 bits if that's what we need though, this is the kind of thing i really want to find out) |
| 22:58 | <Karl> | HDR icons would be very cool - one of the things I really love about the Mac (at least traditionally) is the fidelity and attention to detail even in "little things" like icons. Richer colours might not be the thing you'd immediately notice, but if you got used to it and went back to SDR colour, I think you'd feel that it just wasn't as good; that something was just missing. |
| 23:01 | <Domenic> | https://github.com/whatwg/html/issues/299 is somewhat relevant |
| 23:08 | <Ian Hickson> | based on some research it looks like 32 bits to describe the colors in the file itself would be fine in a vector format; we can always extend it later with a color space block to change how those 32 bits are interpreted |
| 23:09 | <Ian Hickson> | e.g. in the extreme we could literally define a block that defines a palette using groups of floats and then index into that |
| 23:11 | <sideshowbarker> | Domenic's link makes me realize that Dean Jackson is probably among the specific people from who you'd want to get feedback on this |
| 23:12 | <Domenic> | It looks like there are two issues: color space and how many bits you use to represent that space |
| 23:12 | <Domenic> | If you are using a high-gamut space like rec2020 (HDR) then 8 bits per channel will produce visible banding |
| 23:12 | <Domenic> | Seems like people are variously claiming you need 10, 12, or 14. |
| 23:12 | <Domenic> | So the current proposal is 16 bits per channel |
| 23:13 | <Domenic> | And there is some debate about 16-bit float vs. 16-bit int which I can't quite understand |
| 23:13 | <Ian Hickson> | in the output you want more than 32 bits total per pixel for sure |
| 23:13 | <Ian Hickson> | but colors in a vector format aren't used per-pixel |
| 23:13 | <Ian Hickson> | they're used as end-points of gradients, and solid colors |
| 23:13 | <Domenic> | Ah yeah good point |
| 23:14 | <Domenic> | So people wouldn't be able to manually create perfect gradients out of strokes but that's fine |
| 23:14 | <Ian Hickson> | yeah |
| 23:14 | <Ian Hickson> | they couldn't anyway :-) |
| 23:15 | <Domenic> | I guess the only remaining edge case I can think of is some company saying "our brand color is exactly between these two 8 bit values, how dare you not let us express it precisely" |
| 23:15 | <Ian Hickson> | i'm willing to take that phone call |
| 23:16 | <Ian Hickson> | if only to hear their explanation of how they're going to calibrate everyone's monitors and make sure everyone has perfectly-calibrated light bulbs |
| 23:17 | <Ian Hickson> | sideshowbarker: do you know what dean's current contact info is? is he still at apple? i thought i'd read he'd left at some point in the past few years but i admit i'm out of touch |
| 23:27 | <sideshowbarker> | sideshowbarker: do you know what dean's current contact info is? is he still at apple? i thought i'd read he'd left at some point in the past few years but i admit i'm out of touch |
| 23:27 | <Ian Hickson> | cool |
| 23:27 | <Ian Hickson> | thanks |