- From: Tim Moss <Tim@bango.com>
- Date: Sun, 31 Jul 2005 09:58:54 +0100
- To: "Holley Kevin \(Centre\)" <Kevin.Holley@O2.com>, <public-bpwg@w3.org>
- Message-ID: <2BC2AEC80DD48B40AAAB98A4BE71B5C979C1C1@erol.Westbrooke.bango.net>
Since there's no way to change/enhance the browser client on many (or most) of these devices, and a similar proportion won't support client side programming (with JavaScript etc.) the best hope for these existing devices is to improve the device capability databases and description languages (e.g. the work of the MWI DDWG) and use this information server-side to adapt the content as best as possible for the clients in question. The work of the W3C DIWG e.g. DISelect should of great benefit here. None of this solves the window size problem you mentioned earlier, but devices where you can change the window-size are on the whole more advanced, e.g. PCs, PDAs etc. So to start with a 'standard' mechanism for using client side programming to send window size information to the servers could be developed in parallel with a standard for future browsers to automatically send this to headers. Hopefully future browsers will also take advantage of the output of the DIWG, so that some of the content adaptation can take place client side as well, reducing the need for all content to be dynamically generated by the servers. ________________________________ From: Holley Kevin (Centre) [mailto:Kevin.Holley@O2.com] Sent: 30 July 2005 17:56 To: Tim Moss; michael@mxtelecom.com; public-bpwg@w3.org Subject: Re: Best Practices document - not best practices 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 Sunday, 31 July 2005 08:59:03 UTC