
(Better) Tabs with Round Out Borders - joshuacc
http://css-tricks.com/better-tabs-with-round-out-borders/
======
dekz
Props to the author showing a iterative development process instead of just a
example and code dump.

------
firefoxman1
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?

~~~
mappu
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.

~~~
sp332
_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.

------
kennywinker
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?

~~~
Groxx
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.

~~~
kennywinker
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.

~~~
Groxx
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.

------
kingofspain
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.

------
baby
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+

~~~
mark_story
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.

------
baddox
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.

~~~
xentronium
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.

------
mise
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.

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

~~~
Spearchucker
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!

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

------
scriptproof
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>

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

~~~
scriptproof
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.

~~~
stan_rogers
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.

~~~
scriptproof
Of course, it is proven in the link above.

~~~
talmand
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.

------
thomasfl
Exquisite graphic design, quality css and good explanation.

------
drivebyacct2
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!

~~~
reissbaker
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.

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

------
robwgibbons
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?

~~~
tagawa
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).

