W3C home > Mailing lists > Public > public-bpwg@w3.org > July 2005

Re: Best Practices document - not best practices

From: Holley Kevin \(Centre\) <Kevin.Holley@O2.com>
Date: Sat, 30 Jul 2005 17:56:18 +0100
Message-ID: <729015D2FB03A041A00327DCD0836983890A52@Uksthmsx014>
To: <Tim@bango.com>, <michael@mxtelecom.com>, <public-bpwg@w3.org>
But is there anything else that could be done to help those existing clients?

Regards, 

Kevin
 

-- 
Kevin Holley 
O2 Group Technology
Tel: +44 1473 782214 _ Fax: +44 7711 752031 _ Mobile: +44 7802 220811
IM: kevinaholley (AIM/MSN/Y!/Skype)



-----Original Message-----
From: public-bpwg-request@w3.org <public-bpwg-request@w3.org>
To: Holley Kevin (Centre) <Kevin.Holley@O2.com>; michael@mxtelecom.com <michael@mxtelecom.com>; public-bpwg@w3.org <public-bpwg@w3.org>
Sent: Sat Jul 30 17:17:34 2005
Subject: RE: Best Practices document - not best practices

Certainly going forwards, but it probably won't help many of the millions if not billions of clients already out there!
 


  _____  

From: Holley Kevin (Centre) [mailto:Kevin.Holley@O2.com] 
Sent: 30 July 2005 17:05
To: Tim Moss; michael@mxtelecom.com; public-bpwg@w3.org
Subject: Re: Best Practices document - not best practices



So isn't this something the W3C can fix, to create a standard for window display advice from client to server?

Regards,

Kevin


--
Kevin Holley
O2 Group Technology
Tel: +44 1473 782214 _ Fax: +44 7711 752031 _ Mobile: +44 7802 220811
IM: kevinaholley (AIM/MSN/Y!/Skype)



-----Original Message-----
From: Tim Moss <Tim@bango.com>
To: Holley Kevin (Centre) <Kevin.Holley@O2.com>; michael@mxtelecom.com <michael@mxtelecom.com>; public-bpwg@w3.org <public-bpwg@w3.org>
Sent: Sat Jul 30 16:40:03 2005
Subject: RE: Best Practices document - not best practices

Its not generally possible for the server to detect window size without help from the client.  Some browsers may send this information automatically in custom headers but most don't.  I'm not aware of a 'standard' way of sending this info to the server.

JavaScript or similar could be used to determine the window size client side, but this information then needs to be sent to the server for it to be able to do anything with this information which is likely to require another round trip.

The same is largely true about display capability; the server can lookup device capability information for mobile devices, and get a reasonably accurate answer providing the client sends enough information in the request headers (e.g. user agent, reference to UAProf file) but this won't work for laptops, PCs where different resolution screens can be plugged in to them.

With the more capable mobile devices where additional software can be installed, there's no guarantee that a third party browser has the same display capabilities as the standard browser on that device, and often the display capabilities of a browser differ from the physical screen resolution, browsers often take up screen space to show titles, scroll bars, margins etc.






Tim Moss
CTO
Bango

m: +44 78 8779 4032
t: +44 12 2347 2823
w: http://www.bango.com <http://www.bango.com/>

 
Mobile Content World 2005
******************************************************************
"Come and see us on stand 14 at MCW 2005
Olympia Conference Centre, London, UK
13th - 15th September 2005"
 <http://www.mobilecontentworld.biz/> www.mobilecontentworld.biz



  _____ 

From: public-bpwg-request@w3.org [mailto:public-bpwg-request@w3.org] On Behalf Of Holley Kevin (Centre)
Sent: 30 July 2005 10:07
To: michael@mxtelecom.com; public-bpwg@w3.org
Subject: Re: Best Practices document - not best practices



Thanks Michael, Daniel,

so it sounds like one best practice is to use a separate stylesheet and not put that information in the header.

I have another question though.

Is it possible for the server to detect the size of window in use - as opposed to the display capability?

Regards,

Kevin


--
Kevin Holley
O2 Group Technology
Tel: +44 1473 782214 _ Fax: +44 7711 752031 _ Mobile: +44 7802 220811
IM: kevinaholley (AIM/MSN/Y!/Skype)



-----Original Message-----
From: public-bpwg-request@w3.org <public-bpwg-request@w3.org>
To: public-bpwg@w3.org <public-bpwg@w3.org>
Sent: Wed Jul 27 20:58:04 2005
Subject: Re: Best Practices document - not best practices


Daniel Barclay wrote:

>
> Holley Kevin (Centre) wrote:
>
>> ....  When looking at the WURFL site I
>> note that the real content of the page (not the links or the photos but
>> the meat of the page ... i.e. text about WURFL ...)  ... is towards the
>> bottom of the HTML.  I rather suspect that HTML tools deliberately put
>> "meat" text at the bottom of the HTML.  Why is this?
>
>
> If you're talking about CSS style information that is embedded in an HTML
> document, it's at the top of the document because of HTML format:  The
> STYLE element has to be within the HEAD element, which is comes before
> the
> BODY element.

Also, if you don't have your rendering metadata before you start
receiving your data, then you really have to wait until the end of the
document to render anything. This leads to bad error handling (you can't
display a partial document) and slow page load times (you cannot begin
to render until the last byte has arrived).

Keeping the styling information at the top, or somehow first to the
rendering engine means that you can display content as soon as you get
it. Whether this is by putting it inline (like the wurfl site does) or
external to the page (like an xsl stylesheet, or a css link), it has to
be better.

Michael




=====================================================

This electronic message contains information from O2 which may be privileged or confidential. The information is intended to be for the use of the individual(s) or entity named above. If you are not the intended recipient be aware that any disclosure, copying distribution or use of the contents of this information is prohibited. If you have received this electronic message in error, please notify us by telephone or email (to the numbers or address above) immediately.

=====================================================
Received on Saturday, 30 July 2005 16:56:23 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:08:48 UTC