| 01:10 | <MikeSmith> | TabAtkins: about https://github.com/whatwg/html/issues/4752#issuecomment-508500008, I guess Bikeshed doesn’t yet provide a way to link to value definitions for global attributes? |
| 01:12 | <MikeSmith> | hmm, and maybe it doesn’t yet have a way to link to definitions for global attributes? (not just values) |
| 04:29 | <MikeSmith> | Domenic: FYI I finally got around to raising an SVG-spec issue about the spec no longer defining any attributes as required https://github.com/w3c/svgwg/issues/710 |
| 04:51 | <Domenic> | \o/ |
| 11:50 | <annevk> | JakeA: re https://twitter.com/jaffathecake/status/1147071838561984513 it could maybe fall out of the Storage Standard, but we haven't really properly layered all the things that we store on top of it |
| 11:52 | <annevk> | JakeA: I do think we should do more to standardize this stuff; I haven't had the time yet, but maybe I should try to find someone more actively |
| 15:00 | <innovati> | Is this the spot to ask about HTML Custom Elements, or Web Components? There are plenty of tools in use out there like Angular, React, etc that provide some kind of custom components for people building sites, but outside of those tools it's just kind of a black box as to what they're doing |
| 15:01 | <innovati> | I have found myself needing to modify or update websites built using these tools after the fact, externally, which means I have to look at the page, use Mutation Observers to watch for changes, and continually try to make sure my changes are present, not wiped out, but present every time they should be present |
| 15:02 | <innovati> | So my question is - in a future where people are using standards to build sites in similar ways, would the elements being output from standards-based tools be outputting things that the browser and JS would know about, and that would be simpler for me to extend from the outside? |
| 15:03 | <innovati> | Would some hypothetical React version be able to build on top of, and work alongside a different tool, sharing elements and 'components' without fighting to overwrite them and not have any knowledge of what the other tool thought about the component? |
| 15:19 | <annevk> | innovati: might depend a bit to what extent strong encapsulation is used and what you need to do |
| 15:20 | <innovati> | Is the difference between something like React and Heresy that the browser would know about, and other tools could also interact with the 'components' Heresy was working with, but React is currently kind of a black box to the browser and other JS? https://github.com/WebReflection/heresy |
| 15:21 | <innovati> | I don't do stuff with Web Components or these other tools but there's some kind of a difference or a distinction that's presently missing and I'm not sure how to put my finger on it but I know there's a better way than what we do now, and I believe the better tech might already exist |
| 18:01 | <Krinkle> | annevk: curious if you have a recommendation for 2019 for the use case of individually ephemeral values stored per-origin in the browser. I last looked at this in 2015, and at the time H2 was just coming up and there was a drive (at Wikipedia) to move away from cookies. Unfortunately, while sessionStorage (aka tabStorage) and localStorage have taken over a few use cases, the vast majority seems still only suitable for cookies. In particular because in |
| 18:01 | <Krinkle> | a large deployment, using localStorage means when keys change/evolve or features never used again, it accumulates. Hence resulting in loss of functionality after a while. |
| 18:03 | <annevk> | Krinkle: you’d have to do it in userland |
| 18:03 | <Krinkle> | We have a homemade abstraction over localStorage that does expiry through enumeration, but we don't enable it for most cases because it absolutely kills performance on mobile (eg. 200ms or more blocking I/O to iterate the keys, and 50ms+ to get their value). |
| 18:04 | <Krinkle> | it seems browsers don't read the per-origin thing into memory very well, so it's full disk I/O to open, read, query and close the underlying database every time complete no-go. |
| 18:04 | <annevk> | Krinkle: we have an idea around storage buckets that would be easier to isolate and manage, but still early days |
| 18:04 | <Krinkle> | yeah, the storage units and the way service workers does it seems very useful for PWA use of "caching" |
| 18:05 | <annevk> | Krinkle: Domenic et al are working on KV Storage which should do more things async |
| 18:06 | <Krinkle> | but that's different from more user-facing storing of "forgettable state", e.g. 15/200 random banners you've seen already, a section that's collapsed by default, an A/B test token, random crap like that (multiplied by 100). As a user navigates around the site, all of that builds up, but it never goes away, especially problematic for power users and regular contributors that interact with a ton of different front-end features. |
| 18:07 | <Krinkle> | (and worse in Firefox because if you visit one of the 900 wikis just once, it stays around forever and even our slow garbage collector can't reach it unless you visit the site again). |
| 18:07 | <Krinkle> | although I hear that's finally being changed |
| 18:07 | <Krinkle> | annevk: OK, so not something we can polyfill today yet with reasonable compat. |
| 18:08 | <annevk> | Only with IDB |
| 18:08 | <Krinkle> | IDB has TTL on keys? |
| 18:08 | <annevk> | Krinkle: it should not block as badly |
| 18:08 | <annevk> | Krinkle: cause async |
| 18:09 | <annevk> | Krinkle: you will also have more capacity |
| 18:09 | <annevk> | Gotta go |
| 18:10 | <Krinkle> | right, so manual garbage collecting could be more incremental and graceful. |
| 18:11 | <Krinkle> | Thanks, I think we could give that a go |