4 ms·
An experiment mimicking the Dock of OS X using only CSS
- jarek-foksa 15y agoIs something like -webkit-box-reflect available on other browsers? It seems to be totally non-standard (none of the CSS specs mentions it).
- ComputerGuru 15y agoThings that start with -webkit are only (at least originally) available on WebKit browsers (Chrome and Safari, mainly).
- spydum 15y agoIsn't this sort of thing is why everyone hated IE6? I can't help but think we're going to have a bunch of bloat due to formatting between the webkit-/moz- options, just like we had to for IE.
- rplnt 15y agoThose vendor specific things (moz, webkit, o) are often identical to w3c drafts and will probably be removed after the specification is finished.
- spooneybarger 15y agoThe idea behind vendor specific items is that people can play around with things after vendors introduce them in an attempt to get traction for wider adoption... IE6 in my experience was less hated for this than for implementing the box model differently. I don't have to use vendor specific extensions unless I want to play around on the cutting edge. I have no easy way to work around the different box model in older IEs.
- sdkmvx 15y agoThe vendor specific thing allows vendors to do widespread bug testing. People who coded border-radius expect it to work, and (I'm not 100% sure of the current state of that) people who wanted it before they were sure it worked had to do -webkit-, and -moz-, etc. They should understand that the vendors aren't 100% sure they coded it right. This way, if someone finds a bug with -webkit-, they don't have to worry about breaking websites by changing it.
- rhplus 15y agoWhat will happen to all those -webkit and -moz declarations in the wild once a feature gets added to the standard? Will all browsers be expected to observe -webkit-feature-foo or -moz-feature-foo as though the author intedended to use feature-foo with no vendor tag? It seems unlikely that all authors will go back and update their code once standardized.
- jlarocco 15y agoIt's the website developer's responsibility to switch it over. Using them in the first place is saying, "I want to use cutting edge features that may change and break at any time." Being removed and replaced with the standard version is just a special case. But it doesn't hurt to use multiple versions, so most people just specify it for each browser and the standard. The browser will ignore the ones it doesn't understand. For example, this works: div { -webkit-border-radius: ...; -moz-border-radius: ...; border-radius: ...; }
- dylangs1030 15y agoThat's because it is non-standard, and it's supposed to be. The author gives a short description of the compatibility, starting with Chrome at full support (webkit), to Firefox (some supported features), to Opera (no extra support, but basic functioning remains). The good thing is that even without webkit, it won't just stop working altogether, but you really won't have it optimized.
- ootachi 15y agoA combination of CSS transforms, opacity, gradients, and -moz-element (https://developer.mozilla.org/en/CSS/-moz-element https://developer.mozilla.org/en/CSS/-moz-element) allows you to do this in Firefox. I prefer Mozilla's method over WebKit's since it gives you more control: -moz-element is basically a way to replicate any element (even cross-domain iframes!) and apply any transform you want.
- rplnt 15y agoDoes not work properly in two of three browsers I have. I don't see a reason why not use javascript in cases like this. I get it as a showcase of power of css but please, don't use this on your websites (yet). Here's[1] an similair example from 2007, works just fine in all three browsers I tested. [1] http://www.ndesign-studio.com/demo/css-dock-menu/css-dock.html http://www.ndesign-studio.com/demo/css-dock-menu/css-dock.ht...
- dylangs1030 15y agoWhich browsers?
- rplnt 15y agoOpera, Chrome, and Konqueror. In Chrome it seems to work fine, in Opera the reflection is missing and in the Konqueror there is no reflection and it is not animated.
- nazar 15y agoMaybe you really should reconsider you browser preferences? I mean, it also doesn't work in the browser that the kid from next door built as his school side project.
- rplnt 15y agoI don't use Konqueror, I just have it. My point was that even with this browser the javascript version works. Chrome is quite popular in desktop market and Opera is too (in some regions at least). Besides that, the same rendering engine is used in mobile and internet-enabled devices (such as a TV) -- so it's still relevant.
- chuinard 15y agoThis one has a nicer bounce effect on click.
- king_magic 15y agoIt looks nice on Safari, but I do echo other people's comments: the code looks like it uses non-standard mechanisms for achieving it's goals and had to be tailored for specific browser families. To me, that's a "code smell".
- city41 15y agoIt's an experiment using cutting edge browser technology. It's acceptable to only work in certain browsers.
- king_magic 15y agoAnd one cannot critique an experiment?
- ja2ke 15y agoSaying "This experiment uses experimental features" presented as a negative is odd, that's all.
- CamperBob 15y agoDon't shake the platform when the user moves the mouse across the icons; the effect is rather nauseating. (FF 9.0 on Win7)
- emehrkay 15y agothe problem is that the icons don't overlap. The space between them isn't a hit target They are like [ ] [ ] [ ] When it should be [ ][ ][ ] and just center the image inside This is really cool though
- dylangs1030 15y agoYes, and I remember some early GNOME docks had this same issue, so you couldn't appreciate fluid motion when you moved the cursor horizontally across the dock. But it's very well done otherwise.
- alpb 15y agoI think the growth rate should be adjustable easily. What's your approach to this problem?
- michaelhue 15y agoThe growth rate can be changed quite easily in line 190 and 199 of dock.css.
- city41 15y agoThe link to the old version leads to a 404.
- michaelhue 15y agoFixed, sorry about that.
- jebblue 15y agoIt works on the latest Google Chrome and Firefox on the latest Ubuntu and looks nice. On my several years old computer both cores used around 20% to 30% while moving between the icons at a normal pace. Not critical and good performance, comparable to a few flash sites I checked for comparison. One of those flash sites seemed to mess up the browser and the subsequent flash dock sites failed to load correctly. I don't see this with HTML 5 and CSS sites which achieve the same level of feature usability.
- statictype 15y agoHave there been any usability tests (or even just a logical argument) that show the OS X-style dock to be a good UI mechanism? Seems to me that turning off magnification and flushing it to a corner (so that everytime it grows it doesn't move around the existing icons) would have been a better default solution. Apple usually thinks these things through though so maybe I'm missing something?
- eridius 15y agoThe hit space for the icons is static, and matches the area of the un-zoomed icon. It achieves this by growing and shrinking (and sliding) the zoomed icon as you mouse across it, so you come to the end of the icon at the same place you would have if the icon didn't zoom in at all. This allows it to look neat while still having good usability, because your spatial memory is left intact (the only thing that changes that is adding/removing icons).
- statictype 15y agoYou're talking about horizontal space? Or does it apply to vertical space as well. Because I had a lot of trouble acquiring the resizing corner of a window when it was near the dock. I would miss that tiny target and mouse-over a dock icon and then have to drag the mouse a lot further up to make the icon go back down. I have since switched to having the dock on the left side of the screen instead of the bottom and that seems to be noticeably easier to use.
- eridius 15y agoI was talking strictly about the horizontal space. If you don't like the icons moving up to cover more vertical space, maybe you should just turn off zooming?
- pohl 15y agoConsidering that it is merely a refinement of the NeXT dock that was conceived in the late 80s I'd say it hasn't aged too badly. I suspect it will gradually die as the iOS-like springboard app launcher that appeared in Lion matures.
- peteforde 15y agoI am seriously impressed. Thanks for sharing! I wish there was an easy way to fit this into some of my projects. I don't mean the browser incompatibilities others have pointed out, either! I feel like the idea of using this in a practical application is stunted by the "Ikea effect" of something looking awesome in the showroom but crappy in your actual house. Unless you take great pains to make sure that everything in a room matches thematically, it will look like a careless hodge-podge of well-intentioned designs that don't work well with each other. The reason it looks great inside OS X is that Apple have put years of thought into how the Dock fits in with the rest of the user experience. You can't drop a dock into an application without putting real thought into whether it's the right navigation tool. It's usually not the right navigation tool, but it sure is pretty.
- pazimzadeh 15y agoWorks great in Safari. In Chrome, there is a flicker when you click an icon. Sometimes the entire window flickers white.
- ecaron 15y agoWasn't Google's homage to the OS X dock, done in 2005, also using pure CSS? http://www.macworld.com/article/43631/2005/03/googlex.html http://www.macworld.com/article/43631/2005/03/googlex.html