(Better) Tabs with Round Out Borders | Hacker News Reader

(Better) Tabs with Round Out Borders

css-tricks.com

197 pointsjoshuacc39 comments

Props to the author showing a iterative development process instead of just a example and code dump.

Those tabs are beautiful at the end.

A little off topic, but at the end where it says browser compatibility is "everything but IE" got me wondering. Does Microsoft's IE team care about their product at all?

I thought with IE9 being so standard-compliant and 6 finally dead, tiresome browser-compatibility fixes were a thing of the past. I'm sure Microsoft's IE team reads about how much their browser sucks, right? Why does IE continue to suck?

It looks just fine in IE9, rounded corners and everything. The only thing that's missing are the gradients the author adds at the end - and that's only because he picked and chose what vendor-specific CSS to use there.

EDIT: On the subject of vendor-specific extensions, it seems to me that a lot of new features of "the open web" such as WebGL, Native Client, and advanced CSS trickery all basically work best in Chrome, or maybe Firefox six months later (remember how long it took firefox to get text-overflow:elipsis?). These are all features that basically exist in a single browser at the moment. Here's some food for thought; we've had all of these in a single browser before, and that browser was IE6. ActiveX and a certificate system replaces Native Client and sandboxing, and it had it's own css filters for an awful lot of things just arriving in CSS3, as well as DirectX-accelerated transforms.

We've transitioned from having only one browser support the common features of the internet (IE6), though a brief period of openness, but it seems like we're heading down the single-browser path again. Just because Webkit is open source and the W3C publish a standard doesn't mean that everything is better this time - nobody thought IE would stagnate in its heyday.

Just because Webkit is open source and the W3C publish a standard doesn't mean that everything is better this time - nobody thought IE would stagnate in its heyday.

Well it's better in one important way: the browser makers don't try to dictate behavior of other browsers. Instead of fighting, they put their own behavior in a namespace until they agree on an open standard. Then they can drop the prefixes.

It's not really true that Chrome gets all of the features first. For example their implementation of IndexedDB is using an outdated API at the moment. And Firefox is the only vendor supporting CSS calc() (which is really, really awesome).

Yep, it does make you wonder, doesn't it?

I thought ... tiresome browser-compatibility fixes were a thing of the past

Not by a long shot. One thing to keep in mind are browser half-lives. IE's decay rate, in particular, is horrible. IE 6 is still a problem in some sectors, and IE 7 & 8 still linger just as much, if not more. IE 9 is a huge step in the right direction, but still, more advanced features such as support for local databases, ES 5 strict, web sockets, and web workers, won't land until IE 10. The same is even true for lesser features that other browsers have had for years, like text shadow.

Whatever happened to web standards?

    background:      -o-linear-gradient(top, #ECECEC 50%, #D1D1D1 100%);
    background:     -ms-linear-gradient(top, #ECECEC 50%, #D1D1D1 100%);
    background:    -moz-linear-gradient(top, #ECECEC 50%, #D1D1D1 100%);
    background: -webkit-linear-gradient(top, #ECECEC 50%, #D1D1D1 100%);
    background: linear-gradient(top, #ECECEC 50%, #D1D1D1 100%);

Wasn't the whole point of web standards to move beyond bullshit like that?

Yes. But forward-consistency and early access are both valuable for site-makers, so pre-standardized features are prefixed in case they change when the standard comes out.

If you want to use standards, you need to select what's available to you by your target audience, and ignore the non-standard-compliant cases. If you want to do things, and keep as large a target audience as possible, you need to either hack them together with old tech or jump through hoops to do it with new tech. Especially given the web's rocky past, many developers would prefer to use the new stuff. And there are tools to help - Less or Scss, for instance, make those prefixes essentially free.

But that's just a fact of programming in general - you could write a web-app and get it on any computer with a modern browser. Or you could write it in Ruby, and get it on any computer with a Ruby interpreter, and include an installer / instructions for those that don't. Or you could write it in C, and get it on any computer with a C compiler, and you may have to write your own library code / preprocessor controls to handle strange architectures, and change things based on your target OS. Or you could write it in assembly, and have it run on almost anything, but have to handle multiple flavors and an endless variety of available memory, and input and output devices.

Or do any of the above, pick a subset of the devices that are technically capable of reading your code, and screw the rest. Porting Doom 3 to Commodore 64 probably isn't going to work, despite the code being written to the standard of whatever language it was written in (probably C, which I will assume for now), and compilers adhering to the same standard for targeting the C64. That you can't run Doom 3 on your C64 doesn't mean the standard is broken or useless.

The nice thing about those prefixes is that, in general, it means you can use new features and know they'll work as you designed for years to come. If a re-design every year or so is cheaper than vendor prefixes, then yes, they're a pain - wait until the standard comes out. If not, they're a time saver to get handy new features a couple years early, and free switch-over to the standard when and where it's implemented.

I agree it's better than what we had before, but...

1. Basically now we're stuck with +five lines to specify one thing. When can we switch to just one line, and drop the prefix versions? I doubt any time soon. We're only now dropping support for IE6.

2. how useful is it to be able to build stuff that only works in some browsers? I get that it helps push stuff forward, but you get myriad posts on HN that are like "look at this sweet thing I built (only works on chrome)" or something similar. Good for you, you built something cool, but you might as well have done it as a native app because I can't run it without downloading a different browser.

Interoperability is one of the basic premises of the web.

Which is why many projects have moved beyond writing such things by hand, and use css-compilers. And interoperability is never one of the premises of the bleeding edge, which is generally what those myriad posts touch on (HTML5 audio, for example).

Many of the older CSS3 specs are now supported in modern browsers, so I'd say we're pretty close, really. Or now, if you only support the most recent version (which accounts for what, >50%?). A stupendously far cry from where we used to be not too long ago.

The benefit of being able to use prefixed features sooner outweighs the cost of having to wait for the standards process to complete, then for browser vendors to implement the features, then for those features to ship in some future version. Prefixed features are about creating value sooner, and they do, but it is unfortunate that the standards process can't keep up.

A Javascript-based solution to this problem: let Javascript customize the web-standard version to your browser's version if supported.

http://leaverou.github.com/prefixfree/

Not a perfect solution, but it's interesting.

It's not bullshit, it's pretty great and much better than what we had before. This is a desired result of the standards process, exactly the opposite of what you seem to think it is.

There has to be a way for browsers to test new features in the wild. That's how it's always been and will always be, which also has the nice side effect that the standards body (or single vendors inside the body) cannot slow everyone down. If everyone could only implement features when they are really done and part of the standard the world would be a dreary place indeed.

The problem with this is that when two browsers implement a feature with either a different syntax or different results you would be forced to do browser detection and have two stylesheets or use hacks. That reallx used to happen and it sucked. The prefixes avoid this problem altogether. When everyone agrees about a feature the prefixes can be dropped – in this case (if the syntax doesn't change) nobody even has to change anything. All the designer has to do is delete lines as more browsers adopt the standard.

What you are seeing is the necessary result of a standards process with many vendors.

i believe that linear-gradient without any prefix works in the latest version of all those browsers.

So how long until we can drop the prefix versions. If the answer is > 2 years I say --prefix tags are bullshit.

I don't use prefixed versions in any of my work. pretty much all of them are for non-layout styles, which just means that people who don't upgrade their browsers to the latest version get a slightly uglier version of the site. I like to give people a reason to upgrade without breaking my site for them.

The "background linear-gradient" is the web standard and supported by all. the -$PREFIX ones are for old versions of those browsers.

Like it. I finally feel we're at the stage now where I can start dropping things like this into pages without too much worrying about compatibility.

Many a year has gone by where I've seen cool things appear that I'd love to use but just couldn't write off ~ 70% of browsers. Those days are numbered, more or less, and it makes me unsad.

wait what is this sorcery: "display: inline-block;" It's a new feature of CSS3 right?

edit: I feel so stupid not knowing about this even after years of CSSing. Apparently it's CSS2 but doesn't work well if you don't have IE8+

inline-block exists in IE6/7 it just works a bit differently. It doesn't apply to elements that are display:block by default. However, it works quite well on span and other inline elements.

It's interesting that the author uses :after to put the single pixel horizontal border at the bottom of the tab row. I'm no designer, but I'm sure I've done that part before just with normal border rules.

There are slight problems with doing this with borders. <li> bottom borders is shown ON TOP of <ul> bottom border, so you end up with two pixel border. You can slightly tweak margin on selected <li> only, but :after element seems easier.

If you're following the steps, it's interesting to zoom in on your page to better see what's going on with the curves.

Impressive results here. Reaching this kind of overlapped tab style is non-trivial even with plain images/sprites.

Not THAT non-trivial. I built overlapping tabs using images and JavaScript in 1997 - that wasn't more than a few hours' work (couldn't have been - I have the attention span of a door handle).

http://www.wittenburg.co.uk/mobile

Click "Handsets" on the top menu.

Select any phone on the left.

Tabs are shown on the right.

[Edit] Not saying joshuacc's CSS version is trivial. It's not. And it IS impressive!

For the record, this isn't my work. :-)

It does not work on IE7 and has squared tabs on IE 8. And JQuery is required too, it is not installed on all websites. This version works on any browser without framework: http://www.xul.fr/javascript/tabs.php

jQuery is NOT required. He is only using it in the demo to change the selected class on the menu items.

jQuery code is embedded in the demo I have downloaded, and the goal of the demo is to show how to use the tool. I have tried to remove this code and then tabs do not work.

All you need to do is change the className of the old selected li element to "" and the new selected li element to "selected". That doesn't require jQuery, but if you remove the code without replacing it with a non-jQuery alternative, of course it's not going to work. The tabs, though, don't depend on jQuery.

Of course, it is proven in the link above.

Nothing has been proven, the article in question is about how to STYLE the tabs to get the rounded corner design, not how they function as tabs. That is a secondary concern.

The use of jQuery was to provide the functionality so you can see it in action. If I felt the need I could easily recreate the tabs on a series of pages that do not require javascript at all.

The only reason this might need javascript involved is if the tabs are changing content on the page without loading a new page, such as swapping out divs in a container.

I believe you are confused about design versus function.

Exquisite graphic design, quality css and good explanation.

These tabs are awkward in my browser. The way they overlap gives a physical sense that the tab over there was the one I was just in because it's sitting above the tab next to it.

... except it doesn't appear to be intentional, or in line with what I just visited. On the example page, click the last, then second, then third to last tabs. Even though you're in the second tab and were just on the third, the last tab appears to be resting on top.

It looks awkward to me. Sorry, that was a lot of criticism for a well written iterative CSS guide which I appreciate!

I see what you're saying but it isn't that big a deal to me. The way to avoid that though is not to overlap the tabs. The author should have provided a second row without overlap as an additional example.

I was thrown off too -- until I realized that Chrome does tabs that way, and it's not confusing there at all. It's just that the post author overlapped them in the opposite direction that tabs typically are laid out: the rightmost tab in the CSS version is the highest, instead of the leftmost one like in Chrome / Sublime Text / other noticeably overlapping tabbed applications.

Chrome's always overlap in one direction though, it's at least consistent.

Impressive, sir. Too bad no IE support. Basically useless in application without an IE-specific sheet. In which case, why do it in pure CSS at all?

Hardly useless, if it degrades gracefully. In this case, the fallback in IE 8 & 9 seems to be perfectly usable for me (I haven't tested older versions).

Reply on news.ycombinator.com