| 02:11 | <yhirano__> | annevk: I left a comment. |
| 02:12 | <yhirano__> | annevk: https://chromium-review.googlesource.com/c/chromium/src/+/792712 is landed, you will see the old behavior on Canary in a couple of days. |
| 08:30 | <annevk> | Domenic: what do you think of specification literals such as 'MIME type <text/html;charset=UTF-8>' or 'URL <about:blank>' with the MIME type and URL standards defining that it means to pass the <> contents to the respective parser to get the literal |
| 08:32 | <annevk> | Domenic: though maybe I should first find sufficient unique instances |
| 08:53 | <smaug____> | hayato: curious, do you happen to have a list of websites using custom elements (v1) ? |
| 08:55 | <hayato> | smaug____: I don't . YouTube still uses custom elements v0. |
| 08:55 | <smaug____> | yeah, that I know. |
| 08:56 | <hayato> | I think most google sites still use custom elements v0 |
| 08:56 | <smaug____> | it is surprising that youtube moved to use v0 |
| 08:56 | <smaug____> | from non-custom element code |
| 08:56 | <smaug____> | even though v0 was already deprecated |
| 08:56 | <smaug____> | oh well |
| 08:57 | <smaug____> | (or perhaps it has some v0 usage before too) |
| 08:57 | <smaug____> | s/has/had/ |
| 08:58 | <hayato> | Most web sites are still using Polymer 1.x, where custom elements v0 is used. |
| 08:59 | <hayato> | I think when they started to use Polymer, Polymer 1.x was the latest version. |
| 11:07 | <dpk> | is there any plan to improve the story for persistence of arbitrary data structures? |
| 11:08 | <dpk> | IndexedDB is nice but it seems in terms of access patterns, you can have any you like as long as it's B-tree |
| 11:09 | <dpk> | if you want to make a trie or something and store that persistently ... i guess what i'd like is a way to send an arraybuffer to be stored on disk which would then be mmap'd by the browser, or similar |
| 11:09 | <dpk> | maybe IndexedDB already does something like that? |
| 11:13 | <annevk> | dpk: you can store an ArrayBuffer in IDB, but probably not done in terms of mmap |
| 11:15 | <Mek> | we've certainly been thinking about some kind of low-level mmap-like storage primitive, in hopes it might let people build their own sqlite etc like stuff on top. Nothing concrete yet though |
| 11:16 | <Mek> | just a "maybe if we do this we can finally get rid of websql"... |
| 11:55 | <dpk> | i must say i'm surprised by how 'high-level' a solution IDB is |
| 11:55 | <dpk> | i thought the point of this new 'extensible web' shibboleth was that you give us the mashed potatoes and we have to make our own bookshelves out of that |
| 11:56 | <gsnedders> | dpk: DB stuff is all mirred in politics, unfortunately |
| 11:59 | <annevk> | Well, standards is politics, so I'm not sure that helps |
| 12:00 | <annevk> | IDB basically predated the idea to go very low-level and was largely designed as an alternative to WebSQL |
| 12:03 | <dpk> | ah |
| 12:07 | <annevk> | WebSQL is still the only API that's seen somewhat favorably, but it's not really standardized to the extent needed |
| 12:08 | <annevk> | And I guess localStorage might be too, by those who don't care about synchronous I/O being bad |
| 12:09 | <dpk> | i assumed localStorage was for stuff that fits in real memory, hence the 5 MB size limit |
| 12:10 | <annevk> | dpk: I guess we can retroactively try to explain it that way, but at some point it will still need to be written to and from disk |
| 12:11 | <annevk> | dpk: that is a reason why it has its own limit though; maybe we should formalize that more in the spec so that nobody tries to actually raise it |
| 13:48 | <annevk> | Domenic: started creating your desired MIME type JSON test resource: https://github.com/w3c/web-platform-tests/pull/7764 |
| 13:49 | <annevk> | Domenic: still need to write wrappers for Request/Response/Blob/File |
| 14:44 | <annevk> | (also done now; many failures) |
| 14:56 | <wanderview> | JakeA: should "RespondToSameOriginRequestWithCrossOriginResponse" show up here even if it its had zero hits? Or does it missing mean there have been zero uses? https://www.chromestatus.com/metrics/feature/popularity |
| 15:52 | <Domenic> | annevk: https://github.com/whatwg/mimesniff/issues/7 is interesting because it seems like a case of conflicting constituencies; non-browsers use the mimesniff algorithms too, and sometimes don't have content-types to rely on. Maybe we should state explicitly that mimesniff shouldn't be used for places like go, only for browsers? That seems kind of harsh and against the spirit of other things like URL and MIME type |
| 15:52 | <Domenic> | parsing though. |
| 15:53 | <annevk> | Domenic: I need to think through it again, but if servers sniff I believe they should sniff exactly in the same way as browsers do |
| 15:54 | <Domenic> | Well, but browsers don't always need to sniff |
| 15:54 | <Domenic> | This also motivates some of the other mimesniff bugs that are open but don't have browser-observable impact, e.g. what a font MIME type is |
| 15:55 | <annevk> | well browsers have a font code path that sniffs, I don't know if that's helped with a font MIME type though |
| 15:55 | <Domenic> | i.e. it doesn't matter to a browser whether it's application/font-woff or font/woff, just that it should interpret is as a WOFF. But people writing server software might want to sniff files and determine whether to serve them as font/woff |
| 15:55 | <annevk> | But yeah, I think you're correct that we might have to clarify a few things around scope |
| 15:55 | <Domenic> | In other words if we scope only to browsers, all the "MIME Sniffing" is actually kind of disingenuous; it's more "resource type sniffing" and the actual MIME types don't matter |
| 15:56 | <annevk> | Well, it matters a bit for browsers as they might want to expose it as font/woff somewhere |
| 15:57 | <annevk> | E.g., sniffed images types are exposed through document.contentType |
| 15:57 | <Domenic> | True |
| 15:57 | <annevk> | So if browsers implemented some kind of font viewer... |
| 15:57 | <annevk> | (If they did I'd hope they make it make cross-origin documents always) |
| 15:58 | <annevk> | Domenic: quick yes/no on whatpr.org? |
| 15:58 | <Domenic> | annevk: I have no opinion one way or the other |
| 15:59 | <annevk> | ta |
| 15:59 | <annevk> | You'll have to look at such URLs a lot so you better not complain about it later |
| 16:01 | <Domenic> | As I said, I'm happy with what we have currently, s3.whateverwhatever, so it's all fine with me :) |
| 16:06 | <annevk> | Domenic: I filed a follow-up issue to work out the scope stuff for MIME Sniffing |
| 16:06 | <Domenic> | Nice |
| 16:53 | <Ms2ger> | whatpr.org? |
| 17:08 | <annevk> | See misc-server |
| 17:40 | <annevk> | Domenic: sorry for the initial agitated response in that test PR; most of your suggestions are great and I should just take my time to get to them |
| 17:42 | <Domenic> | No problem, seemed fine to me :) |
| 17:58 | <annevk> | Domenic: do you know if "async append" is still being worked on? |
| 17:59 | <annevk> | Domenic: there's renewed interest in DOMChangeList et al internally (from the wasm side) and we'll discuss it during the upcoming Mozilla week |
| 17:59 | <annevk> | Domenic: would be good to have all the information if there's anything new I might not have seen |
| 18:02 | <Domenic> | annevk: I think Ojan was going to post something about async append/DOMChangeList soon |
| 18:05 | <annevk> | Domenic: so the other thing is that I have tested most of the non-ASCII stuff in a more ad-hoc fashion and in the 3 other test PRs |
| 18:05 | <annevk> | Domenic: the multiple slashes thing I hadn't really studied thus far though |
| 18:06 | <annevk> | Domenic: within the next 8 days or would be ideal; seems Ojan no longer hangs out here |
| 18:07 | <Domenic> | Yeah I let him know |
| 18:08 | <annevk> | ta |
| 19:11 | <alsoStevenXL> | 0/ |
| 20:17 | <timwis> | Hey folks, what's the best way to pass an object to a custom element? I assume using attributes requires encoding/decoding JSON (unless you override setAttribute?), and the html5 dataset object also seems to cast things to strings. Should I just use a new attribute? |
| 20:41 | <annevk> | timwis: if it must be declarative, yes |
| 20:45 | <timwis> | annevk: as opposed to what? |
| 20:49 | <TimothyGu> | timwis: would merely setting a property of the custom element work? |
| 20:50 | <timwis> | TimothyGu: that's what I meant about using a new attribute; meant to say property |
| 20:50 | <TimothyGu> | timwis: ah. I think annevk understood it to mean HTML attribute |
| 20:50 | <timwis> | that works for now, was wondering if there were any other ways |
| 21:04 | <TabAtkins> | timwis: Yeah, the standard pattern is to have an attribute and a property that reflects it. (That way you don't have to override get/setAttribute, that's just the standard source of truth, and the property consults the attribute when it's queried.) That means you need something that can be serialized to a string. If you want something that's not serializable, then you have just a property, not an attribute, and it's |
| 21:04 | <TabAtkins> | only accessible via JS. |
| 21:13 | <annevk> | Or a method |
| 21:31 | <timwis> | TabAtkins: isn't there a significant performance hit from serializing and deserializing? for instance, if you want to pass a large array of objects to a custom element instance |
| 21:32 | <TabAtkins> | That sounds almost certainly like something that you would not put into the markup as an attribute. |
| 21:44 | <timwis> | TabAtkins: right, but I might pass it via react/vue templates |
| 21:44 | <timwis> | i guess the onus would be on the framework to set the property rather than attribute |
| 21:44 | <TabAtkins> | Then you do what you've gotta do, yeah. |
| 22:53 | <MikeSmith> | TabAtkins: about https://github.com/whatwg/html-build/issues/113 (syntax highlighting for the HTML spec), is that JSON structure otherwise OK as far as what you need? |
| 22:53 | <TabAtkins> | Yup! |
| 22:53 | <MikeSmith> | cool |
| 22:54 | <TabAtkins> | I just need to finish separating out the highlighter. |
| 22:57 | <MikeSmith> | super, I have 1106 test cases you can use :) |
| 22:58 | <MikeSmith> | by the way, you’re handling WebIDL highlighting, so I guess that means you must have wrote a WebIDL parser? |
| 23:05 | <MikeSmith> | :) https://groups.google.com/a/chromium.org/forum/#!msg/chromium-dev/hlv-fbFW-6o/fnZoRd7IBQAJ 😂 |
| 23:06 | <MikeSmith> | > "Random amateur" might be a cool job title for me to change to :). In point of fact, though, I get paid for this, so I'm more of a random professional. |
| 23:06 | <MikeSmith> | pkasting++ :) |