Re: [whatwg] HTTP/2 push detection and control in JavaScript

On Tue, Feb 24, 2015 at 9:32 AM, Brendan Long wrote: > HTTP/2 associates priority information with HEADERS > (but as a flag, not as a > normal header), so maybe it would make sense to add this to Fetch's > Headers

Re: [whatwg] allow in body + DOM position as a rendering hint

For anyone interested in this topic.. Note that the conversation has moved to Bugzilla, please chime in with your thoughts and feedback there: https://www.w3.org/Bugs/Public/show_bug.cgi?id=27303#c14 On Tue, Nov 11, 2014 at 10:17 AM, Ilya Grigorik wrote: > I've opened a bug to tr

Re: [whatwg] allow in body + DOM position as a rendering hint

I've opened a bug to track this: https://www.w3.org/Bugs/Public/show_bug.cgi?id=27304 On Tue, Nov 4, 2014 at 4:44 PM, Ilya Grigorik wrote: > > On Wed, Nov 5, 2014 at 9:08 AM, Ryosuke Niwa wrote: > >> > Re, re-evaluation previous elements: note that UA *can*, just as it

Re: [whatwg] allow in body + DOM position as a rendering hint

On Wed, Nov 5, 2014 at 9:08 AM, Ryosuke Niwa wrote: > > Re, re-evaluation previous elements: note that UA *can*, just as it does > > today (modulo some error conditions), hold painting until it finds all > the > > stylesheets, regardless of the position in the document. So, > > assuming that's t

Re: [whatwg] allow in body + DOM position as a rendering hint

On Sat, Nov 1, 2014 at 5:18 PM, Simon Pieters wrote: > A bare or

Re: [whatwg] allow in body + DOM position as a rendering hint

On Thu, Oct 30, 2014 at 7:56 AM, Simon Pieters wrote: > The spec currently allows @import "other.css"; in > body (at least at the start of an element). I don't know if it has the > properties you want in existing impls. I also don't know if scoped is OK or > not for your use case. Deprecated in

Re: [whatwg] allow in body + DOM position as a rendering hint

On Thu, Oct 30, 2014 at 2:44 PM, Ben Maurer wrote: > > On Thu, Oct 30, 2014 at 2:26 PM, Ilya Grigorik > wrote: >> >> On Thu, Oct 30, 2014 at 12:17 PM, Ben Maurer >> wrote: >> >>> We talked a bit before about the idea of async stylesheets (like asyn

Re: [whatwg] allow in body + DOM position as a rendering hint

On Thu, Oct 30, 2014 at 1:25 AM, Wu,Ping(Sumeru) wrote: > I have three comments on the summary and the previous discussion: > > 1.There are many questions about “After all, all browsers are after > the same goal and want to optimize their time to first paint, regardless of > whether its a mo

[whatwg] allow in body + DOM position as a rendering hint

(based on discussion at the webperf group meeting at TPAC... hopefully I captured the discussion correctly. If not, please jump in!) HTML5 spec: "If the rel attribute is used, the element is restricted to the head element." [1] Above language is too restrictive, allowing link element to be presen

Re: [whatwg] Expose XMLHttpRequest [Fetch?] priority

r xhr = new XMLHttpRequest; > // assume large values are higher priority > xhr.fetch.priority = document.getElementById('script').fetch.priority - 1; > In terms of high level requirements: - The developer *must* be able to override browser set priorities. - Developer set priorities mus

Re: [whatwg] getting rid of anonymizing redirects

On Wed, Oct 8, 2014 at 11:36 AM, Peter Lepeska wrote: > Does this have implications for resource hints? Do we want the ability to > specify “noreferrer” for prerendered pages? Currently noreferrer only > applies to the tag. My understanding is that you set a global policy, which would apply to

Re: [whatwg] Preloading and deferred loading of scripts and other resources

On Thu, Sep 11, 2014 at 7:55 PM, Ryosuke Niwa wrote: > On Sep 8, 2014, at 10:54 PM, Ilya Grigorik wrote: > > > On Mon, Sep 8, 2014 at 7:59 PM, Ian Hickson wrote: > > > >>> The platform is missing a lower-level primitive (declarative and > >>> im

Re: [whatwg] getting rid of anonymizing redirects

On Tue, Oct 7, 2014 at 8:28 AM, Peter Lepeska wrote: > Looks like this is already supported: > https://html.spec.whatwg.org/multipage/semantics.html#link-type-noreferrer > . > > Just need to educate web developers to you use it. > It's a bit more complicated. The redirector use case has many dim

Re: [whatwg] Expose XMLHttpRequest [Fetch?] priority

be > incorrect for this use case. > Proportional within the same level of the tree, and based on assigned weights within that level. ig > > On Wed, Oct 1, 2014 at 8:19 PM, Ilya Grigorik wrote: > >> >> On Wed, Oct 1, 2014 at 7:59 PM, Chad Austin wrote: >> >&g

Re: [whatwg] Expose XMLHttpRequest [Fetch?] priority

On Wed, Oct 1, 2014 at 7:59 PM, Chad Austin wrote: > I don't see a way to set a priority value in there. The specific wording > is "Streams can be prioritized by marking them as dependent on the, > completion of other streams". > > I see that a client can specify the weight of a stream and you c

Re: [whatwg] Expose XMLHttpRequest [Fetch?] priority

On Wed, Oct 1, 2014 at 4:48 PM, Chad Austin wrote: > Does HTTP 2.0's dependency graph + weights system allow traditional > priority semantics? That is, higher-priority resources would be serviced > before lower-priority resources, unless resource capacity remains available. Yes, that's exactly

Re: [whatwg] Expose XMLHttpRequest [Fetch?] priority

0-7 priority is not sufficient. See previous discussion / proposal: http://lists.w3.org/Archives/Public/public-whatwg-archive/2014Aug/0081.html ig On Wed, Oct 1, 2014 at 10:54 AM, Chad Austin wrote: > Hi all, > > I posted the following message to WebApps, but Anne van Kesteren suggested > that

Re: [whatwg] Preloading and deferred loading of scripts and other resources

On Mon, Sep 8, 2014 at 7:59 PM, Ian Hickson wrote: > > The platform is missing a lower-level primitive (declarative and > > imperative) that is able to explain resource loading with the same > > expressive power as requests initiated by the browser itself. > > That isn't a problem. > I don't fol

Re: [whatwg] Preloading and deferred loading of scripts and other resources

On Mon, Sep 8, 2014 at 1:33 PM, Ian Hickson wrote: > > I really like your proposal for "as="... Concretely it could look > something > > like this: > > > > > href="/some/asset.css" > > as="stylesheet"(used to initialize default priority, headers, > > etc) > > load-set

Re: [whatwg] Preloading and deferred loading of scripts and other resources

[[stuck in the mod queue.. attempt #5, apologies for dupes if you get them]] Ian, thanks for writing this up. The first thing that strikes me about this entire topic is its scope, and I'm wondering if we should take a step back and (a) extract some lower level primitives, (b) leave the rest to li

Re: [whatwg] resource hints and separating download from processing

On Fri, Aug 15, 2014 at 9:26 AM, Ian Hickson wrote: > > Two high-level cases: > > (a) optimizing load sequence of page that's currently being loaded > > (b) optimizing page load of a (potential) future navigation > > > > For (a), we need to expose "preconnect" and "preload", such that the > > dev

[whatwg] exposing dependencies + weights (aka, priorities) to web developers

(followup / continuation of [1]) Trying to hash out some ideas for how to connect Fetch and the new transport capabilities of HTTP/2. Would love to hear everyone's thoughts: https://docs.google.com/document/d/1jSpWc6jkrUoYtGWcxev9Blkkv9RhoO1XtqinBvXqhgY/edit ig [1] http://lists.whatwg.org/htdig

Re: [whatwg] resource hints and separating download from processing

On Mon, Aug 11, 2014 at 12:57 PM, Ian Hickson wrote: > > It's murky to me how I'd declare a resource, specify its priority > > relative to others, and/or add a dependency. Any other (more complete) > > examples, by any chance? :) > > All of that is out of scope of ES6 (and thus the gliffy), but i

Re: [whatwg] resource hints and separating download from processing

On Mon, Aug 11, 2014 at 8:33 AM, Ian Hickson wrote: > On Thu, 7 Aug 2014, Ilya Grigorik wrote: > > > > I'm working on the "resource hints" spec we've been discussing on > > public-webperf... > > FYI, I'm currently working an a depen

Re: [whatwg] resource hints and separating download from processing

On Thu, Aug 7, 2014 at 4:39 PM, Ben Maurer wrote: > > On Thu, Aug 7, 2014 at 3:21 PM, Ilya Grigorik wrote: > >> >> It would be nice if there was a more declarative relationship between the >>> declarative fetch and the eventual use of the resource (assuming the >

Re: [whatwg] resource hints and separating download from processing

On Thu, Aug 7, 2014 at 2:55 PM, Ben Maurer wrote: > Not sure if you've seen this thread: > http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2014-July/297257.html. > I had the same basic interest as you (decoupling resource fetching from > execution). I'd be curious to hear your thoughts about

[whatwg] resource hints and separating download from processing

I'm working on the "resource hints" spec we've been discussing on public-webperf... "This specification defines preconnect, preload, and prerender hints that the developer, or the server generating or delivering the resources, can use in an interoperable way to assist the user agent in the decisio

Re: [whatwg] The src-N proposal

On Mon, Nov 18, 2013 at 8:13 PM, Bruno Racineux wrote: > Because these (only 0.2% uzing gzip) stats do not look good at all in > support of your theoretical argument: > http://trends.builtwith.com/Server/GZIP-Module > That measures "mod_gzip" adoption. HTTP Archive tracks top 300K (Alexa) sites

Re: [whatwg] The src-N proposal

On Sun, Nov 10, 2013 at 12:58 PM, Adam Barth wrote: > > I believe you're applying an inappropriately high standard of required > > agreement to this proposal, compared to what the usual required level > > is for something to be accepted. > > If Blink ships src-N and WebKit ships srcset, we'll hav

Re: [whatwg] The src-N proposal

On Sun, Nov 10, 2013 at 8:59 AM, Tab Atkins Jr. wrote: > It's easy to look at something more complex than what you're used to > and dismiss all the excess as unneeded, but it's really, seriously not > in this case. The things I'm addressing are the things that RICG > research found were common an

Re: [whatwg] The src-N proposal

On Sat, Nov 9, 2013 at 2:49 AM, Markus Lanthaler wrote: > Well, an alternative would be to move the complexity to the server. I very > much doubt that webmasters are going to create all those variations > manually > anyway. And if so, it's enough to store them according a naming convention > the s