On Sun, 15 Mar 2009 21:12:39 +0100 Came this utterance formulated by Gunlaug Sørtun to my mailbox:
> Ib Jensen wrote: > > > That means roughly, that a "developer" should have at least three > > screens with different resolutions and X number of browsers > > installed, on different systems, to in fact have a chance to guess > > which size of units to use. > > Not at all. You can check all conditions on a screen with high enough > resolution, but you may have to keep track of those browsers and how > they evolve and respond to changes on the hardware side. > > The reason I opted for such a large screen-area on my workstation, is > that I can simulate nearly all hardware/software induced conditions on > it through a few clicks. Most web designers can simulate parts of > modified conditions at the user-end by zooming up and down the entire > page in a capable browser. > > First: get the terms, and sizes, right. > > Resolution is somewhere between 72 and 300dpi and most > viewports/screens are between 640 and 3600px wide. Phone and palm browsing is on the increase and screen width there is typically under 400px. > Resolution vs pixel-width affect actual > screen size, so a 2400px wide screen with 220dpi resolution (not many > of those around, but they're coming) will be physically quite small in > size. So, forget about 15", 17", 19" and so on for screens. A screen > is so and so many screen-pixels wide and tall, regardless of its > actual size. > > This resolution vs. size range can not be covered by web designers by > using "one size fits all" methods - the browsers and end-user settings > have to bridge the gap. What we have to do is to allow browsers to do > their job - we have to work _with_ the media and not against them, and > only decide which limits we have to set so our creations have a chance > to survive. > > The only somewhat safe way to lay out web pages so they work > everywhere, is to not lock sizes to anything but viewport - using > percentage, and decide what is too wide or too narrow for our > creations. > > 'em' is locked to font-size, so 'em' is in most cases only useful for > setting limits - min-width and/or max-width, and those limits should > be quite generous. > 'px' is also locked, so they're also most useful for setting generous > limits. > > > In time browsers and other software will be modified to "un-lock" both > 'em' and 'px' - in a way, in order to make sensible use of higher > resolution on screens. Full page zoom is one way to do that, and most > browsers already have the basics (for manual setting) in place. > Screen-pixels and design-pixels then become relative to each other - > as they already are on regular printers, and the software will do the > conversion (see "wishful thinking" in another thread today). > > For full page zoom browsers seem to go the "adaptive zoom" route, > probably because they can't cover the wide resolution/actual screen > size range any other way and make it "fit on screen" for all > end-users. Most fluid-width designs will then work quite well without > modifications, but both 'em' sized and 'px' sized designs may run into > range problems since they can't really adapt to viewports/screens > unless browsers override their fixed width (my browser-preference can > already do that). > > Fixed-width layouts, being it 'px' or 'em', will probably never go out > of fashion ... they just won't work very well outside their creators' > preferred range. > > Support for "media queries" is slowly growing across browser-land, so > we are, or will be, able to modify our designs a bit to suit the > various conditions. Great care has to be taken here though, as we must > know what various browsers actually do under various conditions before > we try to"improve things". > > > Now, browsers and screen-resolutions can only go one way, upwards, > while screen-sizes can and will go both ways. Thus, the future for > rendering on flat screens is predictable, although it is hard to say > how quickly they evolve and spread. They have to introduce one or more > non-flat"screens" for anything to change. > > > So, IMO, it is best *not* to convert a fluid layout into anything else > right now, but instead only control the upper and lower limit for its > fluidity so it doesn't become ridiculously and/or unusably wide or > narrow. > > That this "control of fluidity" can be achieved both forward and in > reverse, and in a few other ways, may complicate matters for those who > haven't grasped the whole "adapt or fail" concept. However, rising > resolution and both larger and smaller screens and various devices are > hitting the market around us, so quick learners will be at an > advantage. > > regards > Georg > -- > http://www.gunlaug.no > ______________________________________________________________________ > css-discuss [cs...@lists.css-discuss.org] > http://www.css-discuss.org/mailman/listinfo/css-d > List wiki/FAQ -- http://css-discuss.incutio.com/ > List policies -- http://css-discuss.org/policies.html > Supported by evolt.org -- http://www.evolt.org/help_support_evolt/ -- Michael All shall be well, and all shall be well, and all manner of things shall be well - Julian of Norwich 1342 - 1416 ______________________________________________________________________ css-discuss [cs...@lists.css-discuss.org] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ List policies -- http://css-discuss.org/policies.html Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
