| 01:18 | <MikeSmith> | Domenic: I see "Agreement to the DCO is thus transmitted with each patch." but I don't find an actual description of how the agreement is actually recorded/transmitted |
| 01:19 | <Domenic> | MikeSmith: it appears to be the "Signed-off-by: Name <email>" lines in a given patch |
| 01:19 | <MikeSmith> | ah wait the paragraph just before that |
| 01:19 | <Domenic> | I'm a little unclear why asking a developer to include a signed-off-by line would be less onerous than asking them to sign a CLA |
| 01:20 | <MikeSmith> | that plus I wonder what happens if they forget to include that line in the commit message |
| 01:21 | <MikeSmith> | I guess reviewers are supposed to check for that before they merge anything |
| 01:22 | <zcorpan> | MikeSmith: https://github.com/ResponsiveImagesCG/picture-element/issues/256 |
| 01:25 | <MikeSmith> | zcorpan: yep, saw that you had raised that. I have no strong opinion on it either way. I don't think it would be any harder to implement a check for than any other of the esoteric requirements for srcset+sizes |
| 01:26 | <MikeSmith> | zcorpan: we're already at the point with the validator where the requirements have necessitated breaking abstractions in the code in order to implement |
| 01:27 | <MikeSmith> | well maybe not necessitated, but at least I couldn't figure out a way to add some things without violating a few |
| 01:28 | <MikeSmith> | zcorpan: e.g., this is what the "Require sizes attr when srcset specifies width" check looks like: Require sizes attr when srcset specifies width |
| 01:28 | <MikeSmith> | oops |
| 01:28 | <MikeSmith> | https://github.com/validator/validator/commit/8a4adc9834eeb8994deefed9948bc063cc79ce93 |
| 01:29 | <MikeSmith> | all of the datatype checks in the validators are done using singleton instances of the particular classes that do each check |
| 01:31 | <zcorpan> | MikeSmith: ok. for the issue i'm leaning towards just changing the grammar to require the default length |
| 01:35 | <MikeSmith> | zcorpan: ok. I think that might at least not have the particular issue that the width-required change did. |
| 01:36 | <MikeSmith> | zcorpan: part of the thing that complicates implementing these check is the sort of circular dependency between srcset and sizes with regard to width descriptors |
| 01:37 | <MikeSmith> | in that the spec says both, "If a source element has a sizes attribute present or an img element has a sizes attribute present, all image candidate strings for that element must have the width descriptor specified." and (now also) "If the srcset attribute has any image candidate strings using a width descriptor, the sizes attribute must also be present, and the value must be a valid source size list. |
| 01:37 | <MikeSmith> | Spec bugs: 26537 |
| 01:37 | <MikeSmith> | oofs |
| 01:39 | <zcorpan> | MikeSmith: i am aware of the two-way dependency, i'm not familiar enough with your impl to tell if there's a better way to do it |
| 01:40 | <MikeSmith> | zcorpan: yeah was just thinking out loud |
| 01:41 | <MikeSmith> | I reckon Henri could figure out a more elegant way for now what's there works fine |
| 01:42 | <zcorpan> | ok cool |
| 03:42 | <MikeSmith> | Domenic: I guess the DCO/Signed-off-by thing is not meant to be any less onerous for contributors than signing a CLA isーbut I think one advantage is that it obviates any need to have any process for signing the CLA that's separate from the process for creating a patch/PR, and especially that it obviates the need to keep any separate record somewhere of who's signed the CLA |
| 03:43 | <MikeSmith> | since the record of agreements is just right there within the change history for the sources |
| 07:44 | <MikeSmith> | botie, inform hsivonen when you have a minute please take a look at the following and let me know if you're OK with it. Basically it just refines fatal-error messages for files with content-type mismatches to include mention of the URL for the file. It seems safe to do since it's not leading any info the user doesn't already know. https://github.com/validator/validator/commit/c98215c55d2a8cd433877da23119 |
| 07:44 | <botie> | will do |
| 07:44 | <MikeSmith> | 16c9ebbfd342 |
| 07:44 | <MikeSmith> | botie, inform hsivonen https://github.com/validator/validator/commit/c98215c55d2a8cd433877da2311916c9ebbfd342 |
| 07:44 | <botie> | will do |
| 08:15 | <ineedhelpors> | hey guys |
| 08:15 | <ineedhelpors> | in need of advice |
| 08:19 | <ineedhelpors> | paying $10 btc if sum1 can help me with a file upload issue |
| 08:23 | <annevk> | Hixie: per https://twitter.com/sgalineau/status/564904540906872833 we should probably list instructions for how to unsubscribe |
| 08:24 | <caitp-> | you should probably make it a 1 or 2 step process |
| 08:25 | <caitp-> | and easy enough to figure out that nobody needs to dig around to find instructions and follow them |
| 08:26 | <annevk> | I suspect it's as easy as putting un in the obvious place of the subscribe address |
| 08:44 | <Krinkle> | Are there any plans for a Cookie interface in the DOM? E.g. for setting/getting cookies in a more object-oriented fashion, and removing the need for string parsing as much (ala classList) |
| 08:45 | <Ms2ger> | Not afaik |
| 08:45 | <annevk> | I think the recommendation is to leave cookies as a network affair to persist some state about the user |
| 08:46 | <annevk> | And put actual data either locally or on the server somehow |
| 08:46 | <Krinkle> | It seems the latest trend is to write a spec and have browsers implement it, instead of writing a library and poplarising it. I want in :) |
| 08:46 | <annevk> | Heh, I think it's always been a bit of both |
| 08:46 | <Krinkle> | Yeah, that's what the big apps do (e.g. Google, Wikipedia, ..) |
| 08:47 | <Krinkle> | typically only one main cookie, though that's never really true |
| 08:47 | <Krinkle> | Not having to parse and construct document.cookie would be nice :) |
| 08:51 | <Krinkle> | rhartl/jquery-cookie/issues/349 |
| 08:51 | <Krinkle> | https://github.com/carhartl/jquery-cookie/issues/349 |
| 08:51 | <Krinkle> | Cookie.set(), get(), remove() |
| 08:59 | <annevk> | Krinkle: if you do want to propose something, remember that anything synchronous is unlikely to fly |
| 09:01 | <Krinkle> | annevk: I don't mind either way. I'm happy for it to be async. |
| 09:03 | <Krinkle> | Though I'm curious with regards to race conditions |
| 09:03 | <Krinkle> | you wouldn't want one thing to set and another thing to check its existence and also start setting the same thing |
| 09:04 | <Krinkle> | Though in a good app (or just a simple app?) a single key would be managed by the same code which would thus naturally be aware of it. |
| 09:04 | <Krinkle> | Except when in multiple tabs of course. |
| 09:06 | <Krinkle> | with Promise and yield this can be abstracted though I suppose |
| 09:07 | <Krinkle> | annevk: You reckon it's feasible? I imagine even without the async benefit, the simplified and directer API for the browser would be worth something. |
| 09:08 | <Krinkle> | and if we made it a promise (or did you have another async method in mind?) it would be an opportunity to make cookie setting no longer blocking the main UI thread. |
| 09:11 | <terinjokes> | Krinkle: it's seems fairly easy to mock a library up to see how it works :) |
| 09:12 | <Krinkle> | Any ideas for what would be a logical/sensible location? global Cookie? Cookieset? document.cookieset? The cross-over between document and window is getter better lately, but it still not clear to me which way it's moving. |
| 09:13 | <Krinkle> | I guess for cookies, it's fine for it to not be attached to the document object, right? |
| 09:16 | <terinjokes> | Krinkle: why not make it a library first? |
| 09:16 | <Krinkle> | Sure |
| 09:22 | <annevk> | Krinkle: it would have to work in workers if we do something |
| 09:22 | <annevk> | Krinkle: it's not clear that people want to do something though; making cookies a network affair has some obvious benefits |
| 09:23 | <Krinkle> | annevk: What you do mean by network affair? No longer exposed in JS entirely? |
| 09:23 | <annevk> | Krinkle: yeah, what HttpOnly does |
| 09:23 | <Krinkle> | Interesting |
| 09:24 | <Krinkle> | Yeah, especially lacking a JsOnly option |
| 09:24 | <terinjokes> | we use cookies entirely as a token that we're the same session. we'd rather use one of the other storage mechanisms |
| 09:24 | <annevk> | well that's indexed DB et al |
| 09:25 | <Krinkle> | While most things I see use Storage for local stuff, there's a bunch of stuff out there that uses cookies. But being sent to the server each request for no reason |
| 09:25 | <terinjokes> | you can update older code |
| 09:25 | <annevk> | Krinkle: we should offer more control over whether cookies are included in a fetch |
| 09:25 | <annevk> | Krinkle: but what we have for that is an all-or-nothing flag |
| 09:26 | <Krinkle> | Which flag is that? |
| 09:26 | <annevk> | withCredentials in XMLHttpRequest, though it's limited to cross-origin fetches |
| 09:26 | <annevk> | fetch() has a way to do it same-origin |
| 09:27 | <Krinkle> | Ah, yeah |
| 09:27 | Krinkle | was just reading fetch.spec |
| 11:02 | <JakeA> | TabAtkins: is there someone/somewhere/something that collects layout use-cases that aren't possible with CSS? |
| 11:03 | <astearns> | JakeA: there's this one: https://www.w3.org/dpub/IG/wiki/Pagination_Requirements |
| 11:06 | <JakeA> | astearns: yeah, I guess I'm looking for something like that but general |
| 11:07 | <astearns> | JakeA: I think it's hard to come up with general layout requirements that mean much - tying things to specific uses helps refine the requirement |
| 11:08 | <astearns> | JakeA: one of the big lacks is laying out elements in relation to other elements, but that's too vague to be useful |
| 11:08 | <astearns> | JakeA: laying out elements in relation to a page (for instance) helps focus the idea |
| 11:09 | <JakeA> | astearns: heh, the issue I have is an element-to-element relation thing |
| 11:10 | <astearns> | JakeA: looking for a place to add your issue to, then? |
| 11:10 | <JakeA> | astearns: Well, maybe. I probably need to think about it a bit more, but was just wondering if there was a place for that type of thing |
| 11:11 | <astearns> | JakeA: mostly just www-style, I think. Or it could be a new specifiction topic... |
| 11:12 | <astearns> | JakeA: the houdini folks tasked with the custom layout spec might be looking for use cases |
| 11:49 | <gsnedders> | So what's happening with the Ruby stuff? Are browsers implementing the stuff in the W3C spec? |
| 11:54 | <MikeSmith> | annevk: about http://w3c-test.org/conformance-checkers/html/elements/a/href/userinfo-password-contains-pile-of-poo-novalid.html |
| 11:54 | <MikeSmith> | <a href="http://foo:💩@example.com"></a>; |
| 11:54 | <MikeSmith> | that should actually be valid, right? |
| 11:55 | <Ms2ger> | gsnedders, I wish I knew |
| 11:56 | <annevk> | MikeSmith: yeah, don't really see why it wouldn't be |
| 11:56 | <MikeSmith> | ok |
| 11:56 | <annevk> | MikeSmith: well perhaps <a> being empty is a problem? |
| 11:56 | <MikeSmith> | nah that's not the intent |
| 11:57 | <MikeSmith> | I wrote that test intending for it to just test whether pile-of-poo is allowed in the password part |
| 11:58 | <MikeSmith> | annevk: so <a href="http://💩:foo⊙ec"></a>; should be valid too? |
| 11:58 | <MikeSmith> | pile-of-poo in username part |
| 11:59 | <annevk> | yeah |
| 11:59 | <MikeSmith> | k |
| 11:59 | <MikeSmith> | thanks |
| 12:36 | <gsnedders> | Ms2ger: bah |
| 12:46 | <GPHemsley> | Periodic reminder that the RFC 2119 disclaimer has an erratum. |
| 12:47 | <GPHemsley> | Since nobody seems to know that. |
| 12:50 | <GPHemsley> | Errata ID 499 |
| 12:50 | <GPHemsley> | http://www.rfc-editor.org/errata_search.php?rfc=2119 |
| 13:01 | <annevk> | Seems like it has a bunch of typos. I remember Ian pointing out "NOT RECOMMENDED" once |
| 13:10 | <jgraham> | Not sure I even agree with the first two corrections there |
| 13:13 | <GPHemsley> | jgraham: I'm talking specifically about a single erratum. |
| 13:19 | <annevk> | GPHemsley: http://www.rfc-editor.org/errata_search.php?eid=499 works |
| 13:20 | <GPHemsley> | annevk: Oh, does it? I didn't realize. I searched the HTML for an id. |
| 13:20 | <GPHemsley> | (And found a whole lot of other issues.) |
| 13:21 | <GPHemsley> | I guess I overlooked the huge form at the top. |
| 13:21 | <GPHemsley> | Habit, I suppose. |
| 14:41 | <wanderview> | JakeA: this comment makes me think again we need some kind of stale-while-invalidate method in Cache: https://github.com/slightlyoff/BackgroundSync/issues/17#issuecomment-73685856 |
| 14:44 | <JakeA> | wanderview: can't you do that programmatically pretty easily? |
| 14:44 | <JakeA> | wanderview: http://jakearchibald.com/2014/offline-cookbook/#stale-while-revalidate |
| 14:45 | <wanderview> | JakeA: true... your statement "you're more likely to create this poor experience with the fetch event" made me think its kind of a footgun, though... would be nice to have a simpler way to DTRT |
| 14:46 | <wanderview> | JakeA: also, the browser could possibly optimize it if its a single method |
| 14:47 | <wanderview> | I guess we can just see what libraries emerge... if its necessary then maybe one of them will add a wrapper for stale-while-revalidate |
| 14:53 | <wanderview> | JakeA: I think part of my reason for wanting this is that we have Cache.add()... why have that convenience method but not the stale-while-revalidate one? :-) |
| 15:17 | <slightlyoff> | wanderview: I'm not sure a feature is justified for that. Putting everything in dev control makes it, as annevk said, something we can just advise users for. We avoided this error for Push/Notifications by design. Not sure why BG Sync is different |
| 15:24 | <wanderview> | slightlyoff: well... its not just something you would use for BG sync... but yea, thats fine |
| 15:24 | <slightlyoff> | wanderview: I don't understand. You seem to be suggesting that BG sync is somehow not simply a question of waking/sending-an-event to a SW which is in full control....why? |
| 15:26 | <wanderview> | slightlyoff: I'm saying stale-while-revalidate would be useful for normal fetch event handling in addition to BG sync |
| 15:27 | <slightlyoff> | wanderview: and I'm saying that adding a special-case API when you have the full power to do it yourself is premature |
| 15:27 | <slightlyoff> | wanderview: I'd like to see evidence of patterns in use, not idle speculation in bugs |
| 15:28 | <wanderview> | slightlyoff: when I wrote "yea, thats fine" above.. I meant I'm not pushing to add a method and we don't need to argue about it :-) |
| 15:28 | <wanderview> | slightlyoff: I just find it odd to have convenience methods like Cache.add() and .addAll()... but not other convenience methods |
| 15:28 | wanderview | shrugs |
| 15:29 | <slightlyoff> | it's fair |
| 15:29 | <slightlyoff> | I guess what I'm getting at is we could sketch out super-common uses for add and addAll |
| 15:29 | <slightlyoff> | stale-while-revalidate seems important, but I'm unclear how it fits into the evented lifecycle right now |
| 15:30 | <slightlyoff> | we've talked about waitUntil in addition to respondWith for fetch events |
| 15:30 | <slightlyoff> | and if we see a lot of use of that to implement stale-while-revalidate, I'd be moved to add sugar |
| 15:31 | <wanderview> | why would the life cycle have to change if we can already implement stale-while-revalidate with existing primitives? |
| 15:36 | <slightlyoff> | wanderview: well, i think it'd be a bit of a hack today |
| 15:36 | <slightlyoff> | wanderview: without waitUntil, you can _in theory_ be killed while doing the revalidate bit |
| 15:37 | <slightlyoff> | wanderview: it's unlikely to happen |
| 15:37 | <slightlyoff> | wanderview: but it's an interesting question, and the opportunities for better CPU/memory usage aren't well studied yet |
| 15:38 | <wanderview> | slightlyoff: are you saying the UA is allowed to kill the SW before cache.put() here? http://jakearchibald.com/2014/offline-cookbook/#stale-while-revalidate |
| 15:38 | <wanderview> | or before the cache.put() resolves I guess... would be nice if the spec said something about keeping the SW alive until in-flight network requests are complete or something |
| 15:39 | <annevk> | wanderview: that'd give an easy trick for keeping it alive for a long time |
| 15:40 | <wanderview> | annevk: is the SW allowed to be killed if there is still script running? that seems like an easier trick to keep it alive... setTimeout(), etc |
| 15:41 | <annevk> | wanderview: I would imagine it can be killed after each task |
| 15:41 | <annevk> | wanderview: as long as it keeps track of important tasks somehow such as incoming messages so they get handled the next time |
| 15:43 | <wanderview> | annevk: it would be nice if the spec was explicit about this stuff :-) but without that, I think we would want to keep the SW alive until the network response body is complete in this code: http://jakearchibald.com/2014/offline-cookbook/#stale-while-revalidate |
| 15:44 | <annevk> | wanderview: well I've been asking for a more explicit lifecycle for a long time now |
| 16:33 | <JakeA> | annevk: wanderview: slightlyoff has asked for fetchEvent.waitUntil for this case |
| 16:38 | <wanderview> | JakeA: seems like a good idea... I commented in the waitUntil issue |
| 16:39 | <annevk> | JakeA: sure, that doesn't fix the lifecycle issue though |
| 16:40 | <JakeA> | annevk: as in, specing timeouts etc if a non-resolving promise is passed to event.waitUntil (for example) |
| 16:40 | <annevk> | JakeA: defining what happens with outstanding tasks |
| 16:41 | <annevk> | JakeA: making sure that the definitions are such that no fetch event can get lost, even if the UA does several reboots of the SW |
| 16:41 | <JakeA> | gotcha |
| 16:46 | <wanderview> | annevk: it seems we can improve our understanding of the life cycle with waitUntil() even if every corner case is not spec'd out yet... no? |
| 16:47 | <annevk> | wanderview: well, web developers have another straw to hold onto |
| 16:47 | <annevk> | (pessimistically put) |
| 16:47 | <annevk> | I'm not sure it'll help implementers much |
| 16:48 | <wanderview> | annevk: I think it will... I have a specific issue waitUntil() would help with... namely around not canceling networking requests that are on-going like in JakeA's stale-while-revalidate recipe |
| 16:48 | <wanderview> | annevk: soon gecko will cancel network requests when the SW thread is stopped |
| 16:49 | <annevk> | wanderview: it will cancel the SW network requests, right? |
| 16:49 | <wanderview> | waitUntil() seems easier to deal with than trying to infer how long to keep the SW thread alive through a heuristic there |
| 16:49 | <wanderview> | annevk: yes |
| 16:49 | <annevk> | wanderview: not new fetches coming from a worker or document? |
| 16:50 | <wanderview> | annevk: it will cancel a fetch() started in the SW... a worker or document that does a fetch() cancels it when you navigate away from the document |
| 16:50 | <wanderview> | (same thing as stopping the worker thread...) |
| 16:50 | <annevk> | Yeah, but if we do that then I don't understand why we don't put waitUntil() on the global... |
| 16:50 | <annevk> | And of course we have to protect against waitUntil() abuse |
| 16:51 | <wanderview> | annevk: because you can't keep a dedicated worker alive if its parent document has navigated away! that seems... to explode my brain |
| 16:51 | <annevk> | It just moves the problem elsewhere, e.g. waitUntil(new Promise(() => {})) |
| 16:51 | <wanderview> | annevk: it seems waitUntil is SW specific because it has unique (ill defined) shutdown conditions |
| 16:52 | <wanderview> | annevk: all other workers have clearly defined shutdown conditions tied to a document |
| 16:52 | <wanderview> | as far as I understand it |
| 16:53 | <tobie> | annevk: is http://www.w3.org/TR/html-design-principles/ still a thing, and if not, is there something that replaces it? |
| 16:53 | <JakeA> | annevk: it isn't on the global because success/failure is meaningful to the event dispatcher |
| 16:54 | <JakeA> | in the case of install & background sync for example |
| 16:55 | <annevk> | tobie: there was an editor's draft I can't find that has the baby steps principle |
| 16:55 | <annevk> | tobie: what's written there is still valid, but it's no longer maintained |
| 16:56 | <annevk> | tobie: perhaps we should adopt it as a wiki page |
| 16:56 | <tobie> | annevk: I like that |
| 16:58 | <annevk> | I like the "please remember your job" appeals on public-webapps ignoring end users |
| 16:58 | <annevk> | Oh no, I don't |
| 17:03 | <tobie> | annevk: decided to stay away from this conversation too. (Well, mostly: https://twitter.com/tobie/status/561079141517524992) |
| 17:05 | <annevk> | lol dglazkov |
| 17:06 | <dglazkov> | what did I do? |
| 17:07 | <annevk> | dglazkov: in my example bug you posted a link to some cool techno |
| 17:07 | <dglazkov> | nooooo.... |
| 17:07 | <annevk> | dglazkov: are you secretly a DJ at night? |
| 17:07 | <dglazkov> | omg |
| 17:08 | <dglazkov> | much embarrass |
| 17:08 | <annevk> | it's quite enjoyable |
| 17:09 | <dglazkov> | annevk: uh... yeah.. that was my promotion tactic... that's it |
| 17:09 | <dglazkov> | it wasn't a copypasta at all |
| 17:09 | <annevk> | hehe, "feel free to follow me on Twitter" |
| 17:11 | <wanderview> | annevk: JakeA: what kind of device works without power connected and without a battery? (in regards to https://github.com/slightlyoff/BackgroundSync/issues/35) |
| 17:12 | <JakeA> | ohhh a riddle |
| 17:12 | <wanderview> | just trying to understand the unicorn we are naming |
| 17:12 | <JakeA> | :D |
| 17:13 | <annevk> | wanderview: steam engine :-) |
| 17:13 | wanderview | proposes the .isThisThingOn attribute. |
| 17:13 | <jgraham> | A wind up radio? One of those watches that takes energy from your movements? |
| 17:13 | <jgraham> | Something with solar panels? |
| 17:13 | <wanderview> | the correct answer is solar powered browsers |
| 17:13 | <wanderview> | :-) |
| 17:13 | <JakeA> | wanderview: "chargingOnly" intends to mean "only sync if the device isn't discharging it's supply of power" |
| 17:14 | <JakeA> | but for a desktop machine, without a battery, you could say it is not charging |
| 17:14 | <JakeA> | because it has no battery to charge |
| 17:14 | <gsnedders> | What happens if it's a desktop machine currently relying on a UPS? |
| 17:15 | <wanderview> | JakeA: what about a power time estimate... "do the thing if we think we have enough power for more than 4 hours"... A/C power implies infinite time |
| 17:15 | wanderview | over complicates all the things. |
| 17:16 | <wanderview> | annevk: I would accept onSteamPower as an attribute |
| 17:17 | <annevk> | I'm okay with acOnly |
| 17:17 | <wanderview> | annevk: I just dislike that "ac" is hard to understand if you don't know you're talking about power |
| 17:18 | <annevk> | Agreed |
| 17:18 | gsnedders | is with wanderview here |
| 17:18 | <annevk> | JakeA: what was wrong with my suggestions? |
| 17:18 | <annevk> | JakeA: e.g. excludeBattery seems pretty clear |
| 17:18 | <annevk> | JakeA: or stationaryPower |
| 17:19 | wanderview | likes excludeBattery or something like it. |
| 17:19 | <wanderview> | avoidBattery |
| 17:19 | <wanderview> | exceptBattery |
| 17:19 | <wanderview> | ohGodNotTheBattery |
| 17:19 | <annevk> | preserveBattery |
| 17:19 | <JakeA> | haha |
| 17:19 | <wanderview> | annevk++ |
| 17:20 | <JakeA> | wanderview: annevk: *Battery could mean devices with a battery |
| 17:20 | <JakeA> | nothing to do with the battery discharging |
| 17:20 | <wanderview> | JakeA: preserveBattery seems kind of clear |
| 17:20 | <annevk> | JakeA: yeah, that seems covered |
| 17:20 | <wanderview> | "kind of clear"... I aim high! |
| 17:21 | <annevk> | JakeA: my laptop has a battery, but preserving isn't needed if power is plugged in |
| 17:21 | <JakeA> | hm, it sounds like it'll still happen on battery but preserve it somehow, like a low power mode |
| 17:21 | <JakeA> | maybe that's just me |
| 17:22 | <JakeA> | notDuringDischarge but ew discharge |
| 17:22 | <JakeA> | ugh |
| 17:22 | <annevk> | I mean the UA might still do it on battery I think |
| 17:22 | <annevk> | I don't think we want to give the app absolute control here |
| 17:22 | <annevk> | All these things are hints |
| 17:22 | <wanderview> | JakeA: I think preserveBattery makes sense... because the battery will be used as long as the device is on... and yea... gives wiggle room for the UA |
| 17:23 | <wanderview> | bikeshedding names makes me hungry |
| 17:23 | <JakeA> | The only use-case I have for this option is deferring it to a settings menu for the user, so the UA doing something different breaks that |
| 17:24 | <annevk> | I don't follow that |
| 17:25 | <JakeA> | So, my podcast app has a menu, where I the user can say "only sync when plugged in please" |
| 17:25 | <JakeA> | Does the option have a use outside of user settings? |
| 17:25 | <annevk> | Not sure, but if it's up to the user it shouldn't be up to the app |
| 17:26 | <JakeA> | right, ideally all syncs should be in one settings menu in the browser, and the user gets to decide what connectivity or battery state they're restricted to |
| 17:26 | <JakeA> | but for that to work, you need to display the sync's description |
| 17:26 | <JakeA> | which is set by the app |
| 17:27 | <JakeA> | which means you get that problem |
| 17:27 | <JakeA> | (https://github.com/slightlyoff/BackgroundSync/issues/29) |
| 17:27 | <annevk> | yeah, the user would just disable it for all syncs |
| 17:28 | <JakeA> | but I'm happy for my podcast app to update feeds whenever, but not download podcasts - actually that means the sync still happens, the battery api would be used within the sync in that case |
| 17:28 | <JakeA> | hmm |
| 17:43 | <wanderview> | fyi... if anyone is interested in testing the gecko service worker implementation... I'll be posting updated builds here until everything is in the tree: http://blog.wanderview.com/sw-builds/ |
| 17:49 | <Domenic> | Anyone else have opinions on this? https://twitter.com/streamsstandard/status/565196470836396033 |
| 17:50 | <wanderview> | Domenic: I prefer silent... you're asking it to enter a state... its already in that state... not an error (in my opinion) |
| 17:50 | wanderview | lunches |
| 18:00 | <jgraham> | annevk: Does fetch have enough infrastructure for specifying a HTTP-based protocol? Or how does one do that? The context is the WebDriver spec which specifies a HTTP-based API for remote controlling browsers. So it feels like you need some mechanism for parsing requests and constructing responses. |
| 18:01 | <jgraham> | current spec is https://w3c.github.io/webdriver/webdriver-spec.html |
| 18:07 | <JakeA> | Domenic: agree with wanderview. It's in the spirit of clearTimeout(123456) |
| 18:37 | <annevk> | jgraham: well everything XHR and fetch() can do... |
| 18:37 | <annevk> | jgraham: it depends on the details I guess |
| 18:38 | <jgraham> | Yeah, so I wonder if refering to Fetch is the right thing |
| 18:39 | <jgraham> | I wasn't sure it had all the bits needed for a server though, since it's all about being a client |
| 18:56 | <annevk> | Ooh |
| 18:56 | <annevk> | Not sure, Fetch is heavily client-focused |
| 18:59 | <Domenic> | I think you're underselling yourself annevk :). Service worker is like a server in many ways and the Fetch primitives (like Response) seem to be working pretty well there |
| 19:03 | <jgraham> | So this is literally my internal monolouge on the subject played out on irc :) |
| 19:09 | <wanderview> | that would be an interesting experiment... build a web server where network requests produce an onfetch event and you respondWith() the response |
| 19:10 | <wanderview> | would be a cool node module |
| 19:10 | <wanderview> | just need some streams support :-) |
| 19:32 | <Domenic> | I really should start putting together some demos with the streams polyfill that's already all ready to go |
| 19:32 | <Domenic> | In Node especially |
| 19:32 | <Domenic> | Although to be fair there's https://streams.spec.whatwg.org/#example-rs-pull :P |
| 20:01 | <botie> | hsivonen, at 2015-02-10 07:44 UTC, MikeSmith said: when you have a minute please take a look at the following and let me know if you're OK with it. Basically it just refines fatal-error messages for files with content-type mismatches to include mention of the URL for the file. It seems safe to do since it's |
| 20:01 | <botie> | not leading any info the user doesn't already know. https://github.com/validator/validator/commit/c98215c55d2a8cd433877da23119 and at 2015-02-10 07:44 UTC, MikeSmith said: https://github.com/validator/validator/commit/c98215c55d2a8cd433877da2311916c9ebbfd342 |
| 21:05 | <annevk> | wanderview: your blog needs some TLS |
| 21:05 | <wanderview> | annevk: not supported on custom domains with github pages... I checked |
| 21:05 | <wanderview> | annevk: I put the images on people.mozilla.org behind https, though |
| 21:06 | <annevk> | wanderview: you would need to know that in advance to avoid being spoofed :-) |
| 21:06 | <annevk> | wanderview: that's kinda shitty with GitHub, but I guess it makes some sense |
| 21:07 | <ondras> | firebase hosting uses tls by default |
| 21:07 | <ondras> | just in case. |
| 21:07 | <wanderview> | annevk: if you just do wanderview.github.io... https works... but there is no way to specify a cert for a custom domain |
| 21:12 | <Domenic> | wanderview: I indirect behind CloudFlare because I am lazy... |
| 21:12 | <wanderview> | Domenic: is there a guide on setting that up? |
| 21:13 | <Domenic> | wanderview: it is pretty simple, and you can use terinjokes as your personal tech support. Basically you follow https://help.github.com/articles/setting-up-a-custom-domain-with-github-pages/ |
| 21:14 | <wanderview> | ok... I've done that using dnsimple as my DNS provider |
| 21:14 | <wanderview> | Domenic: cloudflare lets you get ssl on github pages, though? not sure I understand how that works |
| 21:15 | <Domenic> | wanderview: yeah cloudflare gives you free TLS on your custom domain. |
| 21:15 | <Domenic> | It then proxies gh-pages in the background |
| 21:15 | <terinjokes> | if you upgrade to Pro you can upload the custom cert |
| 21:15 | <wanderview> | ah.... I see the diagrams here now: https://www.cloudflare.com/ssl |
| 21:17 | <terinjokes> | nvm, i read "custom cert" rather than "custom domain" |
| 21:18 | <wanderview> | Domenic: terinjokes: thanks! I'll make a note of that for a weekend project :-) |
| 23:21 | <JonathanNeal> | In today’s world of browsers and machines, does it improve performance to cache deep objects like toString = Object.prototype.toString? |
| 23:23 | <gsnedders> | JonathanNeal: in cold code? yes; in hot code? you're saving *at most* one class check per access |
| 23:23 | <gsnedders> | (of course in cold code you shouldn't care about the performance!) |
| 23:26 | <JonathanNeal> | gsnedders: Interesting. I still see this pattern in new scripts (and to be clear and narrow I’m referring to caching only for the sake of shortening the lookup). So, should we drop it? Did it once have significant impact on performance in old IE or something? |
| 23:27 | <gsnedders> | JonathanNeal: it did everywhere in the days before JITs |
| 23:28 | <gsnedders> | you might see a small performance increase in really tight loops, but by the time you're doing toString.call you've probably lost |
| 23:28 | <gsnedders> | But benchmark and don't take my word for it, etc. |
| 23:28 | <JonathanNeal> | I’ve been looking for existing benchmarks. Are there some keywords I haven’t used that might help me in my search? |
| 23:29 | <gsnedders> | I dunno! |
| 23:30 | <Domenic> | You should be benchmarking a larger app anyway |
| 23:30 | <Domenic> | Your code will be cold or hot only depending on the context of the app it's running in |
| 23:30 | <gsnedders> | And quite possibly inlined into it |
| 23:35 | <JonathanNeal> | Thanks gsnedders, Domenic. In our polyfill project, there’s a small discussion happening as to whether we should drop local variables that cache deep properties. I can’t find an existing benchmark, so I’ll just recommend we keep the local variables and test to see if we can drop them. |
| 23:36 | <MikeSmith> | does anybody know, when you do a multipart/formdata file upload in a browser running under Windows, it seems like it sets a Content-Type based on the file extension |
| 23:36 | <Domenic> | Or you could actually benchmark your own code instead of looking for a benchmark of someone else' code |
| 23:36 | <JonathanNeal> | Domenic: That’s what I thought I just said. Sorry if I miscommunicated. |
| 23:37 | <Domenic> | hmm ok |
| 23:37 | <Domenic> | sorry then |
| 23:37 | <JonathanNeal> | I did miscommunicate. I meant, s/test/test our library ourselves |