[whatwg] should we add beforeload/afterload events to the web platform?
Henri Sivonen
hsivonen at iki.fi
Mon Feb 6 02:37:02 PST 2012
On Tue, Jan 17, 2012 at 6:29 PM, Boris Zbarsky <bzbarsky at mit.edu> wrote:
> On 1/17/12 7:49 AM, Henri Sivonen wrote:
>>
>> On Sun, Jan 15, 2012 at 11:23 PM, Boris Zbarsky<bzbarsky at mit.edu> wrote:
>>>
>>> Preventing _all_ loads for a document based on
>>> some declarative thing near the start of the document, on the other hand,
>>> should not be too bad.
>>
>>
>> A page-wide "disable optimizations" flag could easily be cargo-culted
>> into something harmful. Consider if the narrative becomes that setting
>> such a flag is good for mobile or something.
>
> Who said anything about "disable optimizations"? I suggested a flag to
> prevent all subresource loads, not just speculative preloads. Basically a
> "treat this as a data document" flag.
Oh I see. Sorry.
>>> If that plus a beforeprocess event addresses the
>>> majority of the web-facing use cases, we should consider adding that.
>>
>> So what are the Web-facing use cases? As in: What are people trying to
>> accomplish with client-side transformations?
>
> Well, what mobify is apparently trying to accomplish is take an existing
> (not-mobile-optimized, or in other words typically
> ad-and-float-and-table-laden) page and modify it to look reasonable on a
> small screen. That includes not loading some of the stylesheets and various
> changes to the DOM, as far as I can tell.
FWIW, I'm completely unsympathetic to this use case and I think we
shouldn't put engineering effort into supporting this scenario. As far
as the user is concerned, it would be much better for the site to get
its act together on the server side and not send an ad-laden table
page to anyone. It sucks to burn resources on the client side to fix
things up using scripts provided by the same server that sends the
broken stuff in the first place.
--
Henri Sivonen
hsivonen at iki.fi
http://hsivonen.iki.fi/
More information about the whatwg
mailing list