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

<q> and language-specific quotation marks

P: n/a
Greetings.

Do any popular browsers correctly support <q>, at least for Western
languages? I've noticed that Mozilla uses the standard English
double-quote character, ", regardless of the lang attribute of the HTML
document. Will any browsers render German-style quotes or French-style
guillemots for lang="de" and lang="fr", respectively?

Regards,
Tristan

--
_
_V.-o Tristan Miller [en,(fr,de,ia)] >< Space is limited
/ |`-' -=-=-=-=-=-=-=-=-=-=-=-=-=-=-= <> In a haiku, so it's hard
(7_\\ http://www.nothingisreal.com/ >< To finish what you
Jul 20 '05 #1
Share this Question
Share on Google+
63 Replies


P: n/a
Tristan Miller <ps********@nothingisreal.com> wrote in
news:38****************@ID-187157.news.dfncis.de:
Greetings.

Do any popular browsers correctly support <q>, at least for
Western languages? I've noticed that Mozilla uses the standard
English double-quote character, ", regardless of the lang
attribute of the HTML document. Will any browsers render
German-style quotes or French-style guillemots for lang="de" and
lang="fr", respectively?


IE doesn't support <q>

Getting quote marks around <q> tags in IE
http://groups.google.com/groups?thre...6.ph.gla.ac.uk

--
Kayode Okeyode
http://www.kayodeok.co.uk/weblog/
Jul 20 '05 #2

P: n/a
H.F. ?

"Tristan Miller" <ps********@nothingisreal.com> wrote in message
news:38****************@ID-187157.news.dfncis.de...
Greetings.

Do any popular browsers correctly support <q>, at least for Western
languages? I've noticed that Mozilla uses the standard English
double-quote character, ", regardless of the lang attribute of the HTML
document. Will any browsers render German-style quotes or French-style
guillemots for lang="de" and lang="fr", respectively?

Regards,
Tristan

--
_
_V.-o Tristan Miller [en,(fr,de,ia)] >< Space is limited
/ |`-' -=-=-=-=-=-=-=-=-=-=-=-=-=-=-= <> In a haiku, so it's hard
(7_\\ http://www.nothingisreal.com/ >< To finish what you

Jul 20 '05 #3

P: n/a
Tristan Miller wrote:

Do any popular browsers correctly support <q>, at least for Western
languages? I've noticed that Mozilla uses the standard English
double-quote character, ", regardless of the lang attribute of the HTML
document. Will any browsers render German-style quotes or French-style
guillemots for lang="de" and lang="fr", respectively?


Mozilla displays French language quote delimiters with the following
in css:

[lang="fr"] {
quotes: ' ' ' '
}

German could be handled in a similar fashion.

[lang="de"] {
quotes: '' '"'
}

I don't know German nearly well enough to write in it, so I've never
actually used the second example.

--
Brian
follow the directions in my address to email me

Jul 20 '05 #4

P: n/a
Tristan Miller <ps********@nothingisreal.com> wrote:
Do any popular browsers correctly support <q>
No.
I've noticed that Mozilla uses the standard English
double-quote character, ", regardless of the lang attribute of the
HTML document.
If you mean what you wrote, the Ascii quotation mark, then it's
definitely not _standard_ for English, or any language (except computer
"languages"). It's just the worldwide common surrogate.
Will any browsers render German-style quotes or
French-style guillemots for lang="de" and lang="fr", respectively?


Only if you write them as actual characters (and then the lang
attribute is immaterial in this issue). Why wouldn't you do that? We
can use language-specific punctuation characters for other things (such
as inverted question mark at the start of a question in languages that
require it), and seldom do we see requests to dispense with that by
using markup (like <question>) instead. What's so special about
quotations, then?

Beware that attempts to make browsers implement <q> by using CSS are
generally not successful and that _correct_ use of quotation marks is
trickier than people think.

Anyway, <q> was good idea as described (as an example) in the SGML
standard, but HTML did not adopt the idea early enough (and well
enough), and now it's too late. Just forget <q>.

--
Yucca, http://www.cs.tut.fi/~jkorpela/
Pages about Web authoring: http://www.cs.tut.fi/~jkorpela/www.html

Jul 20 '05 #5

P: n/a
Tristan Miller <ps********@nothingisreal.com> writes:
Greetings.

Do any popular browsers correctly support <q>, at least for Western
languages? I've noticed that Mozilla uses the standard English
double-quote character, ", regardless of the lang attribute of the HTML
document. Will any browsers render German-style quotes or French-style
guillemots for lang="de" and lang="fr", respectively?


AIUI, a browser is not required to make allowances for the
declared language; if you want these changes, you are supposed to
use CSS to specify them (shameless snippet from CSS2 spec:)

Q:lang(en) { quotes: '"' '"' "'" "'" }
Q:lang(no) { quotes: "" "" "<" ">" }

....however, to my knowledge, neither Mozilla nor MSIE support
this. Mozilla uses " " ' ' regardless of what you specify using
CSS; and MSIE (last I checked) doesn't support the <q> element
properly at all. I think Opera might, but since that's not very
mainstream, it probably won't help you much.

-Micah
Jul 20 '05 #6

P: n/a
Micah Cowan <mi***@cowan.name> wrote:
AIUI, a browser is not required to make allowances for the
declared language;
The HTML specification says: "User agents should render quotation marks
in a language-sensitive manner (see the lang attribute)." In that
sense, it's not a requirement for conformance to recommendation, just a
recommendation in the recommendation. :-) On the other hand, it is a
bit unrealistic to say that user agents should behave that way, since
it is rather hard to support all the thousands of languages, even in a
detail like this, since official information on punctuation rules is
not easy to find.
if you want these changes, you are supposed to
use CSS to specify them
No, you're not. The HTML specification says that browsers should do
such things automatically. And in practical terms, <q> markup is
useless.
(shameless snippet from CSS2 spec:)

Q:lang(en) { quotes: '"' '"' "'" "'" }
Q:lang(no) { quotes: "" "" "<" ">" }


How typical. Both rules are completely wrong, by the rules of those
languages. Correct English orthography uses none of the characters
listed, and Norwegian surely does not use less than sign and greater
than sign as inner quotes.

To repeat myself: Forget <q>. Use plain Ascii quotation marks, unless
you _know_ the correct use of punctuation characters in the language of
the context where the quotation appears and you can be reasonably sure
that browsers support those characters well enough. And when estimating
whether you _know_ such issues, it is useful to remember that the
authors of the CSS specification didn't have a clue.

--
Yucca, http://www.cs.tut.fi/~jkorpela/
Pages about Web authoring: http://www.cs.tut.fi/~jkorpela/www.html

Jul 20 '05 #7

P: n/a
"Jukka K. Korpela" <jk******@cs.tut.fi> writes:
Micah Cowan <mi***@cowan.name> wrote:
AIUI, a browser is not required to make allowances for the
declared language;
The HTML specification says: "User agents should render quotation marks
in a language-sensitive manner (see the lang attribute)." In that
sense, it's not a requirement for conformance to recommendation, just a
recommendation in the recommendation. :-) On the other hand, it is a
bit unrealistic to say that user agents should behave that way, since
it is rather hard to support all the thousands of languages, even in a
detail like this, since official information on punctuation rules is
not easy to find.
if you want these changes, you are supposed to
use CSS to specify them


No, you're not. The HTML specification says that browsers should do
such things automatically.


SHOULD and MUST are very different--formally. You *are* supposed
to use CSS if you want to force a conforming user-agent to Do The
Right Thing(TM). However, since there don't seem to be any
conforming user-agents... <grin>.
And in practical terms, <q> markup is useless.
Yeah, which sucks.
(shameless snippet from CSS2 spec:)

Q:lang(en) { quotes: '"' '"' "'" "'" }
Q:lang(no) { quotes: "" "" "<" ">" }


How typical. Both rules are completely wrong, by the rules of those
languages. Correct English orthography uses none of the characters
listed, and Norwegian surely does not use less than sign and greater
than sign as inner quotes.


Agreed about (en); although even if it had been correct, I didn't
post using an encoding that would have allowed more appropriate
ones.

As to (no); you're right, that's stupid. That's how they were in
the CSS2 standard, though (should've been &#x2039; and &#x203a; I
believe)
To repeat myself: Forget <q>.
But only until the stupid mainstream browsers (IOW, MSIE) get it
right. However, someone pointed out elsethread that apparently newer
versions Mozilla *can* get it right. Yay!
Use plain Ascii quotation marks
Why? Every browser I've seen supports &ldquo;, &rdquo;,
etc. Currently, the articles I've written in DocBook which use
DocBook's <quote> element are translated using these (and the
single-quote equivalents).
, unless
you _know_ the correct use of punctuation characters in the language of
the context where the quotation appears and you can be reasonably sure
that browsers support those characters well enough.


But when you *don't* know this, are you sure that the Ascii
quotation marks are appropriate?

-Micah

Jul 20 '05 #8

P: n/a
"Jukka K. Korpela" <jk******@cs.tut.fi> exclaimed in <Xn*****************************@193.229.0.31>:
such things automatically. And in practical terms, <q> markup is
useless.


So. In practical terms, marking up an inline quotation as an inline
quotation is useless.

This is good to know.

--
- Tina Holmboe Greytower Technologies
ti**@greytower.net http://www.greytower.net/
[+46] 0708 557 905
Jul 20 '05 #9

P: n/a
Micah Cowan <mi***@cowan.name> wrote:
SHOULD and MUST are very different--formally.
Theoretically HTML 4 specifications use RFC language here, but in
practice their wording is not that formal. Anyway, by the RFC language,
the statement that browsers SHOULD "render quotation marks in a
language-sensitive manner" means that "there may exist valid reasons in
particular circumstances to ignore [that statement] particular item,
but the full implications must be understood and carefully weighed
before choosing a different course". So if an implementator has
understood the full implications etc. and decided not to make a user
agent behave that way, what makes us think that an author knows better?
You *are* supposed
to use CSS if you want to force a conforming user-agent to Do The
Right Thing(TM).
No, of course not. First, HTML specifications do not postulate any use
of CSS. They are meant to be used without a style sheet, with CSS style
sheets, or with other style sheet. Second, author style sheets (by
design and by implementation) certainly cannot force anything. Third, a
duplicate implementation of quotation mark rendering would be a shot in
the dark. A browser programmer can be in a position to _know_ that e.g.
curly quotes are not available in a rendering situation and use Ascii
quotation marks instead, and if an author style sheet tries to force
curly quotes, it could end up with having no quotes rendered.
Agreed about (en); although even if it had been correct, I didn't
post using an encoding that would have allowed more appropriate
ones.
Surely you could write a style sheet in Ascii only and yet use any
Unicode character in generated content.
As to (no); you're right, that's stupid. That's how they were in
the CSS2 standard, though (should've been &#x2039; and &#x203a; I
believe)


No, notations like &#x2039; have no meaning in CSS.
To repeat myself: Forget <q>.


But only until the stupid mainstream browsers (IOW, MSIE) get it
right.


They'll never get it right. It'll take several years before the next
version of MSIE exists and has over 50 % share of MSIE installations.
And that's virtual eternity. Especially since by that time <q> will
have been officially deprecated or obsolete for years.
Use plain Ascii quotation marks


Why? Every browser I've seen supports &ldquo;, &rdquo;,
etc.


Then you haven't seen enough. Ascii quotation marks are _safe_, as I
wrote. If you consider using real quotation marks, then you should at
least refrain from using those quasi-mnemonic entity references and use
character references instead.
, unless
you _know_ the correct use of punctuation characters in the
language of the context where the quotation appears and you can be
reasonably sure that browsers support those characters well
enough.


But when you *don't* know this, are you sure that the Ascii
quotation marks are appropriate?


Ascii quotation marks are still the safest way. It's true that these
days, the number of browsers that fail to render the character
references for curly quotes properly is rather small - but yet not
zero, and users are accustomed to seeing Ascii quotation marks, so this
is not a big issue. I'm personally moving towards using "smart"
quotation marks on new pages, especially since it's awkward to change
such things later - I cannot just do a simple editing operation to
change Ascii quotation marks to any smart characters, since Ascii
quotation marks are used for HTML markup (attribute value delimiters).

Besides, there are other problems with correct quotation marks, even
the guillemets. The guillemets are technically rather safe, being
ISO 8859-1 characters, but the clueless line breaking rules in browsers
cause quite some trouble (see
http://www.cs.tut.fi/~jkorpela/html/nobr.html ).

--
Yucca, http://www.cs.tut.fi/~jkorpela/
Pages about Web authoring: http://www.cs.tut.fi/~jkorpela/www.html

Jul 20 '05 #10

P: n/a
ti**@greytower.net (Tina Holmboe) wrote:
such things automatically. And in practical terms, <q> markup is
useless.
So. In practical terms, marking up an inline quotation as an inline
quotation is useless.


Yes, because no software actually uses such markup for useful purposes,
_and_ the theoretically available markup is poorly designed.
This is good to know.


It is, is it not? Similarly, marking up a question as a question would
be useless, if <question> markup existed but had been defined so that
browsers should insert language-specific quotation mark(s) and they
actually did not do that and no search engine or other useful software
used that markup either.

We can still survive, can't we? The question mark is available, and so
are quotation marks. Actually, both a question mark and the quotation
marks are effectively markup - at the text level. If anyone wishes to
write an indexing robots that recognizes quotations, he could start
from recognizing strings delimited by quotation marks. (One might
consider treating <blockquote> as indicating quotation, but abuse is so
widespread that this would not be pragmatically wise.)

--
Yucca, http://www.cs.tut.fi/~jkorpela/
Pages about Web authoring: http://www.cs.tut.fi/~jkorpela/www.html

Jul 20 '05 #11

P: n/a
"Jukka K. Korpela" <jk******@cs.tut.fi> exclaimed in <Xn****************************@193.229.0.31>:
ti**@greytower.net (Tina Holmboe) wrote:
such things automatically. And in practical terms, <q> markup is
useless.
So. In practical terms, marking up an inline quotation as an inline
quotation is useless.


Yes, because no software actually uses such markup for useful purposes,
_and_ the theoretically available markup is poorly designed.


Oddly enough, such tools exist. I can only guess that you find the Mozilla
solution "useless", but even Mark Pilgrim has a script for extracting
quotations.
are quotation marks. Actually, both a question mark and the quotation
marks are effectively markup - at the text level. If anyone wishes to
write an indexing robots that recognizes quotations, he could start
from recognizing strings delimited by quotation marks. (One might


In Finnish - of which I know nothing - it might be that quotation marks
are always used to signify actual quotations. Such is not the case in
other languages.

How you intend to attach citation information to that text level markup
I cannot even begin to guess at.

Are we going to start writing browsers that use heuristic algorithms to
determine whether a random piece of text is one thing or the other ? That
might be amusing, but I fail to see it being helpful to anyone.

Be all of this as it may. So far I have not seen a sensible explanation of
why the *name* of the element had to change.

--
- Tina Holmboe Greytower Technologies
ti**@greytower.net http://www.greytower.net/
[+46] 0708 557 905
Jul 20 '05 #12

P: n/a
Jukka K. Korpela wrote:
Especially since by that time <q> will
have been officially deprecated or obsolete for years.


It is already gone int eh XHTML 2 drafts. Replaced by <quote>, that will
have more realistic demands on quote marks -- the author inserts them
directly into the XHTML:

<quote xml:lang="en">"Hello"</quote>

IIRC

--
Toby A Inkster BSc (Hons) ARCS
Contact Me - http://www.goddamn.co.uk/tobyink/?id=132

Jul 20 '05 #13

P: n/a
Tim
On 12 Oct 2003 14:26:49 -0700,
Micah Cowan <mi***@cowan.name> wrote:
Every browser I've seen supports &ldquo;, &rdquo;,


Not every one that I've used, and some of the ones that didn't were the
only browsers available for that computer system. Though I dare say
that users would get used to what they're supposed to resent, and given
a push the browser developers might bother to include recognition for
them, even if they only map them back to the ordinary quote symbols.

--
My "from" address is totally fake. (Hint: If I wanted e-mails from
complete strangers, I'd have put a real one, there.) Reply to usenet
postings in the same place as you read the message you're replying to.
Jul 20 '05 #14

P: n/a
Tim
On Sun, 12 Oct 2003 22:50:24 GMT,
ti**@greytower.net (Tina Holmboe) wrote:
So far I have not seen a sensible explanation of why the *name* of
the element had to change.


The obvious reasons:

Q is broken, and is always going to be. Changing it will cause even
more problems.

Adding a new element with a clear definition that can be implemented in
the same way, in all browsers, and ignored without problems, is an
improvement to the situation.

e.g. Someone said, <quote>"this is a pain."</quote> will be rendered as:

Someone said, "this is a pain."

Whether or not the browser knows there's a quote there, or not.

Quote is a better term than just q, likewise for other one letter tags.

An XHTML 2, or any other NEWER form of language, doesn't have to be the
same as the older versions. Older browsers will have problems with
newer languages, no matter what. Newer browsers should handle new
languages properly, and older ones as best as possible. Older documents
should be handled in the manner that the old specifications mention, and
newer documents, likewise.

--
My "from" address is totally fake. (Hint: If I wanted e-mails from
complete strangers, I'd have put a real one, there.) Reply to usenet
postings in the same place as you read the message you're replying to.
Jul 20 '05 #15

P: n/a
In article <pa****************************@goddamn.co.uk> in
comp.infosystems.www.authoring.html, Toby A Inkster
<Us******************@deadspam.com> wrote:
<quote xml:lang="en">"Hello"</quote>


I'm trying hard to understand what advantage that has over

"Hello"

but I'm failing.

--
Stan Brown, Oak Road Systems, Cortland County, New York, USA
http://OakRoadSystems.com/
HTML 4.01 spec: http://www.w3.org/TR/html401/
validator: http://validator.w3.org/
CSS 2 spec: http://www.w3.org/TR/REC-CSS2/
2.1 changes: http://www.w3.org/TR/CSS21/changes.html
validator: http://jigsaw.w3.org/css-validator/
Jul 20 '05 #16

P: n/a
Stan Brown:
<quote xml:lang="en">"Hello"</quote>
I'm trying hard to understand what advantage that has over "Hello" but I'm failing.


Let's say you want to do this:

quote {
font-style: italic;
}

You can of course add a meaningless "span" to your unstylable piece of
naked text, but wouldn't a meaningful element be better?

--
Bertilo Wennergren <be******@gmx.net> <http://www.bertilow.com>

Jul 20 '05 #17

P: n/a
Micah Cowan <mi***@cowan.name> wrote:
Every browser I've seen supports &ldquo;, &rdquo;,


Young boy!
Jul 20 '05 #18

P: n/a
Stan Brown wrote:
In article <pa****************************@goddamn.co.uk> in
comp.infosystems.www.authoring.html, Toby A Inkster
<Us******************@deadspam.com> wrote:
<quote xml:lang="en">"Hello"</quote>


I'm trying hard to understand what advantage that has over
"Hello"
but I'm failing.


You're right. Scrap it. Scrap <strong> too -- we can just mark important
text *like* *this*.

--
Toby A Inkster BSc (Hons) ARCS
Contact Me - http://www.goddamn.co.uk/tobyink/?id=132
playing://Random/peter_stuart_-_waiting_for_peace_to_come.ogg
Jul 20 '05 #19

P: n/a
"Jukka K. Korpela" <jk******@cs.tut.fi> writes:
Micah Cowan <mi***@cowan.name> wrote:
SHOULD and MUST are very different--formally.
Theoretically HTML 4 specifications use RFC language here, but in
practice their wording is not that formal.


The second paragraph of section 4 makes it 100% formal.
Anyway, by the RFC language,
the statement that browsers SHOULD "render quotation marks in a
language-sensitive manner" means that "there may exist valid reasons in
particular circumstances to ignore [that statement] particular item,
but the full implications must be understood and carefully weighed
before choosing a different course". So if an implementator has
understood the full implications etc. and decided not to make a user
agent behave that way, what makes us think that an author knows
better?
That's completely non-sequitur. The author is the *most*
qualified to make that decision, as it's *his* friggin' document,
and *his* choice of language. Even if it's not "correct", an
author has the right to exert such control over his own document,
and indeed the duty to do so if he wishes to achieve these results.
You *are* supposed
to use CSS if you want to force a conforming user-agent to Do The
Right Thing(TM).


No, of course not. First, HTML specifications do not postulate any use
of CSS. They are meant to be used without a style sheet, with CSS style
sheets, or with other style sheet.


The <style> element allows you to use any arbitrary style sheet
language, but CSS is specifically required for support of, e.g.,
style attributes.
Second, author style sheets (by
design and by implementation) certainly cannot force anything.
If the user agent claims to be conforming to HTML 4 and CSS Level
2, and the style sheet is active (by default or by user choice)
the rules specified must be obeyed above any defaults specified
by the "internal stylesheet".
Third, a
duplicate implementation of quotation mark rendering would be a shot in
the dark. A browser programmer can be in a position to _know_ that e.g.
curly quotes are not available in a rendering situation and use Ascii
quotation marks instead, and if an author style sheet tries to force
curly quotes, it could end up with having no quotes rendered.
If the programmer is in a position to know that they are not
available, he/she is in a position to substitute appropriate
characters, as is the case in some existing implementations.
Agreed about (en); although even if it had been correct, I didn't
post using an encoding that would have allowed more appropriate
ones.


Surely you could write a style sheet in Ascii only and yet use any
Unicode character in generated content.


I'm talking about the pasted snippet from my post, not a literal stylesheet.
As to (no); you're right, that's stupid. That's how they were in
the CSS2 standard, though (should've been &#x2039; and &#x203a; I
believe)


No, notations like &#x2039; have no meaning in CSS.


I realize that. I was just using the SGML convention for
specifying the characters I would have wanted (since I wasn't
posting in Unicode).
Use plain Ascii quotation marks


Why? Every browser I've seen supports &ldquo;, &rdquo;,
etc.


Then you haven't seen enough. Ascii quotation marks are _safe_, as I
wrote.


&ldquo; and &rdquo; are _safe_ too. And more typographically
correct--as you yourself have pointed out. They work on a huge
variety of user-agents, including non-graphical ones, etc. Where
they are not available, they are often substituted with your
ASCII favorites.
If you consider using real quotation marks, then you should at
least refrain from using those quasi-mnemonic entity references and use
character references instead.


They are required to be supported by HTML 4.0-conformant user
agents, and are much more readale when editing source. However, I
typically post-process my HTML files to replace those entity
references not required by HTML 3.2 with the equivalent character
references.

-Micah
Jul 20 '05 #20

P: n/a
In article <m3************@localhost.localdomain>, Micah Cowan wrote:

The <style> element allows you to use any arbitrary style sheet
language, but CSS is specifically required for support of, e.g.,
style attributes.


Wrong. Read closely Section 14.2.2.

--
Chris Hoess
Jul 20 '05 #21

P: n/a
Micah Cowan <mi***@cowan.name> wrote:
Theoretically HTML 4 specifications use RFC language here, but in
practice their wording is not that formal.


The second paragraph of section 4 makes it 100% formal.


Thanks for a good laugh. Seriously, you haven't actually studied the
HTML specification much if you think that it really sticks to RFC
language.

I think I will refrain from commenting further - there's too much
confusion in your ideas of forcing things in CSS, etc. Hang around and
you'll gradually see that.

--
Yucca, http://www.cs.tut.fi/~jkorpela/
Pages about Web authoring: http://www.cs.tut.fi/~jkorpela/www.html

Jul 20 '05 #22

P: n/a
In article <bm*************@news.t-online.com> in
comp.infosystems.www.authoring.html, Bertilo Wennergren
<be******@gmx.net> wrote:
Stan Brown:


[stripped attribution restored]
Toby A Inkster <Us******************@deadspam.com>
<quote xml:lang="en">"Hello"</quote>

I'm trying hard to understand what advantage that has over
"Hello"
but I'm failing.


Let's say you want to do this:
quote {
font-style: italic;
}
You can of course add a meaningless "span" to your unstylable piece of
naked text, but wouldn't a meaningful element be better?


No, I don't think so. More precisely, I don't think such a styling
in <quote> or <span> is ever appropriate. Maybe in other languages
things are different, but AFAIK in English inline quotes are not
styled differently from regular text.

--
Stan Brown, Oak Road Systems, Cortland County, New York, USA
http://OakRoadSystems.com/
HTML 4.01 spec: http://www.w3.org/TR/html401/
validator: http://validator.w3.org/
CSS 2 spec: http://www.w3.org/TR/REC-CSS2/
2.1 changes: http://www.w3.org/TR/CSS21/changes.html
validator: http://jigsaw.w3.org/css-validator/
Jul 20 '05 #23

P: n/a
Tim <ad***@sheerhell.lan> exclaimed in <au********************************@4ax.com>:
On Sun, 12 Oct 2003 22:50:24 GMT,
ti**@greytower.net (Tina Holmboe) wrote:
So far I have not seen a sensible explanation of why the *name* of
the element had to change.
The obvious reasons:

Q is broken, and is always going to be. Changing it will cause even
more problems.


Firstly, no - it is not obvious. An indication of that is that I wouldn't
ask if it was.

Secondly, am I to understand that:

Q is broken because not everyone agrees that (visual) UAs should
include language specific quotation marks. It is further broken
because very few (one?) (visual) UA today actually implements it
as it is specified. Changing the definition of Q to be more in line
what some believe it should be, and more in line of what is currently
implemented, will cause MORE problems.
That makes absolutely no sense at all. For the very last time:

* Q, today, is not commonly implemented per specs in visual UAs.
Therefore, changing the specs to come into line with how it IS
implemented will present no problems.

* Q, today, is understood by quite a few UAs, visual and non-visual,
whether rendered as suggested by the specs or not. Redefining the
way an UA should render Q will not change that, nor will it represent
a problem.

* Changing the definition AND the name will leave the above-mentioned
tools hanging out to dry. It will present no - NO - advantage over
changing the definition and KEEPING the name.

* And, finally, a visual UA that actually implements todays Q element
per specs would - if the definition was changed but the name kept -
in some circumstances render

<quote>"something"</quote>

as

""something""

That is hardly a major problem compared to the benefits of keeping
the meaning intact.


Quote is a better term than just q, likewise for other one letter tags.
Quite possibly. Breaking tools for the sake of the better term is a
terrible idea.

An XHTML 2, or any other NEWER form of language, doesn't have to be the
same as the older versions. Older browsers will have problems with
newer languages, no matter what. Newer browsers should handle new
Not if atleast some thought is given to backwards compatibility. An
HTML 4 UA can still make sense of an XHTML 2.0 document *if they don't
go changing the names for elements that retain the meaning*.

languages properly, and older ones as best as possible. Older documents
should be handled in the manner that the old specifications mention, and
newer documents, likewise.


... and new languages designed for public consumption should try to
retain backwards compatibility. Anything else is sheer folly.

--
- Tina Holmboe Greytower Technologies
ti**@greytower.net http://www.greytower.net/
[+46] 0708 557 905
Jul 20 '05 #24

P: n/a
Stan Brown:
I'm trying hard to understand what advantage that has over
"Hello"
but I'm failing.
Let's say you want to do this:
quote {
font-style: italic;
}
You can of course add a meaningless "span" to your unstylable piece of
naked text, but wouldn't a meaningful element be better?
No, I don't think so. More precisely, I don't think such a styling
in <quote> or <span> is ever appropriate. Maybe in other languages
things are different, but AFAIK in English inline quotes are not
styled differently from regular text.


That seems to rule out lots of use of styling. E.g.:

<strong>whatever</strong>

strong {
color: red;
background-color: white;
}

Never style a "span"? Never put a special background color on
a piece of text (logically marked up), because you dont do
that kind of thing in ordinary printed text?

And what about using a special voice to read quotes in a
voice browsers?

And how do we do this without using some mark-up?

Confucius said:
<quote cite="http://www.wisewords.org/confucius.html#bla">
"Bla, bla."
</quote>

--
Bertilo Wennergren <be******@gmx.net> <http://www.bertilow.com>

Jul 20 '05 #25

P: n/a
Tina Holmboe:
* And, finally, a visual UA that actually implements todays Q element
per specs would - if the definition was changed but the name kept -
in some circumstances render <quote>"something"</quote>
as
""something"" That is hardly a major problem compared to the benefits of keeping
the meaning intact.


Except it caters to those UA that _don't_ follow the specs, while
punishing those UAs (and their users) that _do_ follow the specs.

That seems like a strange practice, and a weird idea.

--
Bertilo Wennergren <be******@gmx.net> <http://www.bertilow.com>

Jul 20 '05 #26

P: n/a
Tina Holmboe wrote:
Q, today, is understood by quite a few UAs, visual and non-visual,


Such as?

--
Brian
follow the directions in my address to email me

Jul 20 '05 #27

P: n/a
In article <bm*************@news.t-online.com> in
comp.infosystems.www.authoring.html, Bertilo Wennergren
<be******@gmx.net> wrote:

(Once again, I have restored the attribution that you stripped out.
Please do not put other people's words in my mouth. How would you
like it if I used your name on a quote that you disagree with?)
Toby A Inkster <Us******************@deadspam.com>
Let's say you want to do this:
quote {
font-style: italic;
}
You can of course add a meaningless "span" to your unstylable piece of
naked text, but wouldn't a meaningful element be better?


Stan Brown:
No, I don't think so. More precisely, I don't think such a styling
in <quote> or <span> is ever appropriate. Maybe in other languages
things are different, but AFAIK in English inline quotes are not
styled differently from regular text.


That seems to rule out lots of use of styling. E.g.:

<strong>whatever</strong>

strong {
color: red;
background-color: white;
}

Never style a "span"?


That is not what I said. I said I don't think that styling a quote
in italics is appropriate, whether you use <quote> or <span> to do
it.

Of course there are all sorts of uses for styling <span>. But I
don't believe -- and again, somebody might well post a
counterexample to educate me -- I don't believe that it is ever
appropriate to style an inline quote in English differently from its
surrounding text.

--
Stan Brown, Oak Road Systems, Cortland County, New York, USA
http://OakRoadSystems.com/
HTML 4.01 spec: http://www.w3.org/TR/html401/
validator: http://validator.w3.org/
CSS 2 spec: http://www.w3.org/TR/REC-CSS2/
2.1 changes: http://www.w3.org/TR/CSS21/changes.html
validator: http://jigsaw.w3.org/css-validator/
Jul 20 '05 #28

P: n/a
Stan Brown wrote:
(Once again, I have restored the attribution that you stripped out.
Please do not put other people's words in my mouth. How would you
like it if I used your name on a quote that you disagree with?)
Toby A Inkster <Us******************@deadspam.com>
Let's say you want to do this:


Can anyone see the irony?

--
Toby A Inkster BSc (Hons) ARCS
Contact Me - http://www.goddamn.co.uk/tobyink/?id=132

Jul 20 '05 #29

P: n/a
Brian <us*****@mangymutt.com.invalid-remove-this-part> exclaimed in <LtKib.758870$Ho3.196014@sccrnsc03>:
Tina Holmboe wrote:
Q, today, is understood by quite a few UAs, visual and non-visual,


Such as?


Mozilla ?

Opera ?

A number of UAs that process HTML and extract quotations ?

--
- Tina Holmboe Greytower Technologies
ti**@greytower.net http://www.greytower.net/
[+46] 0708 557 905
Jul 20 '05 #30

P: n/a
Tim
ti**@greytower.net (Tina Holmboe) wrote:
So far I have not seen a sensible explanation of why the *name* of
the element had to change.


Tim <ad***@sheerhell.lan>
The obvious reasons:

Q is broken, and is always going to be. Changing it will cause even
more problems.

ti**@greytower.net (Tina Holmboe) wrote:
Firstly, no - it is not obvious. An indication of that is that I wouldn't
ask if it was.

Secondly, am I to understand that:

Q is broken because not everyone agrees that (visual) UAs should
include language specific quotation marks. It is further broken
because very few (one?) (visual) UA today actually implements it
as it is specified.
Isn't that just why Q is broken?
Changing the definition of Q to be more in line
what some believe it should be, and more in line of what is currently
implemented, will cause MORE problems.
Isn't there no change to Q's definition, Q just disappears, and a new
element called Quote, that just happens to perform a similar function,
gets a better definition? People would use Q, if they did, and it'd be
handled just the same as Q was before (however the browser author
decided to handle it), but quote *might* get handled as the
specifications said.
Quote is a better term than just q, likewise for other one letter tags. Quite possibly. Breaking tools for the sake of the better term is a
terrible idea.
Thus, we should never have dropped HTML 3.2 and stayed there? All the
HTML language versions have progressed and made some elements obsolete,
some dropped completely.
An XHTML 2, or any other NEWER form of language, doesn't have to be the
same as the older versions. Older browsers will have problems with
newer languages, no matter what. Newer browsers should handle new Not if at least some thought is given to backwards compatibility. An
HTML 4 UA can still make sense of an XHTML 2.0 document *if they don't
go changing the names for elements that retain the meaning*.
It still can. It handles documents identified as HTML 4 as HTML 4
documents, and documents identified as XHTML 2.0 as XHTML 2.0, and so
on. Whatever the ranting views of various people, the doctype does have
a good potential use of identifying the type of document, so the
user-agent can handle it properly.
languages properly, and older ones as best as possible. Older documents
should be handled in the manner that the old specifications mention, and
newer documents, likewise.

... and new languages designed for public consumption should try to
retain backwards compatibility. Anything else is sheer folly.


So, you don't like HTML 4.01 either?

I disagree. The user-agent ought to be able to handle different
languages (including different versions), but I don't see that the
document language has to support every bit of rubbish that was
previously done.

--
My "from" address is totally fake. (Hint: If I wanted e-mails from
complete strangers, I'd have put a real one, there.) Reply to usenet
postings in the same place as you read the message you're replying to.
Jul 20 '05 #31

P: n/a
Tina Holmboe wrote:
Brian <us*****@mangymutt.com.invalid-remove-this-part> exclaimed in <LtKib.758870$Ho3.196014@sccrnsc03>:
Tina Holmboe wrote:
Q, today, is understood by quite a few UAs, visual and non-visual,
Such as?


Mozilla ?

Opera ?


We've been discussing those, but when I read "quite a few," I thought
maybe there were some special tools in addition to the 2 browsers that
render the quotes. (Since that's all they, I see no advantage to <q>
over using quotes in the text.)
A number of UAs that process HTML and extract quotations ?


ok, *such as*?

--
Brian
follow the directions in my address to email me

Jul 20 '05 #32

P: n/a
I V
On Tue, 14 Oct 2003 16:52:25 +0000, Brian wrote:
Tina Holmboe wrote:
Brian <us*****@mangymutt.com.invalid-remove-this-part> exclaimed in <LtKib.758870$Ho3.196014@sccrnsc03>:
Tina Holmboe wrote:

Q, today, is understood by quite a few UAs, visual and non-visual,

Such as?


Mozilla ?

Opera ?


We've been discussing those, but when I read "quite a few," I thought
maybe there were some special tools in addition to the 2 browsers that
render the quotes. (Since that's all they, I see no advantage to <q>
over using quotes in the text.)


That's not quite true. Mozilla lets you access he URL in the 'cite'
attribute from the context menu. The UI is pretty awful, but it does at
least allow users to view the information.

--
"Okay, this time I'm Poison Ivy, you're Harley Quinn, and we're pulling a
daring heist of an adult novelty goods store."
http://www.huh.34sp.com/

Jul 20 '05 #33

P: n/a
Brian <us*****@mangymutt.com.invalid-remove-this-part> exclaimed in <dRVib.774038$uu5.134604@sccrnsc04>:
A number of UAs that process HTML and extract quotations ?


ok, *such as*?


That, Brian, was - I'm sorry to say - predictable. Sorry, I don't have
an extensive list. The two I know of is my own quote extracting gimmick and
the script Mark P. is using.

There are others, afaik. I'm sure Google can help.

--
- Tina Holmboe Greytower Technologies
ti**@greytower.net http://www.greytower.net/
[+46] 0708 557 905
Jul 20 '05 #34

P: n/a
In article <pa****************************@goddamn.co.uk> in
comp.infosystems.www.authoring.html, Toby A Inkster
<Us******************@deadspam.com> wrote:
Stan Brown wrote:
(Once again, I have restored the attribution that you stripped out.
Please do not put other people's words in my mouth. How would you
like it if I used your name on a quote that you disagree with?)
Toby A Inkster <Us******************@deadspam.com>
>Let's say you want to do this:


Can anyone see the irony?


You mean, because you use an obviously fake address and do it in
the wrong way?

The alternatives are to use what information, poor as it is, you
give, or to falsely attribute(*) your words, which I do not agree
with, to me.

(*) Yes, I know. See Fowler at "split infinitive".

--
Stan Brown, Oak Road Systems, Cortland County, New York, USA
http://OakRoadSystems.com/
HTML 4.01 spec: http://www.w3.org/TR/html401/
validator: http://validator.w3.org/
CSS 2 spec: http://www.w3.org/TR/REC-CSS2/
2.1 changes: http://www.w3.org/TR/CSS21/changes.html
validator: http://jigsaw.w3.org/css-validator/
Jul 20 '05 #35

P: n/a
Stan Brown <th************@fastmail.fm> writes:
In article <bm*************@news.t-online.com> in
comp.infosystems.www.authoring.html, Bertilo Wennergren
<be******@gmx.net> wrote:
Stan Brown:


[stripped attribution restored]
Toby A Inkster <Us******************@deadspam.com>
<quote xml:lang="en">"Hello"</quote>

I'm trying hard to understand what advantage that has over
"Hello"
but I'm failing.


Let's say you want to do this:
quote {
font-style: italic;
}
You can of course add a meaningless "span" to your unstylable piece of
naked text, but wouldn't a meaningful element be better?


No, I don't think so. More precisely, I don't think such a styling
in <quote> or <span> is ever appropriate. Maybe in other languages
things are different, but AFAIK in English inline quotes are not
styled differently from regular text.


Not true. I have read many books where inline quotes were
indicated by italics. Sometimes this was 100% consistent, and
other times it is frequently used (even in modern books) to
indicate "thought"-quotes. In ths case a "class" attribute might
be appropriate.

However, I agree that <quote xml:lang="en">"Hello"</quote> has no
advantage over "Hello" ... but <quote xml:lang="en">Hello</quote>
does. In particular, it places the burden of having to remember
what level of quotations to use upon the user agent, instead of
the author; and it allows you to easily quote a section of text
that contains a quote: you merely wrap another <quote/> around it
without having to change double-quotes to singles, etc.

-Micah
Jul 20 '05 #36

P: n/a
Stan Brown <th************@fastmail.fm> writes:
In article <bm*************@news.t-online.com> in
comp.infosystems.www.authoring.html, Bertilo Wennergren
<be******@gmx.net> wrote:

(Once again, I have restored the attribution that you stripped out.
Please do not put other people's words in my mouth. How would you
like it if I used your name on a quote that you disagree with?)
Toby A Inkster <Us******************@deadspam.com>
Let's say you want to do this:
quote {
font-style: italic;
}
You can of course add a meaningless "span" to your unstylable piece of
naked text, but wouldn't a meaningful element be better?


Stan Brown:
No, I don't think so. More precisely, I don't think such a styling
in <quote> or <span> is ever appropriate. Maybe in other languages
things are different, but AFAIK in English inline quotes are not
styled differently from regular text.


That seems to rule out lots of use of styling. E.g.:

<strong>whatever</strong>

strong {
color: red;
background-color: white;
}

Never style a "span"?


That is not what I said. I said I don't think that styling a quote
in italics is appropriate, whether you use <quote> or <span> to do
it.


Yes it is, though it may not have been what you meant. Read your
quote above again.

-Micah
Jul 20 '05 #37

P: n/a
Stan Brown <th************@fastmail.fm> writes:
In article <pa****************************@goddamn.co.uk> in
comp.infosystems.www.authoring.html, Toby A Inkster
<Us******************@deadspam.com> wrote:
Stan Brown wrote:
(Once again, I have restored the attribution that you stripped out.
Please do not put other people's words in my mouth. How would you
like it if I used your name on a quote that you disagree with?)

> Toby A Inkster <Us******************@deadspam.com>
>>Let's say you want to do this:


Can anyone see the irony?


You mean, because you use an obviously fake address and do it in
the wrong way?


No, because you attribute to Toby A Inkster a quote which in fact
originated from Bertilo Wennergren, whilst you complain about
incorrect attributions to you (which I can't seem to find -- the
quoting levels make it entirely obvious which quotes are yours
and which aren't--though I'll agree that *all* levels should have
been properly attributed for absolute clarity). It's pretty
ironic to me, too :-)

This seems very much like the stereotypical spelling or grammar
corrections, which are of course obliged to contain at least one
such error in the complaint.

-Micah
Jul 20 '05 #38

P: n/a
Andreas Prilop <nh******@rrzn-user.uni-hannover.de> writes:
Micah Cowan <mi***@cowan.name> wrote:
Every browser I've seen supports &ldquo;, &rdquo;,


Young boy!


(Sorry I didn't obey the Followup-To header; mainly because I
don't understand why it broke the cross-post, and because I do
not read the c.i.w.a.h [yet]).

Yeah, you're right: I'm mistaken (for some reason, I'd thought
they were included in the entities for 3.2; obviously
not). However, every *current* browser I've seen supports them,
and the character reference equivalents (to which I frequently
convert these through postprocesing) are supported by the
previous generation of browsers. I don't encounter too many
people still surfing with browsers much older than that, so am
not too concerned; especially since those browsers would have
bigger issues with other standard-conformant but not
backwards-compatible facilities I frequently use.

-Micah
Jul 20 '05 #39

P: n/a
"Jukka K. Korpela" <jk******@cs.tut.fi> writes:
Micah Cowan <mi***@cowan.name> wrote:
Theoretically HTML 4 specifications use RFC language here, but in
practice their wording is not that formal.


The second paragraph of section 4 makes it 100% formal.


Thanks for a good laugh. Seriously, you haven't actually studied the
HTML specification much if you think that it really sticks to RFC
language.


I'd be much happier if you'd actually produce some quotes from
the spec to back up that statement, rather than just haughtily
assert that my notion is laughable. In particular, I can't think
of many instances in which you can prove that a specification
didn't mean "must" where it says "must", and "should" where it
says "should". And, in *particular*, I see no reason why you
should not interpret the "should" in 9.2.2, which we were
discussing, in accordance with the RFC language--especially since
the spec itself tells you to. After all, if you can't treat a
spec as law, then what good is a spec? Better to buy a book that
teaches you all sorts of non-conformant but "de facto standard"
extensions and base your code on that :-(

I'll concede the point about requiring CSS; so I will modify my
previous assertion to "you are *supposed* to use style sheets to
indicate your preferences for the handling of <q>"; there, does
that make you happier?

For my part, the mere fact that the W3C recommends their use
instead of typing quotation marks directly (see, e.g., checkpoint
3.7 of the WCAG) gives me pause to dismiss them, and a comparison
of the relative advantages/disadvantages to using typed-in
quotation marks causes me to conclude that would not a poor
practice to prefer to use <q> (were it not for the fact that it
is not well-supported by a certain browser with very large
market-share). This doesn't stop me from writing my DocBook XML
stuff using the <quote> element, though; and the major advantage
to this is that I can choose to convert these to XHTML <q> in my
XSLT stylesheets once they are well-supported in the mainstream;
but convert them to suitable quote-mark characters in the
meantime.

The only actual disadvantage to <q> that I can see is in the case
of long quotations containing actual paragraph breaks (for
example, in conversations), since each new paragraph should being
with opening quote-marks; but in this case, the quote doesn't
really fit the qualification of "inline quote".

-Micah
Jul 20 '05 #40

P: n/a
On Wed, 15 Oct 2003, Micah Cowan wrote:
Andreas Prilop <nh******@rrzn-user.uni-hannover.de> writes:
Micah Cowan <mi***@cowan.name> wrote:
Every browser I've seen supports &ldquo;, &rdquo;,
Young boy!

[...] Yeah, you're right: I'm mistaken (for some reason, I'd thought
they were included in the entities for 3.2; obviously
not). However, every *current* browser I've seen supports them,
fair comment, but:
and the character reference equivalents (to which I frequently
convert these through postprocesing) are supported by the
previous generation of browsers.


So it seems you have no need to advocate use of the entity names!
While the difference in coverage can now be considered quite small,
and some would deem it no longer of any significance, the fact is that
one does get somewhat wider coverage with &#bignumber; notation for
these characters, than with the &entityname; notations which HTML4
defined.

The only other consideration I could think of is that some of the
entity names, such as &trade; , &Omega; etc are immediately intuitive
(if somewhat messy) if the browser doesn't understand them - and
therefore displays them as coded. Whereas browsers that are too old
(or incomplete - see WebTV) to understand &#bignumber; notation are
liable to display something incomprehensible and/or silly.

But by now I wouldn't consider that to be a substantive argument. If
folks choose to use old or incomplete software, I'm willing to go some
way - as far as it doesn't disadvantage other users - to maintaining
compatibility, but I see no call for heroic measures.
Jul 20 '05 #41

P: n/a
Stan Brown wrote:
Toby A Inkster wrote:
Can anyone see the irony?


You mean, because you use an obviously fake address and do it in
the wrong way?


No, because you complain about misattributing quotes and in the same post
misattribute a quote which Bertilo said to me.

And the address is real.

--
Toby A Inkster BSc (Hons) ARCS
Contact Me - http://www.goddamn.co.uk/tobyink/?id=132

Jul 20 '05 #42

P: n/a
In article <m3************@localhost.localdomain> in
comp.infosystems.www.authoring.html, Micah Cowan <mi***@cowan.name>
wrote:
Stan Brown <th************@fastmail.fm> writes:
That is not what I said. I said I don't think that styling a quote
in italics is appropriate, whether you use <quote> or <span> to do
it.


Yes it is, though it may not have been what you meant. Read your
quote above again.


I have done so, and I stand by what I said.

--
Stan Brown, Oak Road Systems, Cortland County, New York, USA
http://OakRoadSystems.com/
HTML 4.01 spec: http://www.w3.org/TR/html401/
validator: http://validator.w3.org/
CSS 2 spec: http://www.w3.org/TR/REC-CSS2/
2.1 changes: http://www.w3.org/TR/CSS21/changes.html
validator: http://jigsaw.w3.org/css-validator/
Jul 20 '05 #43

P: n/a
In article <pa***************************@goddamn.co.uk> in
comp.infosystems.www.authoring.html, Toby A Inkster
<Us******************@deadspam.com> wrote:
Stan Brown wrote:
Toby A Inkster wrote:
Can anyone see the irony?
You mean, because you use an obviously fake address and do it in
the wrong way?


No, because you complain about misattributing quotes and in the same post
misattribute a quote which Bertilo said to me.


I have tried and failed to figure out who said what -- because
Bertilo persisted in snipping attributions and I was working from
his article, which I replied to.
And the address is real.


Yeah, right.

--
Stan Brown, Oak Road Systems, Cortland County, New York, USA
http://OakRoadSystems.com/
HTML 4.01 spec: http://www.w3.org/TR/html401/
validator: http://validator.w3.org/
CSS 2 spec: http://www.w3.org/TR/REC-CSS2/
2.1 changes: http://www.w3.org/TR/CSS21/changes.html
validator: http://jigsaw.w3.org/css-validator/
Jul 20 '05 #44

P: n/a
Stan Brown wrote:
Toby A Inkster wrote:
Stan Brown wrote:
You mean, because you use an obviously fake address and do it in
the wrong way?


And the address is real.


Yeah, right.


If you don't believe me, send an e-mail.

--
Toby A Inkster BSc (Hons) ARCS
Contact Me - http://www.goddamn.co.uk/tobyink/?id=132

Jul 20 '05 #45

P: n/a
"Alan J. Flavell" <fl*****@ph.gla.ac.uk> writes:
On Wed, 15 Oct 2003, Micah Cowan wrote:
Andreas Prilop <nh******@rrzn-user.uni-hannover.de> writes:
Micah Cowan <mi***@cowan.name> wrote:

> Every browser I've seen supports &ldquo;, &rdquo;,

Young boy!
[...]
Yeah, you're right: I'm mistaken (for some reason, I'd thought
they were included in the entities for 3.2; obviously
not). However, every *current* browser I've seen supports them,


fair comment, but:
and the character reference equivalents (to which I frequently
convert these through postprocesing) are supported by the
previous generation of browsers.


So it seems you have no need to advocate use of the entity names!
While the difference in coverage can now be considered quite small,
and some would deem it no longer of any significance, the fact is that
one does get somewhat wider coverage with &#bignumber; notation for
these characters, than with the &entityname; notations which HTML4
defined.


Yes, and I do try to prefer the character references. However,
the entity names are much easier to remember (for me), and I tend
to hand-write code using those. If I'm concerned about coverage,
I will post-process.

Of course, there are many much older entity names which I have no
problem with keeping in my production HTML, because they've been
in the HTML standards from the beginning (though IIRC, they
weren't *required* in 2.0).
The only other consideration I could think of is that some of the
entity names, such as &trade; , &Omega; etc are immediately intuitive
(if somewhat messy) if the browser doesn't understand them - and
therefore displays them as coded. Whereas browsers that are too old
(or incomplete - see WebTV) to understand &#bignumber; notation are
liable to display something incomprehensible and/or silly.
Weren't character references *always* a part of SGML/HTML? I
realize that doesn't do anything for broken browsers, but "too
old"? (I'm afraid that I am a bit young to remember much about
Mosaic and that generation...)
But by now I wouldn't consider that to be a substantive argument. If
folks choose to use old or incomplete software, I'm willing to go some
way - as far as it doesn't disadvantage other users - to maintaining
compatibility, but I see no call for heroic measures.


Agreed here. :-)

-Micah
Jul 20 '05 #46

P: n/a
On Thu, 16 Oct 2003, Micah Cowan wrote:
Of course, there are many much older entity names which I have no
problem with keeping in my production HTML, because they've been
in the HTML standards from the beginning (though IIRC, they
weren't *required* in 2.0).


May I congratulate you on the accuracy of your historical detail?

In fact, Netscape were so late[1] in finally implementing those
character entity names that had been proposed in HTML/2.0/RFC1866,
that for a while the entities were on the verge of being taken out of
HTML3.2; but they finally made it.

[1] long after other browsers of the time had implemented them, I
mean.

(And history repeated itself with HTML4 and NN4.*, as you're clearly
aware).
The only other consideration I could think of is that some of the
entity names, such as &trade; , &Omega; etc are immediately intuitive
(if somewhat messy) if the browser doesn't understand them - and
therefore displays them as coded. Whereas browsers that are too old
(or incomplete - see WebTV) to understand &#bignumber; notation are
liable to display something incomprehensible and/or silly.


Weren't character references *always* a part of SGML/HTML?


Oh yes, but in SGML the number which appears on the &#number; notation
relates to the "Document Character Set", and, up until RFC2070 set out
the plan for HTML to use iso-10646/Unicode as the "Document Character
Set" regardless of what external coding was in use (that
misleadingly-named "charset" parameter from the MIME specification),
there were many browsers which behaved as if the document character
set contained only 256 code points (8-bit character set) and was
aligned to whatever external character coding was in use.

WebTV still seems to behave on that basis (except that, judging from
its developer viewer, at least, there's only one character set and
coding which it implements: a somewhat stripped-down version of
Windows-1252).

Indeed, for an 8-bit character architecture it was the obvious thing
to do, in the short term, because basically the browser developer just
fed the 8-bit characters to the system's existing display routines:
it needed a lot more work (and understanding and expertise) to support
Unicode, back when operating systems themselves had no support and
browser authors has to spin their own as part of the browser design (I
think for example of Alis Tango browser, which implemented Unicode -
but ran on Windows/3.x OS, that had no Unicode support itself).

But now it's all coming together - in various ways, but all supporting
the same underlying concept (the black-box character model described
in RFC2070).

cheers
Jul 20 '05 #47

P: n/a
Micah Cowan <mi***@cowan.name> wrote:
"Jukka K. Korpela" <jk******@cs.tut.fi> writes:
Micah Cowan <mi***@cowan.name> wrote:
>> Theoretically HTML 4 specifications use RFC language here, but
>> in practice their wording is not that formal.
>
> The second paragraph of section 4 makes it 100% formal.
Thanks for a good laugh. Seriously, you haven't actually studied
the HTML specification much if you think that it really sticks to
RFC language.


I'd be much happier if you'd actually produce some quotes from
the spec to back up that statement, rather than just haughtily
assert that my notion is laughable.


I'm sorry, but it really is a matter of experience with reading the
HTML 4 specifications. If you read them for a while, with your mind
oriented towards considering exactness and conformance to rules and
specifications, you will soon realize that they are loose prose, rather
than an exact specification. I'll skip the question whether the
paragraph mentioned even tries to be _formal_, so let's just discuss
exactness (which can be formalized or non-formalized).

In section 4, http://www.w3.org/TR/html4/conform.html , the spec says:
"The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. However, for
readability, these words do not appear in all uppercase letters in this
specification."
The spec uses the odd, non-RFC-style phrase "we recommend that" too.
Should they be read as being identical with "it is recommended that"?
Even if we, rather unnaturally, assume that the answer is negative, you
will find lots of occasions where those key words are used so that they
hardly carry their RFC meanings. For example, B.1 Notes on invalid
documents http://www.w3.org/TR/html4/appendix/notes.html#h-B.1
plays with those words, yet begins with a nullifying disclaimer:
"The following notes are informative, not normative. Despite the
appearance of words such as "must" and "should", all requirements in
this section appear elsewhere in the specification."
What's the idea of using those words at all in an _informative_
appendix? And if all the requirements in the appendix (which is OTOH
said to be informative, i.e. contain no requirements) appear elsewhere,
then we apparently need to read between the lines a lot.

OK, enough said. The HTML 4 specification is nowhere near an exact
specification, and doesn't even really try. (And it contains some
formalized parts, mainly the DTDs and DTD fragments, but these in turn
are to be taken with quite some salt - as we know, HTML wasn't _really_
meant to be an SGML application.)
I'll concede the point about requiring CSS; so I will modify my
previous assertion to "you are *supposed* to use style sheets to
indicate your preferences for the handling of <q>"; there, does
that make you happier?
No, not at all. The theory behind <q> says that browsers should use
language-specific quotation marks, and elsewhere the specification says
quite a lot (though sloppily formulated) about language markup, so if
the spec *supposes* something in this respect, it's this: you're
supposed to use lang attributes, and browsers are supposed to know and
apply the rules of different languages. (CSS might conceivably be used
to express the author's preference on presentational details when a
language has several alternative styles of using quotation marks, as
some languages have.)
For my part, the mere fact that the W3C recommends their use
instead of typing quotation marks directly (see, e.g., checkpoint
3.7 of the WCAG) gives me pause to dismiss them,
Thanks for pointing that out. I'm currently writing some practical
instructions on applying WCAG, and I need to remember to mention that
"checkpoint" 3.7 is mostly nonsense and conflicts even with the way W3C
is going. - Using blockquote for block quotations is OK but hardly
sufficient - speech browsers don't do indents, and neither do most of
them express blockquote markup in any other way, so for accessibility,
the author needs to word his document so that by merely reading it
aloud, it is sufficiently obvious which parts are quoted and which are
not. Well, someone might say that if you do this for inline quotations
too, _then_ you can use <q> markup. You can use it when you don't need
it. But it's better to use quotation marks even then, since _they_ give
an additional hint to all people who see the document.
This doesn't stop me from writing my DocBook XML
stuff using the <quote> element, though;
Naturally you can use any suitable approach there.
and the major advantage
to this is that I can choose to convert these to XHTML <q> in my
XSLT stylesheets once they are well-supported in the mainstream;


That can hardly be a major advantage, since that time will never come.
The <q> is element is to be removed sooner than any major changes take
place on the browser front. But maybe you can use the <quote> element.
In fact you could in practice do it right away, since browsers are
expected to ignore tags that they don't recognize.

--
Yucca, http://www.cs.tut.fi/~jkorpela/
Pages about Web authoring: http://www.cs.tut.fi/~jkorpela/www.html

Jul 20 '05 #48

P: n/a
Jukka K. Korpela wrote:
from recognizing strings delimited by quotation marks. (One might
consider treating <blockquote> as indicating quotation, but abuse is so
widespread that this would not be pragmatically wise.)


Speaking about <blockquote>...

I've been reading this thread with interest, but I still can't make up
my mind about how to use <q> and <blockquote> (or <quote> and
<blockquote> in XHTML 2.0).

Indeed, short and long quotations should be surrounded by quotation
marks in some way. These quotation marks can either be included directly
in the (X)HTML document, or be rendered via stylesheets.

In my opinion, it would be more consistent to use one single method for
both <q> (or <quote>) and <blockquote>, i.e. directly in the content, or
via style.

We know that the style choice is not really usable as today: IE will
ignore generated content, Mozilla is unable to handle nested quotes, etc.

Ok, so we're left with including the quotation marks directly in the
content, which makes sense because, after all, quotation marks are
nothing more than punctuation signs.

Now I read somewhere that in this case, quotation marks should ideally
appear outside of <quote> element, like this: "<quote>quotation</quote>"
instead of <quote>"quotation"</quote>

Fine. But then, what about <blockquote> ? Considering that a typical
<blockquote> looks like:
<blockquote><p>first paragraph</p><p>second paragraph></blockquote>

where should we put the quotation marks ? Outside of the <blockquote> ?
But then they will appear on a single line because <blockquote> and <p>
are block elements. Inside of the first <p> and the last <p> (or any
suitable combination), but then we have quotation marks inside a
quotation wich we wanted to avoid in the case of <quote>...

So I have this feeling that we will only have a consistent, unique
method to delimit quotations when rendering via stylesheet is widely
implemented (which can take a while, I agree...)

Or do you have any wise advice ?

--
to email me, add "poinot" before the at-sign in my
address and wanadoo after it...

Jul 20 '05 #49

P: n/a
Vincent wrote:
Fine. But then, what about <blockquote> ? Considering that a typical
<blockquote> looks like:
<blockquote><p>first paragraph</p><p>second paragraph></blockquote>

where should we put the quotation marks ? Outside of the <blockquote> ?


Well, the best answer is that you don't! Large quoted sections are best
identified by indenting and then maybe italicising.

If you did want to add quote marks:

<blockquote><p>'first paragraph</p><p>'second paragraph'</p></blockquote>

(Note: no closing quote in first paragraph. This is consitant with proper
English punctuation. Indeed, this post assumes that the page language and
thus quoting style is English.)

--
Toby A Inkster BSc (Hons) ARCS
Contact Me - http://www.goddamn.co.uk/tobyink/?id=132
Jul 20 '05 #50

63 Replies

This discussion thread is closed

Replies have been disabled for this discussion.