New home page

[Stephan Soller]

On 05.10.2010 12:13, Nick Sabalausky wrote:
> "Stephan Soller"<stephan.soller at helionweb.de>  wrote in message
> news:i8epjv$1d3p$1 at digitalmars.com...
>> On 05.10.2010 04:28, Nick Sabalausky wrote:
>>> "Walter Bright"<newshound2 at digitalmars.com>   wrote in message
>>> news:i8d77c$1bf1$1 at 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