RE: [ResourcePriorities] Overstepping boundaries?

I agree. It seems useful both to implementors and users to have a feature
described in a separate spec, even if that feature affects HTML, CSS and
SVG.

The HTML spec in particular does this way too rarely, resulting in a spec
that is very hard to understand.

/ Jonas
On Sep 27, 2013 6:39 PM, "Jatinder Mann" <jmann@microsoft.com> wrote:

> 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
>
>
>
>
>
>