|
P: n/a
|
From: "Alan J. Flavell" <fl*****@ph.gla.ac.uk>
Subject: Re: zen question
Date: 17. lipanj 2004 9:29
On Wed, 16 Jun 2004, Laurence Tureaud wrote, quoting: a resource we can all refer to when making the case for <acronym
title="Cascading Style Sheets">CSS</acronym>-based design.
"CSS" is not an acronym, though. | |
Share this Question
|
P: n/a
|
On Thu, 17 Jun 2004 12:44:22 +0200, Berislav Lopac
<be************@dimedia.hr> wrote: From: "Alan J. Flavell" <fl*****@ph.gla.ac.uk>
Subject: Re: zen question
Date: 17. lipanj 2004 9:29
On Wed, 16 Jun 2004, Laurence Tureaud wrote, quoting:
a resource we can all refer to when making the case for <acronym
title="Cascading Style Sheets">CSS</acronym>-based design.
"CSS" is not an acronym, though.
That entirely depends on your definition of "acronym". Several dependable
dictionaries I've consulted define "acronym" without mention of it having
to be pronounceable. The W3 specs don't make it clear either.
Surely we can agree on a few things here, though: an acronym can also be
considered an abbr; IE won't do abbr; no UA's I'm aware of do anything
special with acronym that they don't do with abbr (other than IE observing
it and not the other). So I'm, frankly, inclined to look the other way if
acronym is misused (which I'm not convinced it is here anyway), being that
there no known loss in accessibility or usability. | |
|
P: n/a
|
Neal wrote: I'm, frankly, inclined to look the
other way if acronym is misused (which I'm not convinced it is here
anyway), being that there no known loss in accessibility or usability.
For my part, I'm confuses as to why the w3c felt the need to have both
<acronym> and <abbr>. Why not <abbr> with optional attribute
type="acronym"? I wonder too about things like <OL> and <UL>. Had it
been my choice, I think I'd have gone with <LIST>, again with optional
attribute type="ordered".
--
Brian (remove ".invalid" to email me) http://www.tsmchughs.com/ | |
|
P: n/a
|
"Neal" <ne*****@yahoo.com> wrote in message
news:op**************@news.individual.net... On Thu, 17 Jun 2004 12:44:22 +0200, Berislav Lopac
<be************@dimedia.hr> wrote:
From: "Alan J. Flavell" <fl*****@ph.gla.ac.uk>
Subject: Re: zen question
Date: 17. lipanj 2004 9:29
On Wed, 16 Jun 2004, Laurence Tureaud wrote, quoting:
a resource we can all refer to when making the case for <acronym
title="Cascading Style Sheets">CSS</acronym>-based design.
"CSS" is not an acronym, though.
That entirely depends on your definition of "acronym". Several dependable
dictionaries I've consulted define "acronym" without mention of it having
to be pronounceable.
Can you check again to make sure they don't say it has to be a *word*? All
the resources I trust specify that an acronym is a *word* created from the
initials of other words. I would argue that "CSS" is not a word.
The W3 specs don't make it clear either.
The specs do make it clear what *they* think: they include "GmbH" and
"F.B.I." as abbreviations that they consider to be acronyms. However, they
didn't invent the word "acronym", nor are they a group of experienced
lexicographers, so nothing they say about the meaning of the word is
dispositive. OTOH, as you observe below, they don't really make it clear why
acronyms and abbreviations need distinct tags anyway, and as the W3
indicates, there are abbreviations (like "SQL") that are spoken both ways,
so they could just as well have used ABBR for both, so practically speaking
it likely doesn't matter.
Surely we can agree on a few things here, though: an acronym can also be
considered an abbr; IE won't do abbr; no UA's I'm aware of do anything
special with acronym that they don't do with abbr (other than IE observing
it and not the other). So I'm, frankly, inclined to look the other way if
acronym is misused (which I'm not convinced it is here anyway), being that
there no known loss in accessibility or usability. | |
|
P: n/a
|
"Brian" <us*****@julietremblay.com.invalid> wrote in message
news:10*************@corp.supernews.com... Neal wrote:
I'm, frankly, inclined to look the
other way if acronym is misused (which I'm not convinced it is here
anyway), being that there no known loss in accessibility or usability.
For my part, I'm confuses as to why the w3c felt the need to have both
<acronym> and <abbr>. Why not <abbr> with optional attribute
type="acronym"? I wonder too about things like <OL> and <UL>. Had it
been my choice, I think I'd have gone with <LIST>, again with optional
attribute type="ordered".
I agree with LIST instead of OL and UL, but I don't know about the type
attribute. Indicating that the markers should be bullets or roman numerals
or whatever takes care of that. While bulleted lists don't have their order
indicated by the markers, they are nevertheless ordered in the sense that it
would be unacceptable for a UA to render the items in different order from
the one in which they appear in the HTML. | |
|
P: n/a
|
"Harlan Messinger" <h.*********@comcast.net> writes: I agree with LIST instead of OL and UL, but I don't know about the type
attribute. Indicating that the markers should be bullets or roman numerals
or whatever takes care of that. While bulleted lists don't have their order
indicated by the markers, they are nevertheless ordered in the sense that it
would be unacceptable for a UA to render the items in different order from
the one in which they appear in the HTML.
Would it? If it's an unordered list, then the final display order
should be arbitrary. I don't know of any UAs that sort the output into
a different order (alphabetic?) but if it's a real UL, and not an OL
that has "list-style-type: disc" or similar, it shouldn't matter.
--
Chris | |
|
P: n/a
|
"Chris Morris" <c.********@durham.ac.uk> wrote in message
news:87************@dinopsis.dur.ac.uk... "Harlan Messinger" <h.*********@comcast.net> writes: I agree with LIST instead of OL and UL, but I don't know about the type
attribute. Indicating that the markers should be bullets or roman
numerals or whatever takes care of that. While bulleted lists don't have their
order indicated by the markers, they are nevertheless ordered in the sense
that it would be unacceptable for a UA to render the items in different order
from the one in which they appear in the HTML.
Would it? If it's an unordered list, then the final display order
should be arbitrary.
How often, in the real world, would someone type a list of items and then
have a desire to indicate explicitly that the UA should feel free to display
them in another, arbitrary, order?
I don't know of any UAs that sort the output into
a different order (alphabetic?) but if it's a real UL, and not an OL
that has "list-style-type: disc" or similar, it shouldn't matter. | |
|
P: n/a
|
On Thu, 17 Jun 2004, Brian wrote: For my part, I'm confuses as to why the w3c felt the need to have both
<acronym> and <abbr>.
*They* were confused, too! The discussions showed clearly that
everyone participating was quite certain what the word "acronym" meant
and thus needed no definition in the spec, and that everyone who said
otherwise was wrong. Unfortunately, the meanings of which they
claimed to be so certain were all different...
OK, so why did they put <acronym> and <abbr> into the spec, and not
any other kind of distinction? Well, the sceptics would say it was
because Netscape had already implemented <abbr> and MS had already
implemented <acronym> - so they both had to go into the spec or else
the Big Two wouldn't have accepted the spec.
More constructively, some participants reckoned that <acronym> would
give a valuable clue to speaking browsers. But that fails miserably
when you get folks who reckon that "F.B.I." (*with* the dots,
ferchrissake) is an "acronym".
So the W3folk stuffed both the tags into the spec, woffled vaguely
about what they meant, gave some examples (including the misleading
one just mentioned), and left the users to work it out. And when it
came to implementing this part of HTML4, MS sat on their hands, it
seems. | |
|
P: n/a
|
Harlan Messinger wrote: Brian wrote...
I wonder too about things like <OL> and <UL>. Had it been my
choice, I think I'd have gone with <LIST>, again with optional
attribute type="ordered".
I agree with LIST instead of OL and UL, but I don't know about the
type attribute. Indicating that the markers should be bullets or
roman numerals or whatever takes care of that. While bulleted lists
don't have their order indicated by the markers, they are
nevertheless ordered in the sense that it would be unacceptable for
a UA to render the items in different order from the one in which
they appear in the HTML.
Of course. It would be unacceptable for a ua to change the order of
any characters in the stream, too. Only presntations suggestions from
the author or user should change where an element would otherwise
appear in the document, no? But an UL, even where its LI elements are
specified by the author, does not mean the same thing as an OL.
--
Brian (remove ".invalid" to email me) http://www.tsmchughs.com/ | |
|
P: n/a
|
On Thu, 17 Jun 2004 13:20:01 -0400, Harlan Messinger
<h.*********@comcast.net> wrote: How often, in the real world, would someone type a list of items and then
have a desire to indicate explicitly that the UA should feel free to
display
them in another, arbitrary, order?
For me, the difference between OL and UL is that items in an OL are
intentionally sequential, whether in order of importance, relevance, time,
or other parameter(s). UL, on the other hand, could be put into other
orders if the author so desired, but this is not to say there's any reason
a UA should re-order a UL.
So I see a semantic reason for both UL and OL, in addition to a useful
purpose. (Let us remember that, while we strive to separate content from
presentation, some presentation must be considered for non-CSS rendering.)
Regarding <l marker="disc"> or <l marker="arabic"> - this would be
extendable to allow for all sorts of rendering possibilities. Though we'd
need to have a way to determine default performance if a UA does not
support what we requested, and it becomes something like <l
type="unordered" marker="circle"> or <l type="ordered" marker="romanlc"> -
or perhaps more compactly, <ul marker="circle"> and <ol marker="romanlc">
- then we wonder why the marker style is even necessary, and we're back to
<ol> and <ul>... so I don't see that as an improvement over what we
currently have.
Contrast this to <acronym> and <abbr> which are not really organic to
HTML, and which are marginally useful at best. For this reason I rarely if
ever have used these, and doubt I ever will. | |
|
P: n/a
|
"Neal" <ne*****@yahoo.com> wrote in message
news:op**************@news.individual.net... On Thu, 17 Jun 2004 13:20:01 -0400, Harlan Messinger
<h.*********@comcast.net> wrote:
How often, in the real world, would someone type a list of items and
then have a desire to indicate explicitly that the UA should feel free to
display
them in another, arbitrary, order?
For me, the difference between OL and UL is that items in an OL are
intentionally sequential, whether in order of importance, relevance, time,
or other parameter(s). UL, on the other hand, could be put into other
orders if the author so desired, but this is not to say there's any reason
a UA should re-order a UL.
If there is no reason at all why a UA would do anything differently because
the order of my list happens to be arbitrary (and if, in fact, the UA really
ought NOT to do anything differently), then there's no more reason to make
that fact explicit in markup than there is to indicate with markup that the
information contained in the list makes me sad, or that it was dictated to
me over the phone instead of copied and pasted from a Word document.
So I see a semantic reason for both UL and OL,
I don't.
in addition to a useful
purpose.
That either. | |
|
P: n/a
|
On Thu, 17 Jun 2004 11:36:01 -0400, Harlan Messinger
<h.*********@comcast.net> wrote:
"Neal" <ne*****@yahoo.com> wrote in message
news:op**************@news.individual.net... On Thu, 17 Jun 2004 12:44:22 +0200, Berislav Lopac
<be************@dimedia.hr> wrote:
> From: "Alan J. Flavell" <fl*****@ph.gla.ac.uk>
> Subject: Re: zen question
> Date: 17. lipanj 2004 9:29
>
> On Wed, 16 Jun 2004, Laurence Tureaud wrote, quoting:
>
>> a resource we can all refer to when making the case for <acronym
>> title="Cascading Style Sheets">CSS</acronym>-based design.
>
> "CSS" is not an acronym, though.
That entirely depends on your definition of "acronym". Several
dependable
dictionaries I've consulted define "acronym" without mention of it
having
to be pronounceable.
Can you check again to make sure they don't say it has to be a *word*?
All
the resources I trust specify that an acronym is a *word* created from
the
initials of other words. I would argue that "CSS" is not a word.
Direct quote from m-w.com:
: a word (as NATO, radar, or snafu) formed from the initial letter or
letters of each of the successive parts or major parts of a compound term;
also : an abbreviation (as FBI) formed from initial letters : INITIALISM
So, an initialism is a kind of acronym. The word acronym includes
initialisms in its definition; therefore <acronym> markup is applicable to
initialisms, at least per this definition.
Remember, dictionaries are descriptive, not proscriptive; proper
dictionaries reflect actual usage, and I must report I find m-w's
definition to be spot on with regards to how the term is actually used
(outside of linguistic circles where more precise terminology is, of
course, required). | |
|
P: n/a
|
"Neal" <ne*****@yahoo.com> wrote in message
news:op**************@news.individual.net... On Thu, 17 Jun 2004 11:36:01 -0400, Harlan Messinger
<h.*********@comcast.net> wrote:
"Neal" <ne*****@yahoo.com> wrote in message
news:op**************@news.individual.net... On Thu, 17 Jun 2004 12:44:22 +0200, Berislav Lopac
<be************@dimedia.hr> wrote:
> From: "Alan J. Flavell" <fl*****@ph.gla.ac.uk>
> Subject: Re: zen question
> Date: 17. lipanj 2004 9:29
>
> On Wed, 16 Jun 2004, Laurence Tureaud wrote, quoting:
>
>> a resource we can all refer to when making the case for <acronym
>> title="Cascading Style Sheets">CSS</acronym>-based design.
>
> "CSS" is not an acronym, though.
That entirely depends on your definition of "acronym". Several
dependable
dictionaries I've consulted define "acronym" without mention of it
having
to be pronounceable.
Can you check again to make sure they don't say it has to be a *word*?
All
the resources I trust specify that an acronym is a *word* created from
the
initials of other words. I would argue that "CSS" is not a word.
Direct quote from m-w.com:
: a word (as NATO, radar, or snafu) formed from the initial letter or
letters of each of the successive parts or major parts of a compound term;
also : an abbreviation (as FBI) formed from initial letters : INITIALISM
So, an initialism is a kind of acronym. The word acronym includes
initialisms in its definition; therefore <acronym> markup is applicable to
initialisms, at least per this definition.
Remember, dictionaries are descriptive, not proscriptive
Erm...usually the point made is that they are not prEscriptive... | |
|
P: n/a
|
On Thu, 17 Jun 2004 17:18:20 -0400, Harlan Messinger
<h.*********@comcast.net> wrote:
"Neal" <ne*****@yahoo.com> wrote in message
news:op**************@news.individual.net... For me, the difference between OL and UL is that items in an OL are
intentionally sequential, whether in order of importance, relevance,
time,
or other parameter(s). UL, on the other hand, could be put into other
orders if the author so desired, but this is not to say there's any
reason
a UA should re-order a UL.
If there is no reason at all why a UA would do anything differently
because
the order of my list happens to be arbitrary (and if, in fact, the UA
really
ought NOT to do anything differently), then there's no more reason to
make
that fact explicit in markup than there is to indicate with markup that
the
information contained in the list makes me sad, or that it was dictated
to
me over the phone instead of copied and pasted from a Word document.
Well, would you advocate doing unordered lists like:
<l>
<li>Lawyers</li>
<li>Guns</li>
<li>Money</li>
</l>
and ordered lists like:
<l>
<li>1. Bite</li>
<li>2. Chew</li>
<li>3. Swallow</li>
</l>
?
We can even replace dl with this by nesting a list.
<l>
<li>Acronym
<l>
<li>A word web authors argue about</li>
</l>
</li>
<li>Usenet
<l>
<li>A place web authors argue</li>
</l>
</li>
</l>
I can actually respect such a view - that the three li's are purely
presentational and have no semantic value.
But at least in the case of ol, there's another consideration - again, the
fact that users in a no-CSS environment need usable rendering, and doing
numbered lists like in my imaginary scenario above results in a poorer
rendering than a traditional ol. I don't feel the divorce of content and
presentation need go so far that non-CSS visual users must be faced with
poorer rendering because no attention is placed to their environment's
usability. | |
|
P: n/a
|
On Thu, 17 Jun 2004 17:24:19 -0400, Harlan Messinger
<h.*********@comcast.net> wrote:
"Neal" <ne*****@yahoo.com> wrote in message
news:op**************@news.individual.net... Remember, dictionaries are descriptive, not proscriptive
Erm...usually the point made is that they are not prEscriptive...
| |
|
P: n/a
|
Yikes! My client is getting assertive!
On Thu, 17 Jun 2004 17:24:19 -0400, Harlan Messinger
<h.*********@comcast.net> wrote: "Neal" <ne*****@yahoo.com> wrote in message
news:op**************@news.individual.net... Remember, dictionaries are descriptive, not proscriptive
Erm...usually the point made is that they are not prEscriptive...
One lousy letter off... :) But you know what I mean. | |
|
P: n/a
|
Neal wrote: would you advocate doing
This is purely academic, since backward compatability requires us to
use <ul> and <ol>. But I've thought about this before, so here goes:
unordered lists like:
<list>
<item>Lawyers</item>
<item>Guns</item>
<item>Money</item>
</list>
ordered lists like:
<list type="ordered">
<item>Bite</item>
<item>Chew</item>
<item>Swallow</item>
</list>
Definition list. I hadn't thought of this. Perhaps we could have
been parsimonious here, too, but I don't know. A definition list is
a sort of flexible array. I think it would actually be better to
have something like <dl>, but something more geneneral, to be used
for more than defining terms. How about complexlist?
<complexlist>
<item>Acronym<item>
<itemdesc>A word web authors argue about</itemdesc>
<item>Usenet</item>
<itemdesc>A place web authors argue</itemdesc>
</complexlist>
For that matter, an optional grouping element would be nice:
<complexlist>
<listgroup>
<item>Acronym<item>
<itemdesc>A word web authors argue about</itemdesc>
<itemdesc>
A word formed by taking the first letter
of several words; example: radar
</itemdesc>
<itemdesc>An element supported by Gatesware</itemdesc>
</listgroup>
<listgroup>
<item>Usenet</item>
<itemdesc>A place web authors argue</itemdesc>
</listgroup>
</complexlist>
We can even replace dl with this by nesting a list.
<l>
<li>Acronym
<l>
<li>A word web authors argue about</li>
</l>
</li>
<li>Usenet
<l>
<li>A place web authors argue</li>
</l>
</li>
</l>
Interesting approach, but it seems something is lost.
at least in the case of ol, there's another consideration - again,
the fact that users in a no-CSS environment need usable rendering,
I don't advocate eliminating the semantic notion of an ordered list.
Only that I'd have tried to keep is simple and self-documenting: a
<list> item, with an attribute type to declare the list as
containing ordered <item>s. CSS could be used to suggest Roman or
Arabic numbers, or letters, or....
--
Brian (remove ".invalid" to email me) http://www.tsmchughs.com/ | |
|
P: n/a
|
Neal <ne*****@yahoo.com> wrote: On Thu, 17 Jun 2004 17:18:20 -0400, Harlan Messinger
<h.*********@comcast.net> wrote:
"Neal" <ne*****@yahoo.com> wrote in message
news:op**************@news.individual.net... For me, the difference between OL and UL is that items in an OL are
intentionally sequential, whether in order of importance, relevance,
time,
or other parameter(s). UL, on the other hand, could be put into other
orders if the author so desired, but this is not to say there's any
reason
a UA should re-order a UL.
If there is no reason at all why a UA would do anything differently
because
the order of my list happens to be arbitrary (and if, in fact, the UA
really
ought NOT to do anything differently), then there's no more reason to
make
that fact explicit in markup than there is to indicate with markup that
the
information contained in the list makes me sad, or that it was dictated
to
me over the phone instead of copied and pasted from a Word document.
Well, would you advocate doing unordered lists like:
<l>
<li>Lawyers</li>
<li>Guns</li>
<li>Money</li>
</l>
and ordered lists like:
<l>
<li>1. Bite</li>
<li>2. Chew</li>
<li>3. Swallow</li>
</l>
?
I'm advocating what I said previously: have only one kind of list
element, and still provide the control over markers that exists now.
We can even replace dl with this by nesting a list.
This follows from what I said about not differentiating ordered lists
from unordered lists in the markup only if you ignore the reason I
gave for saying that.
<l>
<li>Acronym
<l>
<li>A word web authors argue about</li>
</l>
</li>
<li>Usenet
<l>
<li>A place web authors argue</li>
</l>
</li>
</l>
I can actually respect such a view - that the three li's are purely
presentational and have no semantic value.
But at least in the case of ol, there's another consideration - again, the
fact that users in a no-CSS environment need usable rendering, and doing
numbered lists like in my imaginary scenario above results in a poorer
rendering than a traditional ol.
True, but it's you who made up the way of producing item numbering
that you display above. *I* never suggested it was a good way.
I think you ought to reread my original comment, because you are now
consistently ignoring a key part of it: "I agree with LIST instead of
OL and UL, but I don't know about the type attribute. Indicating that
the markers should be bullets or roman numerals or whatever takes care
of that. While bulleted lists don't have their order indicated by the
markers, they are nevertheless ordered in the sense that it would be
unacceptable for a UA to render the items in different order from the
one in which they appear in the HTML."
I don't feel the divorce of content and
presentation need go so far that non-CSS visual users must be faced with
poorer rendering because no attention is placed to their environment's
usability.
You already agreed that, once CSS is used to determine the marker
type, UAs aren't going to distinguish between OL and UL lists, so what
poorer rending are you talking about now?
--
Harlan Messinger
Remove the first dot from my e-mail address.
Veuillez ôter le premier point de mon adresse de courriel. | |
|
P: n/a
|
Neal wrote: Surely we can agree on a few things here, though: an acronym can also be
considered an abbr; IE won't do abbr; no UA's I'm aware of do anything
special with acronym that they don't do with abbr (other than IE
observing it and not the other). So I'm, frankly, inclined to look the
other way if acronym is misused (which I'm not convinced it is here
anyway), being that there no known loss in accessibility or usability.
I use (misuse) acronym to highlight words in my text that I want to give
a definition of meaning for, on a school website. Is this incorrect
(well, I suppose I know it is incorrect). But is it forgivable? | |
|
P: n/a
|
On Fri, 18 Jun 2004, Ian Watts wrote: I use (misuse) acronym to highlight words in my text that I want to give
a definition of meaning for, on a school website. Is this incorrect
Yes. <dfn title="blah blah"> would be[1] an appropriate markup
for a defining instance; where the HTML spec offers an appropriate
element, then it's ipso facto incorrect to (mis)use anything else.
[1] along with appropriate CSS styling proposal(s), obviously (some
kind of dotted border seems to be a conventional choice). | |
|
P: n/a
|
Ian Watts wrote: I use (misuse) acronym to highlight words in my text that I want
to give a definition of meaning for, on a school website. Is this
incorrect (well, I suppose I know it is incorrect).
Exactly so. A. Flavell's solution seems pretty logical.
But is it forgivable?
Not if you knew better. ;-)
--
Brian (remove ".invalid" to email me) http://www.tsmchughs.com/ | |
|
P: n/a
|
Brian wrote: Ian Watts wrote:
But is it forgivable?
Not if you knew better. ;-)
I do now - thanks ;-) | |
|
P: n/a
|
On Thu, 17 Jun 2004, Stan Brown wrote: "CSS" is not an acronym, though.
Oh gawd. Not this again.
It's OK, I've made my point that "acronym" has a precise technical
meaning which might have been useful in HTML, but was sabotaged even
by some of the drafters of HTML4; and a sloppy usage that is of no
practical use to anyone. There's nothing to be gained by spinning it
out, but maybe there are some newcomers who weren't aware of the past
discussions. | | This discussion thread is closed Replies have been disabled for this discussion. | |  Question stats - viewed: 1827
- replies: 24
- date asked: Jul 20 '05
|
