- From: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
- Date: Wed, 6 Jan 2010 10:52:32 +0100
- To: robert@ocallahan.org
- Cc: www-style <www-style@w3.org>
On Tue, Jan 5, 2010 at 7:59 PM, Robert O'Callahan <robert@ocallahan.org> wrote: > On Wed, Jan 6, 2010 at 6:22 AM, Giuseppe Bilotta > <giuseppe.bilotta@gmail.com> wrote: >> >> Honestly, I don't like this idea. > > I don't like it either, but given Webkit and IE are doing it already, this > horse has left the building. Or we could fix Webkit and IE to do the right thing, and push for a web that does the right thing. As others have pointed out, CSS is not just for HTML, and HTML+CSS is not just for the web, so destroying CSS because of some broken websites is not exactly the best course of action. If a fixed px/pt ratio is chosen as the preferred solution for the mess of mixing absolute and relative units of measure, I would rather see px defined in terms of pts (and thus of inches) as suggested elsewhere in this thread, rather than the other way around, and have the UAs query the display dpi to adjust for the physical px size. With this approach, screen rendering would essentially be equivalent to zooming at an actual dpi/96dpi factor, so I would gather most UAs should be able to handle it without issues. The upside of this approach is that it should make webpage rendering consistent across displays, provided the physical dpi information is correct. And font size selector options such as the one found on www.dell.com or other sites wouldn't be necessary. Rendering speed might suffer a hit on very low end hardware, but to my knowledge this would only affect older hardware that is at 96dpi already, i.e. not needing any 'conversion factor'. Also, for performance and quality reasons, UAs could clip the dpi ratios to round factors (e.g. assuming a 120dpi on a 133dpi display, thus achieving a zoom factor of 125% rather than 138.54%) -- Giuseppe "Oblomov" Bilotta
Received on Wednesday, 6 January 2010 09:53:25 UTC