[whatwg] RWD Heaven: if browsers reported device capabilities in a request header

[Charles Pritchard]

Scripting on the client side works just fine. It's pure markup situations where you run into problems.

I'm well aware that Image nodes are alive. I'm keeping an eye out on the DOMParser method to see if they're alive when it parses as text/html.

I recently wrapped some noscript tags around HTML image nodes to prevent them from blocking my onload. Works fine.


-Charles



On Feb 6, 2012, at 12:16 PM, Matthew Wilcox <mail at matthewwilcox.com> wrote:

>> 
>> Scripting on the client side for the purposes of content negotiation *does
>> not work*
>> 
> Please, understand this. Because browsers pre-fetch as soon as a node is
>> created there can be no client-side solution to this issue with the current
>> HTML/JS specifications and browser behaviour. The image linked in the HTML
>> is *always* requested, and it is requested before the client can do a
>> damned thing about it.
>> 
> 
> 
>> 
>> On 6 Feb 2012, at 20:03, Charles Pritchard wrote:
>> 
>>> On Feb 6, 2012, at 11:49 AM, Boris Zbarsky <bzbarsky at MIT.EDU> wrote:
>>> 
>>>> On 2/6/12 2:26 PM, Bjartur Thorlacius wrote:
>>>>> On Mon, 06 Feb 2012 18:59:14 -0000, Boris Zbarsky <bzbarsky at mit.edu>
>> wrote:
>>>>>> That really depends on what the application is doing. Depending on
>>>>>> input capabilities, you may want to have multiple pages instead of a
>>>>>> single page for some sort of configuration setup, for example.
>>>>>> 
>>>>> Whether to use monolithic forms or paginated wizards is a presentation
>>>>> thing
>>>> 
>>>> Not on the HTML level.  Not if you want to allow useful non-scripted
>> semantic submission of partially-filled-in info in the paginated case.
>>>> 
>>>>> that need not even have anything to do with HTTP. You can fetch
>>>>> half the monolithic form and fetch the rest when the user has filled in
>>>>> most of former half.
>>>> 
>>>> Not without script.
>>> 
>>> 
>>> I really didn't like the consequences of server-side scripting to manage
>> dependencies. It was always more work than simply doing the scripting in
>> the client side. It was more prone to error. It let our coders get away
>> with less rugged design.
>>> 
>>> I'm in the responsive and universal design camp. I'm in the
>> accessibility camp. At present, it does require scripting. I'm building web
>> apps, so, scripting comes with that territory.
>>> 
>>> 
>>> It seems to me like these folk are looking for <iframe defer> and <style
>> defer> and some sort of media selector for the network information API, to
>> minimize bandwidth on metered connections without needing to use scripting
>> to do that work.
>>> 
>>> I'm interested in seeing a solution here. I do not think server-side
>> management is the right one.
>>> 
>>> 
>>> -Charles
>>> 
>> 
>>