On Wed, 23 Apr 2008, Jon Gibbins (dotjay) wrote:
For example, take that both abbr title=United States of
AmericaUSA/abbr and abbr title=United Space
AllianceUSA/abbr previously occurred in the document, and you
*don't* want, as an author, for every future use of either term to
On Thu, 27 Nov 2008, Calogero Alex Baldacchino wrote:
Perhaps a silly idea: what if abbreviations could work as an img-map
couple? That is, i.e., an abbr without a title could avail of a, let's
say, 'ref' attribute indicating the id of a previous abbr element with
a title, and the former
Ian Hickson ha scritto:
On Thu, 27 Nov 2008, Calogero Alex Baldacchino wrote:
Perhaps a silly idea: what if abbreviations could work as an img-map
couple? That is, i.e., an abbr without a title could avail of a, let's
say, 'ref' attribute indicating the id of a previous abbr element with
a
I am sorry to hear that cross-references are gone. The replacement you
suggest does not catch the difference between navigational and informational
hyperlinks. The difference is essential e.g. for GNU info: navigational
links are near jumps to child nodes; informational links can transport the
Ian Hickson wrote:
3) Documents that use the same acronym to mean different things in
different contexts/sections.
For example, take that both abbr title=United States of
AmericaUSA/abbr and abbr title=United Space AllianceUSA/abbr
previously occurred in the document, and you *don't* want,
2008/4/23 Ian Hickson [EMAIL PROTECTED]:
Summary: I've made the title= attribute on abbr optional again.
Maybe we need a smart validator that maintains a set of abbreviations
it comes across, if an abbr with no title attribute is encountered
that isn't in the set of already seen abbreviations,
Nicholas Shanks wrote:
On Mon, 21 Apr 2008, Patrick H. Lauke wrote:
Assistive technology is certainly a valid use case here.
Why? It doesn't seem to be the case to me that people using ATs are any
less able to work out what an abbreviation is than anyone else.
I think the point is that
Ian Hickson:
HTML5 had a complex mechanism for cross-references using dfn,
abbr,
i, and so forth. I've removed it. It really didn't add much
compared to
a href= other than a whole lot of complexity, and there was very
little demand for it really.
It was kinda cool, though.
I've also made
Nicholas Shanks:
I hope the following aids matters.
Aids? :)
Situations where expansions of abbreviations are needed:
1) People unfamiliar with the topic being discussed.
This includes adhoc abbreviations, which I frequently use in table
headers.
2) Documents that exist as
Le 2008-04-21 à 13:20, Tab Atkins Jr. a écrit :
Plus, who actually wants to mark up every instance of an abbreviation?
That's a ton of work for next to no reward, and apparently isn't
something
that can be automated (since there are conflicts between
abbreviations and
actual words). Mark
Summary: I've made the title= attribute on abbr optional again.
On Mon, 21 Apr 2008, Jens Meiert wrote:
The point of abbr is to expand the acronym, not to just mark up what
is an acryonym or abbreviation.
Doesn't this claim that the general information that some text is an
The point of abbr is to expand the acronym, not to just mark up what is
an acryonym or abbreviation.
Doesn't this claim that the general information that some text is an
abbreviation (w/o an expanded form) is basically useless? And is
abbrISS/abbr not more useful since less ambiguous than ISS
On Mon, Apr 21, 2008 at 4:15 AM, Jens Meiert [EMAIL PROTECTED] wrote:
The point of abbr is to expand the acronym, not to just mark up what
is
an acryonym or abbreviation.
Doesn't this claim that the general information that some text is an
abbreviation (w/o an expanded form) is basically
Jens Meiert writes:
The point of abbr is to expand the acronym, not to just mark up
what is an acryonym or abbreviation.
Doesn't this claim that the general information that some text is an
abbreviation (w/o an expanded form) is basically useless?
Well it's very close to being useless.
Patrick H. Lauke writes:
Smylers wrote:
Well it's very close to being useless. In that if browsers don't do
anything with some mark-up, there's no point in having it (and
indeed no incentive for authors to provide it).
Assistive technology is certainly a valid use case here.
Would
Ian, I think you have made a mistake.
We need to go through this more methodically before making a decision.
I hope the following aids matters.
First, lets think about who will use abbreviations and why they need
them, second, think about where the information could come from.
Situations
Nicholas Shanks writes:
Ian, I think you have made a mistake.
The message of Ian's you replied to covered several different things (as
indicated by the subject line) and you didn't quote any of it. Could
you be more specific on which bit you consider to be a mistake?
We need to go through
Jim Jewett writes:
It isn't clear why the validity constraints of abbr need to be
tightened.
HTML 5 didn't start as HTML 4, so it isn't so much a case of
tightening HTML 4 as having to provide a reason to include things into
HTML 5 -- including those defined in HTML 4.
The use cases are
On 21/04/2008, Smylers [EMAIL PROTECTED] wrote:
Can you link to examples of such webpages, which have abbr elements
without title attibutes? What does that mark-up currently achieve?
Out of 130K pages from dmoz.org, I see 592 using abbr elements, and
36 of those using it at least once with no
HTML5 had a complex mechanism for cross-references using dfn, abbr,
i, and so forth. I've removed it. It really didn't add much compared to
a href= other than a whole lot of complexity, and there was very
little demand for it really. I've also made the title= attribute on
abbr required, and
Ian Hickson wrote:
On Fri, 14 Oct 2005, Lachlan Hunt wrote:
Just a few issues regarding the use of abbr and dfn elements.
*The abbr Element's title Attribute*
I think the title attribute should also be allowed to be omitted from
the abbr element if there is another abbr element with a title
21 matches
Mail list logo
