Jacob Carlborg wrote:
> I think this site has good CSS tutorials: http://css.maxdesign.com.au/
> Here is a tutorial for a liquid three column layout with a header and a footer: http://css.maxdesign.com.au/floatutorial/tutorial0916.htm

Thanks!

On 05.10.2010 04:28, Nick Sabalausky wrote:
> "Walter Bright"<newshound2@digitalmars.com>  wrote in message
> news:i8d77c$1bf1$1@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. It's all about what kind of data you have at hand: a heading, a list, tabular data, a figure with an image, etc. It says nothing about how the page is supposed to look, it's just the pure content.

After defining the content the appearance is setup with CSS. And there table layouts are used pretty often (if not always). If you don't care about older IE versions you can use "display: table" and companions. Basically these display properties just make elements behave like the corresponding HTML elements (e.g. "table-cell" maps to the td element).

Prior to that CSS only had mechanisms for defining float layouts (the "float" property) but these can be used for table layout, too. It's not
that difficult but it's less flexible. All you need is a container with "overflow: hidden". To create columns inside it just set some child elements to "fload: left". This will look like this:

    -- overflow: hidden ----------------------
    |                                        |
    |  -- float: left --  -- float: left --  |
    |  |               |  |               |  |
    |  |               |  |               |  |
    |  |               |  |               |  |
    |  |               |  -----------------  |
    |  |               |                     |
    |  -----------------                     |
    |                                        |
    ------------------------------------------

This method works quite well, only IE 6 makes some trouble because the floats trigger some bugs (but if you add a few pixels of reserve space it will be all right for IE 6). The main drawback of this method is that the floated boxes are independent of each other, each gets its own height and with. If you want them to have a consistent layout you have to assign fixed widths and highs. There are some workarounds for this (e.g. using a repeating background image on the container) but I suppose I already talked to much about CSS.

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

ps.: I'm usually only reading this newsgroup because I'm somewhat new to D. But I couldn't resist answering about CSS. ;)


Happy programming

Stephan Soller

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

"Stephan Soller" <stephan.soller@helionweb.de> wrote in message news:i8epjv$1d3p$1@digitalmars.com...
>  (and the search engines are very happy about proper HTML code, too).

I've actually come across this point before, that search engines will rank a page that doesn't use tables for layout better than one that does. I can't really argue against that point, but I am really curious. Does anyone have links to any authoritative information on this?

On 05/10/2010 02:13, Andrei Alexandrescu wrote:
> On 10/4/10 18:54 CDT, Walter Bright wrote:
>> Brian Hay wrote:
>>> With all due respect to Walter, as a professional web designer I have
>>> to agree with Andrei. It's terrible for all the reasons mentioned ...
>>> and more. "1995 programmer art" sums it up.
>>
>> Ok, but on the other hand, mint.com gets high fives for its home page.
>> But I find it to be slow loading, the green-on-green text (near the
>> bottom) impossible to read, and the animated text slideshows irritating.
>>
>> Or maybe I'm just too old :-)
>
> I think you and I (as many programmers who aren't web designers) are in
> the "don't/don't" place (we don't know what we don't know). Getting from
> there to "do/don't" -> "do/do" -> "don't/do" is a long, arduous process.
> So we're essentially unable to predict accurately the likeability of a
> web page by only looking at it, and clearly we're not in the position of
> designing a good website.
>
> Having gladly acknowledged your interest in this topic (as I agree
> marketing is at this point essential), my overarching advice is:
>
> 1. Find a good professional.
>
> 2. Explain in broadest terms _what_ you are trying to achieve at the
> highest level (NOT "here's _how_ I want this to be, tweak it"). For
> example, instead of saying "I want three equally sized columns because
> nobody told me that that design is cr(ee|ap)py, and please color them
> like pee in a swimming pool while you're at it", tell them "I have three
> product lines, and I want them featured on the homepage in a simple and
> straightforward manner".
>
> 3. Let the (wo)man do h(is|er) job.
>
> 4. Pay h(im|er) a small fraction of the money you'd be losing in
> opportunity costs should you do all the work yourself starting from
> "don't/don't".
>
> 5. ...
>
> 6. Profit!
>
>
> Andrei


I totally agree with the "we're not in the position of designing a good website.", but I'm not so sure about "predict accurately the likeability of a web page"
Well, maybe not super-accurately, but I think most developers would get a good sense if a page is good or not. Especially since, in the case of D and DigitalMars, it is us/Walter who knows exactly what the target audience is, the purpose of the website, etc.. A hired professional might know that, but not as well.

I have an alternate suggestion. Go to an open source web templates (like http://www.oswd.org/), selected a few of them, and then choose one. The choose part can be either just Walter choosing, or maybe the community could vote on one, or maybe some other alternative in between (the community just commenting on what they think). But a simple process, not too complicated.

A new web design is nice to have, but frankly, I think much better would be a reorganization of the site, at least the D site. I won't go into much detail here, but just mention that I think it has too many links, and they are not very well organized. I much prefer the http://www.d-programming-language.org/ site for example.

-- 
Bruno Medeiros - Software Engineer

On 05.10.2010 12:24, Nick Sabalausky wrote:
> "Stephan Soller"<stephan.soller@helionweb.de>  wrote in message
> news:i8epjv$1d3p$1@digitalmars.com...
>>   (and the search engines are very happy about proper HTML code, too).
>
> I've actually come across this point before, that search engines will rank a
> page that doesn't use tables for layout better than one that does. I can't
> really argue against that point, but I am really curious. Does anyone have
> links to any authoritative information on this?
>

I would also like to see solid information on that topic but I'm afraid this statement is very hard to catch. The Google SEO Guide mainly focuses on the title and description of websites as well as headings an links. I suppose more detailed structures and elements (lists, tables, em, code, etc.) are not that important for search engines but for other tools that need to work with the document structure (js scripts, screen readers, semantic analysis, data mining, etc.).

Happy programming
Stephan

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

Stephan Soller wrote:
> 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). :)

A javascript D syntax highlighter? Please post!

On 05/10/2010 06:51, Jacob Carlborg wrote:
<snip>
> I think this site has good CSS tutorials: http://css.maxdesign.com.au/
> Here is a tutorial for a liquid three column layout with a header and a
> footer: http://css.maxdesign.com.au/floatutorial/tutorial0916.htm

That's geared towards creating a layout with two fixed-width navigational columns and a central 'main' column.

What's wanted here is three equal columns, which is a quite different thing.

Stewart.

That's because HTML/CSS is a pretty terrible language for anything beyond simple layouts. It shares more with Word/PDF/PostScript in terms of its purpose and history than it does with real gui layout engines (GTK, QT, etc).

Hardcore HTML/CSS people tout the virtues of separating the content from the presentation. The problem is that HTML has implicit presentation that you often can't override with CSS. There are limits to what you can do with positioning. If I want to rearrange elements in my page I have to change the HTML, I can't do it all on the CSS side. That's not separation of content from presentation!

Real separation of the presentation has to happen right at the data layer. But that's server side in most applications. So you run your data through one view abstraction (template language such as Freemarker, PHP, JSP etc), then to HTML, and then polish it with CSS. Oh, and that application runs on an app server that runs in a Java virtual machine that runs in an VMware OS that runs on a real OS that actually accesses real hardware. That's an absurd number of layers...

Anyway, to get back to HTML. They'll say use divs not tables because a table represents a distinct concept not a layout element and it has accessibility implications. And yet I you can't layout things with divs in the same way that I can with a table. And even if there are obscure CSS properties that let me, half the user's browsers don't support them.

Sometimes I feel like I'm the only one that sees the naked Emperor. People are so excited about the Internet but they don't realize that browsers are just implementing one view language that's 15 years old and really isn't all that great. The beauty of the Internet is the emergent properties that arose from the concept of linking sites. But that's not something that has to be unique to the HTML language itself.

And sure there's some cool stuff in HTML5 but a pig's still a pig even when you velcro a TV to its head and a database on its back.


-Arlo




On 10/04/2010 02:23 PM, Walter Bright wrote:
>
> That's what bugs me. Something as straightforward as a 3 column layout
> shouldn't require "tricks" for it. Googling it found 3 pages dedicated
> to explaining this "trick" (each of them wildly different, of course).
>