RE: [ResourcePriorities] Overstepping boundaries?

I don't see this as overstepping boundaries. In order to solve this performance problem, I think it makes sense to start by specifying the end to end solution in one document and making sure the Web Performance working group feels that this solution solves the problem we set out to solve. Once we feel that our solution satisfies the performance issue, we can then evangelize this feature with the HTML, CSS, and SVG working groups to get more feedback. We can also consider at that time if it makes more sense to split up Section 4.4 and 4.5 into the latest HTML, CSS, and SVG specs. 

That being said, I feel that specifying all the different technologies impacted by this feature in one document is actually quite useful to web developers trying to understand and use this feature and browser vendors trying to implement it. Other specs have done similar things. For example, the Composting and Blending spec [1] defines blend modes and compositions for SVG, CSS, and Canvas in one spec. At the very least, this spec should point to all the different pieces.

Thanks,
Jatinder

[1] http://dev.w3.org/fxtf/compositing-1/#csscompositingandblending 

-----Original Message-----
From: Marcos Caceres [mailto:marcos@marcosc.com] 
Sent: Tuesday, September 10, 2013 11:38 PM
To: public-web-perf@w3.org
Subject: [ResourcePriorities] Overstepping boundaries?

The "Resource Priorities" spec is very important, welcomed, and highly relevant work and I'm excited to see it taking place. However, at the same time, I'm very concerned that this specification is overstepping its boundaries by proposing to modify existing HTML interfaces and markup attributes - as well as specify what the behaviour of the attributes are on a per Element basis outside of HTML. I would much rather *only* see this spec define the markup attributes and IDL attributes - and let others who want to make use of this specification just hook into this spec. It's just better layering, IMO. 

Thus, I would kindly ask that you remove all of section 4.4 from the specification and just focus on defining a general postpone and lazyload solution (and maybe show, in a non-normative way, how it could apply to existing HTML elements to meet particular use cases - or get Hixie to add this stuff to HTML itself): the current approach of defining the behaviour for every single element in the platform to which this applies won't scale in the long term - it's a bottleneck: e.g., if this group is disbanded in a few years, who will maintain this list? - will other groups have to come and beg this group to be added to the list in 4.4? what if the Editors are on vacation or don't have the bandwidth to define how this works with some new platform Element? section 4.4 risks also causing a whole bunch of political issues as it could be seen as "authoritative" over new specs that could make use of this work, etc. 

Kind regards,
Marcos 

PS:  Your WebIDL in 4.4 is invalid - partial interfaces can't have extensions declarations (i.e.. you can't say " : HTMLElement"; otherwise, a partial interface could break/override the inheritance chain of the interface it's extending). 
PSS: I would kindly also ask that you move this spec to GitHub. It makes it much easier for the community to track changes, file bugs, and send pull requests (compared Mercurial). 

--
Marcos Caceres

Received on Saturday, 28 September 2013 01:39:05 UTC