| 01:07 | <TabAtkins> | Domenic: You want "all: default;", which I need to go spec. |
| 01:08 | <TabAtkins> | Which means "pretend only the UA stylesheet exists". |
| 01:10 | <Domenic> | TabAtkins: meh, what I want is more like "all: like-ye-old-reset-stylesheet". i.e. no margins or padding or font size adjustment. |
| 01:11 | <TabAtkins> | You're not getting that, because it's opinionated in a weird way. |
| 01:11 | <TabAtkins> | "do what the UA stylesheet does" is simple and easy to talk about, and has a useful purpose in returning you to the "clean slate" that you started the page with. |
| 01:11 | <Domenic> | yeah, I agree. |
| 01:12 | <Domenic> | I was just sold for a long time that all: reset was going to replace my reset stylesheets, by parties unknown. it turned out to be false. |
| 01:12 | <TabAtkins> | Depends on what your reset stylesheets do. |
| 01:12 | <TabAtkins> | all: default; will replace your normalize.css. ^_^ |
| 03:09 | <JonathanNeal> | Death to normalize.css! And anyone who ever contributed to it. |
| 03:13 | <caitp> | well that seems a bit harsh |
| 03:39 | <roc> | gsnedders: ask on mozilla IRC instead? |
| 03:46 | <roc> | I mean, #developers, not #firefox |
| 03:46 | <roc> | or try it in a clean profile |
| 04:46 | <JonathanNeal> | caitp: it was a joke |
| 07:45 | <karlcow> | CSSOM and resize https://lists.w3.org/Archives/Public/public-webapps/2009AprJun/1061.html |
| 08:48 | <annevk> | Glenn Adams still hasn't fixed the CSSOM bugs? Shocker |
| 10:03 | <zcorpan> | didn't ie drop resize on elements recently? |
| 10:03 | <zcorpan> | seems like a good time to spec it |
| 10:06 | <annevk> | hah |
| 10:07 | <Ms2ger> | Morning zcorpan |
| 10:07 | <zcorpan> | good morning |
| 10:08 | <Ms2ger> | Your chocolate should be underway today |
| 10:08 | <Ms2ger> | In the meantime, want to do some reviews? :) |
| 10:08 | <zcorpan> | ooooh |
| 10:23 | <jgraham> | Ms2ger: Well played :) |
| 11:55 | <JakeA> | TabAtkins: what do you think of a :tab-focus pseudo to specifically target keyboard focuses? |
| 11:56 | <JakeA> | I find myself calling .blur() on something after mouse/touch to avoid buttons looking "stuck" |
| 11:56 | <JakeA> | which is obviously bad for a11y |
| 12:16 | <annevk> | JakeA: are you solving a CSS problem with blur()? |
| 12:16 | <annevk> | JakeA: isn't this why CSS gives you control over outline? |
| 12:20 | <JakeA> | annevk: I want my buttons/links to have a focus style so they can be tabbed through, but when they're clicked I don't want the button to appear "stuck" due to the focus style |
| 12:22 | <JakeA> | annevk: Firefox doesn't focus buttons on click, but it does for tabindex elements & links. Chrome focuses anything on click that can receive focus. Safari doesn't focus links on click but will focus tabindex elements… it's a bit of a mess |
| 12:23 | <annevk> | UI input is a topic standards cover very poorly |
| 12:23 | <JakeA> | Tbh, I like the model of focus-on-click, because I'd expect the next tab to go to the tabbable element after the one I clicked, but the styling gets in the way |
| 12:23 | <annevk> | but thanks for explaining, :tab-focus makes sense |
| 14:14 | <annevk> | JakeA: what are the chances of Google following if we shipped proposal 3 from https://github.com/slightlyoff/ServiceWorker/issues/566 ? |
| 14:15 | <annevk> | JakeA: I sort of stopped caring about this when nobody wanted to give up scopes, but others do so I'll proxy |
| 14:18 | <JakeA> | annevk: I thought the conclusion of our meeting was that multiple scopes aren't needed, but it'd be nice to be able to change scopes in the activate event? |
| 14:19 | <annevk> | JakeA: the meeting summary suggests multiple scopes was very much on topic? |
| 14:20 | <JakeA> | annevk: yeah, my misremembering, sorry. I think we're still lacking good example cases where this is needed, but at least we have a way to add it without breaking compat |
| 14:21 | <annevk> | JakeA: so changing scopes would probably be okay as is? But multiple scopes would be more contentious? |
| 14:23 | <annevk> | And opting into fetch events seems contentious as well... |
| 14:23 | <annevk> | Sorry, opting out |
| 14:23 | <JakeA> | annevk: I think multiple scopes are the most contentious bit |
| 14:23 | <annevk> | ta |
| 14:24 | <JakeA> | which bit are Moz most interested in, or is it all of it? |
| 14:24 | <annevk> | I'm not sure, Ehsan asked about proposal #3 so I'll let you know when I know more |
| 14:24 | <annevk> | Some of Moz are interested in dropping all scopes still :p |
| 14:25 | <annevk> | (but they have also admitted defeat, don't really want to scare anyone) |
| 14:27 | <JakeA> | yeah, scopes have been really useful when it came to hosting on things like github & local servers |
| 14:27 | <annevk> | I don't disagree with that, but they're tacked on rather than a boundary which is the part that's wrong |
| 14:34 | <JakeA> | annevk: have you seen https://github.com/slightlyoff/StorageDurability/blob/master/explainer.md before? Who'd be good to get involved at Mozilla? We need something to achieve storage persistence, and I quite like the simplicity of this one |
| 14:47 | <annevk> | JakeA: probably the same people as SW |
| 14:49 | <annevk> | JakeA: the "What's All This About?" is rather Chrome-centric |
| 14:49 | <annevk> | JakeA: nobody else cared about that filesystem API and I'm not sure what it has to do with storage durability... |
| 14:51 | <JakeA> | annevk: yeah, I'm not sure what the onsync thing is either |
| 14:52 | <JakeA> | I'd rather it kept to one method |
| 15:34 | <annevk> | JakeA: is this replacing the evicted stuff? |
| 15:37 | <JakeA> | annevk: I still think those are useful, but we sorely need storage persistence, so I'm willing to move anything more complicated to "v2" |
| 15:38 | <wanderview> | annevk: you mean the onevicted event in SWs? I seem to recall some issue about that |
| 15:38 | <annevk> | I still think we should just provide everyone persistent storage |
| 15:39 | <annevk> | Plus heuristics, plus some kind of eviction... |
| 15:39 | <JakeA> | annevk: it's tough to put the user in charge of "uninstalling" things they didn't "install" |
| 15:39 | <annevk> | JakeA: this SD proposal also seems to assume the quota API is a thing we want |
| 15:39 | <wanderview> | I guess the hard part is determining who might be a bad actor in the system... who is using an unfair share of disk space blocking others from using it |
| 15:39 | <annevk> | JakeA: perhaps it's only really persistent if you bookmark |
| 15:40 | <wanderview> | annevk: do the specs have the concept of bookmarks, or is that a UA concept? |
| 15:40 | <JakeA> | annevk: I think bookmarking can auto-grant the permission, but I still think we need the permission |
| 15:41 | <wanderview> | JakeA: reading your comment about `navigator.requestStorageDurability()` I wondered... wouldn't everyone just call this? why wouldn't they call it? |
| 15:41 | <annevk> | wanderview: it would be a UA concept |
| 15:41 | <wanderview> | is the idea that it creates a doorhanger or something? |
| 15:41 | <JakeA> | The idea is to allow a web user to safely cache 10gb of movies for a flight, without visiting another origin as they board the plane which puts their system under pressure and the browser throws everything away |
| 15:42 | <JakeA> | wanderview: it would show up a permission request |
| 15:42 | <annevk> | So many prompt designs :-( |
| 15:42 | <wanderview> | yea... if every page wants this for its 100kb of "essential" data... thats gonna be a lot of prompts |
| 15:42 | <annevk> | The user will have to click through an enormous amount of dialogs this way |
| 15:43 | <wanderview> | what about the call taking a size limit... durable up to this amount... UA can auto-grant permission for sizes less than X |
| 15:43 | <annevk> | notifications / storage / push / background / geolocation / ... |
| 15:43 | <annevk> | wanderview: well, UAs can always have better heuristics I suppose |
| 15:43 | <JakeA> | wanderview: that's the quota API isn't it? I thought the feeling was that size is too difficult to communicate to users |
| 15:43 | <annevk> | wanderview: I think we've lost the moment we ask the user for a specific amount of storage |
| 15:44 | <wanderview> | hmm |
| 15:44 | <JakeA> | annevk: Chrome already rolls notification & push into one permission request |
| 15:44 | <wanderview> | what about making all storage up to X durable by default... this API request is just for storage above X and does trigger a prompt |
| 15:44 | <JakeA> | if you request push, you get notificaitons |
| 15:44 | <wanderview> | so vast majority of websites don't need it |
| 15:45 | <wanderview> | maybe this is already whats there |
| 15:46 | <annevk> | JakeA: but Chrome has a distinct one for background push? |
| 15:46 | <annevk> | JakeA: (with background above I meant sync) |
| 15:46 | <JakeA> | annevk: hasn't been worked out yet |
| 15:46 | <annevk> | JakeA: right... |
| 15:47 | <annevk> | wanderview: we already have a quote of 10MiB or some such per eTLD+1 |
| 15:47 | <annevk> | wanderview: quota |
| 15:47 | <annevk> | wanderview: and I think Firefox at some point had a prompt design |
| 15:47 | <wanderview> | annevk: in a spec or gecko? |
| 15:47 | <wanderview> | this needs to be consistent across browsers so web developers can design sane offline apps |
| 15:47 | <wanderview> | it seems to me |
| 15:48 | <annevk> | wanderview: https://html.spec.whatwg.org/#disk-space-2 |
| 15:48 | <JakeA> | annevk: it has/had an appcache prompt |
| 15:48 | <annevk> | JakeA: well that too, but I thought there was something around storage |
| 15:48 | <wanderview> | annevk: we have persistent, temp, and default storage... the spec stuff I've seen does not have the concept of "default" storage |
| 15:48 | <annevk> | or maybe that was Opera... hmm |
| 15:49 | <annevk> | HTML has "A mostly arbitrary limit of five megabytes per origin is suggested. Implementation feedback is welcome and will be used to update this suggestion in the future." |
| 15:49 | <wanderview> | yea |
| 15:49 | <JakeA> | As a user, if my device comes under storage pressure, I wouldn't expect to see things in the disk-usage menu that I hadn't 'added' somehow |
| 15:49 | <wanderview> | fun that its uncompressed size :-) I've been compressing in Cache |
| 15:51 | <wanderview> | also... uncompressed size for quota... just seems terrible for the user |
| 15:51 | <JakeA> | agreed |
| 15:51 | <wanderview> | JakeA: is there anything that prevents ad iframes from requesting these perms on every page visit? |
| 15:52 | <JakeA> | wanderview: generally we don't let iframes request permissions |
| 15:52 | <wanderview> | I seem to recall we had a problem with that and the contacts perm request in fxos |
| 15:52 | <annevk> | If I frequently visit something or have it bookmarked I would be quite happy if things got stored without anyone bothering me about it... |
| 15:52 | <JakeA> | since it doesn't tally with the url the user can see |
| 15:52 | <annevk> | wanderview: I wouldn't get hung up on compressed vs uncompressed, that should all really be up to the UA and we shouldn't really have to expose that |
| 15:52 | <wanderview> | yea |
| 15:52 | <annevk> | wanderview: although maybe at some point people don't want to see things compressed twice or some such... so we might add more control then |
| 15:53 | <wanderview> | annevk: I think the UA should be smart enough to do that |
| 15:53 | <JakeA> | annevk: yeah, bookmark or add-to-homescreen should auto-grant I think |
| 15:54 | <JakeA> | The UA could even auto deny the permission on things like first visit |
| 15:55 | <wanderview> | I wonder if the UA could do a dynamic heuristic like... auto-grant the durable permission at first... when the page actually breaches limit X, then place the door hanger... to avoid overwhelming the user with prompts |
| 15:56 | <wanderview> | I guess it comes down to when the API tells the page it officially has the storage or not |
| 15:59 | <annevk> | wanderview: might get problematic |
| 15:59 | <annevk> | wanderview: fairly simple app, large video file, boom |
| 15:59 | <wanderview> | annevk: why is that a boom? prompts, user says yes or no... |
| 16:00 | <annevk> | wanderview: oh right, it can still store it but it might not be persistent |
| 16:00 | <annevk> | wanderview: sorry |
| 16:00 | <annevk> | wanderview: yeah might be okay |
| 16:01 | <wanderview> | with limited disk space... seems like we need a cooperative system... but of course the web is full of evil people |
| 16:02 | <annevk> | well the end goal is that the browser gets the whole hard drive |
| 16:02 | <annevk> | which is not super limited |
| 16:03 | <wanderview> | annevk: on mobile it is |
| 16:03 | <annevk> | low end, true, high end, less so |
| 16:03 | <annevk> | but yeah, that's why we need to give users insight into storage used |
| 16:04 | <annevk> | improving UI around this seems like it should be priority 1 |
| 16:04 | <annevk> | because if that's unclear while we start handing out persistent storage we got a real mess |
| 16:20 | <wanderview> | I think low end mobile is what we should design... if we don't think disk is a limited resource then we should just not bother with any of this |
| 16:27 | <annevk> | wanderview: well I think we need to handle full disk |
| 16:28 | <annevk> | wanderview: and let the user manage storage |
| 16:28 | <annevk> | wanderview: those are all things we could do before we attempt persisting |
| 16:28 | <wanderview> | annevk: I agree we need it because storage is a limited resource (especially on mobile) :-) |
| 16:58 | <Domenic> | Is there any way to create an ArrayBuffer whose backing memory is composed of several other array buffers? |
| 17:09 | <paul_irish> | I'm trying to quiet the console spam in Chrome around "invalid" mimetypes. I want to validate that specs do not have normative mimetype requirements for stylesheets, images, and fonts. |
| 17:10 | <Domenic> | paul_irish: I think per recent discussions in this channel, stylesheets have normative requirements. annevk was mentioning it IIRC? |
| 17:11 | <gsnedders> | paul_irish: most of the time the behaviour is undefined |
| 17:11 | <gsnedders> | CSS de-facto has to be loaded with the right mime type (at least cross-origin), because of data-leakage attacks |
| 17:11 | <annevk> | paul_irish: arguably HTTP requires resources to have valid MIME types |
| 17:12 | <annevk> | paul_irish: however, browsers do not enforce MIME types for images, stylesheets, and scripts |
| 17:12 | <annevk> | paul_irish: oops, they do for stylesheets, not for fonts |
| 17:12 | <gsnedders> | annevk: stylesheets I think same-origin in quirks you can use whatever |
| 17:13 | <annevk> | gsnedders: yup |
| 17:13 | <paul_irish> | for stylesheets i looked at the impl in blink. it we would silently fail if its cross-origin, there is no text/css or "" empty mimetype, and the payload doesn't start with valid CSS. |
| 17:14 | <paul_irish> | but outside of those 3 constraints, it's good |
| 17:15 | <annevk> | it should fail same-origin as well I think in standards mode |
| 17:15 | <annevk> | dunno if empty MIME type matches the spec |
| 17:15 | <annevk> | offhand |
| 17:16 | <paul_irish> | k. thanks |
| 17:17 | <annevk> | paul_irish: if the metrics show that over time more people use correct MIME types the console spam may be worth it |
| 17:18 | <annevk> | paul_irish: the current model is rather prone to attacks |
| 17:18 | <paul_irish> | <img src="evil.js"> ? |
| 17:51 | <annevk> | paul_irish: more like <script src=image> |
| 17:51 | <paul_irish> | gotcha |
| 17:52 | <annevk> | paul_irish: basically a mismatch between what the server thinks the file can be used for and what the browser allows |
| 17:52 | <annevk> | paul_irish: sniffing is defined and it's somewhat clear to server operators these days not a lot can be trusted, but if we could improve that'd be nice |
| 17:53 | <annevk> | Domenic: I think only Blob supports that... |
| 17:53 | <annevk> | Domenic: also, that seems more like a feature for views than the buffer... |
| 17:55 | <Domenic> | annevk: meh not sure why it would be. I have several arraybuffers and I want to concatenate them with a transfer instead of copy. |
| 17:56 | <annevk> | Domenic: there's a proposal for transfer I think |
| 17:56 | <Domenic> | annevk: yep, that's where I came from actually. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/ArrayBuffer/transfer |
| 17:57 | <Domenic> | We're thinking of using transfer for byte streams |
| 17:57 | <Domenic> | but we still have a use case where people want to read an entire stream into one big array buffer |
| 17:57 | <annevk> | I'd like some syntax for ArrayBuffer so you can do AB1 + AB2 |
| 17:57 | <Domenic> | i think it's OK to say people have to do that manually though, and/or wait for an ES7 combiner method |
| 17:59 | <wanderview> | does it really matter how the ArrayBuffer stores it in memory if there is an API to create an AB from multiple other ABs? |
| 18:00 | <Domenic> | wanderview: I just want no-copies guaranteed, not sure whether I care about how it's stored. |
| 18:03 | <wanderview> | Domenic: well, no-copy means multiple segments if you have multiple sources :-) feedback from people in the room with me is that multiple segments is harder to do and also keep the various view classes fast |
| 18:03 | <Domenic> | interesting |
| 18:04 | <wanderview> | for example if your UInt16 crosses segment boundaries or something... now you can't just simple processor primitives... you have to additional logic in the path |
| 18:04 | <wanderview> | it seems possible... but sounds like there would be push-back |
| 18:55 | <rillian> | so, the media element resource selection algorithm says the user agent will discard <source> elements whose type attributes it knows it cannot play |
| 18:56 | <rillian> | I assume that means canPlayType() == '' |
| 18:57 | <rillian> | but there seems to be no coupling to the actual resource load |
| 18:57 | <rillian> | so the type attribute can be pure fiction outside of the 'I know I can't play that' constraint |
| 18:57 | <rillian> | is that correct? |
| 18:58 | <rillian> | I ask because imgur.com's new gifv service makes pretty markup with webm and mp4 source links...and serves video/mp4 to for both resources. |
| 18:59 | <TabAtkins> | I think so, yeah. |
| 19:01 | <rillian> | ok, so all that careful arguing we did for page control of which resource to load...not so much :( |
| 19:52 | <zewt> | sounds like the usual "seems to work" that everything on the web falls into when you have variable behavior |
| 20:45 | <annevk> | rillian: the page does control what to load, no? |
| 20:46 | <annevk> | rillian: I'm not sure if it's all browsers yet, but the MIME type stated by the server is ignored, I believe, but the MIME type stated by the page is used for negotiation by browsers |
| 21:26 | <rillian> | annevk: I'm not sure that's true |
| 21:27 | <rillian> | I mean, I hope we reject sources with types we can't play |
| 21:27 | <rillian> | but we accept sources whose actual type doesn't match their declared type |
| 21:28 | <Domenic> | Are 304s still transparent to fetch? Or is there some fromCache flag? |
| 21:28 | <rillian> | I fear without that kind of enforcement the type attribute on <source> is as moot as the type from the server |
| 21:29 | <TabAtkins> | rillian: The 'enforcement' is "the browser won't play it if it doesn't know that the type attribute specifies something it can play". |
| 21:35 | <rillian> | TabAtkins: the spec says "A type that the user agent knows it cannot render" which is the opposite |
| 21:35 | <rillian> | perhaps because of the whole 'maybe' thing with canPlayType? |
| 21:35 | <TabAtkins> | Sorry, I got lost in the negations. Obviously I mean the other way. ^_^ |
| 21:35 | <rillian> | heh |
| 21:36 | <rillian> | anyway, this is just me failing to not say 'I told you so'. It is what it is. |
| 21:36 | <rillian> | I was just sad that it's possible to totally lie about the type attribute |
| 21:37 | <rillian> | lie *with* the type attribute on <source> |
| 21:44 | <TabAtkins> | Eh, turns out type-sniffing video is just easier and more reliable for everyone. |
| 21:46 | <TabAtkins> | The only real reason to declare the type is to avoid retrieving anything at all when we can tell ahead of time that it definitely won't work, which is precisely what it does. |
| 22:02 | <annevk> | Domenic: there's various open issues around caching |
| 22:12 | <Domenic> | annevk: use case: trying to adaptively estimate download speeds and use that to choose quality for future video downloads, but want to eliminate outliers caused by caching returning very fsat |
| 22:15 | <annevk> | Domenic: the outstanding issues are primarily around security and a good model for partially cached resources |
| 22:15 | <annevk> | Domenic: it's clear that exposing this would be useful |
| 22:15 | <annevk> | Domenic: see bugs on Fetch and various issues scattered around GitHub |
| 22:15 | <Domenic> | ah yeah security fun times |
| 22:15 | <Domenic> | yeah it sounded familiar just kind of remembered it being resolved by now |
| 22:16 | <annevk> | Domenic: there's bits in the spec |
| 22:17 | <annevk> | Domenic: the partially cached stuff is still somewhat broken, I forgot why fromCache hasn't been added yet |
| 22:17 | <annevk> | Domenic: perhaps I was waiting for feedback on the general design of things first and some answer about how to handle partial caches |
| 22:17 | <annevk> | Domenic: it's all in the issues somewhere |
| 22:18 | <annevk> | https://lists.w3.org/Archives/Public/www-international/2015JanMar/0080.html "Do not interpret my comments as an attack on the author." trololol |
| 22:35 | <Domenic> | O_O |
| 22:38 | <TabAtkins> | Glenn "I've never made a nontrivial edit to the only CSS spec I maintain" Adams |
| 23:12 | <MikeSmith> | that nickname's probably too long for him to fit on his business card |
| 23:12 | <MikeSmith> | so probably need to do some brainstorming to help him come up with a shorter nickname |
| 23:13 | <dglazkov> | don't be mean to folks :) |
| 23:13 | <MikeSmith> | hey I'm just trying to be helpful here |
| 23:14 | <MikeSmith> | anyway, speaking of helpful, "Waiting for available socket" |
| 23:14 | <MikeSmith> | I seem to be getting that message in Chrome oftenish these days |
| 23:15 | <MikeSmith> | or more accurately, in Chromium, built from trunk |
| 23:15 | <MikeSmith> | I got a lot of tabs open but I wouldn't think that would cause it |
| 23:15 | <MikeSmith> | also, this is on OSX |
| 23:16 | <caitp-> | i've seen that a few times before, on stable builds afaik |
| 23:16 | <MikeSmith> | ah OK |
| 23:16 | <MikeSmith> | well to be clear when it happens, the page load just hangs |
| 23:16 | <MikeSmith> | or I mean the response never comes at all |
| 23:16 | <caitp-> | yeah |
| 23:17 | <MikeSmith> | I seem to be getting it when trying to load *.w3.org resources |
| 23:20 | <caitp-> | ulimit maybe? or does that affect osx |
| 23:22 | <Domenic> | it affects osx worst of all |
| 23:22 | <Domenic> | osx has very low defaults |
| 23:23 | <MikeSmith> | ah ok |
| 23:23 | <MikeSmith> | what's ulimit? |
| 23:23 | MikeSmith | googles |
| 23:23 | <caitp-> | kern.maxfiles seems to be around 12k here |
| 23:28 | <MikeSmith> | so would the number of open tabs have any effect on this? |
| 23:29 | <MikeSmith> | I have about 75 tabs open |
| 23:30 | <caitp-> | i'm not sure exactly how chromium's socket pooling works, if each frame gets its own socket pool then sure |
| 23:30 | <caitp-> | running a webserver or database or building big code would add to it |
| 23:31 | <caitp-> | or maybe it's a bug in chrome, hard to say :< |
| 23:32 | <MikeSmith> | wait so I had naively assumed it meant chrome was waiting for a network socket |
| 23:32 | <caitp-> | psychic debugging is hard, i'm just throwing ideas at you |
| 23:33 | <MikeSmith> | heh |
| 23:34 | <MikeSmith> | anyway ulimit -n says 2560 on my system, which seems like it should be enough |
| 23:35 | <MikeSmith> | I'll give up for now |
| 23:36 | <MikeSmith> | on the bright side, it's cool how Chrome doubles as a system load tester |
| 23:50 | <jgraham> | They should get bratell on that. I hear his hobby is running at the system resource limits |
| 23:50 | <gsnedders> | I seem to remember him claiming to have surprisingly few tabs open when I last spoke to him. |
| 23:50 | <gsnedders> | Like only a few hundred. |
| 23:52 | <jgraham> | Well with presto on 32bit windows he had enough open to frequently test the OOM handling |
| 23:59 | <jgraham> | annevk: Did you see http://daniel.haxx.se/blog/2015/02/24/curl-smiley-urls-and-libc/ ? |