Is there a preferred structure for navigation links?

[nice.guy.nige]

While the city slept, dorayme feverishly typed:

Then you either think wrong, along with Nige, asdf and Adrienne

Why is it wrong to use a simple (and beautifully styled) list to represent
something as basic as a list of links, rather than kludging the whole thing
up in a table, which is not what the table was designed for?

And it is *not* just me, asdf and Adrienne. Thankfully the wider community
appreciates that lists of links are just that - lists, and should be marked
up as such.

or else it is kosher to use tables for 'non-tabular data' as long as it
is not for mere page layout.

But that is the point. You *are* talking about using it for mere page
layout, otherwise why would you want to arrange your menu in a single table
row? Surely for presentation and nothing else.

 

[dorayme]

While the city slept, dorayme feverishly typed:


Why is it wrong to use a simple (and beautifully styled) list to represent
something as basic as a list of links,

When did I say it *was* wrong? What did I say that implies *any* such
thing? It would be scarcely believable to me to hear you say this after
what have said if I did not know that quite often received false ideas
are constantly uttered without proper analysis.

up in a table, which is not what the table was designed for?

You produce no evidence that a table was not designed to cope with a one
row or one col table. Until you produce such an argument, you cannot
hope to make a case.

You also give no argument that what some thing is made for is something
that it *must* be used for. Or that bad consequences are guaranteed for
each individual case or type of case. Not a single thing have you
argued. You give no first principles as to what semantic meaning is
about, you show no consequences, you show no idea of any relationship at
all between lists and tables and yet you feel it is somehow helpful to
pipe up and not even bother to think about the details of what I said,
instead choosing thoroughly false attributions.

And it is *not* just me, asdf and Adrienne.

Once again, you completely fail to see that I said this very same thing
earlier. Perhaps I am being unfair to you and your newsreader is getting
only bits and pieces? Almost everyone is with you. I expect you take
great comfort in that. But give me good arguments instead any day!

Thankfully the wider community
appreciates that lists of links are just that - lists, and should be marked
up as such.

Everyone, including me appreciates that lists of links are just that -
lists! But I do not agree that a list cannot be represented on a web page
by a table. I recommend (I suppose you missed this too) that they
generally be represented by the specialist tool of UL or OL. But I do
not make your mistake of supposing for no good reason that it would be
wrong to use a table for them ever.

But that is the point. You *are* talking about using it for mere page
layout, otherwise why would you want to arrange your menu in a single table
row? Surely for presentation and nothing else.

You have it quite wrong and confused. You are assuming, as is common in
these debates, what is at issue. You are so sure you have the numbers
and are right that you can't even see this.

What is the reason for making a list horizontal rather than vertical if
it is not for page layout? The same considerations apply for choosing a
row rather than a col for the same (ie. a single list) in a table.

In the end - something you can never hope to understand if you don't dig
a little into what semantic meaning is all about and remain content to
follow the crowd and the well known sayings - it comes down to the tool
that will produce the *presentation* (yes, the presentation, the
appearance) that human beings have familiarity and recognition of.

Users can often tell immediately that a list is a list from merely
seeing or hearing it in a context. You seem unable to acknowledge that
these humans do it completely and utterly on the appearances or
presentation alone. But they do! Why? Because they have nothing else to
go on. They do not know the HTML, remember that.

There is no secret knowledge, no hocus pocus. The element delivers the
only thing that it needs to deliver in the causal chain via the browser
and that is appearance, sights, sounds, feels. The human looks and hears
and feels and judges on the basis of these things and these things alone
in a communication. A table will deliver a single list in *some
circumstances* as well, if not better, than a list.

 

[asdf]

When did I say it *was* wrong? What did I say that implies *any* such
thing? It would be scarcely believable to me to hear you say this after
what have said if I did not know that quite often received false ideas
are constantly uttered without proper analysis.

You produce no evidence that a table was not designed to cope with a one
row or one col table. Until you produce such an argument, you cannot
hope to make a case.

You also give no argument that what some thing is made for is something
that it *must* be used for. Or that bad consequences are guaranteed for
each individual case or type of case. Not a single thing have you
argued. You give no first principles as to what semantic meaning is
about, you show no consequences, you show no idea of any relationship at
all between lists and tables and yet you feel it is somehow helpful to
pipe up and not even bother to think about the details of what I said,
instead choosing thoroughly false attributions.


Once again, you completely fail to see that I said this very same thing
earlier. Perhaps I am being unfair to you and your newsreader is getting
only bits and pieces? Almost everyone is with you. I expect you take
great comfort in that. But give me good arguments instead any day!


Everyone, including me appreciates that lists of links are just that -
lists! But I do not agree that a list cannot be represented on a web page
by a table. I recommend (I suppose you missed this too) that they
generally be represented by the specialist tool of UL or OL. But I do
not make your mistake of supposing for no good reason that it would be
wrong to use a table for them ever.


You have it quite wrong and confused. You are assuming, as is common in
these debates, what is at issue. You are so sure you have the numbers
and are right that you can't even see this.

What is the reason for making a list horizontal rather than vertical if
it is not for page layout? The same considerations apply for choosing a
row rather than a col for the same (ie. a single list) in a table.

Can I take this one, Nige?

The reason is that the styling (in your example 'horizontal') is entirely
separate from the underlying code, which is what we should ALL be doing...
separating content from presentational markup. By using a table to achieve
this, you effectively inextricably link the structure to what is contained
within it. The menu *cannot* be restyled or re-oriented for different
devices like PDAs, mobile phones, screen readers, and even print with an
appropriate stylesheet. (Well, actually, you probably could reorient table
rows and cols using CSS, but the question then would be 'why on earth would
you do that?'. That would be confusing in the extreme to make rows look like
columns and vice-versa) In effect, the structural markup of the table almost
*becomes* the content if you use them for presentational effects, which must
surely be less-than-optimal practice. Sure, it'll probably validate ok, but
lists are a demonstrably more elegant solution for the above reasons
(amongst others).

In the end - something you can never hope to understand if you don't dig
a little into what semantic meaning is all about and remain content to
follow the crowd and the well known sayings - it comes down to the tool
that will produce the *presentation* (yes, the presentation, the
appearance) that human beings have familiarity and recognition of.

Yes, yes... but if you don't understand WHY it's important to seperate
presentation from actual content, you'll be spending the rest of your life
reworking the presentation of pages that could have been easily (in the best
scenario, of course), simply restyled with CSS only.

Users can often tell immediately that a list is a list from merely
seeing or hearing it in a context. You seem unable to acknowledge that
these humans do it completely and utterly on the appearances or
presentation alone. But they do! Why? Because they have nothing else to
go on. They do not know the HTML, remember that.

....until you want to restyle or re-orient the list, of course.

There is no secret knowledge, no hocus pocus. The element delivers the
only thing that it needs to deliver in the causal chain via the browser
and that is appearance, sights, sounds, feels. The human looks and hears
and feels and judges on the basis of these things and these things alone
in a communication. A table will deliver a single list in *some
circumstances* as well, if not better, than a list.

Which circumstances? In an ideal world with perfect browsers, a UL or OL
would deliver a list in ALL circumstances however you want it to look.

 

[Jonathan N. Little]

The reason is that the styling (in your example 'horizontal') is entirely
separate from the underlying code, which is what we should ALL be doing...
separating content from presentational markup. By using a table to achieve
this, you effectively inextricably link the structure to what is contained
within it. The menu *cannot* be restyled or re-oriented for different
devices like PDAs, mobile phones, screen readers, and even print with an
appropriate stylesheet. (Well, actually, you probably could reorient table
rows and cols using CSS, but the question then would be 'why on earth would
you do that?'. That would be confusing in the extreme to make rows look like
columns and vice-versa) In effect, the structural markup of the table almost
*becomes* the content if you use them for presentational effects, which must
surely be less-than-optimal practice. Sure, it'll probably validate ok, but
lists are a demonstrably more elegant solution for the above reasons
(amongst others).

This is probably the best point and explanation of the trouble of using
tables to solve your presentation problems. If you are using a table
just to make your list horizontal then that is "presentation". Whether
on not a *list* of links is vertical or horizontal has *no* relevance to
its content. If the content runs beyond the right side of the viewport
and the device does not support horizontal scrolling...well that is like
receiving a book that chop vertically in half where half of the words
went with the margin! You are ignoring the "device independent" aspect
of the web. Just that this fact has been unrealized or ignored in the
past does not justify its continued practice.

 

[Awful Dog Autry]

Then you either think wrong, along with Nige, asdf and Adrienne or
else it is kosher to use tables for 'non-tabular data' as long as it
is not for mere page layout.

What else is html for but layout? Forget it, though. This is an
incessant argument which will not be resolved one way or the other to
most opponents' satisfaction, and if the table is valid html, so be it.

 

[Lars Eighner]

What else is html for but layout?

You are kidding, aren't you? Aren't you?

 

[Joy Beeson]

What else is html for but layout?

What did you intend to say where this sentence has "html"?

 

[dorayme]

Well, according to the orthodoxy, that _is_ for page layout which is why
you do it by changing only the CSS (e.g. floating the list items or
making them inline, but leaving the HTML alone).


And in that case you are changing the HTML for "presentational" reasons
which is what makes people uneasy.

Yes, indeed, I hear this clearly and have for some time, notwithstanding
the impression that some people get. But I have a plan to make people
less uneasy.

The difficulty is how to get the various 'first principle' ideas in this
business to be understood. In usenet posts, it is not easy because it
needs *many things* to be said and who is going to listen? And they tend
to be said at different times and in different contexts. To get out of
this difficulty and raise the level of coherent presentation I am some
way into a few pages on the matter which I will stick on a server soon.

However, you might be interested in a snippet of how I present the
differences in how people can see the content/style separation.

1. There is the presentation that belongs to the element intrinsically
as part of its semanticity

2. There is the presentation that authors are free to impose.

The content/style separation practice that I am a fan of is the
separation of intrinsic (semantic) presentation from extrinsic
presentation (job for the author CSS).

Paragraphs are dead simple. As long as there is any member of the set of
a small range of vertical spaces or suitable pauses between the blocks
of contiguous or continuous sentences, humans see them as paragraphs.
This styling is *intrinsic*. The width, the colour, the background, the
relation to pictures, other divisions containing menus is *extrinsic*.

Headings are recognised by being a bit bigger or bolder or louder and/or
at least standing alone. If the styles for these basic features are
absent, there is no semantic content to separate out from anything. Try
reading my article on the drug laws at:

<http://dorayme.netweaver.com.au/drugLaws_sans_dpr.html>

which should be 100% html kosher. Great content (as distinct from
style)? Not! Or should I say, pity it is almost complete gibberish?

This is the fantasy of those that think there is something practically
left over from the presentation - worthy content. I expect that they
will complain that I have deliberately sabotaged the article's
presentation or is it the content I have sabotaged? In that case,
perhaps they might like to explain how I could have turned off all the
default CSS or browser inbuilt coded default styling?

Indeed, the situation is much much worse than I show there. At least the
words follow each other along the lines and the sentences go in a
natural order and there is no funny 'positioning' after classing each
para to jumble things up even more!

It is incredible to me that more people do not see that some basic
presentation is part and parcel of the specialist semantic tools in HTML.

Anyway, to address your remark above more particularly - and this
following is not too easy for me to convey and will be hard to quite
catch on to without some reflection by readers - consider the business
of an HTML table and the conditions under which we would say that
authors are making 'presentational decisions'.

I want to distinguish here two types of presentational decisions that an
author can make about tables. It is hard to see what could be content as
distinct from presentation with a table because a table is so obviously
presentational! What could sensibly be identified as its content? I
think a way can be found by taking very seriously the distinction I made
above between intrinsic and extrinsic.

Let us take a perfectly proper and uncontroversial candidate for the
HTML table: A list of goods as against a list of prices, prices being
able to be matched across rows or across columns.

Well, now hang on a minute! Which is it to be? Is it to be across rows
or across columns? Is the decision to do one rather than another a 'page
layout decision'?

Well, not in the sense that where to put the table on the page is a page
layout decision. Not in the sense of what pretty background colour to
put in alternate cols or rows or the whole table. Not in the sense of
how cool the border styling should be. With me so far?

I say we *can* discern the content. It is the set of presentational
possibilities that allow a human user to discern the relationship
between the list of goods to the list of prices. The set is just one
little ol' thing. The members of this set are more than one but not by
any stretch of the imagination as many as the members of the set that
make up the extrinsic possibilities.

In this way we can home in on some roughly intelligible content. The
main members of such a simple table's content are the vertical and the
horizontal alternative layouts. The horizontal is not a different
content to the vertical under this interpretation. Both are as good as
each other in respect to conveying the information about the lists. With
me so far?

The set of other stylings, pretty pretty, aesthetic positioning etc, are
much greater in members by comparison. One set is the intrinsic styling
set and the other is the extrinsic styling set. On my account the
difference between content and styling for a table is something that can
be accounted for and it explains why it is important to get author
styles out of the table and separate into CSS sheets.

The default styles will take care of the meaning, the content, the
intrinsic presentation. Author CSS is the job of all other
presentational requirements, all the 'beyond the call of duty' ones and
the 'lets get really cool' ones.

Now to come back to the impression that using a table for a list is a
presentational decision, my answer is no, it is not. Because a table is
a way of organising lists. A one row or one col table for an unordered
list is not wrong in itself. Nor is a two col one for an ordered list.
Why? Because there is a content. The content is that intrinsic
presentation. It just so happens that tables have this nature to be able
to do this naturally. Can't be done with one <p> with default styles.
Can be done with ULs and OLs and should be in general because these are
beaut flexible specialist tools whose defaults are human recognisable.

Now when asdf and Nige and others ask tricky questions that make it seem
that if you put a list in the form of a table it is *just* for
presentational reasons, my reaction is: hello! All semantic content is
presentational so you better have another objection, a deeper one. Plus
a table is a device to communicate lists, it is not a paragraph or an
empty thing like a div or a frog or Roger Rabbit.

I have hurried along with the last few paras here, there is a lot more
to be said. But I guess I better stop. I have been meaning to post this
for at least a day!

Nice to know that you are sympathetic with some of my thoughts in this
matter. Naturally, I do not expect agreement with all the above! I'd

 

[dorayme]

This is probably the best point and explanation of the trouble of using
tables to solve your presentation problems. If you are using a table
just to make your list horizontal then that is "presentation".

No competent author would do this *just* for this simple reason. They
can easily make it a horizontal list!

But they might do it because they find difficulty in getting the style
they want with a UL or an OL. First, not everyone is as ingenious as you
are with styles. Take that as a compliment. Second, even you might not
be able to pull off some things that some authors could quite
legitimately want.

Now the main point is that it is not *wrong* to present a list via a
table. It would be to stick it in a paragraph and style spans and
spaces. It would be crazy to style with divs. And it would be because
these elements either have no semantic content or are meant for quite
different content. But a table is absolutely for list items, it gobbles
list items as a natural food and presents them in rows and/or columns.

It is not *wrong* to use a table in any sense beyond it is not generally
advisable because it is not as flexible as specialist list elements. If
an author has a practical reason, Ben mentioned IE, others have
mentioned the difficulty of lining up numbers as nicely as they like in
OLs a few times and there are other pesky problems that authors might
sometimes face. I say let them buy a little inflexibility for the other
benefits.

But you and asdf make it out like it goes right against the practice of
separating content from style. It does not go *right against* this. You
would be exaggerating to say so because a table is a general vehicle for
presenting list content and it is a sheer myth that you can't usefully
have a one col or one row table. The fault is not the style/content
separation so much as using a truck when you can use a ute. There is
some cumbersomeness but it is not the end of the world to reconfigure a
table to vert from horiz.

Whether
on not a *list* of links is vertical or horizontal has *no* relevance to
its content. If the content runs beyond the right side of the viewport
and the device does not support horizontal scrolling...well that is like
receiving a book that chop vertically in half where half of the words
went with the margin! You are ignoring the "device independent" aspect
of the web. Just that this fact has been unrealized or ignored in the
past does not justify its continued practice.

I have ignored no such thing and this is almost a defamation of
character Jonathan. I will talk to my lawyer! You are painting a picture
of an author making an incompetently wide table for too many menu or
other list items. A very modest item list (three or four or five) in a
horiz table is not ignoring the "device independent" aspect of the web.
And a vertical table certainly is not! You should be ashamed to say such
a thing to me. It just goes to prove how jumpy and paranoid you
fundamentalists are! <g>

 

[Mike Silva]

I just wanted to check in again and say that I'm finding this
discussion quite thought-provoking, so thanks for that.

Mike

 

[Awful Dog Autry]

You are kidding, aren't you? Aren't you?

Why? Html may do a few other things like providing form data upon
submission but its primary purpose is to organize and present (id est:
layout) the content offered by the page. Perhaps you are attributing a
more limited meaning to the term "layout".

 

[Lars Eighner]

In our last episode,
<[email protected]>,
the lovely and talented Awful Dog Autry
broadcast on alt.html:

Why? Html may do a few other things like providing form data upon
submission but its primary purpose is to organize and present (id est:
layout) the content offered by the page.

Well, no. The purpose of HTML is to abstract content from layout.

 

[Awful Dog Autry]

Well, no. The purpose of HTML is to abstract content from layout.

Then where does the layout come from in the first place?

 

[Raymond Schmit]

Well, no. The purpose of HTML is to abstract content from layout.

http://www.tizag.com/htmlT/htmllayout.php

prove that layout can be a part of HTML.

 

[dorayme]

prove that layout can be a part of HTML

You prove that it can't be.

 

[Chris F.A. Johnson]

Then where does the layout come from in the first place?

If there's no CSS, then the browser uses its defaults.

 

[asdf]

You prove that it can't be.

The W3C's own website says (ref. http://www.w3.org/MarkUp/ ('What is
HTML')):

"HTML is the lingua franca for publishing hypertext on the World Wide Web.
.... HTML uses tags such as <h1> and </h1> to structure text into headings,
paragraphs, lists, hypertext links etc."

The important word here is *structure*. Structure <> Layout. Layout is - or
rather *should* be - achieved through styling the underlying HTML markup.

The intention of the HTML specification was never to produce a document
layout engine, but to produce a document *structure* engine. The reasoning
behind this was (and still is), that layout should be (and is) controlled at
the client (which it still is). Witness how the same web page (however "well
styled" or marked up) will always have minor differences between different
browsers and operating systems combinations.

Moreover, anybody can choose to tell their browser - the decent ones at
least - to ignore styling elements entirely, or to turn off graphics or
other content, and thus break 'the layout'.

In your previous 'incomprehensible' web page example, that is precisely what
occurred. You *styled* all the elements to *make* them incomprehensible for
whatever reason. When I turned off CSS in my browser, it was prefectly -
although boringly - legible and lucid.

That's the whole point... that layout and style are controlled *at the
client*, and not necessarily by the designer. As designers, all we can do is
to 'give hints' to the browser as to how they should be displayed.

Sure HTML is *necessary* to produce a layout for a web page, and a layout
will not exist without HTML, but you can't have an HTML layout *without*
styling of some form either through CSS or other means. The W3C's (which, of
course is a vast cooperative venture between designers and other interested
parties, and thus representative of the wider web development community)
preferred recommendation is that we should use HTML for structural markup,
and to use CSS to style those structural elements.

The way that table use for layout developed as 'acceptable use' was, that in
the 90s there wasn't much of an alternative. We were forced firstly by lack
of a CSS specification, then lack of browser support for said specification
to use an alternate means to 'lay out' our pages. We've gradually evolved
past that of course, and we now have a method of styling our markup that (an
I reiterate) allows us to stick more closely to the intention of purpose of
HTML, and to return control of layout and presentation style to the browser,
which is how it should be.

You wouldn't say you would use bricks to design a house, in the same way
that you wouldn't use HTML to produce a layout.

 

[dorayme]

In case you are not aware of this, asdf, your news reader does not cut
out my sig. My sig is very important, I do not like to see it used in
vain. <g>

I have been meaning to get back to you from other posts. The delay is
trying to work out how I might convey what I have been thinking without
generating further misunderstandings and resisting the temptation to
score this or that little point. But I guess I better make one or two
points here. I like your persistence and it would be rude to delay
further.

The W3C's own website says (ref. http://www.w3.org/MarkUp/ ('What is
HTML')):

"HTML is the lingua franca for publishing hypertext on the World Wide Web.
... HTML uses tags such as <h1> and </h1> to structure text into headings,
paragraphs, lists, hypertext links etc."

The important word here is *structure*. Structure <> Layout. Layout is - or
rather *should* be - achieved through styling the underlying HTML markup.

The intention of the HTML specification was never to produce a document
layout engine, but to produce a document *structure* engine.

That is fine by me. I have never denied it. All I am insisting on is
that we should distinguish between the presentation that is intrinsic to
a semantic element and that which is not. I did my best to quickly
explain this in my post replying to Ben. I will try to improve on that
when I have time.

What I find a little frustrating is that you and others seem unaware of
this intrinsic presentation. For me (and maybe others similarly
inclined), there is no getting away from this intrinsic presentation
when talking about semantics for humans in the real world.

Don't misunderstand this, I can give a few abstract meanings to the idea
of a semantic meaning of an HTML element that is quite distinct from any
presentational feature whatsoever. But that is like imagining lots of
totally useless abstract things like smiles without faces (Lewis Carroll
books and films cheat, they show the mouth! I don't cheat this way. My
brain is full of crazy uselessly pure things like this.)

The reasoning
behind this was (and still is), that layout should be (and is) controlled at
the client (which it still is). Witness how the same web page (however "well
styled" or marked up) will always have minor differences between different
browsers and operating systems combinations.

Moreover, anybody can choose to tell their browser - the decent ones at
least - to ignore styling elements entirely, or to turn off graphics or
other content, and thus break 'the layout'.

In your previous 'incomprehensible' web page example, that is precisely what
occurred. You *styled* all the elements to *make* them incomprehensible for
whatever reason. When I turned off CSS in my browser, it was prefectly -
although boringly - legible and lucid.

That is because you did not turn off CSS in your browser. You just
managed to turn mine off. You are seeing the default CSS. My lame
attempt at the impossible was what you saw. You see, your browser would
have no clue how to do this. God Himself could not do it. It is
logically impossible to turn *all* styles off.

Your browser relied on top margins, it relied on default display modes
for the P element. How can I get it across to you that some of these
things are inextricably bound up with the very meaning of what a
paragraph is. If you remove some of what I call intrinsic appearance,
you suck all the human DPR out too.

You don't know about DPR?

When a person sees a heading or paragraph and recognises it *as a
paragraph*, or *as a heading*, never mind the meaning of the words or
sentences, we need a name for this process or act of recognition. Let us
call it "Parts of document recognition", or better sounding, "document
part recognition" - you know, on the model of "Parts of speech" being
the basic types of words that English has.

I will use "DPR" for this. I will not explain why human DPR is
important, I assume we all know. Simply, it is very important for a
human reader to recognise that a group of contiguous sentences is
intended as a whole thought (paragraph!) or that a piece of text is a
heading description (heading!). When human users can know this, we can
say that the HTML is DPR kosher. When a human user sees or hears a
webpage and can recognise quickly what the headings are and what the
paragraphs are, we can say that the user has successfully had DPR in
respect at least to these two elements. We can say the doc is DPR good,
we can say the author is conscious of his DPR obligations.

I have not fully worked out the grammar of this. Gimme a break, I just
invented the term! <g>

DPR is pretty well the whole show where mark up elements are concerned.
The whole point of an author using the right element for a job (eg. a
table for a list ... ok I am teasing you here a little) is to induce DPR
in humans. If they do not use a P for a paragraph, they are going to go
around the mulberry bush to induce DPR and then their efforts will be
wasted if the audience says bugger the author's CSS and uses defaults.
The defaults are geared to stop all DPR being killed. And that to me is
pretty well the same thing as it ensuring that the built in semantics of
the element are not lost.

asdf, there is no spooky semantics or meaning or tightly hidden in the
contenthood at the essential heart of HTML elements. It is not like
that! It is all on show, it is all about function, causes, a
co-operative communication machinery, authors, docs, browsers, human
audiences. The real world coinage is not some abstract or spooky DPR
magic elixir sprinkled on elements at birth.

It is all about the transmission of dumb appearances!

 

[dorayme]

Why? Html may do a few other things like providing form data upon
submission but its primary purpose is to organize and present (id est:
layout) the content offered by the page.

Well, no. The purpose of HTML is to abstract content from layout.[/QUOTE]

"The purpose of HTML is to abstract content from layout"

Interesting sentence. But like any sentence, for it to be useful, we
need to know what it means. From where I sit, I *can* imagine it as
true, false, neither true nor false. Mainly it sounds like something
that has something or other exactly backwards. But never mind. No one
has to rely on pithy little saying for understanding when there are so
many other long-winded ways to say useful things. <g>

 

[dorayme]

I don't really disagree with any of it. I think the distinction between
"extrinsic" and "intrinsic" may not always be an exact one. It's a bit
like discussions about the difference between design and engineering,
form and function etc...

The essential point is that we're talking about adding further
decoration to objects that are already presentational. The easy division
into "semantics" and "presentation" that everyone would like comes only
at the cost of imaginary chimeras like "the abstract paragraph" and "the
abstract table". But there are no such things.

It's OK to use invented concepts in an argument but not imagined ones.
Someone who wants to argue for the pure separation of content and
presentation therefore has to explain what an abstract table is supposed
to be, which I've never seen done without a lot of floundering that
quickly loses relevance.

Although you're the one writing more words on the subject, your view of
things is really the more economical one.

I am using my debating partners to try to eventually reduce the torrent
of words I need to get the ideas across and also to explain things to
myself better. Please do not tell them of this selfish aim or they will
stop talking to me and then my task will be more boring. <g>