CSS and plain text

[Michael Bulatovich]

Is there a way to use CSS to format "plain" text in an html document. By
plain I mean text which is not contained by <por <h#tags.

Is there no way to control how this stuff is rendered?

tia

[Beauregard T. Shagnasty]

Michael Bulatovich wrote:

Is there a way to use CSS to format "plain" text in an html document. By
plain I mean text which is not contained by <por <h#tags.

If you are using a Strict DOCTYPE, there should be no text outside of ..
some .. element. Transitional will let you get away with it, but it is
poor practice to do so. You lose semantic meaning if you do that.

Is there no way to control how this stuff is rendered?

If you describe the circumstance, some advice could be given. Such as
"put it in a <div..." Got a sample page?

--
-bts
-Motorcycles defy gravity; cars just suck.

[Andy Dingley]

Michael Bulatovich wrote:

Is there a way to use CSS to format "plain" text in an html document.

CSS can format it, but it'll all be formatted the same. The scope of
CSS is selected (by and large) at the boundaries of these elements.

Is there no way to control how this stuff is rendered?

Look into using the <spanelement, or read any tutorial on CSS

[Brendan Gillatt]

Michael Bulatovich wrote:

Is there a way to use CSS to format "plain" text in an html document. By
plain I mean text which is not contained by <por <h#tags.

Is there no way to control how this stuff is rendered?

I mostly use the body element to change page wide things for text as all
your text should definitely be in there!

[Jukka K. Korpela]

Beauregard T. Shagnasty <a.*********@example.invalidscripsit:

If you are using a Strict DOCTYPE, there should be no text outside of
.. some .. element.

Even if you use a Transitional DOCTYPE, there is no content text outside of
some element, since everything is at least inside the <bodyelement. (Some
early CSS implementations failed to apply style sheet rules to that element
when the _tag_ <bodywas missing, but this was definitely an error - the
element is there even if the tags aren't - and shouldn't be a problem these
days, and never was if you use explicit <bodyand </bodytags.)

--
Jukka K. Korpela ("Yucca")
http://www.cs.tut.fi/~jkorpela/

[David Dorward]

Michael Bulatovich wrote:

Is there a way to use CSS to format "plain" text in an html document. By
plain I mean text which is not contained by <por <h#tags.

In an HTML document all text has to be contained by /some/ element. Apply
the style to that element.
--
David Dorward <http://blog.dorward.me.uk/ <http://dorward.me.uk/>
Home is where the ~/.bashrc is

[Beauregard T. Shagnasty]

Jukka K. Korpela wrote:

Beauregard T. Shagnasty <a.*********@example.invalidscripsit:

>If you are using a Strict DOCTYPE, there should be no text outside of
.. some .. element.

Even if you use a Transitional DOCTYPE, there is no content text
outside of some element, since everything is at least inside the
<bodyelement.

Of course. But you knew that, and so do I.

--
-bts
-Motorcycles defy gravity; cars just suck.

[Patrick Sullivan]

Andy is right, look at <span>, it's the inline method to contain styling.

--

Patrick Sullivan, AA-BA, BA-IT

"Michael Bulatovich" <Pl****@dont.trywrote in message
news:ed********@news2.newsguy.com...

Is there a way to use CSS to format "plain" text in an html document. By
plain I mean text which is not contained by <por <h#tags.

Is there no way to control how this stuff is rendered?

tia

[Jukka K. Korpela]

Spartanicus <in*****@invalid.invalidscripsit:

>If you describe the circumstance, some advice could be given. Such as
"put it in a <div..."

But "some .. element" should be "some semantic element", that excludes
<div>.

Should it? Even under the circumstances that HTML has a rather limited
repertoire of semantic elements? Quite often, the choice is between a
non-semantic element (<divor <span>) and a semantically _wrong_ element,
such as abusing <pfor something that ain't no paragraph.

From the CSS viewpoint, using semantically wrong elements has the practical
drawback that they may come with default property values that have been
designed with the correct semantics in mind. If you use <pfor
representing, say, a short copyright notice (<p>&copy; 2006 John Doe</p>),
you have to worry about the default top and bottom margin, or perhaps
default padding. Using <div>, you can pretty safely expect no default
rendering specialties: the <divelement is rendered as a block, normally
with no margins or padding. (The HTML specifications even say this
relatively clearly, though not explicitly in CSS terms.) So you can just
start _adding_ the styling you wish.

--
Jukka K. Korpela ("Yucca")
http://www.cs.tut.fi/~jkorpela/

[Spartanicus]

"Jukka K. Korpela" <jk******@cs.tut.fiwrote:

>>If you describe the circumstance, some advice could be given. Such as
"put it in a <div..."

But "some .. element" should be "some semantic element", that excludes
<div>.

Should it?

Always, if the content as per the OP is text (or an element who's non
replaced content is text).

>Even under the circumstances that HTML has a rather limited
repertoire of semantic elements? Quite often, the choice is between a
non-semantic element (<divor <span>) and a semantically _wrong_ element,
such as abusing <pfor something that ain't no paragraph.

From the CSS viewpoint, using semantically wrong elements has the practical
drawback that they may come with default property values that have been
designed with the correct semantics in mind. If you use <pfor
representing, say, a short copyright notice (<p>&copy; 2006 John Doe</p>),
you have to worry about the default top and bottom margin, or perhaps
default padding. Using <div>, you can pretty safely expect no default
rendering specialties: the <divelement is rendered as a block, normally
with no margins or padding. (The HTML specifications even say this
relatively clearly, though not explicitly in CSS terms.) So you can just
start _adding_ the styling you wish.

For a copyright notice, rendering with a top margin is appropriate for
non CSS rendering situations. Renderings other than a visual rendering
should be considered. A paragraph should render with a leading and
trailing pause in the audio domain, this is required here.

If no other suitable markup like <li>, <hxetc. should be used, I've
not yet encountered "loose" text content for which paragraph markup
wasn't appropriate. The dictionary definition of "paragraph" should IMO
not be applied strictly. The semantic distinction between a "real"
paragraph and short text like a copyright notice is IMO not relevant
from any angle. The next function of markup is IMO functionality, for
this paragraph markup is appropriate for all cases of "loose" text that
I've encountered.

--
Spartanicus

[Jukka K. Korpela]

Spartanicus <in*****@invalid.invalidscripsit:

For a copyright notice, rendering with a top margin is appropriate for
non CSS rendering situations.

If you have, say, a collection of miscellaneous notes at the bottom of a
page - the typical context of a copyright notice -, such rendering would
look rather foolish.

Renderings other than a visual rendering
should be considered. A paragraph should render with a leading and
trailing pause in the audio domain, this is required here.

No it isn't. Who wants such pauses between various fairly irrelevant final
notes?

If no other suitable markup like <li>, <hxetc. should be used, I've
not yet encountered "loose" text content for which paragraph markup
wasn't appropriate.

That's just because you _don't_ use paragraph markup semantically.

The dictionary definition of "paragraph" should
IMO not be applied strictly.

That's the common poor excuse that people present when they use markup (or
terms or whatever) so loosely that they have no real meaning any more. What
you are saying is that you do not care about what "paragraph" means in
normal English, which is what the semantic definition of <pin HTML
specifications refers to. You just try to obscure this by throwing in
dictionaries and "strictness". That's like saying that we do not apply
strictly the dictionary definition of "black" but use the word liberally and
progressively (so that it includes white if convenient).

The semantic distinction between a "real"
paragraph and short text like a copyright notice is IMO not relevant
from any angle.

Now that's a yet another attempt at confusing things, and if you really
believed in what you previously wrote (effectively saying that a short
copyright notice _is_ a paragraph), you would not have resorted to that lame
excuse. You are now saying that a semantic distinction is "not relevant from
any angle", so why do you say that we should use semantic markup for
everything?

You have just turned <pinto <divin disguise - into a general block
element. You just lost the semantics included into the use of <pas per the
specifications. If you want the _best_ excuse for that, it's this: "p" is
two characters shorter than "div".

--
Jukka K. Korpela ("Yucca")
http://www.cs.tut.fi/~jkorpela/

[Beauregard T. Shagnasty]

Spartanicus wrote:

"Beauregard T. Shagnasty" <a.*********@example.invalidwrote:

>>Is there a way to use CSS to format "plain" text in an html
document. By plain I mean text which is not contained by <por
<h#tags.

If you are using a Strict DOCTYPE, there should be no text outside
of .. some .. element. Transitional will let you get away with it,
but it is poor practice to do so. You lose semantic meaning if you
do that.

Indeed.

>If you describe the circumstance, some advice could be given. Such as
"put it in a <div..."

But "some .. element" should be "some semantic element", that
excludes <div>.

You and Jukka have covered all the bases. I said what I said (note that
I did mention semantics), because we at this point don't know what the
OP's "plain text" really is. It may itself have no semantic meaning, and
may just be some sort of "decoration."

--
-bts
-Motorcycles defy gravity; cars just suck.

[Spartanicus]

"Jukka K. Korpela" <jk******@cs.tut.fiwrote:

>For a copyright notice, rendering with a top margin is appropriate for
non CSS rendering situations.

If you have, say, a collection of miscellaneous notes at the bottom of a
page - the typical context of a copyright notice -, such rendering would
look rather foolish.

I'm having difficulty imagining what content and structure you are
alluding to, please provide an example.

I consider the following to be best practice markup, with an appropriate
example styling:
http://homepage.ntlworld.ie/spartani..._structure.htm

If not itself marked up as a paragraph, the copyright text could render
flush to the preceding paragraph (depending on the styling defaults of a
visual client), with the possibility that the line break may be obscured
resulting in no way to distinguish it from the preceding paragraph,
demo: http://homepage.ntlworld.ie/spartani..._copyright.png

Using paragraph markup for the copyright text should ensure that it will
always be rendered distinct from preceding semantically marked up
content (excluding daft browser defaults or things like daft user CSS).

Btw, the screenshot is from a reputable client with unmodified default
rendering.

>If no other suitable markup like <li>, <hxetc. should be used, I've
not yet encountered "loose" text content for which paragraph markup
wasn't appropriate.

That's just because you _don't_ use paragraph markup semantically.

Correct, I use markup functionally since there is no benefit in making a
semantic distinction between short text and a paragraph, even if we had
a semantic element for structural short text.

Ideally markup should accurately reflect the content, but since we have
quite limited options within the confines of HTML4, and because there is
no benefit from distinguishing between structural short text and a
paragraph I look at what purposes markup should provide other than to
reflect the semantics. Paragraph markup provides structure, and unlike
the semantic distinction between a paragraph and short text, this
structure provides for an actual need.

The idea that paragraph markup should not be used for short texts
assumes that a clear distinction can be made between the two, this is
obviously not the case, and therefore alone not a viable position.

--
Spartanicus

[Michael Bulatovich]

Thanks Mr. Shagnasty, Jukka, and others. I think you've covered it.

The text to which I referred could be within <bodytags, but not otherwise
contained by what I would recognize as typical selectors for text (h#, p,
blockquote, etc.) If I understand correctly, it sounds like this sort of
thing could be influenced by using the body as selector.
"Beauregard T. Shagnasty" <a.*********@example.invalidwrote in message
news:RY*******************@bgtnsc04-news.ops.worldnet.att.net...

Spartanicus wrote:

>"Beauregard T. Shagnasty" <a.*********@example.invalidwrote:

>>>Is there a way to use CSS to format "plain" text in an html
document. By plain I mean text which is not contained by <por
<h#tags.

If you are using a Strict DOCTYPE, there should be no text outside
of .. some .. element. Transitional will let you get away with it,
but it is poor practice to do so. You lose semantic meaning if you
do that.

Indeed.

>>If you describe the circumstance, some advice could be given. Such as
"put it in a <div..."

But "some .. element" should be "some semantic element", that
excludes <div>.

You and Jukka have covered all the bases. I said what I said (note that
I did mention semantics), because we at this point don't know what the
OP's "plain text" really is. It may itself have no semantic meaning, and
may just be some sort of "decoration."

--
-bts
-Motorcycles defy gravity; cars just suck.

[Jón Fairbairn]

"Michael Bulatovich" <Pl****@dont.trywrites:

Thanks Mr. Shagnasty, Jukka, and others. I think you've covered it.

The text to which I referred could be within <bodytags, but not otherwise
contained by what I would recognize as typical selectors for text (h#, p,
blockquote, etc.) If I understand correctly, it sounds like this sort of
thing could be influenced by using the body as selector.

But what /is/ it? I'm finding it hard to come to terms with
the idea of text that belongs to no semantic category.

--
Jón Fairbairn Jo***********@cl.cam.ac.uk

[Jukka K. Korpela]

Spartanicus <in*****@invalid.invalidscripsit:

>If you have, say, a collection of miscellaneous notes at the bottom
of a page - the typical context of a copyright notice -, such
rendering would look rather foolish.

I'm having difficulty imagining what content and structure you are
alluding to, please provide an example.

A typical example would be http://www.canon.com which has the short
copyright notice as the last item on the page, right after a horizontal
line. There's little reason for any substantial margin before it.

If not itself marked up as a paragraph, the copyright text could
render flush to the preceding paragraph

No it wouldn't, since paragraphs have by default both a top margin and a
bottom margin, in popular browsers.

>That's just because you _don't_ use paragraph markup semantically.

Correct, I use markup functionally

Originally, you said that we should use semantic markup for everything. Now
you are saying that you don't do that yourself. Actually you have now
admitted that you advocate the use of semantic markup (i.e., markup that has
defined semantics) _against_ its defined semantics.

Using markup "functionally" is a new phrase, but it seems to mean the same
as the old procedural markup.

The idea that paragraph markup should not be used for short texts
assumes that a clear distinction can be made between the two,

No it doesn't. It just assumes that you know what a paragraph is and care
about semantic markup. Similarly, there might not always be a rigorous
border between a heading and a short intermittent text. Yet you shouldn't
use heading markup just to get larger or smaller (!) font or bolding or
margins. You are supposed to use logical, semantic markup as far as possible
and to use CSS to suggest rendering features, as desired, both for semantic
and non-semantic elements.

If you wish to use procedural markup, nobody can prevent you, but it is
intellectually dishonest to blow horns and represent yourself as a defender
of semantic markup.

--
Jukka K. Korpela ("Yucca")
http://www.cs.tut.fi/~jkorpela/

[Gus Richter]

Jón Fairbairn wrote:

"Michael Bulatovich" <Pl****@dont.trywrites:

>Thanks Mr. Shagnasty, Jukka, and others. I think you've covered it.

The text to which I referred could be within <bodytags, but not otherwise
contained by what I would recognize as typical selectors for text (h#, p,
blockquote, etc.) If I understand correctly, it sounds like this sort of
thing could be influenced by using the body as selector.

But what /is/ it? I'm finding it hard to come to terms with
the idea of text that belongs to no semantic category.

Anonymous Text / Anonymous Box

<http://www.w3.org/TR/CSS21/visuren.html#anonymous-block-level>

--
Gus

[Spartanicus]

"Jukka K. Korpela" <jk******@cs.tut.fiwrote:

>>If you have, say, a collection of miscellaneous notes at the bottom
of a page - the typical context of a copyright notice -, such
rendering would look rather foolish.

I'm having difficulty imagining what content and structure you are
alluding to, please provide an example.

A typical example would be http://www.canon.com which has the short
copyright notice as the last item on the page, right after a horizontal
line. There's little reason for any substantial margin before it.

I see nothing there that resembles what you wrote. I thought we were
discussing rendering sans CSS, I fail to see how a reference to a page
that uses a CSS generated coloured block with a bottom border to
distinguish it from the copyright line is relevant to that discussion.

>If not itself marked up as a paragraph, the copyright text could
render flush to the preceding paragraph

No it wouldn't, since paragraphs have by default both a top margin and a
bottom margin, in popular browsers.

In at least one browser its different, and there is nothing wrong with
it's default rendering.

It is always a bad idea to rely on the (in this case only possible)
properties of an adjacent element to create functionality that should be
provided by the content's own markup.

>>That's just because you _don't_ use paragraph markup semantically.

Correct, I use markup functionally

Originally, you said that we should use semantic markup for everything. Now
you are saying that you don't do that yourself.

I advocate always using semantic markup elements to mark up text and my
choice of what element to use is governed by real world functionality
rather than using elements that provide no functionality such as div and
span.

>Actually you have now
admitted that you advocate the use of semantic markup (i.e., markup that has
defined semantics) _against_ its defined semantics.

Indeed. Loading a language with various elements to markup slightly
different forms of text is only justified if it can be argued that there
is a functional need for using different text markup elements. No such
case can be made for short text and paragraphs, which is why I consider
the <pelement as a generic markup element for text (providing that no
other better suited existing element should be used, <li>, <hxetc.).

A dogmatic insistence on using the <pelement only for paragraphs
whilst advocating that text which doesn't classify as a paragraph should
be marked up with a non structural and non semantic element like <div>
despite the obvious loss of functionality makes no sense. Using
paragraph markup for short text on the other hand has no drawbacks other
than that it seems to irritate your sense of semantic purity.

Markup is there to provide a function, it's not a dogma that should be
strictly adhered to when the function markup is meant to provide is
lost.

>Using markup "functionally" is a new phrase, but it seems to mean the same
as the old procedural markup.

I'm not familiar with the phrase "procedural markup". Listed in my
dictionary definition is "to advance to a higher degree (as in proceed
MA) or more developed state", which describes what functional markup can
achieve over strict semantic markup quite nicely IMO.

>The idea that paragraph markup should not be used for short texts
assumes that a clear distinction can be made between the two,

No it doesn't. It just assumes that you know what a paragraph is

The resources that I have seen on the definition of what constitutes a
paragraph are all fairly vague, I have found no justification for what I
think is your definition of what constitutes a paragraph.

>and care about semantic markup.

Only if it serves a purpose, not merely for the sake of it. Your
objection is dogmatic with no case being made for the harm done by what
I advocate, whilst being blind to the harm done by using <div>s.

>Similarly, there might not always be a rigorous
border between a heading and a short intermittent text.

I'm again struggling to picture what you mean by that, example please.

--
Spartanicus

[Jukka K. Korpela]

Spartanicus <in*****@invalid.invalidscripsit:

"Jukka K. Korpela" <jk******@cs.tut.fiwrote:

>>>If you have, say, a collection of miscellaneous notes at the bottom
of a page - the typical context of a copyright notice -, such
rendering would look rather foolish.

I'm having difficulty imagining what content and structure you are
alluding to, please provide an example.

A typical example would be http://www.canon.com which has the short
copyright notice as the last item on the page, right after a
horizontal line. There's little reason for any substantial margin
before it.

I see nothing there that resembles what you wrote. I thought we were
discussing rendering sans CSS,

No, you asked about content and structure. The essential point is that a
copyright notice typically appears alone at the end of a page, often
preceded by a horizontal rule that acts as a divider. If you don't want to
count on CSS in producing the rule, you can use <hr>.

It is always a bad idea to rely on the (in this case only possible)
properties of an adjacent element to create functionality that should
be provided by the content's own markup.

Functionality? You mean rendering, right? And adjacent vertical margins are
not a casual phenomenon in CSS: they are _supposed to_ be considered
together.

I advocate always using semantic markup elements to mark up text

Apparently that means "semantics" that consists of what you think about
rendering:

and my choice of what element to use is governed by real world
functionality rather than using elements that provide no
functionality such as div and span.

>Actually you have now
admitted that you advocate the use of semantic markup (i.e., markup
that has defined semantics) _against_ its defined semantics.

Indeed.

OK, I guess we can stop here. You simply use the word "semantic" in a
private meaning that differs from its meaning in normal English - in a
rather striking way. Your "semantic" markup looks suspiciously like
procedural markup.

I'm not familiar with the phrase "procedural markup".

Try reading the SGML Handbook. :-)

--
Jukka K. Korpela ("Yucca")
http://www.cs.tut.fi/~jkorpela/

[Jón Fairbairn]

Gus Richter <gu********@netscape.netwrites:

Jón Fairbairn wrote:

"Michael Bulatovich" <Pl****@dont.trywrites:

Thanks Mr. Shagnasty, Jukka, and others. I think you've covered it.

The text to which I referred could be within <bodytags,
but not otherwise contained by what I would recognize as
typical selectors for text (h#, p, blockquote, etc.) If I
understand correctly, it sounds like this sort of thing
could be influenced by using the body as selector.

But what /is/ it? I'm finding it hard to come to terms with
the idea of text that belongs to no semantic category.

Anonymous Text / Anonymous Box

<http://www.w3.org/TR/CSS21/visuren.html#anonymous-block-level>

Well, that's what it ends up being called for the purposes
of CSS, but what kind of thing /is/ the text?

PETER: I know this English guy who was driving around in
the South. And he stopped for breakfast one morning
somewhere in southeast Georgia. He saw “grits� on the
menu. He’d never heard of grits so he asked the waitress,
“What are grits, anyway?� She said, “Grits are fifty.� He
said, “Yes, but what _are_ they?� She said, “They’re
extra.� He said, “Yes, I’ll have the grits, please.�

-- from “United States�, Laurie Anderson
--
Jón Fairbairn Jo***********@cl.cam.ac.uk
http://www.chaos.org.uk/~jf/Stuff-I-dont-want.html (updated 2006-09-07)

[Gus Richter]

Jón Fairbairn wrote:

Gus Richter <gu********@netscape.netwrites:

>Jón Fairbairn wrote:

>>"Michael Bulatovich" <Pl****@dont.trywrites:

Thanks Mr. Shagnasty, Jukka, and others. I think you've covered it.

The text to which I referred could be within <bodytags,
but not otherwise contained by what I would recognize as
typical selectors for text (h#, p, blockquote, etc.) If I
understand correctly, it sounds like this sort of thing
could be influenced by using the body as selector.
But what /is/ it? I'm finding it hard to come to terms with
the idea of text that belongs to no semantic category.

Anonymous Text / Anonymous Box

<http://www.w3.org/TR/CSS21/visuren.html#anonymous-block-level>

Well, that's what it ends up being called for the purposes
of CSS, but what kind of thing /is/ the text?

This being a CSS NG, the answer was right on, IMHO.

In HTML, it is #PCDATA - "Parsed Character Data" (text and markup).

--
Gus

[Spartanicus]

"Jukka K. Korpela" <jk******@cs.tut.fiwrote:

>I see nothing there that resembles what you wrote. I thought we were
discussing rendering sans CSS,

No, you asked about content and structure.

You claimed in response to:

>For a copyright notice, rendering with a top margin is appropriate for
non CSS rendering situations.

that

>such rendering would look rather foolish.

with a description of the following content and structure that would
demonstrate why:

>a collection of miscellaneous notes at the bottom of a
page - the typical context of a copyright notice

To which the Canon resource you provided has no relevance. Please
provide an example of the content type and structure you alluded to.

>The essential point is that a
copyright notice typically appears alone at the end of a page, often
preceded by a horizontal rule that acts as a divider. If you don't want to
count on CSS in producing the rule, you can use <hr>.

In the following demo:
http://homepage.ntlworld.ie/spartani...structure2.htm
it needs to be made clear that the copyright message applies to the
whole of the page, it can be argued that since it is listed under the
"Notes" level 2 header, structurally the copyright message falls under
that header and may structurally not be seen as applying to the entire
page. It is obvious that the copyright message applies to the whole of
the page in a on screen rendering with CSS enabled, not so in other
rendering scenarios. This is a problem that HTML4 doesn't allow us to
solve properly, that being so, using a <hrelement improves on the
likely on screen sans CSS interpretation. But it only addresses a
symptom in that one domain & circumstance.

The only thing that can reasonably be attributed to a <hrelement is a
certain visual representation, there is no justification from a
semantic, structural or spec point of view for attributing <hrwith
having semantic or structural significance, as a result there is no
justification for expecting a non visual renderer to do anything with
it.

Note also that there is no justification for using a <hrelement for
the original example that I provided:
http://homepage.ntlworld.ie/spartani..._structure.htm
in which there is no ambiguity as to what the copyright message applies
to, hence using a <hrthere would at best be superfluous, at worst it
would create the illusion that the functional problem has been solved by
doing so.

>It is always a bad idea to rely on the (in this case only possible)
properties of an adjacent element to create functionality that should
be provided by the content's own markup.

Functionality? You mean rendering, right?

I meant functionality, which is provided in different forms in different
renderings.

>And adjacent vertical margins are
not a casual phenomenon in CSS: they are _supposed to_ be considered
together.

Again the bottom margin of the preceding element may be null. You seem
to think that you can rely on the preceding element having a bottom
margin equating to the applicable line height. There is no justification
for this, the sample stylesheet provided with CSS 2.0 may suggest that
for example a paragraph has a top and bottom margin, but there is
nothing wrong with a default rendering where semantic block level
elements have a non null top margin and a null bottom margin. This works
fine as long as it is used for all such elements, as demonstrated by at
least one browser.

The same applies to the audio domain, only there instead of visual
spacing it is expressed as a pause.

>I advocate always using semantic markup elements to mark up text

Apparently that means "semantics" that consists of what you think about
rendering:

>and my choice of what element to use is governed by real world
functionality rather than using elements that provide no
functionality such as div and span.

>>Actually you have now
admitted that you advocate the use of semantic markup (i.e., markup
that has defined semantics) _against_ its defined semantics.

Indeed.

OK, I guess we can stop here. You simply use the word "semantic" in a
private meaning that differs from its meaning in normal English - in a
rather striking way. Your "semantic" markup looks suspiciously like
procedural markup.

Throughout this thread I have advocated the use of a semantic element to
mark up text instead of a non semantic element. I find it bizarre how
from that you are trying to make it appear that I am straying from
defined appropriate markup practice.

>I'm not familiar with the phrase "procedural markup".

Try reading the SGML Handbook. :-)

I conclude that the objective of someone who uses language who's
semantics can only be derived from a non publicly available source is to
obscure, rather than to communicate.

I also find it rather telling that you have snipped and not responded to
several of the arguments I put forward.

--
Spartanicus

[Jukka K. Korpela]

Spartanicus <in*****@invalid.invalidscripsit:

You claimed in response to:

>>For a copyright notice, rendering with a top margin is appropriate
for non CSS rendering situations.

that

>such rendering would look rather foolish.

Something like that, yes, though I'm not that interested in opening all the
preceding subtopics, after you have made it clear that you say that
1) people should use semantic markup for everything and
2) you regard markup as semantic if it "functionally" (= presentationally,
in any reasonable interpretation I can imagine) does what you want.
That's a possible approach, and I find it futile to argument against it,
since you seem to have completely lost the semantics of "semantics". How
could I express myself to you using words only if words have quite private
meanings to you?

Throughout this thread I have advocated the use of a semantic element
to mark up text instead of a non semantic element.

You have, and I have explained why semantically wrong semantic markup is
much worse than non-semantic markup. Using <h6>foo bar</h6to make foo bar
appear in smaller font is much worse than <font size="2">foo bar</font>,
even though the <h6markup might "functionally" "work" for the purpose.

I find it bizarre
how from that you are trying to make it appear that I am straying from
defined appropriate markup practice.

You are, because appropriate markup uses semantic elements in their
_defined_ meanings. A <pelement indicates a paragraph of text, not some
arbitrary block.

>>I'm not familiar with the phrase "procedural markup".

Try reading the SGML Handbook. :-)

I conclude that the objective of someone who uses language who's
semantics can only be derived from a non publicly available source is
to obscure, rather than to communicate.

The SGML Handbook has been publicly available for years. Maybe you meant
that it is not available to you free of charge or free of effort? I can
assure that any effort in getting access to the book e.g. through a suitable
library will be outweighed by the effort needed to understand its content.
But anyone who seriously advocates "semantic markup" in public should really
understand the difference between "procedural markup" and "descriptive
markup" as described in the SGML Handbook, in one of its most readable
parts.

ObCSS: Both procedural markup and descriptive markup _may_ have an impact on
rendering in CSS terms. For procedural markup, that would be an _essential_
impact, since procedural markup more or less _means_ controlling the
rendering. For descriptive markup, the connection, if any, is coincidental.
An element like <divis descriptive markup at a rather abstract level,
saying nothing except "this is a block". And that's exactly what is needed -
if I may refer to our Subject - if you wish to apply CSS to a fragment of
plain text that constitutes a block but without any semantic role that would
be _adequately_ described using semantic elements of HTML (i.e., paragraph,
heading, block quotation, or authorship information).

I also find it rather telling that you have snipped and not responded
to several of the arguments I put forward.

Yes, it tells about good Usenet conduct - to quote only the parts you wish
to comment on. So does the fact that in this discussion, which seems to get
somewhat personal at least on your side, I am using my real name and
address.

--
Jukka K. Korpela ("Yucca")
http://www.cs.tut.fi/~jkorpela/

[Andy Dingley]

Spartanicus wrote:

Try reading the SGML Handbook. :-)

I conclude that the objective of someone who uses language who's
semantics can only be derived from a non publicly available source is to
obscure, rather than to communicate.

It's The SGML Way

"If it's worth knowing, it's worth paying big money to a Consultant in
a suit for it."

[Spartanicus]

"Jukka K. Korpela" <jk******@cs.tut.fiwrote:

>You claimed in response to:

>>>For a copyright notice, rendering with a top margin is appropriate
for non CSS rendering situations.

that

>>such rendering would look rather foolish.

Something like that, yes, though I'm not that interested in opening all the
preceding subtopics, after you have made it clear that you say that
1) people should use semantic markup for everything and
2) you regard markup as semantic if it "functionally" (= presentationally,
in any reasonable interpretation I can imagine) does what you want.
That's a possible approach, and I find it futile to argument against it,
since you seem to have completely lost the semantics of "semantics". How
could I express myself to you using words only if words have quite private
meanings to you?

>Throughout this thread I have advocated the use of a semantic element
to mark up text instead of a non semantic element.

You have, and I have explained why semantically wrong semantic markup is
much worse than non-semantic markup. Using <h6>foo bar</h6to make foo bar
appear in smaller font is much worse than <font size="2">foo bar</font>,
even though the <h6markup might "functionally" "work" for the purpose.

It is more than a wild exaggeration to claim that a potential slight
deviation from applying markup semantically (and only by your personal
undisclosed definition of such) amounts to abandoning the principle
completely.

>I find it bizarre
how from that you are trying to make it appear that I am straying from
defined appropriate markup practice.

You are, because appropriate markup uses semantic elements in their
_defined_ meanings. A <pelement indicates a paragraph of text, not some
arbitrary block.

I am finding it increasingly difficult to continue this discussion
because you have not answered several of the points I made before.

a) What is the definition of a paragraph that you are using?
b) Does it align with the body of opinion on what defines a paragraph?
c) If not, why do you think that the definition that you use is correct?
d) What is the use case for using separate markup elements for short
text that is structurally separate from adjacent content and a
paragraph?
e) What is the use case against using paragraph markup for short text?
f) Do you acknowledge the problems I demonstrated caused by using <div>?
g) Do you accept that it is improper to rely on a potential default
styling property of an adjacent element to create a structural
separation?
h) Do you accept that a default rendering where semantic elements have a
non zero top margin and a zero bottom margin is possible, that it works,
and that there is nothing wrong with such a rendering?

>>>I'm not familiar with the phrase "procedural markup".

Try reading the SGML Handbook. :-)

I conclude that the objective of someone who uses language who's
semantics can only be derived from a non publicly available source is
to obscure, rather than to communicate.

The SGML Handbook has been publicly available for years. Maybe you meant
that it is not available to you free of charge or free of effort? I can
assure that any effort in getting access to the book e.g. through a suitable
library will be outweighed by the effort needed to understand its content.
But anyone who seriously advocates "semantic markup" in public should really
understand the difference between "procedural markup" and "descriptive
markup" as described in the SGML Handbook, in one of its most readable
parts.

ObCSS: Both procedural markup and descriptive markup _may_ have an impact on
rendering in CSS terms. For procedural markup, that would be an _essential_
impact, since procedural markup more or less _means_ controlling the
rendering. For descriptive markup, the connection, if any, is coincidental.
An element like <divis descriptive markup at a rather abstract level,
saying nothing except "this is a block".

A <divhas no semantic or structural meaning if used without
attributes. It does not define content to be of type "block", but to be
"block-level" http://www.w3.org/TR/html4/struct/global.html#h-7.5.4
This only refers to which of the two basic HTML *DTD* content models
(block and inline) it belongs to, it should not be taken to have any
relevance to actual content (when used without attributes).

Were it not for the fact that the HTML DTD uses these 2 basic groups of
content models in which these elements must fall we would only have one
"Grouping element", not two (span /and/ div).

The HTML4 spec says: "The DIV and SPAN elements, in conjunction with the
id and class attributes, offer a generic mechanism for adding structure
to documents." http://www.w3.org/TR/html4/struct/global.html#h-7.5.4
But the "structure" in that sentence should only be understood to relate
to the content if such elements are used with attributes for styling or
language flagging purposes. This is supported by the descriptive
comments in the DTD for span and div: "generic language/style container"

>I also find it rather telling that you have snipped and not responded
to several of the arguments I put forward.

Yes, it tells about good Usenet conduct - to quote only the parts you wish
to comment on.

It doesn't help to leave arguments unanswered in a discussion, counter
arguments should be presented, or the point should be conceded. If
points are left unanswered the discussion is in danger of going around
in circles as seems to be happening here with you repeating an argument
that I've responded to before, but you then left those responses
unchallenged.

>So does the fact that in this discussion, which seems to get
somewhat personal at least on your side,

I apologize for accusing you of intending to obscure. I had no way of
knowing for sure that this was your intent, merely that this was the
result.

>I am using my real name and address.

Ad hominem? What does that have to do with what is being discussed?

--
Spartanicus

[Jukka K. Korpela]

Spartanicus <in*****@invalid.invalidscripsit:

>I am using my real name and address.

Ad hominem? What does that have to do with what is being discussed?

Nothing. It is just a matter of civilized conduct. _You_ made personal
attacks against me in public, yet you hide behind a fake name and a fake
address. That's simply disgustingly bad manners and cowardice, _especially_
when you don't change your manners in a situation like this.

You also keep quoting much more than needed to establish what you are
commenting on, and you are apparently _now_ trying to defend the use of <p>
markup for non-paragraphs, _after_ you have clearly made your point about
treating "semantics" as a matter of "functionality", i.e. presentational
(procedural) markup. Under some other circumstances, if you had behaved and
if this were the right group for such discussions, I might have tried to
help you out of corner where you have painted yourself in.

Please continue using the same forged From field as now, until you start
behaving and your postings can be regarded as worth reading. TIA.

--
Jukka K. Korpela ("Yucca")
http://www.cs.tut.fi/~jkorpela/

[Andy Dingley]

Jukka K. Korpela wrote:

yet you hide behind a fake name and a fake address.

Yes, but you claim to be a pot-plant.

Jukka K. Korpela ("Yucca")

[Jón Fairbairn]

Gus Richter <gu********@netscape.netwrites:

Jón Fairbairn wrote:

Gus Richter <gu********@netscape.netwrites:

Jón Fairbairn wrote:
"Michael Bulatovich" <Pl****@dont.trywrites:

Thanks Mr. Shagnasty, Jukka, and others. I think you've covered it.

The text to which I referred could be within <bodytags,
but not otherwise contained by what I would recognize as
typical selectors for text (h#, p, blockquote, etc.) If I
understand correctly, it sounds like this sort of thing
could be influenced by using the body as selector.
But what /is/ it? I'm finding it hard to come to terms with
the idea of text that belongs to no semantic category.
Anonymous Text / Anonymous Box

<http://www.w3.org/TR/CSS21/visuren.html#anonymous-block-level>

Well, that's what it ends up being called for the purposes
of CSS, but what kind of thing /is/ the text?

This being a CSS NG, the answer was right on, IMHO.

In HTML, it is #PCDATA - "Parsed Character Data" (text and markup).

OK, now we've done the whole "what are grits" thing...

What kind of wordage is it in the OP's document doesn't
belong between any of the usual HTML semantic elements? Only
the OP can answer that, though people who understand HTML,
CSS and general literary usage might offer possible cases.

In the case where it's some category for which there is no
semantically suitable HTML, surely the appropriate thing to
do is to put it in a div with class="some mnemonic for
whatever the thing really is" in lieu of a proper piece of
markup?

--
Jón Fairbairn Jo***********@cl.cam.ac.uk

[Spartanicus]

"Jukka K. Korpela" <jk******@cs.tut.fiwrote:

>>I am using my real name and address.

Ad hominem? What does that have to do with what is being discussed?

Nothing. It is just a matter of civilized conduct. _You_ made personal
attacks against me in public, yet you hide behind a fake name and a fake
address. That's simply disgustingly bad manners and cowardice, _especially_
when you don't change your manners in a situation like this.

You also keep quoting much more than needed to establish what you are
commenting on, and you are apparently _now_ trying to defend the use of <p>
markup for non-paragraphs, _after_ you have clearly made your point about
treating "semantics" as a matter of "functionality", i.e. presentational
(procedural) markup. Under some other circumstances, if you had behaved and
if this were the right group for such discussions, I might have tried to
help you out of corner where you have painted yourself in.

Please continue using the same forged From field as now, until you start
behaving and your postings can be regarded as worth reading. TIA.

This reaction at this particular time is certainly one way of avoiding
the awkward questions, but not a worthy one.

O how the mighty has fallen.

--
Spartanicus

[Wes Groleau]

Jón Fairbairn wrote:

What kind of wordage is it in the OP's document doesn't
belong between any of the usual HTML semantic elements? Only

He didn't say it doesn't belong between etc.

He merely said it _isn't_ between etc.

In the case where it's some category for which there is no
semantically suitable HTML, surely the appropriate thing to

I found myself wondering why he doesn't put it in whatever
element it belongs in. (And like you say if there genuinely
isn't one, use div or span)

--
Wes Groleau
Heroes, Heritage, and History
http://freepages.genealogy.rootsweb.com/~wgroleau/