The really crazy thing is that we had great proposals for much better layout systems, and they were rejected:
- First, the model with "springs and struts", employed by all major native GUIs for decades, and also implemented in Firefox as the first Flexbox model (for XUL, the UI description markup language) since ages.
The CSS layout model (with float/clear, display:block|inline|table-cell, vertical align and so on) was based closely on how browsers already rendered layout. For example float, clear and align were attributes on image and table tags before the invention of CSS. CSS just allowed you to decouple these layout properties from the HTML elements.
So basically the CSS layout model were designed by Netscape before the CSS spec were developed.
Should the developers of CSS have discarded this model and instead proposed a different model would require the browser vendors to redesign their rendering engines? I think this would never have worked - remember this was at the height of the browser war, where Netscape and Microsoft routinely ignored W3C standard to pursue proprietary alternatives. We should probably be happy that we got something like CSS at all.
Flexbox is the most underrated CSS modules out there. Making flexible layouts based on the size of the viewport without it is either a major pain or flat out impossible without resorting to JS.
I don't understand why all the CSS efforts are being put into elaborate effects (transforms, blend modes, compositing, etc) when we can't yet effectively create UI layouts. Other underrated property is the non-standard "-webkit-line-clamp" (or "-o-ellipsis-lastline" for Opera), that allows you to cut off with an ellipsis a block of text after a given number of lines.
Yeah, totally. Someone should do that. I've brainstormed about it with a few XCode savvy friends. It would be super-slick if it were integrated into the Finder windows. So, you could drill into the dirs to get to a Xiki menu, and then drill into the Xiki menus in-place right in the OS.
I just made a Shoes menu (shoesrb.com) yesterday, though it's not checked in yet. Clicking Xiki menus that bring up custom native UI windows seems like it could have a lot of potential, though haven't really explored it. Might be interesting to try a shoes native interface for Xiki menus.
Another possible direction... Xiki has a web interface that you can enable. So you can to http://xiki and navigate menus. It probably wouldn't be too tough to make a native OSX app with an embedded browser that displays it.
Maintaining compatibility with existing keyboard UI should be considered essential for accessibility. And I haven't bothered to check compatibility with ARIA.
The idea of compound images is really interesting, although it would require an extra HTTP request to fetch the hight-DPI portion of the image. But maybe less of a problem over SPDY?
The idea truncatable bitstreams is fascinating too. I'm not well versed in networking, but wouldn't the latency of a mobile network kill the benefit of this technique? e.g, by the time the server receives the "connection closed" signal, a large part of the extra data would have been sent, no?
It would need an extra HTTP request, yes. In practice for the PNG solution, one would be better off with sending the DPI in the request headers, so that the "correct" image is the only one sent.
For JPEG 2000, the network characteristics are important, but I don't think it would be too bad on a mobile network. Low DPI devices might get a bit "too much", but it wouldn't be a problem - they can just throw it out (or incorporate more detail).
Headers do seem the best place for a non vendor specific standard to be set. I'd love to see something like
viewport-dpi - the dpi
viewport-max - the maximum possible pixel dimension
and possibly viewport-current - the pixel dimensions at the time of the request
Decent responsive design should deal with the differing viewport sizes, but it might be nice to get a hint before delivering your page what direction to weight that response in.
Something like device-pixel-ratio would be more useful than DPI. Raw DPI is meaningless unless you take distance into account, as is very clear in the case of the projector.
That is certainly the ideal way to reduce the HTTP requests. The problem with this implementation is clear: without a 'src' attribute on your images, if your script fails then your site suddenly has no images at all. Not to mention the overhead of manually modifying all of your existing markup.
Our goal with retina.js was to make it zero-config: no markup changes, no extra element attributes or flags.
The Stripe gallery posted here the other day[1] used src-less img tags for lazy loading. It looks like they handle the script issue by having the normal img tag (with src attribute) nearby in a noscript block.
Doesn't really do much to help with the overhead of modifying existing markup. Perhaps if you're already using something like image_tag in Rails, a retina_image_tag helper might not be too much of a stretch.
No, the distinction of device pixels vs. CSS pixels predates the first "Retina" iPhone. The distinction existed in all browsers supporting full page zoom, including the Safari on the first iPhone, and in Opera for years before that.
"Retina" is just a marketing term for "pixels so small your eye can't distinguish them at a normal distance anymore".
The distinction is also in CSS specs[0] since version 2.1: “The reference pixel is the visual angle of one pixel on a device with a pixel density of 96dpi and a distance from the reader of an arm's length. <…> 1px thus corresponds to about 0.26 mm (1/96 inch).”
I'm afraid this boat has long sailed. The "pixel" term is in the CSS 2.1 Spec. It's set in stone.
Personally I've made peace with it. I say either "CSS pixels" or "device pixels", depending on what I want to express.
And although the high resolution screens have only made the difference between the two more visible, it was there since Opera featured full pages zoom many years ago, and when Mobile Safari introduced the "viewport" meta-tag in 2007.
Unfortunately, redefining "px" from its original meaning as "device pixels" to a new meaning of "probably one 96th of an inch except on mobile browsers where ..." means that CSS no longer has any way to express "device pixels".
The one problem that I have with pictograms-as-fonts is anti-aliasing. The designers that I work with spend hours to make their icons absolutely perfect at every pixel size that they'll be displayed at. This is particularly visible when the icon has horizontal or vertical lines. Most of the time you'll want them have a hard edge, and with anti-aliasing you can never be sure you'll get that result.
This will change in a few years when all our screens have high pixel densities, but for the time being I'm sticking with PNG sprites, with hand-tweeked pixels.
This doesn't seem to work in Chrome on Windows; do you know of any workarounds there? That's not really a small market segment anymore, and I'm not sure I could sell our design team on font icons without a viable solution.
- First, the model with "springs and struts", employed by all major native GUIs for decades, and also implemented in Firefox as the first Flexbox model (for XUL, the UI description markup language) since ages.
- Second, the constraints-based layout model, now employed by OSX 10.8 and considered even superior, was proposed in 1999! http://www.cs.washington.edu/research/constraints/web/ccss-u...
The only explanation I can come up with is a giant disconnect between users (web developers) and implementors.