| 03:59 | <MikeSmith> | cool to see doublec contributing to servo |
| 08:36 | <SimonSapin> | The way to deal with navigating to a text/plain resource is to start the HTML tokenizer in PLAINTEXT mode, right? Is this specified? |
| 08:39 | <annevk> | SimonSapin: yes |
| 08:39 | <annevk> | SimonSapin: https://html.spec.whatwg.org/multipage/browsers.html#read-text |
| 08:39 | <SimonSapin> | thanks |
| 12:28 | <annevk> | wanderview: https://wiki.whatwg.org/wiki/Storage |
| 12:29 | <annevk> | JakeA: https://wiki.whatwg.org/wiki/Storage |
| 12:29 | <wanderview> | thanks |
| 12:29 | <annevk> | wanderview: JakeA: all very tentative |
| 12:29 | <annevk> | wanderview: I'd like to fit in the quota thing somehow, I agree that it seems like developers would like to be able to know how much they can store |
| 12:31 | <wanderview> | annevk: under "storage types" should that say best-effort instead of temporary? |
| 12:31 | <wanderview> | it seems that term is used elsewhere in the page instead of temporary |
| 12:31 | <annevk> | wanderview: temporary is meant for actual cache APIs (where you can clear stuff) |
| 12:32 | <annevk> | wanderview: I guess I should add best effort as well, as the default for non-temporary APIs |
| 12:32 | <wanderview> | ah |
| 12:33 | <annevk> | wanderview: clearer now? |
| 12:33 | <wanderview> | annevk: I guess I just don't see "temporary" mentioned in the "rough plan", so not sure how it fits in |
| 12:34 | <wanderview> | beyond what you told me in irc, of course |
| 12:34 | <annevk> | wanderview: rough plan has "Also create a new storage API for explicit priority-based temporary storage. A key/value/priority store, effectively. Application is in charge of determining and changing priorities over time." |
| 12:34 | <wanderview> | you're right of course... |
| 12:34 | wanderview | drinks more coffee... |
| 12:34 | <wanderview> | I'm working earlier than normal today |
| 12:35 | <annevk> | 10:30 or 9:30? |
| 12:35 | <annevk> | oh wait, my math is off again |
| 12:35 | <annevk> | more like 7:30/8:30 |
| 12:35 | <wanderview> | its 8:30, but with recent time change feels like 7:30 |
| 12:36 | <annevk> | this is like the best three weeks of the year for cooperation with the US |
| 12:36 | <annevk> | due to the US changing a bit earlier than us per some Bush administration decision |
| 12:36 | <wanderview> | annevk: we do our best not to be cooperative, it seems |
| 12:37 | <annevk> | uhuh |
| 12:51 | <annevk> | wanderview: perhaps UX along the lines of "mozilla.org would like to use a significant part of your hard drive (details). [Sure] [Nope]" with the site actually requesting a specific quota |
| 12:51 | <annevk> | wanderview: but that might already be too hard and too easy to say yes to with malicious cases? |
| 13:07 | <wanderview> | annevk: personally I still like the "don't ask except for large amounts" to reduce the amount of prompting |
| 13:07 | <wanderview> | annevk: I guess native gets an implicit prompt and permission when the user hits the "install this app" button |
| 13:10 | <wanderview> | annevk: btw, I want to say the safari on ios already has something like this prompt... I remember getting it while using ft.com "app" in the past |
| 13:16 | <annevk> | wanderview: don't ask seems okay, if we can promise better than "best effort" by default |
| 13:17 | <annevk> | wanderview: so yeah, that'd argue for something like by default you get persistent 10 MiB / 50 MiB or some such, you can ask for more, perhaps a specific amount or something elastic, and that would then create a prompt |
| 13:17 | <annevk> | hmm Nightly is really sucky today |
| 13:24 | <wanderview> | annevk: the problem with setting absolute values is that mobile will have much less space... and space will change over time... but using percantages also sucks because you can end up with unreasonable sizes easily as well... I think thats why gecko has the complex formula we have |
| 13:26 | <annevk> | wanderview: sure, we could say "each website by default has X, they can ask for Y, and we'll grant them Z, with X < Y && Z <= Y |
| 13:26 | <annevk> | " |
| 13:27 | <annevk> | wanderview: and then on top there's the temporary storage stuff, which is maybe some amount up to the UA |
| 13:28 | <annevk> | wanderview: (there's also been requests for separating app layer from data layer within persistent storage, but not super convinced that's going to work out) |
| 13:29 | <annevk> | wanderview: (iOS has "delete app" as suggestion for most, except some built-in stuff that is fancier...) |
| 13:29 | <wanderview> | annevk: yea, I can see the app vs data thing... that would certainly complicate the API, though |
| 13:30 | <annevk> | wanderview: well, we'd have to create yet more APIs... I think, you'd get best effort / persistent or persistent data or temporary |
| 13:31 | <wanderview> | annevk: right now I think people are advised to use separate Cache objects for app resources vs data resources... so I was thinking some kind of API to say "this Cache is best effort" and "this Cache is persistent"... thats more annoying than just saying "this origin is persistent" |
| 13:33 | <annevk> | wanderview: yeah, to keep the initial thing simple we should probably focus on a single persistence bucket |
| 13:34 | <annevk> | wanderview: if we later have more elaborate UX we can see if there's user scenarios for introducing more layers |
| 13:40 | <annevk> | wanderview: I learned from talking to Luke that gaming really wants real cache APIs, with priority; given our efforts there I guess that will be relatively important too |
| 13:47 | <annevk> | Hmm https://www.pandastrike.com/posts/20150311-react-bad-idea no Firefox does not ship Web Components... |
| 13:55 | <jgraham> | Yeah, so that post seems to have two principle problems: 1) the assumption that Web Components ship and 2) the assumption that they actually solve the problems that react et. al. solve, and better |
| 13:57 | <annevk> | A lot of seems to hinge on Web Components having a standards sticker of sorts |
| 16:55 | <dglazkov> | jgraham: a slightly less contrarian point of view: https://www.youtube.com/watch?v=g0TD0efcwVg |
| 16:56 | <dglazkov> | I am happier with that POV. Peeps seems to think it's either/or. Cage matches have always been crowdpleasers |
| 16:57 | <jgraham> | dglazkov: I hope that it does all work together well :) I wasn't taking a point of view, just pointing out that the author of that blog was making an argument that he entirely failed to back up. |
| 16:58 | <jgraham> | I guess if people suddenly want perf above all else it's quite important to be sure that using web components doesn't impose a mandatory performance penalty on the platform |
| 16:59 | <dglazkov> | that would be a terrible thing indeed |
| 16:59 | <jgraham> | (again I don't know if they do or not, but it at least seemed like some of the proposals that may since have been rejkected had that effect) |
| 17:24 | <dglazkov> | jgraham: there's nothing in specs that's inherently imposing perf penalties |
| 18:43 | <aklein> | TabAtkins: ping? |
| 18:44 | <TabAtkins> | aklein: pong |
| 18:45 | <aklein> | TabAtkins: whatever happened to putting SVG elements in the HTML namespace? |
| 18:45 | <aklein> | TabAtkins: or who might know that if it's slipped off your radar |
| 18:46 | <TabAtkins> | We'd still like to, but implementors keep being uninterested? The one case we've been able to drum up some interest with is putting HTML-namespace elements in SVG (rather than duplicating them in the SVG namespace, or using <foreignContent>). |
| 18:46 | <TabAtkins> | If you're interested, let's talk. ^_^ |
| 18:46 | <aklein> | TabAtkins: this came up on webapps the other day re: <template> |
| 18:46 | <TabAtkins> | Yup yup. |
| 18:47 | <aklein> | I'm not in a good position to actively work on this stuff right now, but I figured someone from the SVG WG should be on that thread |
| 18:47 | <TabAtkins> | <template> gives problems both ways. You wanna use it in SVG (thus putting an HTML-namespace element into SVG) and you want it to contain SVG fragments (thus putting an SVG-namespace element into HTML). And you'd like to do both of those without actually writing a namespace. |
| 18:47 | <TabAtkins> | Okay, where's the thread? blink-dev? Haven't checked that in a few days. |
| 18:48 | <aklein> | TabAtkins: https://lists.w3.org/Archives/Public/public-webapps/2015JanMar/0783.html |
| 18:48 | <TabAtkins> | Ah, kk. Havent' gotten down to that yet; still digging my way out of a week+ of email debt. ^_^ |
| 18:48 | <aklein> | I find it more actionable than usual since it's a proposal from a web dev, not an implementor |
| 18:48 | <aklein> | ah, ok |
| 18:48 | <aklein> | er, not a spec author |
| 18:49 | <aklein> | I should say |
| 18:49 | <TabAtkins> | Yeah, I understood what you meant to say. ^_^ |
| 18:57 | <annevk> | TabAtkins: I tried to grep bikeshed for "http:" btw but it looked like a bit too much to figure out for now |
| 18:57 | <annevk> | TabAtkins: did notice that there were a lot of IETF links that did not point to tools.ietf.org |
| 18:58 | <TabAtkins> | Those are all from SpecRef; if they're wrong, Tobie needs to be informed. |
| 18:58 | <annevk> | I thought he fixed them at some point |
| 18:58 | <annevk> | https://github.com/tobie/specref/issues/153 |
| 18:59 | <TabAtkins> | Ah, yup, they're updated in the db. |
| 18:59 | <TabAtkins> | Then people just need to regen their specs. ^_^ |
| 18:59 | <annevk> | Are specs part of the repo? |
| 18:59 | <TabAtkins> | No. |
| 18:59 | <TabAtkins> | That would be all kinds of crazy. |
| 19:00 | <annevk> | E.g. bikeshed/spec-data/readonly/biblio.data has a lot of these |
| 19:01 | <TabAtkins> | Yeah, that's the initial version of the data files, so people can use bikeshed immediately after cloning. It was generated relatively recently. |
| 19:01 | <TabAtkins> | Haha, I did it on Nov 12, *right* about the same time Tobie was fixing that stuff. |
| 19:01 | <annevk> | It has links such as http://www.ietf.org/rfc/rfc2342.txt which should no longer be part of specref afaict |
| 19:01 | <annevk> | I see |
| 19:02 | <TabAtkins> | I'll fix. But if anyone is using the online version, or has run `bikeshed update` since, they'll be good. |
| 19:02 | <annevk> | Ok |
| 19:10 | <boogyman> | annevk: has the FileAPI been put on hold/abandoned, or has Mozilla decided to just halt advancements? https://developer.mozilla.org/en-US/docs/Web/API/File |
| 19:11 | <annevk> | boogyman: neither? |
| 19:11 | <Ms2ger> | boogyman, what makes you say that? |
| 19:11 | <boogyman> | "Obsolete since Gecko 7.0" |
| 19:12 | <annevk> | boogyman: that's referring to those members, that have replacements elsewhere I think |
| 19:12 | <annevk> | boogyman: e.g. file.size (due to blob), file.name, and the FileReader API |
| 19:13 | <Ms2ger> | That was a proprietary File interface, afaict |
| 19:13 | <boogyman> | Thank you both for the clarification |
| 19:13 | <annevk> | Are those proprietary members still present in Firefox? Otherwise we could probably clean up the documentation a bit |
| 19:14 | <Ms2ger> | "obsolete" should mean they've been dropped |
| 19:14 | Ms2ger | pokes |
| 19:16 | <annevk> | We should have some policy that once a new Firefox LTS ships we remove all the removed stuff to avoid clutter |
| 20:38 | <jsbell> | I don't think the font used for "No progress" on critic is big enough. |