Next in Browser Development, High DPI Websites? 447
Joost de Valk writes "In a post at the WebKit blog, Dave Hyatt raises interesting points about the future of web development and browsers. He says, that with screens getting more and more pixels, it is imperative website design takes the next step: High DPI Website rendering. This could mean that a CSS pixel (px) is rendered as a 2x2 pixelblock. In the article he also mentions WebKit will be providing possibilities to use SVG for all kinds of purposes, like backgrounds. He calls upon other browser developers to take part in the discussion so that 'concrete standards in this area can be hammered out.'"
Re:Wait... (Score:1, Informative)
So the idea is that websites can be made to scale for high DPI screens.
Opera Zoom (Score:4, Informative)
Re:Please no... (Score:2, Informative)
Opera already had the option for years so I don't know why that's news.
Flexibility (Score:5, Informative)
However, I would much prefer a standard whereby those wanting higher def could have higher def, and those wanting more content visible could have more content visible. It's all a matter of scaling, once the resolution has been defined.
The main problem with the web - and with GUIs in general - is that they assume that the designer knows better than the user how the user wants things. There are good image formats out there, but very few people use them. SVG has been around for a while, but is rarely implemented. VRML fared no better. Some page styles only work at all at certain resolutions, relying on specific interactions between unscaled pixel-based images and scaled vector fonts.
Part of the problem is that designers have required more and more features, and that different parties have supplied those features in totally incompatible ways - sometimes deliberately so. (JScript was intentionally different from Javascript, for example.) There again, sometimes parties (notably the WWW Consortium) manage to mess things up so much that features never get implemented at all (some HTML standards suffered this fate), only ever get implemented by one very small group (multicast Mosaic, anyone?) or end up being deliberately avoided (font tags, blink tags, backgrounds in tables or table cells, bi-directional text, Java applications as opposed to applets, etc)
As it stands, there is so little agreement on anything and so little uniformity in implementation on the few things that are agreed on, it's a wonder that the web works at all for anyone for any of the time. (Many pages are designed to only work on one specific version of one specific browser on one specific OS with one specific set of utilities installed, so I guess that it is really misleading to call the WWW "world-wide".)
He's posted a followup! (Score:5, Informative)
Re:A couple of things... (Score:3, Informative)
*let's face it, with only 128 Kibibytes of system RAM shared with the bitmapped display, you really don't want to push the resolution
Re:Bad idea in so many ways (Score:5, Informative)
But that's sort of the qhole point of this article: the designer just don't have the information needed to make sure the page looks good and is legible for all its users. Ultimately, you can not know what size and typeface I prefer or need. So you do need some solution to make it look reaonable across a wide range of device parameters and preferences.
Really, _tight_ design control on the web is a pipe dream. The successful designs are made to still look good despite a great deal of unanticipated variation in the end result. Those designers who go all posterior orifice over it and create brittle designs that may look "pixel perfect" on a narrow range of outputs, and fail badly on the rest.
Re:I agree...something fundamentally wrong with th (Score:5, Informative)
I have no idea what you are basing this on, because manufacturers currently offer a wide variety of displays with a huge range of true DPI.
Many laptops for years have been coming with 15" screens that have 1600x1200 resolution, while the standalone 15" LCD you buy at a store might only have 800x600. I'd say that's a pretty significant difference -- enough that IBM shipped their thinkpads with the "large text" setting as default for many years.
There has been a gradual trend towards increasing physical DPI in devices, simply because we all want crisper text and manufacturing limitations are the only reason we don't. Maybe you're happy seeing individual pixels, but when the average customer sees the quality difference between a 96dpi LCD and a 300 dpi LCD, he'll always prefer the higher -- assuming it doesn't make everything hard to see.
They are talking about usability (Score:4, Informative)
A normal 19" LCD monitor you buy for a desktop is usually 1280x1024. Do the math, it works out to around 90dpi, or perhaps ppi (pixels per inch) is a better term. Ok but now a friend of mine has a laptop that has a screen that's only 15" but 1600x1200. That's about 130dpi. So an image on a typical desktop monitor appears much larger than the same image on that laptop. Actually, when you get down to it, text is hard to read on it, it's so small.
Thus what you need is to scale it up so that if something requests to be displayed as 10 pixels, it's actually displayed as more so it appears larger. This of course goes to even larger extremes with higher resolutions displays. You can get displays that are in excess fo 200dpi. Gets real hard to see anything at a normal size, when normal is made for displays in the 80-90dpi range.
Re:Hold yer horses (Score:1, Informative)
A 16-color screen alone is problematic with some programs, drop it to 640x400 and you're in real trouble. Graphical links wasn't usable, firefox wasn't either.. Remembering something about Opera and smallscreen devices, I quickly downloaded it and -- holy crap! It works fine! It was kind of like web browsing on a fast commodore 64, as the fonts were drawn in tiny antialiased forms just a few pixels high and the images were scaled down and dithered, but it was what I needed and got me the info to fix my primary machine.. Total lifesaver.
Good to know, huh?
Re:I agree...something fundamentally wrong with th (Score:3, Informative)
For menus at least, every desktop environment save windows lets you specify the font size of menus and other parts. So grap your upgrade of your OS today! ;)
For much of the remaining text, setting the DPI correctly helps a lot. That leaves the px specified fonts... webdesigners who use these should be summarily shot (with chocolate, e.g.), but the only help there is the zoom, as you write.
I run 1600x1200 on a 21" and 19", and I am quite happy about it. But I don't use windows anymore.
Re:I agree...something fundamentally wrong with th (Score:2, Informative)
Well, obviously it is 1280:768, or after division by 256, 5:3, or 15:9. So it is almost regular wide screen as in 16:9. Does not seem overly wide to me. But don't take this from me, this is typed on a screen with 16:10 resolution.
By the way, there is such a thing as a SHIFT key. You can find two rather largish keys on both sides of the alphanumeric part of most keyboards. Try and use them once in a while before posting something completely uninteresting.
Re:Wait... (Score:5, Informative)
If you're not aware, the CSS "px" unit is defined in the standard as a specific angle of the viewer's vision. In the case of a user sitting ~18in from a ~90DPI display, that works out to one device pixel per "px", or 3/4 of a point.
H manga (Score:2, Informative)
Of course! SVG porn is called H manga [wikipedia.org].
Re:Defective web browsers - except Opera! (Score:2, Informative)
People don't seem to be understanding this... (Score:1, Informative)
I've been reading through the comments and it doesn't seem like the concept here is being grasped. What Hyatt is proposing is meant to be used in conjunction with an OS scaling feature. It is not going to change the way web pages are created, or force you to use a larger font, or anything else. He's simply proposing a way of improving the display of content when the OS is using a scale factor other than 1x.
We have a bunch of flat-panel 17" displays in the office. The native resolution of these displays is 1280x1024. But many people (especially those whose eyesight is not as good as it once was) set their screen resolution at 1024x768, so that the text is readable to them. Because the LCD still has to render into a fixed 1280x1024 pixel grid, the 1024x768 image has to be scaled up to fit the display, which blurs everything as the LCD tries to invent the missing pixels. And people begin to think that flat panels are fuzzier than CRTs. This is even worse with some of the new laptop LCDs that are displaying 1600x1200 on a 15" display -- most text is completely unreadable at that resolution if you don't have perfect eyesight. Heck, I have 20/20 vision and I still find it too small. But setting a lower resolution makes it even worse.
What is needed is a means of scaling up content at the OS's own graphics layer, so that a person can basically emulate a 1024x768 display, but it will still use all of the pixels of the panel. Uniformly, across the system, more pixels will be used to render fonts, icons, images, etc. This provides people with the larger physical size of running in a lower resolution, but with the full clarity of the panel's pixel grid.
This feature is what is being implemented in Windows Vista and (presumably) Mac OS X 10.5. It already exists in an early form in Mac OS X 10.4. This is the scenario that Hyatt is addressing.
The scaling of the UI happens transparently to the software developer: he or she still deals in pixels. But a pixel will only actually show up as a single pixel on the LCD panel if the scale factor of the OS is left at 1x. If it's set to 2x, four pixels will be used. The point is that it is up to the user to set the size of all elements in the system, it's not a developer deciding how large or small the user will see things.
This scaling up of elements is easy enough if they are vector-based. Everything will be nice and crisp. But what of bitmap images, such as icons? By default, they will simply be scaled up much as the LCD panel would do by itself with a lower-resolution input, inventing pixels for the missing data. But what if you actually have higher-resolution data to fill in those missing pixels? You might as well fill it in so that the display is sharper. You would need some way of knowing when the system is scaling up the UI, and you'd provide a higher-resolution image in that case. Mac OS X has begun to accomodate (in 10.4) 256x256 icons for this purpose, so that a 2x scale factor can be used and the normal 128x128 icon size used in some views can remain fully detailed. APIs have been introduced to tell the OS that you're handling the drawing for a particular view and will fill in the appropriate level of detail (so that an app like Photoshop could render more detail at a different scale factor rather than having its bitmaps scaled by the system).
This is where the "High DPI" comes in for web pages: if the user has a high-DPI display (i.e. high resolution on a small screen), and if the user has a scale factor set for the OS, then the web developer ought to have the option of providing more detailed images that fill in the missing pixel data. The web browser would need a means of knowing the system scale factor and possibly loading alternate images that provide greater resolution. Obviously, larger images will require more bandwidth, so ideally we'd be using vector images instead of bitmaps for most things -- hence the inclusion of SVG in Safari.
That's all that's being discussed here. Not a new method of creating web pages, not new elements, not a redefinition of terms. Simply providing an option to provide more data if the display can make use of it.