On 05.10.2010 12:13, Nick Sabalausky wrote:
"Stephan Soller"<stephan.sol...@helionweb.de> wrote in message
news:i8epjv$1d3...@digitalmars.com...
On 05.10.2010 04:28, Nick Sabalausky wrote:
"Walter Bright"<newshou...@digitalmars.com> wrote in message
news:i8d77c$1bf...@digitalmars.com...
Stewart Gordon wrote:
The layout breaks in anything but the default text zoom.
The annoying thing about this is everyone says "don't use tables for
layout, use CSS." Except that using CSS for layout DOESN'T WORK
RELIABLY.
With tables, I can get 3 columns that are actually 3 columns, not 3
columns that are a side effect of bugs in CSS.
YES!! This is a pet peeve of mine (but then, what isn't? ;) ). I've even
been meaning to write up a little article about it. For styling, CSS is,
umm, acceptable. But it's crap for layout. And every argument I've seen
against using tables for layout has been either extremely minor,
questionable/uncited, or just plain bullcrap.
Speaking of, if anyone has links to well-regarded "why you shouldn't use
tables for layout" information, please post them. Whenever I get around
to
doing that little write-up I'd like to try to refute as much as I can. Or
be
proven wrong before making a bigger ass of myself. Either way :)
The point in not using the table _element_ for layout is that HTML should
be used to define the _content_ of your page not its appearance.
...
Basically it's all about separation of content and presentation. It's not
always easy (nor always necessary) but if done right you don't have to
touch the HTML code for your next redesign (and the search engines are
very happy about proper HTML code, too).
Yea, I do agree in principle. But in my experience, certain realities of CSS
complicate the issue.
Basically, I've spent enormus amounts of time and energy getting certain
layouts to work properly and reliably in CSS. There's been plenty of times
I've come across that and eventualy just threw my hands up and said "Ok, the
heck with purity and ideals, I just need to get it done: So hello tables!".
And every single time I've done that everything went smooth from that point
on.
If CSS could handle layouts as well as tables can, then I would be all for
abandoning tables-for-layouts. But CSS just isn't there yet. And I don't see
it progressing much.
Plus I often find redesigning HTML a lot more straightforward than tweaking
typical production-scale CSS (CSS can get real hairy real quick).
Not only that, I've recently started doing my sites in a very
MVC/rails/django-ish way whenever possible, so for me, the HTML usually *is*
just as much part of the view as the CSS anyway. And all I have to do to
redesign it is just tweak an html template file. As a bonus, that allows for
much more flexibility in my redesigns (and much more easily) than CSS could
ever hope to achieve without CSS itself getting a fundamental overhaul.
ps.: I'm usually only reading this newsgroup because I'm somewhat new to
D. But I couldn't resist answering about CSS. ;)
Welcome :)
Thanks. :)
I have to agree that CSS layout techniques have a somewhat steep
learning curve. It's straight forward to use floating boxes for column
layouts and bugs in IE still hurt. However it's the same in every
language/field (e.g. it was totally new to me to use "() ? x : y" to get
the common type of two expressions). Once you get to know some of the
techniques it's way more easy to do stuff in CSS, often just because you
have less text to type and everything in one place (a few lines in a CSS
file).
If CSS could handle layouts as well as tables can, then I would be all for
abandoning tables-for-layouts. But CSS just isn't there yet. And I don't see
it progressing much.
CSS is absolutely ready, IE 6 and 7 are not. As soon as you can assume
IE 8 or any decent browser you can use CSS tables. Sitepoints Book
[Everything You Know About CSS Is Wrong][1] is a very practical guide to
these handy properties. There are also some more experimental column or
grid based properties but I haven't seen any of them out in the wild.
CSS 3 defines quite some interesting stuff but it's very hard to tell if
or when someone can use it.
[1]: http://www.sitepoint.com/books/csswrong1/
Plus I often find redesigning HTML a lot more straightforward than tweaking
typical production-scale CSS (CSS can get real hairy real quick).
"Production-scale" CSS can get really ugly really fast without a fitting
coding style (e.g. I'm almost always defining margin and padding on any
layout elements, just to have the actual values available at the same
code line).
Not only that, I've recently started doing my sites in a very
MVC/rails/django-ish way whenever possible, so for me, the HTML usually *is*
just as much part of the view as the CSS anyway. And all I have to do to
redesign it is just tweak an html template file. As a bonus, that allows for
much more flexibility in my redesigns (and much more easily) than CSS could
ever hope to achieve without CSS itself getting a fundamental overhaul
MVC frameworks are really handy, especially for larg projects. In those
I never had the situation that someone wanted a redesign anyway, they
always wanted new features and therefore the HTML got modified, too.
Personally I can't image a way CSS could ever deliver that kind of
flexibility, simply because it's only concerned with visual presentation
and not with data (like HTML).
However for my private stuff (some documents, almost all presentations)
I use HTML to write the content first and then define some CSS to make
it look good. This is especially handy when doing a presentation about a
programming language since you can use JavaScript to write a small
syntax highlighter (the grammar in the D documentation was really handy
for that). :)
Happy programming
Stephan
