| 09:40 | <mathiasbynens> | annevk: re: https://github.com/whatwg/html/issues/3400#issuecomment-615130411, "valueAsColor() doesn't help with submission" -- is that a dealbreaker somehow? |
| 09:41 | <mathiasbynens> | valueAsDate() doesn't affect submission either, it's just a way to read the serialized value in a different format |
| 09:43 | <annevk> | mathiasbynens: we need something for submission if we're going beyond RGB |
| 09:44 | <mathiasbynens> | annevk: sure, but do developers want to specify the exact serialization format? I was assuming it would be sufficient if the .value would be "any valid CSS color as produced by the CSS color serialization spec", and maybe that's wrong |
| 09:44 | <annevk> | mathiasbynens: it does seem to fine to offer utility methods, but if you're looking at an MVP I'd not target those |
| 09:45 | <annevk> | mathiasbynens: I suspect servers will break if <input type=color> suddenly started emitting non-RGB strings |
| 09:45 | <mathiasbynens> | annevk: yeah i think shoehorning this into type=color is a bad idea in general |
| 09:45 | <annevk> | mathiasbynens: if it's <input type=color widegamut> that's fine though |
| 09:45 | <mathiasbynens> | a new input type seems better |
| 09:46 | <annevk> | mathiasbynens: there's a bunch of precedent with the existing types for attributes to modify them somehow, e.g. <input type=file multiple directory> |
| 09:46 | <mathiasbynens> | I agree we don't want to break <input type=color> :) |
| 09:46 | <annevk> | or webkitdirectory |
| 09:46 | <annevk> | I guess we're mostly aligned then |
| 13:51 | <Domenic> | A new element!! |
| 14:11 | <Domenic> | Specifying MIME type parsing was a good move. It's nice to see things like https://github.com/mensbeam/mime crop up. |
| 14:22 | <annevk> | That's not the PHP I used to write 🙂 |
| 15:19 | <Domenic> | annevk: for portals (spec work is re-starting) we want to have the spec primitives to specify "no storage" for a given browsing context, and then after activation "storage as normal" (i.e. keyed to origin like a TLBC, no double-keying). Will the storage infra work you're workign on provide the primitives for that? |
| 15:43 | <TabAtkins> | I'm going to assume "TLBC" is "Three Letter BaCkronym" |
| 15:45 | <Domenic> | top-level browsing context, ofc |
| 16:04 | <annevk> | Domenic: it would allow you to explain the observable effects, but it's prolly still some work |
| 16:05 | <annevk> | Domenic: this mostly provides infrastructure for replacing the underlying storage bucket and also make it clearer which APIs end up in the same bucket |
| 16:06 | <Domenic> | annevk: hmm so this mostly helps with buckets, not necessarily with double-keying? Or are they connected? |
| 16:07 | <annevk> | Domenic: they are and it helps with double-keying |
| 16:07 | <annevk> | Domenic: but double-keying is different from blocking |
| 16:09 | <Domenic> | Right, that makes sense |
| 16:09 | <Domenic> | Although I wonder why our plan is blocking instead of changing the key to something useless |
| 16:11 | <Domenic> | I guess what I mean is keying to an isolated origin |
| 16:11 | <Domenic> | But then it's pretty weird if only storage treats the origin as opaque |
| 16:11 | <Mek> | storage is mostly blocked on opaque origins anyway? |
| 16:11 | <annevk> | I think so |
| 16:11 | <Domenic> | Is it blocked? I thought it just wrote to something that only you could access. |
| 16:11 | <Mek> | and swapping out storage is much weirder than unblocking imho. What happens to open transactions, etc for example. |
| 16:12 | <Mek> | Currently it is blocked for almost every storage API |
| 16:12 | <Domenic> | I see. https://w3c.github.io/IndexedDB/#dom-idbfactory-open |
| 16:12 | <annevk> | Transactions get terminated |
| 16:12 | <annevk> | Also a problem if you swap with an empty bucket |
| 16:12 | <Domenic> | https://html.spec.whatwg.org/multipage/webstorage.html#storage-object-initialisation-steps |
| 16:12 | <annevk> | aka Clear-Site-Data |
| 16:13 | <Domenic> | I wonder if we can define "storage is blocked" just by piggybacking off of this infrastructure |
| 16:13 | <Mek> | I thought clear-site-data also froze/reloaded pages? But perhaps that was an optional flag. |
| 16:13 | <annevk> | Mek: that's an optional flag that Chrome didn't implement and caused a bunch of trouble for Firefox |
| 16:13 | <Domenic> | I guess we need to define "storage key" separately from "origin" anyway to help with double-keying... /me goes to re-read annevk's proposal |
| 16:13 | <annevk> | Domenic: obtain the key is currently XXX, but yes |
| 16:14 | <annevk> | Domenic: Storage asks for an environment and my idea is to get the key from there; currently it assumes you don't invoke it from an opaque origin environment but I should probably flip that around and only returning failure or some such |
| 16:14 | <Domenic> | This makes sense |
| 16:14 | <Domenic> | I'll comment on the bug |
| 16:20 | <annevk> | Domenic: thanks |
| 16:22 | <annevk> | I need to think a bit more about sessionStorage / history which are of course weirdly special, but it's probably worth starting with this next week even if I leave those as XXX |
| 17:02 | <annevk> | Mek: if nobody does sessionStorage for opaque origins I'd be okay with stopping that |
| 17:02 | <annevk> | Mek: although if pushState() still works... |
| 17:02 | <Mek> | I have no idea what other browsers do for session storage unfortunately |
| 17:03 | <annevk> | Mek: but yeah, at this point I think the best course is that sessionStorage gets its own storage bucket that is session-lifetime-bound somehow |
| 17:04 | <Mek> | seems reasonable, yes... session-lifetime-bound, but also copied-on-creating-auxiliary browsing contexts |
| 17:04 | <annevk> | Mek: and history.pushState() may or may not be able to use that too, not sure I'll figure all that out for v0 though, but I suspect I might try to poke at things a bit |
| 17:06 | <annevk> | Mek: yeah that also needs some work, if the session belongs to the browsing context group the spec might not have to copy |
| 17:06 | <annevk> | oh wait, it probably does need to copy because afterward they are independent? |
| 17:07 | <Mek> | exactly |
| 17:07 | <annevk> | oh well, it's all doable |
| 17:07 | <annevk> | but that does suggest it should have a bucket separate from pushState() |
| 17:07 | <annevk> | don't want to copy over that data too |
| 17:08 | <annevk> | weekend \o/ |
| 17:08 | <Mek> | definitely excited about better figuring out how session storage should/is behaving |
| 17:09 | <Mek> | (third party iframes, and should their storage be copied as well? Unclear in current spec, no idea what other browsers do, chrome does. I.e. a.com embeds b.com. Open a new window of a.com embedding b.com, and the new embedded b.com also gets a copy of the old embedded b.com) |
| 18:43 | <smaug____> | mkwst: you might know if https://w3c.github.io/reporting/#send-reports is supposed to happen for workers too? |
| 18:43 | <smaug____> | the text hints that it should not |
| 18:43 | <smaug____> | but the API is exposed to the workers too |
| 19:25 | <annevk> | smaug____: it should, baku filed an issue I think |
| 19:26 | <annevk> | Mek: I guess that makes sense, but would indeed be good to define it exactly |
| 19:26 | <smaug____> | annevk: ok, thanks. I just asked baku to file an issue, but I guess he did that already :) |