Re: Are we in favour of implementing the client hints header?
On Tue, Mar 8, 2016 at 5:05 AM, Xidorn Quan wrote: > So it seems there were some websites tried to use this, which made its > usage up to 0.06%, but then they abandoned. All of the features above is > used only in ~0.0002% of pages surveyed now, which may indicate its > unpopularity. Not sure why it was ever used in 0.06% of pages, and why > those page abandoned it. Probably Chrome team knows. > I'm suspect of those histograms as many of them take a deep dive around our M49 release. Wondering if we botched something on our end -- I'll investigate. That said, now that we've had this out in the wild for a while, some learnings and feedback: 1) In Chrome we've intentionally restricted initial implementation to apply to subresource requests only - i.e. navigation requests do not get any hints but can opt in their subresources. This decision was mostly a defensive move: we didn't want to send lots of new headers all at once to every site on the web; we wanted sites to opt-in and test their infrastructure. However, as Jonas already noted, said mechanism means that sites (a) can't detect client support for hints and (b) have continue to rely on UA sniffing (both for hints and the values that the hints communicate -- yes, it is ironic :)). This particular limitation came up in most every conversation I've had with various teams experimenting with CH, and was a roadblock for many. Addressing the above would go a long way. If you want to follow along, see: https://github.com/httpwg/http-extensions/issues/156 2) Re, CORS: this has been an ongoing discussion, but I think we're getting close. Opened: https://github.com/whatwg/fetch/pull/258 3) Chrome / Opera / Yandex are close to shipping Save-Data [1], which does not require Accept-CH opt-in; all three browsers will advertise Save-Data whenever the user enables ~"reduce data usage" mode in the browser. While it's still early, I can definitely say that removing the opt-in requirement has helped drum up *a lot* more interest. Aside: are there any user prefs in Firefox that could or should enable Save-Data? [1] https://developers.google.com/web/updates/2016/02/save-data On Thu, Mar 17, 2016 at 3:00 AM, Henri Sivonen wrote: > > I continue to believe that negotation mechanisms that the layout part of > the engine is aware of are superior to pushing the negotiation to the > networking layer. > That may well be true, but as we've discussed before, there are valid use cases where negotiation can: significantly lower the adoption barriers and complexity through automation; enable better data savings; address the myriad of UA-sniffing hacks that developers have to rely on today. Which is to say, they're not exclusive, and I don't think we should consider them as one vs. the other. --- In short, based on the experience so far, the overall feedback I've had has been positive, but we do need to address some of the shortcomings in the current design, as outlined above. With that in place, I think we'll unblock a lot of interesting use cases. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: Frame Timing API
FWIW, we have a tracking issue for this on GH: https://github.com/w3c/frame-timing/issues/40 On Mon, May 11, 2015 at 12:58 PM, Boris Zbarsky wrote: > No, you can't. We explicitly forbid that, precisely because of > side-channel timing attacks. dbaron has a good writeup about how the > :visited mitigation works at http://dbaron.org/mozilla/visited-privacy > but the upshot is that in the above testcase the will be display:none > whether it's visited or not. > Boris, any chance you can also take a look at scenario in: https://github.com/w3c/frame-timing/issues/40#issuecomment-9795 Thanks! ig ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to Implement: User Timing API
\o/ On Thu, Dec 11, 2014 at 5:15 PM, Jonas Sicking wrote: > Yes! > > On Thu, Dec 11, 2014 at 5:11 PM, Kyle Machulis > wrote: > > Summary: We've already got the performance resource timing API > implemented (https://bugzilla.mozilla.org/show_bug.cgi?id=822480), but > never got around to implementing the user timing API. This would allow > users to set unique marks for profiling events in their own code, and most > of the objects already exist, we just need to expose/store them in the > right way. There's some performance tools being developed for FxOS that > polyfill this API, but it'd be nice to just have it done. > > > > Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=782751 > > > > Link to Standard: http://www.w3.org/TR/user-timing/ > > > > Platform Coverage: all > > > > Estimated or Target Release: Firefox 38 > > > > Preference behind which this will be implemented: dom.enable_performance > > ___ > > dev-platform mailing list > > dev-platform@lists.mozilla.org > > https://lists.mozilla.org/listinfo/dev-platform > ___ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: WOFF2 webfont format
On Thursday, October 2, 2014 9:17:38 AM UTC-7, Ehsan Akhgari wrote: > On 2014-10-02, 7:03 AM, Jonathan Kew wrote: > > > > WOFF2 is currently supported by Chrome and Opera,[4] and the Google > > webfonts service is serving WOFF2-compressed fonts to browser versions > > that are known to support it.[5] > > Is support for WOFF2 feature detectible? Or do people need to hardcode > UA versions to know what UAs support it? You don't need UA detection, @fontface with format() hint does the trick: https://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/webfont-optimization#defining-font-family-with-font-face ig ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: Prerendering API
On Wed, Aug 13, 2014 at 5:16 PM, Jonas Sicking wrote: > On Wed, Aug 13, 2014 at 12:24 PM, Ilya Grigorik > wrote: > > On Tue, Aug 12, 2014 at 3:17 PM, Jonas Sicking wrote: > > Do you really think that Google would be able to morph a google > calendar page into the google search result page? > While this is mostly orthogonal to our discussion, worth checking out if you're not familiar with it: https://groups.google.com/a/chromium.org/d/msg/blink-dev/lWCtrTynaVk/Bvf4jIeEuPcJ Obviously, the above does not make the page transition faster, but it does provide a "morph facility". > > On Tue, Aug 12, 2014 at 7:19 PM, Jonas Sicking wrote: > >> > >> On Tue, Aug 12, 2014 at 6:53 PM, Karl Dubost > wrote: > >> > Le 13 août 2014 à 10:09, Jonas Sicking a écrit : > >> But yes, this depends on scripting. It sounds like between the two of > >> us we have three goals > >> > >> * Enable fast navigation between webpages in websites like bugzilla. > >> * When a search result page is loaded, avoid loading and prerendering > >> a separate DOM for each bug. > >> * Avoid relying on JS. > > > > > > So, same origin; substantially different page template; single-page app. > > I'm not sure why you say "single-page app"? The bugzilla search result > page and the page rendering individual bugs are decidedly different > pages right now. I.e. the DOM looks very different, they run different > scripts, they are generated from different server-side scripts and > they use different URLs, including the parts before the #. > > Maybe I don't understand what your definition of "single-page app" is. > In this context, an app that performs in-place updates, as opposed to full page reloads, when transitioning between different views. The views can use different JS, CSS, and so on. To achieve this, you have to build your app in a very particular way. In the case of bugzilla, that would involve a substantial rewrite of the app... you can't just drop in a few prerender tags on the page and defer the rest to the browser. > > It seems like the workflow you're after is something like: > > > route="/other-thing/*" id="ABC"> > > > > When a navigation is initiated to "/other-thing/random", the above > prerender > > context is used: > > - prerender context gets a notification that its visible (i.e. Page > > Visibility API) > > - prerender context inspects the actual target URL, extract right tokens > > from it, does its thing... > > > > Is there even a need for postMessage, etc? Seems like the necessary > pieces > > are already there - i.e. the URL. > > The point of the postMessage was mainly to expose the actual target > URL. I.e. by enabling a message channel between the initiating page > and the prerendered page we wouldn't need to invent an API for > exposing the target URL. Nor would we need to add a route attribute or > define a URL pattern matching syntax. > Why can't I just listen for visibilitychange event and then query document.location in the handler? I'm intentionally handwaving my way through the implementation details, but roughly, I'm picturing it as: render this template, it'll match any of these routes; navigation is invoked; matching prerender is found and is used to render the remainder of the page content. > (Note: I'm still a bit skeptical of the use case, but... curious :)) > > The use case here is any search interface, as well as any page that > contains links to database generated content. Both are incredibly > common on the web. And, like Eshan points out, it works even when > those navigate across origins. > ... assuming all of those pages are rewritten to take advantage of this technique, which is no small ask. To make matters worse, at least as implemented today, prerender is a speculative thing that may or may not happen. In which case, all of the sites would also have to implement a fallback. > So for example: > * Amazon's product search UI > * Amazon's search result UI > * Wikipedia's search UI > * Wikipedia's search result UI > * The search UI on NY Times > * The search results UI on NY Times > * Almost any product listing page > * A contacts manager which uses "real" URLs rather than fragment-based > URLs. > > I'm not sure why you are skeptical about that use case? > All of these are plausible today with current infrastructure. I'm not skeptical of the examples, I'm skeptical of the value add of this API on top of what's out there today. > And to be clear, I'm not proposing making major changes or a
Re: Intent to implement: Prerendering API
On Tue, Aug 12, 2014 at 3:17 PM, Jonas Sicking wrote: > On Tue, Aug 12, 2014 at 1:04 PM, Ilya Grigorik > wrote: > > Whereas for (b) you can also do it in place by prefetching the template > and then issuing a data request for relevant data once you know the exact > URL... Which, of course, is exactly how single-page apps work today. > > I don't understand what you are saying here. > > The point of (b) is that the different base templates. So it'd be very > hard to use pushState and DOM mutations to morph the current page into > the destination page. The fact that the destination page is template > based doesn't make it any easier. > It's been done before, and with pretty good success: - http://pjax.heroku.com/ - https://github.com/rails/turbolinks - derivative of pjax and in fairly wide use, since its core to Rails. As turbolinks repo notes, you get the most benefit from this technique when you preserve the same CSS/JS... but the point is, full replace is not out of scope either. On Tue, Aug 12, 2014 at 7:19 PM, Jonas Sicking wrote: > On Tue, Aug 12, 2014 at 6:53 PM, Karl Dubost wrote: > > Le 13 août 2014 à 10:09, Jonas Sicking a écrit : > But yes, this depends on scripting. It sounds like between the two of > us we have three goals > > * Enable fast navigation between webpages in websites like bugzilla. > * When a search result page is loaded, avoid loading and prerendering > a separate DOM for each bug. > * Avoid relying on JS. > So, same origin; substantially different page template; single-page app. It seems like the workflow you're after is something like: When a navigation is initiated to "/other-thing/random", the above prerender context is used: - prerender context gets a notification that its visible (i.e. Page Visibility API) - prerender context inspects the actual target URL, extract right tokens from it, does its thing... Is there even a need for postMessage, etc? Seems like the necessary pieces are already there - i.e. the URL. ig (Note: I'm still a bit skeptical of the use case, but... curious :)) ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: Prerendering API
(reposting, got stuck in the queue) On Tue, Aug 12, 2014 at 3:17 PM, Jonas Sicking wrote: > On Tue, Aug 12, 2014 at 1:04 PM, Ilya Grigorik > wrote: > > Whereas for (b) you can also do it in place by prefetching the template > and then issuing a data request for relevant data once you know the exact > URL... Which, of course, is exactly how single-page apps work today. > > I don't understand what you are saying here. > > The point of (b) is that the different base templates. So it'd be very > hard to use pushState and DOM mutations to morph the current page into > the destination page. The fact that the destination page is template > based doesn't make it any easier. > It's been done before, and with pretty good success: - http://pjax.heroku.com/ - https://github.com/rails/turbolinks - derivative of pjax and in fairly wide use, since its core to Rails. As turbolinks repo notes, you get the most benefit from this technique when you preserve the same CSS/JS... but the point is, full replace is not out of scope either. On Tue, Aug 12, 2014 at 7:19 PM, Jonas Sicking wrote: > On Tue, Aug 12, 2014 at 6:53 PM, Karl Dubost wrote: > > Le 13 août 2014 à 10:09, Jonas Sicking a écrit : > But yes, this depends on scripting. It sounds like between the two of > us we have three goals > > * Enable fast navigation between webpages in websites like bugzilla. > * When a search result page is loaded, avoid loading and prerendering > a separate DOM for each bug. > * Avoid relying on JS. > So, same origin; substantially different page template; single-page app. It seems like the workflow you're after is something like: When a navigation is initiated to "/other-thing/random", the above prerender context is used: - prerender context gets a notification that its visible (i.e. Page Visibility API) - prerender context inspects the actual target URL, extract right tokens from it, does its thing... Is there even a need for postMessage, etc? Seems like the necessary pieces are already there - i.e. the URL. ig (Note: I'm still a bit skeptical of the use case, but... curious :)) On Wed, Aug 13, 2014 at 12:24 PM, Ilya Grigorik wrote: > On Tue, Aug 12, 2014 at 3:17 PM, Jonas Sicking wrote: > >> On Tue, Aug 12, 2014 at 1:04 PM, Ilya Grigorik >> wrote: >> > Whereas for (b) you can also do it in place by prefetching the template >> and then issuing a data request for relevant data once you know the exact >> URL... Which, of course, is exactly how single-page apps work today. >> >> I don't understand what you are saying here. >> >> The point of (b) is that the different base templates. So it'd be very >> hard to use pushState and DOM mutations to morph the current page into >> the destination page. The fact that the destination page is template >> based doesn't make it any easier. >> > > It's been done before, and with pretty good success: > - http://pjax.heroku.com/ > - https://github.com/rails/turbolinks - derivative of pjax and in fairly > wide use, since its core to Rails. > > As turbolinks repo notes, you get the most benefit from this technique > when you preserve the same CSS/JS... but the point is, full replace is not > out of scope either. > > On Tue, Aug 12, 2014 at 7:19 PM, Jonas Sicking wrote: > >> On Tue, Aug 12, 2014 at 6:53 PM, Karl Dubost >> wrote: >> > Le 13 août 2014 à 10:09, Jonas Sicking a écrit : >> But yes, this depends on scripting. It sounds like between the two of >> us we have three goals >> >> * Enable fast navigation between webpages in websites like bugzilla. >> * When a search result page is loaded, avoid loading and prerendering >> a separate DOM for each bug. >> * Avoid relying on JS. >> > > So, same origin; substantially different page template; single-page app. > > It seems like the workflow you're after is something like: > route="/other-thing/*" id="ABC"> > > When a navigation is initiated to "/other-thing/random", the above > prerender context is used: > - prerender context gets a notification that its visible (i.e. Page > Visibility API) > - prerender context inspects the actual target URL, extract right tokens > from it, does its thing... > > Is there even a need for postMessage, etc? Seems like the necessary pieces > are already there - i.e. the URL. > > ig > > (Note: I'm still a bit skeptical of the use case, but... curious :)) > ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: Prerendering API
On Tuesday, August 12, 2014 8:39:11 AM UTC-7, Jesper Kristensen wrote: > This templated prerendereing sounds like a complicated API. Is there any > advantage of this over what is possible today with a single page > application using history.pushState? I'm still trying to wrap my head around the use case, but I'm with you on this so far... In order to support the proposed behavior, you would need to: (1) implement an endpoint that returns a base template page (2) implement page logic to receive the message, fetch right data, and render it If you have (1) and (2) implemented, you've effectively implemented the single-page app model. It seems like there are two cases to consider here: (a) You're on a page with the same base template as destination (b) You're navigating to a page with a different base template For (a), you're best off reusing the current context (it's already rendered, after all), and issuing a fetch for updated content and rendering it in place - with pushState, etc. Whereas for (b) you can also do it in place by prefetching the template and then issuing a data request for relevant data once you know the exact URL... Which, of course, is exactly how single-page apps work today. In short, seems like this is inventing a derivative single-page app model for building pages/apps, and that makes me wonder because it doesn't seem to make it any easier. Everything described here can be achieved with current tools, but perhaps could be made better with some smart(er) prefetch/prerender strategies? For example, prerender should not be limited to HTML: https://igrigorik.github.io/resource-hints/#prerender In your single-page app, you should be able to inject multiple prerender hints for images, CSS, JS, and let the UA fetch and process those ahead of time. Then, when the user triggers the action, just inject them into the doc and update the UI as necessary. ig ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
