This is Interesting: Free Magazines for Graphics designers and webmasters
Home > Archive > Stylesheets > August 2006 > Re: Why eliminate <br>?
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Re: Why eliminate <br>?
|
|
| Ed Jay 2006-08-02, 3:10 pm |
| Andy Dingley scribed:
>
>Ed Jay wrote:
>
>
>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.
>
><br> is 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 <br> and no-one should defend them, but the fact that
><br> regularly gets mis-used doesn't mean that it should be removed.
Understood.
>
>"one goal of using CSS is to eliminate all mis-used <br> tags" might
>be a better phrasing.
Works for me.
My pages are filled with <br> tags, 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)
| |
| Ed Jay 2006-08-02, 3:10 pm |
| Jukka K. Korpela scribed:
>Ed Jay <edMbj@aes-intl.com> scripsit:
>
>
>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: <br> elements (also listed are
entities, font elements, and other stuff.)
>
>
>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 <br> tags 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 <br> can 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 <br> tags 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)
| |
|
|
| Jukka K. Korpela 2006-08-02, 7:26 pm |
| Andy Dingley <dingbat@codesmiths.com> scripsit:
> <br> is 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/
| |
| Andy Dingley 2006-08-02, 7:26 pm |
| On Wed, 02 Aug 2006 08:46:04 -0700, Ed Jay <edMbj@aes-intl.com> wrote:
>My pages are filled with <br> tags, 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.
| |
| Evertjan. 2006-08-02, 7:26 pm |
| Andy Dingley wrote on 02 aug 2006 in
comp.infosystems.www.authoring.stylesheets:
> On Wed, 02 Aug 2006 08:46:04 -0700, Ed Jay <edMbj@aes-intl.com> wrote:
>
>
> 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)
| |
| Ed Jay 2006-08-02, 7:27 pm |
| Andy Dingley scribed:
>On Wed, 02 Aug 2006 08:46:04 -0700, Ed Jay <edMbj@aes-intl.com> wrote:
>
>
>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 <br> tag is employed liberally as a line separator. 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. :-)
--
Ed Jay (remove 'M' to respond by email)
| |
| Jukka K. Korpela 2006-08-02, 7:27 pm |
| Ed Jay <edMbj@aes-intl.com> scripsit:
>
> Similar...lengthy and verbose diagnostic reports. Lots of one- and
> two-line statements dynamically generated based on entered data. Use
> of the <br> tag 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 <br> effectively 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><br> to create vertical
spacing, that's abuse.
--
Jukka K. Korpela ("Yucca")
http://www.cs.tut.fi/~jkorpela/
| |
| Andy Dingley 2006-08-02, 7:27 pm |
| On Wed, 2 Aug 2006 22:44:41 +0300, "Jukka K. Korpela"
<jkorpela@cs.tut.fi> wrote:
>Andy Dingley <dingbat@codesmiths.com> scripsit:
>
>
>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>...</sentence> markup 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.
| |
| Jukka K. Korpela 2006-08-02, 7:27 pm |
| Andy Dingley <dingbat@codesmiths.com> scripsit:
>
> 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 <br> should 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 <br> altogether 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>...</sentence> markup 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 "¿Cómo?", where "¿" really corresponds to an
opening tag and "?" a closing tag.
Thus, the reason for people's probable dislike for using <sentence> markup
would be that they think they already use sentence markup, just using a
"markup language" embedded into a natural language as punctuation.
>
> 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 <br> is 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/
| |
| Andy Dingley 2006-08-02, 7:27 pm |
| On Wed, 02 Aug 2006 13:26:29 -0700, Ed Jay <edMbj@aes-intl.com> wrote:
>Use of the <br> tag 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.
| |
| Wes Groleau 2006-08-03, 3:42 am |
| Andy Dingley wrote:
> "one goal of using CSS is to eliminate all mis-used <br> tags" 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")
| |
| Wes Groleau 2006-08-03, 3:42 am |
|
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
| |
| Garmt de Vries-Uiterweerd 2006-08-03, 7:35 pm |
| On Wed, 02 Aug 2006 23:39:54 +0200, Jukka K. Korpela <jkorpela@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">...</question> must 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 <br> is 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, <br> can 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
| |
| Spartanicus 2006-08-03, 7:35 pm |
| "Garmt de Vries-Uiterweerd" <garmtdevries@googlemail.com> wrote:
>You are right, <br> can be eliminated completely using <div>. For example:
>
><address>
><div>John Doe</div>
><div>123, Foobar Street</div>
><div>Bazville</div>
></address>
Invalid, <address> is defined as inline and thus cannot contain block
level elements.
--
Spartanicus
| |
| Garmt de Vries-Uiterweerd 2006-08-03, 7:35 pm |
| On Thu, 03 Aug 2006 12:13:52 +0200, Spartanicus <invalid@invalid.invalid>
wrote:
> "Garmt de Vries-Uiterweerd" <garmtdevries@googlemail.com> wrote:
>
>
> Invalid, <address> is 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 <poem> I made up. I should have
given it another name. Sorry for the confusion...
--
Garmt de Vries-Uiterweerd
| |
|
| 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 <OL> would be a good substitute for a colon.
--
Jack.
| |
| The Major 2006-08-03, 7:35 pm |
|
>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
| |
| Andreas Prilop 2006-08-03, 11:08 pm |
| On Wed, 2 Aug 2006, Jukka K. Korpela wrote:
>
> 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?
| |
| Garmt de Vries-Uiterweerd 2006-08-03, 11:08 pm |
| On Thu, 03 Aug 2006 15:20:56 +0200, Andreas Prilop
<nhtcapri@rrzn-user.uni-hannover.de> wrote:
> On Wed, 2 Aug 2006, Jukka K. Korpela wrote:
>
>
> 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
| |
|
|
| Andreas Prilop 2006-08-03, 11:08 pm |
| 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 <br> is the markup equivalent
for Unicode character U+2028 "line separator".
| |
|
| The Major wrote:
>
>
> 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/
| |
| Jukka K. Korpela 2006-08-03, 11:08 pm |
| Andreas Prilop <nhtcapri@rrzn-user.uni-hannover.de> scripsit:
> 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 "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/
| |
| Wes Groleau 2006-08-04, 3:58 am |
|
Wes Groleau wrote:
> Andy Dingley wrote:
>
> 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
| |
| Wes Groleau 2006-08-04, 3:58 am |
|
>
> 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
| |
| Andy Mabbett 2006-08-05, 6:41 pm |
| In message <easjnq$23r$1$8302bc10@news.demon.co.uk>, Jack
<mrdemeanour@nospam.jackpot.uk.net> writes
>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>
| |
|
| Andy Mabbett wrote:
> In message <easjnq$23r$1$8302bc10@news.demon.co.uk>, Jack
> <mrdemeanour@nospam.jackpot.uk.net> writes
>
>
> 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/
| |
| Martin Eyles 2006-08-07, 7:11 am |
| "Jack" <mrdemeanour@nospam.jackpot.uk.net> wrote in message
news:eb2rbq$82a$1$8300dec7@news.demon.co.uk...
> Andy Mabbett wrote:
>
> 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 <q> element 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></s> but 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
| |
| Chris Morris 2006-08-07, 7:11 am |
| "Martin Eyles" <martin.eyles@NOSPAMbytronic.com> writes:
> ie. you would have to allow <s><q><s></s></q></s> but 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 <insblock> and
<insinline> elements rather than trying to fit <ins> to both, of course.
--
Chris
| |
| Alan Silver 2006-08-07, 6:34 pm |
| In article <vcuvc2hgqcllq7ikgldof6so9dj08lo76i@4ax.com>, Ed Jay
<edMbj@aes-intl.com> writes
>I note in an Eric Meyers book that he expresses one goal of using CSS is
>to eliminate all <br> tags. 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 <font> tags (amongst other things) to
something mostly based around CSS.
To suggest that he is claiming that <br> should 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)
| |
| Andy Dingley 2006-08-07, 10:43 pm |
| On Thu, 3 Aug 2006 00:39:54 +0300, "Jukka K. Korpela"
<jkorpela@cs.tut.fi> wrote:
>Andy Dingley <dingbat@codesmiths.com> scripsit:
>
>
>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-)
| |
| Andy Dingley 2006-08-09, 6:35 am |
| 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/serv...y=rogers+aliant
| |
| Lars Eighner 2006-08-16, 6:56 am |
| In our last episode, <vcuvc2hgqcllq7ikgldof6so9dj08lo76i@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 <br> tags. 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_
| |
| Timothy Larson 2006-08-24, 3:39 am |
| Spartanicus wrote:
> But there are a few legitimate uses for using <br>, one example would be
> to create a line break inside an <address> element:
>
> <address>
> My name<br>
> My address
> <address>
In these cases, I'd rather see a container element that enclosed each
line. Then you'd be able to style each line individually, which could
be useful.
Tim
| |
| Spartanicus 2006-08-24, 3:39 am |
| Timothy Larson <thelarsons3@cox.net> wrote:
>
>In these cases, I'd rather see a container element that enclosed each
>line. Then you'd be able to style each line individually, which could
>be useful.
Presentational markup such as <b> or <i> can be used, or styled <span>s,
but you'd still need the <br>.
--
Spartanicus
| |
| Darin McGrew 2006-08-24, 3:39 am |
| Spartanicus <invalid@invalid.invalid> wrote:
Timothy Larson <thelarsons3@cox.net> wrote:[color=darkred]
Spartanicus <invalid@invalid.invalid> wrote:[color=darkred]
> Presentational markup such as <b> or <i> can be used, or styled <span>s,
> but you'd still need the <br>.
If HTML included a <line>...</line> markup, you wouldn't need <br>:
<address>
<line>John Doe</line>
<line>123 Main Street</line>
<line>Anytown USA</line>
</address>
<stanza>
<couplet>
<line>Roses are red</line>
<line>Violets are blue</line>
</couplet>
<couplet>
<line>If it's good enough for Tim</line>
<line>Then it's good enough for you</line>
</couplet>
</stanza>
Sure, you can work around it by using <div>, or a combination of <br> and
<span>, but <line>...</line> or something similiar would have been nice.
--
Darin McGrew, mcgrew@stanfordalumni.org, http://www.rahul.net/mcgrew/
Web Design Group, darin@htmlhelp.com, http://www.HTMLHelp.com/
"I can take one day at a time, but sometimes several days attack me at once."
| |
| Johannes Koch 2006-08-24, 6:50 am |
| Darin McGrew schrieb:
> If HTML included a <line>...</line> markup, you wouldn't need <br>:
<http://www.w3.org/TR/xhtml2/mod-text.html#edef_text_l>
--
Johannes Koch
In te domine speravi; non confundar in aeternum.
(Te Deum, 4th cent.)
| |
| Spartanicus 2006-08-24, 6:50 am |
| Darin McGrew <mcgrew@stanfordalumni.org> wrote:
>
>Timothy Larson <thelarsons3@cox.net> wrote:
>
>Spartanicus <invalid@invalid.invalid> wrote:
>
>If HTML included a <line>...</line> markup, you wouldn't need <br>:
>
> <address>
> <line>John Doe</line>
> <line>123 Main Street</line>
> <line>Anytown USA</line>
> </address>
>
> <stanza>
> <couplet>
> <line>Roses are red</line>
> <line>Violets are blue</line>
> </couplet>
> <couplet>
> <line>If it's good enough for Tim</line>
> <line>Then it's good enough for you</line>
> </couplet>
> </stanza>
>
>Sure, you can work around it by using <div>, or a combination of <br> and
><span>, but <line>...</line> or something similiar would have been nice.
Assuming you'd want to retain validity and the semantics of the
<address> element, then using <div> inside the element is not an option.
(For the sake of not drifting to far off of what is being discussed I'm
ignoring the ambivalence of the element's semantics)
I'd agree that there is a need for an HTML element that could for
example be used for marking up lines of poetry or a lyric, or indeed the
lines inside an <address> element. For the latter case the <address>
element would have to be changed to allow block level child elements,
assuming that the new element would be of type "block".
Using <div>s to mark up things like lines of poetry is something of an
anomaly, semantically
<div>Roses are red</div>
<div>Violets are blue</div>
equates to "Rose are red Violets are blue", which obviously is a problem
in certain rendering situations.
--
Spartanicus
|
|
|
| | Copyright 2003 - 2008 forum4designers.com Software forum Computer Hardware reviews |
|