I'm a bit suspicious of positioning.
My instincts tell me that positioning should be defined in css. Putting it in your js could cause confusing mixing. Also, it seems to preclude graceful degradation.
The gut will tell you a lot of things should go in CSS, but when you ask CSS it says "I SUCK".
My instincts tell me that positioning should be defined in css.
Vertically aligning text with css is entirely possible, although sometimes tricky. Most of the time, line-height will suffice.
But you kind of missed of point. CSS is for styling beyond the browsers defaults. JS is for behaviours. Mixing these things up makes debugging and maintainance difficult.
But you kind of missed of point. CSS is for styling beyond the browsers defaults. JS is for behaviours.
And tables should never be used for layout.
Yeah, I know. But those distinctions are only absolute in an ideal world. But in an ideal world, I wouldn't need to code HTML stuff to earn a living anyway.
In the real world, I tend to go with a more pragmatic point of vue.
Mixing these things up makes debugging and maintainance difficult.
A simple JS code is easier to debug and maintain that a complex CSS construction.
Sorry dude, but I strongly disagree on all of your points.
Indeed, tables should not be used for layout. In 2010 a good coder simply won't have to use tables for layout. There is no layout problem that can't be solved with good css styling.
Also, a coder worth paying should be able to debug complex css in reasonable time. Besides, css should be the first place a coder will look for styling information. Because that's where styling should come from.
Also, if you wanted to keep your js simple, you wouldn't be including styling in it.
Did anything change compared to 2002? Did IE6 improve?
Also, if CSS is for styling (as its name implies), why the hell would it be better than JS or tables for layout?
I'm not sure I understand your latter question. Do you think that there is a significant difference between layout and styling?
I'll answer your questions anyway...
CSS is better then tables for layout because when properly done you will save on bandwidth costs, have a faster loading page, have a faster rendering page, you can centralize your layout code, have a higher degree of human accessibility and have a higher degree of bot accessibility (SEO). Thats a whole bunch of important things. And thats just the ones I can think of off the top of my head.
Oh yeah - and CSS is also better for layout then tables because tables were not designed with page layout in mind. CSS was. Layout design is built in to CSS.
Layout in external CSS is better then layout in JS because of maintainability/debugging and graceful degradation: if your page layout relies on js then you are doing it wrong. (I'm also assuming that you are using unobtrusive js here. Layout in inline js would be another level of sinfulness)
Regarding your first question: no, ie6 hasn't improved. So what? Again, a good coder can make most layout solutions work across all major browsers, including ie6. At the very least, ie6 layout issues can be dealt with by an ie6 targeted stylesheet delivered via a conditional comment.
So yes - things have changed since 2002. Coders got better.
I'm not sure what elements vertical-align is supposed to work for, but 95% of the time this does nothing at all. line-height and position:relative are usually what I end up using.
Someone may correct me here (and I'd be happy if they did), but I think the vertical-align property only applies to inline elements, and only relative to other inline elements in the same line. Say, to position a small icon inline with your text.
Set the parent as:
and then the vertical-align will work properly. It is a little hacky? Sure, but no JS.
then the vertical-align will work properly.
...in some browsers.
Let's not forget that vertical-align sucks donkey balls because every browser has a slightly different interpretation of bottom, baseline, middle and top because of how they render fonts differently...
As for the "fancy buttons" can't this be done in CSS? I've never tried assigning a hover value to a button, but if I remember correctly everything past IE6 supports hover on any element, not just anchor. Seems really unnecessary, as the only thing you would lose with CSS is rounded corners in IE.
It's all CSS yes, but it means you don't have to make/test them.
The button is honestly the worst example, the other form elements are more interesting. The radio buttons for instance are very nicely done; styling them yourself is quite unintuitive since you have to use labels and hide the actual input elements.
Agreed, trying to style radio buttons is a major pain in the ass.
No, you cannot do fancy buttons all in CSS. You can do a hover effect, but part of the "feel" of a button is that you can mousedown on it so it activates, then mouseout so it pops back up, and then when you mouse back over it pops back down. The jQuery UI button does this the same way an <input type="button"/> does, anything you try with :hover and :active will not perfectly equate.
Also, try making a toggle button with all CSS... not possible either.
Maybe it's just me but jQuery UI smells bad. It's very un-jQuery-like in the sense that it's quite heavyweight. Rolling a theme for just 1-2 widgets seems like overkill. jQuery Tools just seems like a much more lightweight and robust alternative.
If you want to put one widget on your page, it might not be your cup of tea, especially if you are an efficiency hound.
If you want to integrate twenty of them into a site, however, I must say it does quite a good job of it. You'll appreciate Themeroller when you need to do this one day and you can roll a unified theme for all of your widgets in a few clicks. The theme building range is impressive to say the least.
And as far as jQuery widget plugins go, believe me, it is the most jQuery-like of them all. They've even refined the widget factory in this version so it's more prototype-friendly and has saner getting/setting. (I don't agree with all the changes, but the last factory had its warts in those areas.) Widgets have been crafted to carefully encapsulate their data, allow all options to be changed on the fly (not a small task), and allow everything to be accessible from jQuery collections without polluting $.fn.
For an example of how to do this wrong by pooping out "external API objects", see jQuery Tools.
But this is the problem: unlike, say, ExtJS or even YUI or Mootools or wahtever, jQuery UI is (still) a limited subset of likely widgets that you'll want to use. So it's not a competitor to ExtJS (etc). It's just a heavyweight limited set of components. Take the date picker. There are many other lighter versions out there.
What's more--at least to me--it just feels slow when I use something with a lot of jQuery UI components, especially with all the CSS/JS/images it loads.
jQuery UI is more than a set of widgets, the real value is in the framework. I don't know how ExtJS and YUI handle things under the hood, but the core of jQuery UI is structured neatly so that you can quickly build your own widgets and have them interact with jQuery in all the expected ways.
For example, I have used the widget factory often in my projects ($.Widget in 1.8); it is incredibly useful for developing your own widget that a) has its own $.fn constructor b) offers getter/setters/actions through the $.fn method, an event system and an options store and c) interacts well with a skin framework so you can easily make it look like other widgets. This jQuery UI "interface", you could call it, makes using your widget via jQuery as expressive an experience as possible.
check out mootools-more... it's clean, lightweight, and worth its weight in gold.
jquery lightweight and robust? ... meh.
This one breaks all of my effects even more. I'm seriously considering ditching UI entirely.
I'm seriously considering ditching UI entirely.
Do it. I'll be interested to know what alternatives you try.
Anything equivalent to YUI 2 DataTables?