By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
440,262 Members | 1,128 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 440,262 IT Pros & Developers. It's quick & easy.

Why eliminate <br>?

P: n/a
I note in an Eric Meyers book that he expresses one goal of using CSS is
to eliminate all <brtags. Why?
--
Ed Jay (remove 'M' to respond by email)
Aug 2 '06 #1
Share this Question
Share on Google+
56 Replies


P: n/a
Ed Jay <ed***@aes-intl.comwrote:
>I note in an Eric Meyers book that he expresses one goal of using CSS is
to eliminate all <brtags.
If so then he is putting that to strongly.
>Why?
<bris an element with few appropriate uses, it's often abused to
insert blank lines or "pseudo paragraphs" when real paragraph markup
should be used, or spacing when CSS margins should be used, or to get an
element to have a line break before and after for which the element
should be set to "display:block" instead.

But there are a few legitimate uses for using <br>, one example would be
to create a line break inside an <addresselement:

<address>
My name<br>
My address
<address>

--
Spartanicus
Aug 2 '06 #2

P: n/a
Spartanicus scribed:
>Ed Jay <ed***@aes-intl.comwrote:
>>I note in an Eric Meyers book that he expresses one goal of using CSS is
to eliminate all <brtags.

If so then he is putting that to strongly.
>>Why?

<bris an element with few appropriate uses, it's often abused to
insert blank lines or "pseudo paragraphs" when real paragraph markup
should be used, or spacing when CSS margins should be used, or to get an
element to have a line break before and after for which the element
should be set to "display:block" instead.

But there are a few legitimate uses for using <br>, one example would be
to create a line break inside an <addresselement:

<address>
My name<br>
My address
<address>
Thanks.
--
Ed Jay (remove 'M' to respond by email)
Aug 2 '06 #3

P: n/a
Ed Jay <ed***@aes-intl.comscripsit:
I note in an Eric Meyers book
Which book? Please cite by title and page.
that he expresses one goal of using CSS
is to eliminate all <brtags. Why?
Do you mean he does not explain that in the book?

I guess Eric refers to the common abuse of using successive <brtags to
create vertical spacing. That's clumsy, coarse and unreliable, so surely it
should be replaced by the use of CSS.

Besides, even legitimate uses of <brcan often be replaced by other markup,
usually <div>, and this may help in styling.

Eliminating all <brtags sounds like a misconception, though. It's
impossible to say whether it would be Eric's misconception or yours.

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

Aug 2 '06 #4

P: n/a

Ed Jay wrote:
I note in an Eric Meyers book that he expresses one goal of using CSS is
to eliminate all <brtags. Why?
Because Eric Meyer has some very weird ideas about good HTML.

<bris good. It's an inline element, and it's literally there as a
"line break", for when you need this _within_ a block of text.

It's not a paragraph marker, not a delimiter for headers, and
especially not as a chunk of whitespace for spacing things apart. These
are abuses of <brand no-one should defend them, but the fact that
<brregularly gets mis-used doesn't mean that it should be removed.

"one goal of using CSS is to eliminate all mis-used <brtags" might
be a better phrasing.

Aug 2 '06 #5

P: n/a
On Wed, 2 Aug 2006, Jukka K. Korpela wrote:
Eliminating all <brtags sounds like a misconception, though.
Furthermore, <bris the recommended HTML equivalent for the
Unicode character U+2028 "line separator", which itself should
not be used in markup languages.
http://www.unicode.org/reports/tr20/#Suitable

Aug 2 '06 #6

P: n/a
Andy Dingley scribed:
>
Ed Jay wrote:
>I note in an Eric Meyers book that he expresses one goal of using CSS is
to eliminate all <brtags. Why?

Because Eric Meyer has some very weird ideas about good HTML.
This statement sounds rational. Not because I think Eric Meyer has weird
ideas, but I note that as I read newsgroups pertaining to HTML, javascript
and CSS, each camp thinks "their" methodology is the best, and others miss
the mark. Not quite as religiously as Windows versus Linux, but similar.
>
<bris good. It's an inline element, and it's literally there as a
"line break", for when you need this _within_ a block of text.

It's not a paragraph marker, not a delimiter for headers, and
especially not as a chunk of whitespace for spacing things apart. These
are abuses of <brand no-one should defend them, but the fact that
<brregularly gets mis-used doesn't mean that it should be removed.
Understood.
>
"one goal of using CSS is to eliminate all mis-used <brtags" might
be a better phrasing.
Works for me.

My pages are filled with <brtags, and I'm in no hurry to eliminate them
in favor of defining a bunch of new containers. When I read Meyer's
comment, I became concerned that I was going to be forced to rewrite, but
I couldn't understand why. Thanks all for your input.
--
Ed Jay (remove 'M' to respond by email)
Aug 2 '06 #7

P: n/a
Jukka K. Korpela scribed:
>Ed Jay <ed***@aes-intl.comscripsit:
>I note in an Eric Meyers book

Which book? Please cite by title and page.
"Eric Meyer on CC," Page 5, 'Converting the Document,' 'Stripping Down to
the Minimum:' "Things to eliminate include: <brelements (also listed are
&nbsp; entities, font elements, and other stuff.)
>
>that he expresses one goal of using CSS
is to eliminate all <brtags. Why?

Do you mean he does not explain that in the book?
Not that I saw. I must admit, though, that I didn't scrutinize the entire
book. I read the statement and searched the following several pages, but I
saw no further mention of it.
>
I guess Eric refers to the common abuse of using successive <brtags to
create vertical spacing. That's clumsy, coarse and unreliable, so surely it
should be replaced by the use of CSS.
Could be.
>
Besides, even legitimate uses of <brcan often be replaced by other markup,
usually <div>, and this may help in styling.
Which is where I thought was the direction I was going to have to follow.
>
Eliminating all <brtags sounds like a misconception, though. It's
impossible to say whether it would be Eric's misconception or yours.
I'm willing to buy into any explanation that will save me from having to
do a lot of unnecessary markup. :-)

Thanks.
--
Ed Jay (remove 'M' to respond by email)
Aug 2 '06 #8

P: n/a
On Wed, 2 Aug 2006, I wrote:
http://www.unicode.org/reports/tr20/#Suitable
I realize only now:

http://www.unicode.org/reports/tr20/#Suitable
^^^^^^^^^
3 Characters not Suitable for use With Markup
^^^^^^^^^^^^
http://www.unicode.org/reports/tr20/#Format
^^^^^^^
4 Format Characters Suitable for Use with Markup
^^^^^^^^
One should be more careful with the naming of anchors :-(

Aug 2 '06 #9

P: n/a
Andy Dingley <di*****@codesmiths.comscripsit:
<bris good.
Empty elements aren't good in a language that is expected to be a logical
markup language. They are procedural markup in disguise, or just
misdesigned.

We may have reasons to tolerate and use them, but let's not call them good.
It's an inline element, and it's literally there as a
"line break", for when you need this _within_ a block of text.
What does "line break" mean in speech, in Braille rendering, or to a search
engine?

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

Aug 2 '06 #10

P: n/a
On Wed, 02 Aug 2006 08:46:04 -0700, Ed Jay <ed***@aes-intl.comwrote:
>My pages are filled with <brtags, and I'm in no hurry to eliminate them
in favor of defining a bunch of new containers.
URL?

If your pages are "filled" with <br>, it does indeed sound as if they're
being mis-used and shouldbe removed.

....or else you're publishing poetry.
Aug 2 '06 #11

P: n/a
Andy Dingley wrote on 02 aug 2006 in
comp.infosystems.www.authoring.stylesheets:
On Wed, 02 Aug 2006 08:46:04 -0700, Ed Jay <ed***@aes-intl.comwrote:
>>My pages are filled with <brtags, and I'm in no hurry to eliminate them
in favor of defining a bunch of new containers.

URL?

If your pages are "filled" with <br>, it does indeed sound as if they're
being mis-used and shouldbe removed.

...or else you're publishing poetry.
Got my poetic license somewhere!<brrrrrrrrrrrrrrr>

--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)
Aug 2 '06 #12

P: n/a
Andy Dingley scribed:
>On Wed, 02 Aug 2006 08:46:04 -0700, Ed Jay <ed***@aes-intl.comwrote:
>>My pages are filled with <brtags, and I'm in no hurry to eliminate them
in favor of defining a bunch of new containers.

URL?
My 'pages' is a web-based medical application comprising 7 Perl scripts, 8
linked javascripts, and 2 HTML pages.
>
If your pages are "filled" with <br>, it does indeed sound as if they're
being mis-used and shouldbe removed.
No, if my page...singular...did, you'd most likely be correct, but I'm
talking about pages in the plural, 17 of them. :-)
>
...or else you're publishing poetry.
Similar...lengthy and verbose diagnostic reports. Lots of one- and
two-line statements dynamically generated based on entered data. Use of
the <brtag is employed liberally as a line separator. Because of the
different formats used within the forms and reports, using <bris much
easier (for me) than trying to invent an algorithm to determine when,
on-the-fly, the top or bottom margins of a container should be different
values based on more than up to 250 [variable] textual combinations. :-)
--
Ed Jay (remove 'M' to respond by email)
Aug 2 '06 #13

P: n/a
Ed Jay <ed***@aes-intl.comscripsit:
>...or else you're publishing poetry.

Similar...lengthy and verbose diagnostic reports. Lots of one- and
two-line statements dynamically generated based on entered data. Use
of the <brtag is employed liberally as a line separator.
Do the statements constitute something that can reasonably be called a
paragraph, even if it is a short one? Then use <p>. Otherwise, consider
using <div(typically with class="..."). Or if the statements logically
belong together, maybe they should be grouped, without forced line breaks.
It is not normal to break a line after every statement.
Because of
the different formats used within the forms and reports, using <br>
is much easier (for me) than trying to invent an algorithm to
determine when, on-the-fly, the top or bottom margins of a container
should be different values based on more than up to 250 [variable]
textual combinations. :-)
I don't see the relevance. If you use <breffectively to separate blocks of
text, then you won't get any margins and cannot specify any margins - there
is no element to attach styles to. If you use <br><brto create vertical
spacing, that's abuse.

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

Aug 2 '06 #14

P: n/a
On Wed, 2 Aug 2006 22:44:41 +0300, "Jukka K. Korpela"
<jk******@cs.tut.fiwrote:
>Andy Dingley <di*****@codesmiths.comscripsit:
><bris good.

Empty elements aren't good in a language that is expected to be a logical
markup language. They are procedural markup in disguise,
That's an interesting viewpoint, but still no justification for removing
<br>.

For an empty element (in the SGML DTD sense, not XML) to be justified,
then there has to be a need to represent things that are atomic units of
markup and cannot contain further content. Linebreak _is_ such a thing.

For that matter, you could argue that full stops or periods are too,
except that they already have a usable ASCII character that's not
tainted by pre-existing connotations IT associations around "CR/LF".
Would you claim that periods should be replaced by
<sentence>...</sentencemarkup too ?

>What does "line break" mean in speech, in Braille rendering, or to a search
engine?
I don't know. They may have no meaning at all. In the context of text on
a screen though they're certainly meaningful and obvious -- that alone
is entirely sufficient to justify it.
Aug 2 '06 #15

P: n/a
Andy Dingley <di*****@codesmiths.comscripsit:
>Empty elements aren't good in a language that is expected to be a
logical markup language. They are procedural markup in disguise,

That's an interesting viewpoint, but still no justification for
removing <br>.
Either my point is correct and then it _is_ a justification (though perhaps
not a sufficient one), or it is not and you should have said and proved that
instead of calling the point "interesting".
For an empty element (in the SGML DTD sense, not XML) to be justified,
then there has to be a need to represent things that are atomic units
of markup and cannot contain further content. Linebreak _is_ such a
thing.
Nope, empty elements were taken into SGML for use as placeholders for
content to be included from an external source. They were preserved in XML
mostly to make the world safe for legacy HTML (like <br>) in XML clothes.

Well, this is a CSS group, so we are somewhat off-topic, but the question
started from the question whether <brshould be eliminated in favor of CSS.
Eric Meyer probably does not read this group, so we won't see his own
comments, but my interpretation is that he meant things like <br><br>.
Getting rid of <braltogether would be primarily a _markup_ issue rather
than CSS.
For that matter, you could argue that full stops or periods are too,
except that they already have a usable ASCII character that's not
tainted by pre-existing connotations IT associations around "CR/LF".
Would you claim that periods should be replaced by
<sentence>...</sentencemarkup too ?
No I wouldn't, but the reason is practical rather than theoretical. People
just wouldn't bother using such markup. If used, the markup would allow
better automatic analysis of texts, better formatting, better styling, etc.

Punctuation marks can really be treated as conventional markup. This becomes
rather clear if we think about quotation marks (especially asymmetric
quotation marks, with opening quote different from closing quote) or
Spanish-style questions, like "Cmo?", where "" really corresponds to an
opening tag and "?" a closing tag.

Thus, the reason for people's probable dislike for using <sentencemarkup
would be that they think they already use sentence markup, just using a
"markup language" embedded into a natural language as punctuation.
>What does "line break" mean in speech, in Braille rendering, or to a
search engine?

I don't know. They may have no meaning at all.
Indeed. And markup that has meaning in one presentation media only could be
called presentational, right? But there's really no way to tell from markup
alone, without human judgement, whether <bris supposed to be a replacement
for something more logical (e.g., for indicating the structure of a poem or
a postal address, or even to simulate paragraph division) or just a
formatting tool used for practical reasons.

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

Aug 2 '06 #16

P: n/a
On Wed, 02 Aug 2006 13:26:29 -0700, Ed Jay <ed***@aes-intl.comwrote:
>Use of the <brtag is employed liberally as a line separator.
Line break good, line separator bad.

You'll find it _easier_ with <p>, especially if you learn to use
collapsing vertical margins effectively.
Aug 2 '06 #17

P: n/a
Andy Dingley wrote:
"one goal of using CSS is to eliminate all mis-used <brtags" might
be a better phrasing.
But not a better use of time, since it is impossible.

Impossible to eliminate mis-use of anything that is.

--
Wes Groleau

You're all individuals!
Yes, we're all individuals!
You're all different!
Yes, we are all different!
I'm not!

("Life of Brian")

Aug 3 '06 #18

P: n/a


Jukka K. Korpela wrote:
What does "line break" mean in speech, in Braille rendering, or to a
search engine?
Search engines generally ignore them because they are concerned with the
words, not the layout.

When visible text needs a line break, so does the Braille.
And in that case, there are usually subtle ways one reading
can suggest something different about that particular pause.

--
Wes Groleau
-----------
Daily Hoax: http://www.snopes2.com/cgi-bin/random/random.asp
Aug 3 '06 #19

P: n/a
On Wed, 02 Aug 2006 23:39:54 +0200, Jukka K. Korpela <jk******@cs.tut.fi>
wrote:
Punctuation marks can really be treated as conventional markup. This
becomes rather clear if we think about quotation marks (especially
asymmetric quotation marks, with opening quote different from closing
quote) or Spanish-style questions, like "¿Cómo?", where "¿" really
corresponds to an opening tag and "?" a closing tag.
I started writing a reply trying to argue against this point of view, but
I managed to confuse myself in the process. The following is a train of
thoughts, without a clear conclusion...

First idea:
Yes, punctuation does constitute a (perhaps primitive) form of markup. A
text can be parsed based on punctuation. But the parsing mechanism is
language-dependent. IMHO, it makes more sense to see punctuation as an
integral part of grammar, because markup should be language-independent.

Pro punctuation = markup:
On a very abstract level, you could do something like:

<question lang="es">Cómo se va</question>
<question lang="en">How do you do</question>
<question lang="el">Τι κάνετε</question>

which is completely equivalent to:

<span lang="es">¿Cómo se va?</span>
<span lang="en">How do you do?</span>
<span lang="el">Τι κάνετε;</span>

A parser can always transform the punctuated form to the markup form,
provided that it knows what language the phrase is, and that it knows the
grammar of that language. A smart enough text-to-speech engine should be
able to render the punctuated form correctly. It can also transform the
markup form to the punctuated form, under the same conditions.

Contra punctuation = markup:
If the markup form is presented as text without any styling applied, it
will look like

Cómo se va
How do you do
Τι κάνετε

and when this is copy-pasted to a plain text document, meaning is lost.

Rebuttal: One could argue that a rendering engine must always put the
appropriate question marks around a phrase, and that these question marks
can be copy-pasted along with the rest of the text.

Another contra argument:
On second thought, language alone is not enough to determine the
punctuation. In English, one can use single or double quotation marks, and
even within British English, different styles are possible. Still, one
could argue that this is only a matter of style, not of content. Another
example is a language that can be written in different scripts, such as
Kurdish, which can be written in Latin, Cyrillic or Arabic. I don't know
enough about that language to give a good example, but I'm sure that
<question lang="ku">...</questionmust be rendered differently if the
enclosed text is in Arabic script than when it is in Latin or Cyrillic
script. So the correspondence between markup and presentation is not
entirely one-to-one.

Possible rebuttal:
Along with the language, the script could be specified. RFC 1766 (Tags for
the Identification of Languages, http://www.ietf.org/rfc/rfc1766.txt) says
about the language subtag: "The information in the subtag may for instance
be: [...] Script variations, such as az-arabic and az-cyrillic".

Rebuttal of the rebuttal:
But whereas the main tag must be an ISO 639 code, and country information
must also be given as described in ISO 639, no fixed format is given for
the script information. Would ISO 15924 do? Does it cover all existing
scripts? How does a parser know if the subtag gives country information,
script information, or something else? In short, I don't think a reliable
way exists to indicate the script unambiguously.

But then again:
If the script cannot be determined unambiguously, a parser cannot
interpret the punctuated form any more than it can transform. For a
text-to-speech engine, it is therefore better to have markup than to have
simple punctuation.

Yet another contra argument:
Apart from the details noted above, it is not unreasonable to see (in
English) "xxx!" as equivalent to "<excl>xxx</excl>", "xxx?" as equivalent
to "<question>xxx</question>" and "xxx." as equivalent to
"<sentence>xxx</sentence>". For quotation marks, an equivalent
"<q>xxx</q>" already exists. But what about other punctuation marks, such
as commas and colons?
Indeed. And markup that has meaning in one presentation media only could
be called presentational, right? But there's really no way to tell from
markup alone, without human judgement, whether <bris supposed to be a
replacement for something more logical (e.g., for indicating the
structure of a poem or a postal address, or even to simulate paragraph
division) or just a formatting tool used for practical reasons.
You are right, <brcan be eliminated completely using <div>. For example:

<address>
<div>John Doe</div>
<div>123, Foobar Street</div>
<div>Bazville</div>
</address>

<poem>
<stanza>
<verse>Roses are red,</verse>
<verse>Violets are blue,</verse>
<verse>This poem is boring,</verse>
<verse>And quite silly, too.</verse>
</stanza>
</poem>

--
Garmt de Vries-Uiterweerd
Aug 3 '06 #20

P: n/a
"Garmt de Vries-Uiterweerd" <ga**********@googlemail.comwrote:
>You are right, <brcan be eliminated completely using <div>. For example:

<address>
<div>John Doe</div>
<div>123, Foobar Street</div>
<div>Bazville</div>
</address>
Invalid, <addressis defined as inline and thus cannot contain block
level elements.

--
Spartanicus
Aug 3 '06 #21

P: n/a
On Thu, 03 Aug 2006 12:13:52 +0200, Spartanicus <in*****@invalid.invalid>
wrote:
"Garmt de Vries-Uiterweerd" <ga**********@googlemail.comwrote:
>You are right, <brcan be eliminated completely using <div>. For
example:

<address>
<div>John Doe</div>
<div>123, Foobar Street</div>
<div>Bazville</div>
</address>

Invalid, <addressis defined as inline and thus cannot contain block
level elements.
Oops, you're right. I didn't have the address element as defined in HTML
in mind, just a generic element, like the <poemI made up. I should have
given it another name. Sorry for the confusion...

--
Garmt de Vries-Uiterweerd
Aug 3 '06 #22

P: n/a
Garmt de Vries-Uiterweerd wrote:
For quotation marks, an equivalent "<q>xxx</q>" already exists. But
what about other punctuation marks, such as commas and colons?
I refer to english; I'm not familiar with any languages for which the
following is untrue, but such languages no doubt exist.

Commas are used both structurally (to emphasise the division of a
sentence into clauses) and presentationally (to suggest to someone
reading aloud when they might take breath; and by extension, to help a
silent reader to parse a sentence). Commas very rarely change the
meaning of a sentence. The sentence structure should be definitively
expressed by its grammar, net of commas.

However there are situations in which it may be difficult, even for an
expert author, to construct a sentence that conveys the correct meaning
and also reads well without commas. Lawyers routinely produce complex
sentences without commas, that are often completely impenetrable.

Anyway, I don't think commas are significant structural markup.

A colon is used inter-alia to designate the head of an enumerated list,
and so used in that way, it is structural markup, corresponding (I
suppose) to <OL>. In english, the list following the colon is generally
presented inline, with list-elements separated by semi-colons. So I
would not think that <OLwould be a good substitute for a colon.
--
Jack.
Aug 3 '06 #23

P: n/a
>Commas very rarely change the
meaning of a sentence. The sentence structure should be definitively
expressed by its grammar, net of commas.
That is just not true, as exemplified in Lynn Truss's book 'Eats, Shoots
and Leaves'. It's also said to be the reason why there are so few commas
in legal documents...
--
Chris Hughes
"Reality is that which, when you cease to believe, continues to exist."
http://www.epicure.demon.co.uk
Aug 3 '06 #24

P: n/a
On Wed, 2 Aug 2006, Jukka K. Korpela wrote:
><bris good.

Empty elements aren't good in a language that is expected to be a logical
markup language. They are procedural markup in disguise, or just
misdesigned.
What is your opinion about Unicode character U+2028 "line separator"?
Is it "bad", too?
What does "line break" mean in speech, in Braille rendering, or to a search
engine?
What does "capital letter" mean in speech, in Braille rendering,
or to a search engine?

Aug 3 '06 #25

P: n/a
On Thu, 03 Aug 2006 15:20:56 +0200, Andreas Prilop
<nh******@rrzn-user.uni-hannover.dewrote:
On Wed, 2 Aug 2006, Jukka K. Korpela wrote:
>What does "line break" mean in speech, in Braille rendering, or to a
search
engine?

What does "capital letter" mean in speech,
Sometimes: that a name should be spoken in awe, or with some more
emphasis, or with irony. "This is a good thing". "This is a Good Thing".
in Braille rendering,
a:
o.
..
..

A:

.. o.
.. ..
.o ..
or to a search engine?
No search engine I know of offers the functionality, but one could, in
theory, do a case-sensitive search.

--
Garmt de Vries-Uiterweerd
Aug 3 '06 #26

P: n/a
On Thu, 3 Aug 2006, Wes Groleau wrote:
>What does "line break" mean in speech, in Braille rendering, or to a
search engine?

Search engines generally ignore them because they are concerned with the
words, not the layout.
<brand <pare generally equivalent for search engines.
http://google.com/search?q=display.s...you.might.need
http://google.com/search?q=display.s...you.might.need

Aug 3 '06 #27

P: n/a
On Thu, 3 Aug 2006, Jukka K. Korpela wrote:
Nope, empty elements were taken into SGML for use as placeholders for
content to be included from an external source. They were preserved in XML
mostly to make the world safe for legacy HTML (like <br>) in XML clothes.
IIRC, Dr. Alzheimer, I already noted that <bris the markup equivalent
for Unicode character U+2028 "line separator".

Aug 3 '06 #28

P: n/a
The Major wrote:
>
>Commas very rarely change the meaning of a sentence. The sentence
structure should be definitively expressed by its grammar, net of
commas.

That is just not true, as exemplified in Lynn Truss's book 'Eats,
Shoots and Leaves'. It's also said to be the reason why there are so
few commas in legal documents...
Truss's opinion as to the purpose of a comma:

1. To illuminate the grammar of a sentence
2. To point up [...] such literary qualities as
rhythm, direction, pitch tone and flow

Both sound like presentational purposes to me. Now in that chapter on
commas, Truss gives examples of sentences that are ambiguous, and in
which the comma is needed to clarify the ambiguity. However the comma
has not changed the structure of such a sentence; and anyway such
sentences can (and arguably should) be rewritten in such a way as to
eliminate the ambiguity. Unless, of course, the ambiguity is intentional.

It's quite difficult to write english that's free of all ambiguity, with
or without commas. My view is that if the sentence can be made clear
before inserting commas, that's better than relying entirely on commas
for disambiguation. Gramattical dis

Anyway, this is just an opinion.

--
Jack.
http://www.jackpot.uk.net/
Aug 3 '06 #29

P: n/a
Andreas Prilop <nh******@rrzn-user.uni-hannover.descripsit:
What is your opinion about Unicode character U+2028 "line separator"?
Is it "bad", too?
It's defined for use in _plain text_ as semantically unambiguous for a line
break, as you know (see my "Unicode Explained", p. 426 and p. 469). From the
markup (or styling) perspective, it's no more interesting than Carriage
Return or Line Feed.
>What does "line break" mean in speech, in Braille rendering, or to a
search engine?

What does "capital letter" mean in speech, in Braille rendering,
or to a search engine?
It depends. In speech, it may cause a difference in pronunciation - compare
"it" with "IT". In Braille, it may cause an indication of case shift. To a
search engine, it may well matter, and used to matter to e.g. to good old
AltaVista, but it seems that all general search engines ignore letter case -
but site-specific or otherwise specialized search engines may well
distinguish between "it" and "IT".

ObCSS: A purist might say that CSS has the text-transform property just for
situations where the use of capital letters is presentational only. So if
you would like to _display_ your navigation menu with "ME", "MY DOG" and "MY
PC", it would be better to write the link texts as "me", "my dog" and "my
PC" and use text-transform: capitalize. That way, a case-sensitive search
engine could know that you have "me" and not "ME" (which could be an
abbreviation, with many meanings).

Technically, we could have CSS-generated line breaks too, either by using
display: block or (with much more narrow browser support) by using a :before
or :after pseudoelement and generated content containing a line break. But
this would be far more clumsy than using <br>, I'm afraid.

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

Aug 3 '06 #30

P: n/a


Wes Groleau wrote:
Andy Dingley wrote:
>"one goal of using CSS is to eliminate all mis-used <brtags" might
be a better phrasing.

But not a better use of time, since it is impossible.

Impossible to eliminate mis-use of anything that is.
Allow me to correct my mis-use of punctuation:

Impossible to eliminate mis-use of anything, that is.

--
Wes Groleau

Always listen to experts. They'll tell you
what can't be done and why. Then do it.
-- Robert A. Heinlein
Aug 4 '06 #31

P: n/a
>Commas very rarely change the
meaning of a sentence. The sentence structure should be definitively
expressed by its grammar, net of commas.

That is just not true, as exemplified in Lynn Truss's book 'Eats, Shoots
and Leaves'. It's also said to be the reason why there are so few commas
in legal documents...
Truss proves that a comma can change the meaning,
but did not prove whether it is common or rare
for that to happen. I suspect it is relatively
rare, though I recently unintentionally posted
an example.

I posted:
Impossible to prevent the mis-use of something that is.
I should have posted:
Impossible to prevent the mis-use of something, that is.

--
Wes Groleau
http://freepages.rootsweb.com/~wgroleau/Wes
Aug 4 '06 #32

P: n/a
In message <ea*******************@news.demon.co.uk>, Jack
<mr*********@nospam.jackpot.uk.netwrites
>Commas very rarely change the
meaning of a sentence.
Jack proved Andy is an idiot.

Jack, proved Andy, is an idiot.

As you can see, commas sometimes not only change the meaning of a
sentence, but they are necessary to convey it ;-)

--
Andy Mabbett
Say "NO!" to compulsory ID Cards: <http://www.no2id.net/>

Free Our Data: <http://www.freeourdata.org.uk>
Aug 5 '06 #33

P: n/a
Andy Mabbett wrote:
In message <ea*******************@news.demon.co.uk>, Jack
<mr*********@nospam.jackpot.uk.netwrites
>Commas very rarely change the meaning of a sentence.

Jack proved Andy is an idiot.

Jack, proved Andy, is an idiot.

As you can see, commas sometimes not only change the meaning of a
sentence, but they are necessary to convey it ;-)
Silly - that's an ambiguous sentence that can oh-so-easily be disambiguated.

Jack proved that Andy is an idiot.

The second example, which is contrived and awkward, is best expressed
using the form above; if "Jack" has to precede "Andy" for e.g. poetic
reasons, then probably commas are indispensable for conveying the
correct meaning.

As I said before, I think it's best to try to start with unambiguous
prose. I know that can lead to awkwardness; and especially when spoken
dialogue is being written down, ambiguity can sometimes only be avoided
by using commas.
--
Jack.
http://www.jackpot.uk.net/
Aug 5 '06 #34

P: n/a
"Jack" <mr*********@nospam.jackpot.uk.netwrote in message
news:eb*******************@news.demon.co.uk...
Andy Mabbett wrote:
>In message <ea*******************@news.demon.co.uk>, Jack
<mr*********@nospam.jackpot.uk.netwrites
>>Commas very rarely change the meaning of a sentence.

Jack proved Andy is an idiot.

Jack, proved Andy, is an idiot.

As you can see, commas sometimes not only change the meaning of a
sentence, but they are necessary to convey it ;-)

The second example, which is contrived and awkward, is best expressed
using the form above; if "Jack" has to precede "Andy" for e.g. poetic
reasons, then probably commas are indispensable for conveying the
correct meaning.
All this makes me think of a literary useage involving quotes.

"Jack", proved Andy, "is an idiot
"because he does idiotic things"

Using the <qelement to express this in current html seems a little
awkward, as although there isn't a clear link between the two quotes (beyond
the fact that they are in the same paragraph). If there were a sentence
element this would show the special link.

However, another question would be, how do you handle sentences containing
quotes which contain multiple sentences. This could be an argument against a
sentence element, as the definitions would get messy.

ie. you would have to allow <s><q><s></s></q></sbut not <s><s></s></s>. I
think this is unprecedented in any html elements. I'm not sure however about
its legality in SGML and XML, so it may be possible
Aug 7 '06 #35

P: n/a
"Martin Eyles" <ma**********@NOSPAMbytronic.comwrites:
ie. you would have to allow <s><q><s></s></q></sbut not <s><s></s></s>. I
think this is unprecedented in any html elements. I'm not sure however about
its legality in SGML and XML, so it may be possible
I can't think of an existing HTML element that does it, but it's
certainly possible in SGML.
http://www.dur.ac.uk/c.i.morris/del.html
It validates as HTML 4.01, but it very obviously breaks the prose HTML spec
http://www.w3.org/TR/html4/struct/text.html#h-9.4

This is probably a good reason why there aren't more of them - they're
allowed in HTML, but not all the constraints on their operation
are. This particular one could have been avoided with <insblockand
<insinlineelements rather than trying to fit <insto both, of course.

--
Chris
Aug 7 '06 #36

P: n/a
In article <vc********************************@4ax.com>, Ed Jay
<ed***@aes-intl.comwrites
>I note in an Eric Meyers book that he expresses one goal of using CSS is
to eliminate all <brtags. Why?
To be fair, he does *not* express this as a goal of CSS, he offers it as
a goal of the first project in that book, which is to convert an HTML
page that is full of tables and <fonttags (amongst other things) to
something mostly based around CSS.

To suggest that he is claiming that <brshould be deprecated now that
CSS is well supported is to misrepresent him.

--
Alan Silver
(anything added below this line is nothing to do with me)
Aug 7 '06 #37

P: n/a
In article <vg****************@reader1.news.jippii.net>, Jukka K.
Korpela <jk******@cs.tut.fiwrites
>What does "line break" mean in speech, in Braille rendering, or to a
search engine?
To use the previously offered example of <brbeing used to split lines
in an address, then a screen reader would probably use it to indicate a
slight pause, just like you or I would if we were reading out an
address. A search engine would use it to indicate a separation between
what came before and what came after.

Just a thought.

--
Alan Silver
(anything added below this line is nothing to do with me)
Aug 7 '06 #38

P: n/a
On Thu, 3 Aug 2006 00:39:54 +0300, "Jukka K. Korpela"
<jk******@cs.tut.fiwrote:
>Andy Dingley <di*****@codesmiths.comscripsit:
>>Empty elements aren't good in a language that is expected to be a
logical markup language. They are procedural markup in disguise,

That's an interesting viewpoint, but still no justification for
removing <br>.

Either my point is correct and then it _is_ a justification (though perhaps
not a sufficient one), or it is not and you should have said and proved that
instead of calling the point "interesting".
You're still interesting, even when you're wrong, sweetie. 8-)

Aug 8 '06 #39

P: n/a
Jack wrote:
Commas very rarely change the meaning of a sentence.
But sometimes they do!

"It could be the most costly piece of punctuation in Canada.

A grammatical blunder may force Rogers Communications Inc. to pay an
extra $2.13-million to use utility poles in the Maritimes after the
placement of a comma in a contract permitted the deal's cancellation."

http://www.theglobeandmail.com/servl...=rogers+aliant

Aug 9 '06 #40

P: n/a
Andy Dingley wrote:
These
are abuses of <brand no-one should defend them, but the fact that
<brregularly gets mis-used doesn't mean that it should be removed.
I feel the same way about <marquee>. Maybe it was never officially
part of HTML but all the common browsers support it and it's found the
occasional use (and the occasional misuse). I would like to see
<marqueestandardized so it can be styled with consistency across
browsers.

--
Vid the Kid

Aug 10 '06 #41

P: n/a

VidTheKid wrote:
Andy Dingley wrote:
These
are abuses of <brand no-one should defend them, but the fact that
<brregularly gets mis-used doesn't mean that it should be removed.

I feel the same way about <marquee>.
If you support <marquee>, why stop there? You'd also have to include
<dancing-penguinsand <cursor-trails>.

The effect of marquee is obtainable as a presentation effect. That of
<brrequires embedding in the markup itself (as either a tag or a
charcter, but that's a separate question). Adding marquee to CSS is
justifiable (architecturally if not aesthetically), but not adding it
to HTML.

Aug 11 '06 #42

P: n/a
In article <11*********************@h48g2000cwc.googlegroups. com>, Andy
Dingley <di*****@codesmiths.comwrites
>If you support <marquee>, why stop there? You'd also have to include
<dancing-penguinsand <cursor-trails>.
Now you're talking!! If only the W3C would add this sort of thing to
CSS, we could turn standards-based web design back into the ugly
nightmare of the late 1990s, only with valid pages!!

I would like to propose <dancing-ferretsas an alternative. Please
support me in my quest to have it adopted as a standard.

<g>

--
Alan Silver
(anything added below this line is nothing to do with me)
Aug 13 '06 #43

P: n/a
Nik
Alan Silver wrote:
>
I would like to propose <dancing-ferretsas an alternative. Please
support me in my quest to have it adopted as a standard.
Surely the proper solution would be to hold the semantic content
<dancing creaturesin the HTML and to suggest the type of animal via
the stylesheet?

Nik
Aug 14 '06 #44

P: n/a
Nik wrote:
Alan Silver wrote:

I would like to propose <dancing-ferretsas an alternative. Please
support me in my quest to have it adopted as a standard.

Surely the proper solution would be to hold the semantic content
<dancing creaturesin the HTML and to suggest the type of animal via
the stylesheet?
You mean "skinning" ?

Aug 14 '06 #45

P: n/a
In article <eb**********@gemini.csx.cam.ac.uk>, Nik writes:
>Alan Silver wrote:
>I would like to propose <dancing-ferretsas an alternative. Please
support me in my quest to have it adopted as a standard.

Surely the proper solution would be to hold the semantic content
<dancing creaturesin the HTML and to suggest the type of animal via
the stylesheet?
Absolutely backwards. Animals, be they penguins or ferrets, are
obviously content. Whether they're standing still or dancing is
presentation.

--
Michael F. Stemper
#include <Standard_Disclaimer>
This email is to be read by its intended recipient only. Any other party
reading is required by the EULA to send me $500.00.

Aug 14 '06 #46

P: n/a
Michael Stemper wrote:
In article <eb**********@gemini.csx.cam.ac.uk>, Nik writes:
>Alan Silver wrote:
>>I would like to propose <dancing-ferretsas an alternative.
Please support me in my quest to have it adopted as a standard.
Surely the proper solution would be to hold the semantic content
<dancing creaturesin the HTML and to suggest the type of animal
via the stylesheet?

Absolutely backwards. Animals, be they penguins or ferrets, are
obviously content. Whether they're standing still or dancing is
presentation.
Yes, I hadn't worked that out, but I certainly felt uncomfortable about
the previous remark. So you'd have markup like:

<penguin style="gait:dancing">

or perhaps
<drunkard style="gait:staggering">

....I suppose.

--
Jack.
http://www.jackpot.uk.net/
Aug 14 '06 #47

P: n/a
Andy Dingley wrote:
VidTheKid wrote:
Andy Dingley wrote:
These
are abuses of <brand no-one should defend them, but the fact that
<brregularly gets mis-used doesn't mean that it should be removed.
I feel the same way about <marquee>.

If you support <marquee>, why stop there? You'd also have to include
<dancing-penguinsand <cursor-trails>.
Do commonly-used browsers support those tags?
The effect of marquee is obtainable as a presentation effect. That of
<brrequires embedding in the markup itself (as either a tag or a
charcter, but that's a separate question). Adding marquee to CSS is
justifiable (architecturally if not aesthetically), but not adding it
to HTML.
In other words, you're saying that adding marquee functionality to just
about any element via some CSS property (such as display: marquee)
would be acceptable without formally making <marqueepart of HTML?
I'd go with that. Not that I would advise assigning such a property to
most elements... The problem I see with the way things are now is that
I can't control padding in a marquee element in IE and I can't make a
marquee print as a normal block-level container. (If <marqueewere to
be included in the standard, I would hope the W3C would describe such
logical printing behavior, thus encouraging the browsers to implement
it.)
In general, I don't believe annoying or un-aesthetic things should be
made invalid, illegal, or impossible, just for being displeasing,
especially if they have some obscure but legitimate use. Start doing
that, and what's next, fashion police?

--
Vid the Kid

Aug 15 '06 #48

P: n/a
VidTheKid wrote:
>
In general, I don't believe annoying or un-aesthetic things should be
made invalid, illegal, or impossible, just for being displeasing,
especially if they have some obscure but legitimate use. Start doing
that, and what's next, fashion police?
Surely we're not discussing legislation, nor what might or might not be
"impossible"; the matter at hand seems to be what features ought to be
included in a specification. I would have thought that obscure and
annoying features would be excellent candidates for exclusion from such
a spec.

Advocates of annoying and obscure features ought to be permitted to
write their own specs; I wouldn't want that kind of behaviour to be
illegal, as long as my browser and I are permitted to ignore any
resulting 'recommendation'.

--
Jack.
http://www.jackpot.uk.net/
Aug 15 '06 #49

P: n/a
In our last episode, <vc********************************@4ax.com>, the
lovely and talented Ed Jay broadcast on
comp.infosystems.www.authoring.stylesheets:
I note in an Eric Meyers book that he expresses one goal of using CSS is
to eliminate all <brtags. Why?
because in html doctrine white space is meaningless.

--
Lars Eighner <http://larseighner.com/ <http://myspace.com/larseighner>
War on Terrorism: Treat Viewers like Mushrooms
"It seems perverse to focus too much on the casualties or hardship in
Afghanistan." -Walter Isaacson, _CNN_
Aug 16 '06 #50

56 Replies

This discussion thread is closed

Replies have been disabled for this discussion.