div-based layouts..

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

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

Could you please start using ALL CAPS rather than merely capitalizing
words in Title Case. It makes gibberish babbling posts so much easier
to spot. Thankyou.

Andy Dingley wrote:

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

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

Could you please start using ALL CAPS rather than merely capitalizing
words in Title Case. It makes gibberish babbling posts so much easier
to spot. Thankyou.

It was way over your head was it? If my writings give you too much of a
headache, then your solution is to use killfile.

--
Gus

On 18 Feb, 14:59, Gus Richter <gusrich... (AT) netscape (DOT) net> wrote:

It was way over your head was it?

The problem is that you have an almost completely erroneous idea of
"presentation", "content" and "semantics" as applied to HTML markup.

On 2009-02-18, Andy Dingley <dingbat (AT) codesmiths (DOT) com> wrote:

On 18 Feb, 14:59, Gus Richter <gusrich... (AT) netscape (DOT) net> wrote:

It was way over your head was it?

The problem is that you have an almost completely erroneous idea of
"presentation", "content" and "semantics" as applied to HTML markup.

Go on then, what are the correct ideas of those things?

Andy Dingley wrote:

On 18 Feb, 14:59, Gus Richter <gusrich... (AT) netscape (DOT) net> wrote:

It was way over your head was it?

The problem is that you have an almost completely erroneous idea of
"presentation", "content" and "semantics" as applied to HTML markup.

First response, you don't grasp the ideal of what the goal was (and is)
- to separate content from presentation.
Second response, you make a personal insult without anything to contribute.
Third response, you now say that I have no idea of what I speak, without
any correction or explanation of where you feel I've gone wrong. Nor do
you present what you believe to be correct. Yes it was way over your head.

With strike three, you're out since you reveal yourself to be a
thoughtless, crass buffoon not worthy of my attention. I no longer care
what your opinions are about anything and will do my best not to read
any of your posts and most certainly not to respond to any.

--
Gus

In article
<6fc0dfa0-ecac-4a84-810f-b2a121f03491 (AT) t3g2000yqa (DOT) googlegroups.com>,
Andy Dingley <dingbat (AT) codesmiths (DOT) com> wrote:

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

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

Could you please start using ALL CAPS rather than merely capitalizing
words in Title Case. It makes gibberish babbling posts so much easier
to spot. Thankyou.

Got up on the wrong side of the bed did we, this morning, Andy?

Your phrase "gibberish babbling posts" includes me and that means
trouble!

We meet at twelve paces tomorrow morning. I will play the part of James
McKay (last played by Gregory Peck in The Big Country) and you will play
the part of Buck Hannassey (Chuck Connors). And you will talk and behave
and die like him.

You will shoot before the signal and merely graze me. I will use my
right to shoot into the ground to show how I consider it unworthy to
shoot your disgracefully cowering collapsed self. You will go for a
spare gun from one of your henchmen and Rufus Hannassey (Burl Ives),
your father and master of ceremonies, will shoot you. You will slump
over into a water trough and your thoroughly ashamed but distraught
father will come over to you.

I - and this is the bit I really look forward to (taking care of you was
just business) - will ride off with Julie Maragon (Jean Simmons) and
that really good Mexican stick, Ramón (Alfonso Bedoya) into the sunset.

--
dorayme

On 18 Feb, 18:36, Ben C <spams... (AT) spam (DOT) eggs> wrote:

On 2009-02-18, Andy Dingley <ding... (AT) codesmiths (DOT) com> wrote:

On 18 Feb, 14:59, Gus Richter <gusrich... (AT) netscape (DOT) net> wrote:

The problem is that you have an almost completely erroneous idea of
"presentation", "content" and "semantics" as applied to HTML markup.

Go on then, what are the correct ideas of those things?

Didn't we bash all that out some years ago, such that it's obvious to
anyone who cares? This just isn't an interesting debate any more, and
if someone hasn't bothered to pay attention, it's hardly worth the
effort to correct them any more.

To trawl back up the thread.

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

So what's "Structural" vs. "Semantic" markup? HTML doesn't have any
structure. There's barely any semantics to it, but its structure is
even more flimsy. There's an id attribute, but nothing to make
references to it beyond fragment identifiers. There's no distinction
akin to rdf:about and rdf:resource . There are headings, but no
binding between heading and its related content. If you look at some
of the other markup schemes out there (and there are some, although
most web designers remain unaware) you might see the contrast and the
vast areas of function that HTML just doesn't even attempt to try.

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.

If there's one thing we can state with confidence in a discussion of
HTML with separated content and presentation it's that HTML is _NOT_ a
"function call" or any sort of imperative instruction as to how
content ought to be rendered. It's a declarative _description_ of some
content and some implied "aspect" we asssign to portions of that
content. How this should then be rendered is suggested by the
presentation (but may be over-ruled) and the "how" of how this
rendering will take place is only tenuously coupled to this. In
particular, the "how" of rendering depends more on the user agent's
context than the content itself. "HTML for the web" prioritises multi-
platform support way above specific control of rendering behaviour.

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

That's a failure to understand _why_ CSS supports generated content,
even though it's working hard to avoid turning into DSSSL. Yet again,
you can't grok this stuff until you've read Haakon Lie's PhD thesis.

Along comes XML which uses Semantic Markup (Descriptive Markup) and
truly separates content from presentation.

It's arguable as to whether XML has semantics (XML alone clearly
doesn't, but the author might be using it to mean XML + schema).
However XML is so very, very short of "Descriptive Markup" by any
credible interpretation you can put onto it. It's not clear just what
we need for "Descriptive" markup (Now that _is_ an interesting
question) but we're somewhere between 3 and 6 technology innovations
and protocol layers beyond plain-old XML to get near it.

XML not only re-introduces the concept of separation of content from presentation
(as was the original principle of the World Wide Web),

Whilst this "separation" is indeed an original principle, "separation"
in those days meant rigid styling under the control of the user agent,
certainly not anything supplied by the publisher or per-document! This
is a valid statement, but its truthful interpretation contradicts the
OP's point, rather than supporting it.

The tags used in HTML are really presentational tags.

Again, this is literally true, but the underlying principle
contradicts the argument. <font> is in HTML (from legacy), <font> is
presentational, therefore "HTML tags are really presentational" for at
least some tags. However we don't much care about the HTML
recommendation, we're interested in the best practice of using it (or
else get back to W3Schools) and that means we have to be smart enough
not to fall into such sophistry. Many posters to this newsfroup
understand that. Newbies don't but can have it explained to them. The
OP here though seems to know just enough to repeat the words In Sheer
Capitalised Awe but still doesn't understand the meaning behind.
They're sat there drawing angle brackets with their pointy stick and
wondering why the Cargo is so late in coming.

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.

No! A heading is _not_ a purely presentational concept. It has any
number of semantic implications to it, and they're the defining aspect
to its "headingness". It has the ability to be treated as an
abstraction to represent the section (e.g. in a ToC), it has some
scope of content that it applies to (although in HTML this is weak and
just done by element sequence, or maybe overall block inclusion). It
also has sibling headings and can be part of a list context with them
that can show an overall document structure or map. It has some
presentation loosely attached to it too, but the existence of that
coupling doesn't suddenly change its primary purpose.

An XML schema allows more specific tags, such as <concept> and <conbody>, to be used (call it labelling).

XML Schema does no such thing. Well, once again we're back to a
situation that "it does", but it's just not helpful that it does. XML
Schema "allows" the existence of such tags, but it certainly doesn't
go as far as to bind semantics to them. Even RDF Schema doesn't even
do this - it might categorise them as "resources", "properties" or
"literal values", but it goes no further than that much. You don't get
semantics that easily and you don't get communicable machine
inferrable semantics until you're into ontological territory.

No inference about presentation can be drawn from
those tags. So presentation can be truly separated from content.

A logical non sequitur. You haven't _separated_ content and
presentation, you've just negated presentation. I don't know how far
my nearest unicorn is and whether it's "near" or "far" if there simply
aren't any unicorns. _Separation_ of presentation and content requires
both to exist, _and_ for there to be a distance between.

Twas the reason for XHTML

The reason for XHTML was simply to re-state HTML in XML "because it
was there". No more than that. The one thing XHTML (1.0 at least) is
clear that it isn't is any sort of change to "HTML" other than the
bare minimum needed syntactically. If you want to talk about an XML-
based semantically-rich web-platform replacement for XHTML then be my
guest, but it's actually a terrible idea. The genius of HTML 1.0 is
what was left _out_ of it, not what was added to it. Semantically rich
document markup systems were almost commonplace before HTML 1.0 and
they worked better then that most of them do today. Their problem
though was that weren't _worldwide_ and it's more difficult to make
complex, rich, proprietary systems interwork and spread to simple low-
effort user agents than it is to first make something simple that gets
everywhere, then to make this widespread platform smarter.

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.

Sorry, but I had to sit through this twaddle all through 2000 and wear
a suit whilst doing it. If you're going to recycle buzzwords at me
without any understanding of them, or your own original research in
the field, then you have to pay me a salary. I'll happily listen to
crap for money, but if I'm doing it for free on the internerd then I
expect quality and a smarter level of discourse.

On 2009-02-19, Andy Dingley <dingbat (AT) codesmiths (DOT) com> wrote:

On 18 Feb, 18:36, Ben C <spams... (AT) spam (DOT) eggs> wrote:
On 2009-02-18, Andy Dingley <ding... (AT) codesmiths (DOT) com> wrote:

On 18 Feb, 14:59, Gus Richter <gusrich... (AT) netscape (DOT) net> wrote:

The problem is that you have an almost completely erroneous idea of
"presentation", "content" and "semantics" as applied to HTML markup.

Go on then, what are the correct ideas of those things?

Didn't we bash all that out some years ago, such that it's obvious to
anyone who cares? This just isn't an interesting debate any more, and
if someone hasn't bothered to pay attention, it's hardly worth the
effort to correct them any more.

I probably wasn't paying attention. I think dorayme is right: the
meaning of an HTML element is best described in terms of basic
presentation. You can't sensibly abstract it much further than that.

[...]

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

That's a failure to understand _why_ CSS supports generated content,
even though it's working hard to avoid turning into DSSSL. Yet again,
you can't grok this stuff until you've read Haakon Lie's PhD thesis.

As far as I could tell from that his main reason for not wanting CSS to
be "transformational" (i.e. so you can use it to bolt things on to the
DOM tree all over the place) was the idea that that would make
progressive rendering harder.

I don't think it would make it that much harder than it is anyway. Most
pages need a complete reflow at the end, but you can still put up
what you've got in the meantime so the user can start reading the text.

It's just a matter for smarter authors to make sure that if there's any
content worth reading that it's near the top of the markup.

In any case, getting the data and reflowing it are both pretty fast
these days.

Not everyone shares your enlightened and correct conclusion that a few
extra elements here and there to hang styling off is appropriate, which
means they are always proposing new properties for CSS3 to do every
little thing they can think of that you can already do with a couple of
extra DIVs without stopping to think where (or whether) that might end.

Andy Dingley wrote:

On 16 Feb, 18:31, maya <maya778... (AT) yahoo (DOT) com> wrote:

question: float:left and float:right works, I suppose, when you have
just TWO divs that need to appear side-by-side.. BUT: what about when
you have much more, say, SIX little paragraphs that need to appear side
by side???

Float them all leftwards - they'll work it out for themselves.

Floating is usually pretty easy, it's clearing correctly afterwards
that's more awkward. Read brainjar. Accept that you probably will have
to add a HTML element to set the clearing behaviour on - if there
aren't enough HTML elements there you can't invent a few more with
CSS. You maybe can with
:after { content ... } but that's contrived and not really the best
approach. Just accept that adding a simple HTML element (no text
content needed) _is_ acceptable.

oh man, this is SO MUCH HARDER than with tables... what I hate the most
about this is without tables you can't do layout GRID...

I would like to know the best way to create a div-based layout like
this: http://www.francesdelrio.com/resume/test4.html
with only divs...
(this is done w/tables, just to illustrate what I want..)

I have tried examples mentioned in this thread, like for example
http://glish.com/css/7.asp
but as soon as I start modifying the code I get into trouble...

I have ordered a book to help me out
(http://www.amazon.com/HTML-Utopia-Designing-Without-Tables/dp/0975240277/ref=sr_1_1?ie=UTF8&s=books&qid=1235094397&sr=1-1)
I hope it'll help me..

I have heard people say that one reason why so many people prefer
table-less layouts is that divs load faster than tables, but: content
buried four divs deep really loads faster a table? I find that hard to
believe..

thank you...

Andy Dingley wrote:

On 16 Feb, 18:31, maya <maya778... (AT) yahoo (DOT) com> wrote:

question: float:left and float:right works, I suppose, when you have
just TWO divs that need to appear side-by-side.. BUT: what about when
you have much more, say, SIX little paragraphs that need to appear side
by side???

Float them all leftwards - they'll work it out for themselves.

Floating is usually pretty easy, it's clearing correctly afterwards
that's more awkward. Read brainjar. Accept that you probably will have
to add a HTML element to set the clearing behaviour on - if there
aren't enough HTML elements there you can't invent a few more with
CSS. You maybe can with
:after { content ... } but that's contrived and not really the best
approach. Just accept that adding a simple HTML element (no text
content needed) _is_ acceptable.

pls compare how this looks in IE and FF:
http://www.francesdelrio.com/resume/test2.html

it seems FF has a problem with 'float' prop...

again, pls look in FF...
if I take out 'float' prop then the div falls inside the border, but
then of course the divs are no longer side-by-side..
http://www.francesdelrio.com/resume/test3.html

oh brother...

would appreciate suggestions.. thank you very much...