div-based layouts..

In article <zvmdna6sRMbezgfUnZ2dnUVZ_jmdnZ2d (AT) earthlink (DOT) com>,
Jeff <dont_bug_me (AT) all (DOT) uk> wrote:

dorayme wrote:
In article <4999fd4e$1_4 (AT) news (DOT) bluewin.ch>,
John Hosking <John (AT) DELETE (DOT) Hosking.name.INVALID> wrote:

maya wrote:
I'm converting some table-based code to div-based.. I really don't like
this, I find tables much simpler for some situations, but well...
And for tabular data, tables are not only easier than CSS-based divs,
they're more appropriate, too. (Free conclusion for you to jump to: if
you don't like it, don't do it. ;-) )

the hardest time I have is with content that has to appear side-to-side,
like this page, http://www.francesdelrio.com/resume/skills.html
Surely this is tabular data, and cries out for a <table>.


Look again. At present, it looks to me like headings and lists. It's
not marked up that way though, what looks like headings are spans.

John's point, a good one imo, is that some of the material lends itself
to a table when you consider what needs to be conveyed. How it is laid
out at the moment is not strictly relevant.

Not quite sure it cries out for it. Not that some data does not
sometimes do just this, namely, cry out for one big table

Certainly, in the ordinary concept of the idea of a table, OP can lay
out these lists under col headings, "Markup/Programming Languages",
"IDEs/Tools", "Education" and "Languages" and either one TD row with
lists inside or simply many rows with TDs that contain the items
relevant to the col headings. That there is no particular meaningful
relationship between the items across *all* the rows does not prove that
a table is being used for page layout.

However, as we know, a big table is not very flexible width wise.

Well, it can't wrap under, if that is what you mean.

That is pretty well exactly what I meant. I'm not from earth you know,
you need to make allowances. <g>

It is
very much open to the OP to present the information in a way that is
more flexible. For example, by floating less wide elements (lists,
thinner tables, whatever), the space in a webpage can be more
effectively used up and communication can be enhanced rather than
detracted from. Especially in this case where it is so clear that we are
looking at a list of a man's qualifications.

If horizontal space is needing to be conserved and vertical scrolling
not minded, there is a yet another way, to list and list within list
down the page. I rather fancy this! Closer to no style, as far away as
can be from Travis and his need for stimulation. Yes, I like this idea a
lot. More HTML and less CSS.


I just don't get the lists of lists here. Lists have a real
definition and I can't seem them being used for presentation. That to
me, is the reason for the syntactically empty div.

The OP was exhibiting his qualifications. He had those qualifications
under a few helpful categories. Under A, he expanded, there is a,b,c.
Under B, there is d,e,f and so on. So, it is an option to present this
kind of material as a list, main items being A,B,C and sub items being
a,b,c; d,e,f;...

It is an option. I am not saying he should do this.

--
dorayme

On 17 Feb, 04:27, Gus Richter <gusrich... (AT) netscape (DOT) net> wrote:

Just a gentle reminder that the whole idea is to separate content (html)
from presentation (css).

Idea yes, but not practical to do it entirely. You still need HTML to
attach the CSS to. You may also need to _add_ HTML solely to provide
sufficient attachments.

dorayme wrote:

In article <gndebn$qdf$1 (AT) news (DOT) motzarella.org>,
Gus Richter <gusrichter (AT) netscape (DOT) net> wrote:

dorayme wrote:

[snip, snip]

More HTML and less CSS.
[and more snip]

Just a gentle reminder that the whole idea is to separate content (html)
from presentation (css).

And I need this reminder because?

Because the phrase "More HTML and less CSS" sounds like I meant more
HTML *at the expense* of CSS?

Having this online alzeimic reader - which I know you have been trying
to pry out of my clutches for years Gus <g> - means I have not got the
context of the remark before me.

So, I will simply have to remember what I said, and ... here it is:

"If horizontal space is needing to be conserved and vertical scrolling
not minded, there is a yet another way, to list and list within list
down the page.

Having looked at this again, I think Dorayme has this correct.

The first list (inline or float: left) has: Markup/Programming
Languages,IDEs/Tools,... The sub list (normal) would have the items.

It would take perhaps 2 classes (one to turn off the bullets for
Education, Languages sublist and reset widths) and you could get the
identical look as what was done with extra meaningless markup and you
would have something that is syntactically correct. And you could
maintain this by simply adding items to the list.

YMMV. But I think someone who advertised "CSS (table-less layouts)",
could do that, instead of a nested table layout.

Jeff


I rather fancy this! Closer to plain godly honest default

styles supplied by browser, as far away as can be from Travis and his
need for stimulation. Yes, I like this idea a lot. More reliance on what
the natural HTML delivers and less need for fancy footwork with CSS.

"Cats, Travis and ways to skin them!"

What is wrong with that? <g

dorayme wrote:

In article <gndebn$qdf$1 (AT) news (DOT) motzarella.org>,
Gus Richter <gusrichter (AT) netscape (DOT) net> wrote:

dorayme wrote:

[snip, snip]

More HTML and less CSS.
[and more snip]

Just a gentle reminder that the whole idea is to separate content (html)
from presentation (css).

And I need this reminder because?

Because the phrase "More HTML and less CSS" sounds like I meant more
HTML *at the expense* of CSS?

Having this online alzeimic reader - which I know you have been trying
to pry out of my clutches for years Gus <g> - means I have not got the
context of the remark before me.

So, I will simply have to remember what I said, and ... here it is:

"If horizontal space is needing to be conserved and vertical scrolling
not minded, there is a yet another way, to list and list within list
down the page. I rather fancy this! Closer to plain godly honest default
styles supplied by browser, as far away as can be from Travis and his
need for stimulation. Yes, I like this idea a lot. More reliance on what
the natural HTML delivers and less need for fancy footwork with CSS.

"Cats, Travis and ways to skin them!"

What is wrong with that? <g

Commenting about the alternative of using List in place of Table:

Original:
I rather fancy this! Closer to no style ......... Yes, I like this idea
a lot. More HTML and less CSS.

Memory Recall:
Closer to plain godly honest default styles supplied by browser ........
Yes, I like this idea a lot. More reliance on what
the natural HTML delivers and less need for fancy footwork with CSS.


Although steps have been taken by discouraging the use of font markup
(specifically TT, I, B, BIG, SMALL) in html in favor of style sheets,
there are other presentational markup in html (such as Heading, Table,
List, Horizontal Rule) and although I'm not suggesting to eliminate
their use, it does ring contrary to the ideal of separating content from
presentation when praising presentational markup for requiring less css.
A small point which perhaps I should not have brought up even as a
"gentle reminder".

--
Gus

Andy Dingley wrote:

On 17 Feb, 04:27, Gus Richter <gusrich... (AT) netscape (DOT) net> wrote:

Just a gentle reminder that the whole idea is to separate content (html)
from presentation (css).

Idea yes, but not practical to do it entirely.

True, since in addition to the discouraged font markup that I mentioned
to dorayme, there are other html markup with presentational qualities
such as Paragraph and Phrase Markup.

You still need HTML to
attach the CSS to. You may also need to _add_ HTML solely to provide
sufficient attachments.

Following this idea, you can add as much html as you want as long as
they don't affect presentation such as div and span.

--
Gus

In article <gnem1f$t13$1 (AT) news (DOT) motzarella.org>,
Gus Richter <gusrichter (AT) netscape (DOT) net> wrote:

dorayme wrote:
In article <gndebn$qdf$1 (AT) news (DOT) motzarella.org>,
Gus Richter <gusrichter (AT) netscape (DOT) net> wrote:

....
Commenting about the alternative of using List in place of Table:

Original:
I rather fancy this! Closer to no style ......... Yes, I like this idea
a lot. More HTML and less CSS.

Memory Recall:
Closer to plain godly honest default styles supplied by browser ........
Yes, I like this idea a lot. More reliance on what
the natural HTML delivers and less need for fancy footwork with CSS.

My, my, incredible how biased in my favour my memory works! <g>

Although steps have been taken by discouraging the use of font markup
(specifically TT, I, B, BIG, SMALL) in html in favor of style sheets,
there are other presentational markup in html (such as Heading, Table,
List, Horizontal Rule) and although I'm not suggesting to eliminate
their use, it does ring contrary to the ideal of separating content from
presentation when praising presentational markup for requiring less css.
A small point which perhaps I should not have brought up even as a
"gentle reminder".

Any opportunity to discuss these matters is welcomed, Gus.

Let's talk about H1,P and UL etc. In the orthodox view of those who
speak about the desirability of separating content from style, H1, P, UL
are not thought to be presentational but semantic. They are contrasted
with such elements as B, I, Big. The idea is that you can shove the
function of the latter off to CSS. But you can't do the same with P, H1,
UL. They are different. But different is meant in a precise way, in
relation to particular functions.

Using an H1 says or means something all by itself. It is not a
presentational bit of mark up in the same sense in which B is. The whole
idea of separating out content from style is a pretty good one for all
sorts of reasons and it depends crucially on the distinction between
elements like H1 having meaning as against still-hanging-around elements
like B that are instructions to merely style.

However, if we were to eliminate all the styling elements from HTML (and
many good authors these days do in fact do this), we are *not* left with
something that is without all appearance characteristics. All meaning in
a P or an H1 or a UL would be sucked out of it if browsers had no idea
how to present them without any style sheet by the author. Turning off
style sheets to take a peek does *not* turn off all styles at all. It
turns on the el basico style sheet or browser coding instuctions. These
basic styles are in a sense part of the meaning of the elements. Without
basic appearance, there is no human meaning. A paragraph that did not
look like a paragraph is not a paragraph except in some abstract airy
sense.

In other words, some appearance, some presentation is part and parcel of
the very core of HTML itself. True, there is a level of abstraction
still here in that the set of basic appearances for an H1 or a P are not
fixed in stone. But, my point is that it is not an empty set!

--
dorayme

dorayme wrote:

Any opportunity to discuss these matters is welcomed, Gus.

Let's talk about H1,P and UL etc. In the orthodox view of those who
speak about the desirability of separating content from style, H1, P, UL
are not thought to be presentational but semantic. They are contrasted
with such elements as B, I, Big. The idea is that you can shove the
function of the latter off to CSS. But you can't do the same with P, H1,
UL. They are different. But different is meant in a precise way, in
relation to particular functions.

Using an H1 says or means something all by itself. It is not a
presentational bit of mark up in the same sense in which B is. The whole
idea of separating out content from style is a pretty good one for all
sorts of reasons and it depends crucially on the distinction between
elements like H1 having meaning as against still-hanging-around elements
like B that are instructions to merely style.

However, if we were to eliminate all the styling elements from HTML (and
many good authors these days do in fact do this), we are *not* left with
something that is without all appearance characteristics. All meaning in
a P or an H1 or a UL would be sucked out of it if browsers had no idea
how to present them without any style sheet by the author. Turning off
style sheets to take a peek does *not* turn off all styles at all. It
turns on the el basico style sheet or browser coding instuctions. These
basic styles are in a sense part of the meaning of the elements. Without
basic appearance, there is no human meaning. A paragraph that did not
look like a paragraph is not a paragraph except in some abstract airy
sense.

In other words, some appearance, some presentation is part and parcel of
the very core of HTML itself. True, there is a level of abstraction
still here in that the set of basic appearances for an H1 or a P are not
fixed in stone. But, my point is that it is not an empty set!

I'm not one to criticize W3C for their decisions regarding matters of
separating content from presentation. I take it as worthwhile to move
Presentational Markup into the realm of css (specifically TT, I, B, BIG,
SMALL and attributes align, bgcolor) for the meaning of elements is
primarily to describe the structure and semantics, not the presentation.

Neither am I questioning the difference (if any) between Structural
Markup and Semantic Markup (such as Heading, Table, List, Horizontal
Rule). My view is that Structural Markup are simply funtion calls (or
formats) for two or more internal instructions to accomplish a desired
Presentation and so, Structural Markup is Presentational Markup.

Just as Presentation should be kept out of html, it follows that Content
should be kept out of css, so it would seem to be contradictory to have
Generated Content and List Numbering, but I digress. ;-)

Along comes XML which uses Semantic Markup (Descriptive Markup) and
truly separates content from presentation. XML not only re-introduces
the concept of separation of content from presentation (as was the
original principle of the World Wide Web), but takes it to a new level.
The tags used in HTML are really presentational tags. By nominating a
paragraph as <h1>, the author is really defining an aspect of the
presentation to the reader. An <h1> is a heading. A heading is a
presentation or formatting term more than a content term. An XML schema
allows more specific tags, such as <concept> and <conbody>, to be used
(call it labelling). No inference about presentation can be drawn from
those tags. So presentation can be truly separated from content.

’Twas the reason for XHTML - a small interim step for an author and a
giant step for the web as a move toward an XML world by regaining the
power and flexibility of SGML without most of its complexity.

--
Gus

In article <gng2a0$m4b$1 (AT) news (DOT) motzarella.org>,
Gus Richter <gusrichter (AT) netscape (DOT) net> wrote:

dorayme wrote:
Any opportunity to discuss these matters is welcomed, Gus.

....

In other words, some appearance, some presentation is part and parcel of
the very core of HTML itself. True, there is a level of abstraction
still here in that the set of basic appearances for an H1 or a P are not
fixed in stone. But, my point is that it is not an empty set!


I'm not one to criticize W3C for their decisions regarding matters of
separating content from presentation. I take it as worthwhile to move
Presentational Markup into the realm of css (specifically TT, I, B, BIG,
SMALL and attributes align, bgcolor) for the meaning of elements is
primarily to describe the structure and semantics, not the presentation.

Agreed.

Neither am I questioning the difference (if any) between Structural
Markup and Semantic Markup (such as Heading, Table, List, Horizontal
Rule).

I have never really thought of these two concepts in relation to each
other closely or thought of them as referring to different activities.
Perhaps one emphasises a whole document approach, the other more a local
thing. For example, anyone can see that a set of words that go into a
document at a certain point will be a paragraph because there are lots
of other paras there... But with a heading, one needs to keep an eye out
for the whole doc because they sort of have a cascading (nothing to do
with CSS cascade) logic to their use.

Just as Presentation should be kept out of html, it follows that Content
should be kept out of css, so it would seem to be contradictory to have
Generated Content and List Numbering, but I digress. ;-)

I suppose it is a bit of an anomaly.

Along comes XML which uses Semantic Markup (Descriptive Markup) and
truly separates content from presentation. XML not only re-introduces
the concept of separation of content from presentation (as was the
original principle of the World Wide Web), but takes it to a new level.
The tags used in HTML are really presentational tags. By nominating a
paragraph as <h1>, the author is really defining an aspect of the
presentation to the reader. An <h1> is a heading. A heading is a
presentation or formatting term more than a content term. An XML schema
allows more specific tags, such as <concept> and <conbody>, to be used
(call it labelling). No inference about presentation can be drawn from
those tags. So presentation can be truly separated from content.

I don't quite see it in those terms but I can see how you can get by in

so describing it. The bit that makes me uncomfortable for reasons I must
have given a fair few times by now is your "No inference about
presentation can be drawn from those tags. So presentation can be truly
separated from content".

I think *some inference* can be made. One can infer that at the very
least a p should look, sound, feel like what humans have come to know a
paragraph looks, sounds or feels like. And that ain't like what Roger
Rabbit looks like! I agree that no inference to fancy presentation or
aesthetically pleasing presentation or cool can be inferred.

¹Twas the reason for XHTML - a small interim step for an author and a
giant step for the web as a move toward an XML world by regaining the
power and flexibility of SGML without most of its complexity.

--
dorayme

dorayme wrote:

In article <gng2a0$m4b$1 (AT) news (DOT) motzarella.org>,
Gus Richter <gusrichter (AT) netscape (DOT) net> wrote:

Along comes XML which uses Semantic Markup (Descriptive Markup) and
truly separates content from presentation. XML not only re-introduces
the concept of separation of content from presentation (as was the
original principle of the World Wide Web), but takes it to a new level.
The tags used in HTML are really presentational tags. By nominating a
paragraph as <h1>, the author is really defining an aspect of the
presentation to the reader. An <h1> is a heading. A heading is a
presentation or formatting term more than a content term. An XML schema
allows more specific tags, such as <concept> and <conbody>, to be used
(call it labelling). No inference about presentation can be drawn from
those tags. So presentation can be truly separated from content.

I don't quite see it in those terms but I can see how you can get by in
so describing it. The bit that makes me uncomfortable for reasons I must
have given a fair few times by now is your "No inference about
presentation can be drawn from those tags. So presentation can be truly
separated from content".

I'm sure that those are not my words of describing it, for they are a
section, from God knows where, modified by me and filed away some time
ago. The paragraph describes XML and HTML elements and how they differ.

The *XML* elements <concept> and <conbody> ...... not HTML elements.
Check out an example at:
<http://www.alistapart.com/d/usingxml/xml_uses_a.html>

I think *some inference* can be made. One can infer that at the very
least a p should look, sound, feel like what humans have come to know a
paragraph looks, sounds or feels like. And that ain't like what Roger
Rabbit looks like! I agree that no inference to fancy presentation or
aesthetically pleasing presentation or cool can be inferred.

Inference can be made for HTML elements, but _not_ for XML elements
mentioned or in the example link provided. Don't confuse HTML elements
(which are fixed tags) with XML elements (which can be any tag (label)
you create) where *only* the associated Stylesheet will affect the
presentation, without which the document will only consist of CDATA.

--
Gus

In article <gnggd8$3ig$1 (AT) news (DOT) motzarella.org>,
Gus Richter <gusrichter (AT) netscape (DOT) net> wrote:

dorayme wrote:
In article <gng2a0$m4b$1 (AT) news (DOT) motzarella.org>,
Gus Richter <gusrichter (AT) netscape (DOT) net> wrote:

....

The *XML* elements <concept> and <conbody> ...... not HTML elements.
Check out an example at:
http://www.alistapart.com/d/usingxml/xml_uses_a.html

I think *some inference* can be made. One can infer that at the very
least a p should look, sound, feel like what humans have come to know a
paragraph looks, sounds or feels like. And that ain't like what Roger
Rabbit looks like! I agree that no inference to fancy presentation or
aesthetically pleasing presentation or cool can be inferred.

Inference can be made for HTML elements, but _not_ for XML elements
mentioned or in the example link provided. Don't confuse HTML elements
(which are fixed tags) with XML elements (which can be any tag (label)
you create) where *only* the associated Stylesheet will affect the
presentation, without which the document will only consist of CDATA.

mmm... I confess, XML is not something I know a lot about, but I think I
see what you mean. I better not say too much about XML!

--
dorayme