|
Posted by laurence on June 9, 2005, 8:45 am
Please log in for more thread options
: quoted-printable
David wrote:
> laurence wrote:
>=20
>> I note the document specifies that block level content can be =
included
>> within a <map>. Testing this in order to discover why one might wish =
to do
>> this, I find the block level content is rendered in page flow order
>> anyway, and not magically associated with (say) the image that uses =
the
>> map.
>=20
> "The MAP element may be used without an associated image for=20
> general navigation mechanisms."
>=20
> "Block-level content. This content should include A elements=20
> that specify the geometric regions of the image map and the
> link associated with each region. Note that the user agent
> should render block-level content of a MAP element. Authors
> should use this method to create more accessible documents."
>=20
> -- http://www.w3.org/TR/html4/struct/objects.html#edef-MAP
>=20
> i.e. Its the image map version of the alt attribute.
Thanks David. Perhaps "the image map version of alternate object tags =
embedded within outer object tags", or "noscript embedded in script =
tags" are more analogous. Problem with this proposal is that the block =
level content is always rendered. It is not alternate to anything.
I already read these passages, and it is not clear to me how inclusion =
of block level stuff within a map allows one to create more accessible =
documents, at least any more accessible than putting the block level =
stuff outside the map. The means to provide accessibility for imagemaps =
is provided with alt attribute in areas, accesskey attributes etc.
Moreover, in fact, geometric regions are not successfully specified =
within A elements, even if they are actually specified in A attributes. =
This could simply be standards implementation shortfall, but one has to =
admit, just what the working group intended is completely unclear.
The first quote might lead us to think that included block level stuff =
can be the basis of the map instead of an image. In fact it does not =
render this way - bad standards conformance? Maybe, but I don't think =
that's it. Your supposed to be able to include block-level stuff in the =
map when you are using an image, not simply as an alternate to using an =
image. Why you would want to is the mystery.
Laurence
------=_NextPart_000_005B_01C56CC7.3A673060
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2900.2180" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY>
<DIV><FONT face=3DArial size=3D2>David wrote:</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>> laurence wrote:<BR>> =
<BR>>> I note=20
the document specifies that block level content can be =
included<BR>>>=20
within a <map>. Testing this in order to discover why one might =
wish to=20
do<BR>>> this, I find the block level content is rendered in page =
flow=20
order<BR>>> anyway, and not magically associated with (say) the =
image that=20
uses the<BR>>> map.<BR>> <BR>> "The MAP element may be =
used=20
without an associated image for <BR>> general navigation=20
mechanisms."<BR>> <BR>> "Block-level content. This content =
should=20
include A elements <BR>> that specify the geometric =
regions of=20
the image map and the<BR>> link associated with each =
region. Note=20
that the user agent<BR>> should render block-level =
content of a=20
MAP element. Authors<BR>> should use this method to =
create more=20
accessible documents."<BR>> <BR>> -- =
</FONT><A =
href=3D"http://www.w3.org/TR/html4/struct/objects.html#edef-MAP"><FONT=20
face=3DArial=20
size=3D2>http://www.w3.org/TR/html4/struct/objects.html#edef-MAP</FONT></=
A><BR><FONT=20
face=3DArial size=3D2>> <BR>> i.e. Its the image map version of =
the alt=20
attribute.<BR></FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Thanks David. Perhaps "the image map =
version of=20
alternate object tags embedded within outer object tags", or "noscript =
embedded=20
in script tags" are more analogous. Problem with this proposal is that =
the block=20
level content is always rendered. It is not alternate to =
anything.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>I already read these passages, and it =
is not clear=20
to me how inclusion of block level stuff within a map allows one to =
create more=20
accessible documents, at least any more accessible than putting the =
block level=20
stuff outside the map. The means to provide accessibility for imagemaps =
is=20
provided with alt attribute in areas, accesskey attributes =
etc.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Moreover, in fact, geometric =
regions are=20
not <EM>successfully</EM> specified within A elements, even if they are =
actually=20
specified in A attributes. This could simply be standards=20
implementation shortfall, but one has to admit, just what the =
working group=20
intended is completely unclear.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>The first quote might lead us to =
think that=20
included block level stuff can be the basis of the map =
instead of an=20
image. In fact it does not render this way - bad standards conformance? =
Maybe,=20
but I don't think that's it. Your supposed to be able to include =
block-level=20
stuff in the map when you are using an image, not simply as an alternate =
to=20
using an image. Why you would want to is the mystery.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Laurence</FONT></DIV></BODY></HTML>
------=
|
|
Posted by David Dorward on June 8, 2005, 11:56 pm
Please log in for more thread options
laurence wrote:
> I already read these passages, and it is not clear to me how inclusion of
> block level stuff within a map allows one to create more accessible
> documents, at least any more accessible than putting the block level stuff
> outside the map. The means to provide accessibility for imagemaps is
> provided with alt attribute in areas, accesskey attributes etc.
http://www.cs.tut.fi/~jkorpela/html/mapalt.html might explain why alt isn't
sufficient.
--
David Dorward <http://blog.dorward.me.uk/> <http://dorward.me.uk/>
Home is where the ~/.bashrc is
|
|
Posted by laurence on June 9, 2005, 9:41 am
Please log in for more thread options
David wrote:
>
> http://www.cs.tut.fi/~jkorpela/html/mapalt.html might explain why alt
> isn't
> sufficient.
>
Thanks David. An excellent link.
Laurence
|
|
Posted by Lauri Raittila on June 9, 2005, 1:10 am
Please log in for more thread options
in comp.infosystems.www.authoring.html, laurence wrote:
> David wrote:
> > -- http://www.w3.org/TR/html4/struct/objects.html#edef-MAP
> I already read these passages, and it is not clear to me how inclusion
> of block level stuff within a map allows one to create more accessible
> documents, at least any more accessible than putting the block level
> stuff outside the map.
Easy. Your imagemap should be map, or graph, or somethign like that. It
makes sence to alwas have alternative. Imagine map of Finland, with
hotspots in places some hotel chain has hotel. If you are not too
familiar with Finland, it might be hard to find right dot, if you know
which city you are going. If there is list of those same hotels, you can
find name of city easily. If, OTOH, you are coming from Russia, you find
your place easier using the map.
Now, if you are using text browser, if this is done with area elements
with alt attributes, and list with links, you get same stuff twice. With
block content in map element, you only get it once.
You think leaving out alt attributes in area elements would do this, ut
that is of course bad assumption, as nobody actually uses them and so
every text browser provides links to the links.
(No, I don't know if it goes like this, but I think is good enough
scenario to explain the spec)
> The means to provide accessibility for imagemaps
> is provided with alt attribute in areas, accesskey attributes etc.
Exept those don't work too well, which is problem.
> Moreover, in fact, geometric regions are not successfully specified
> within A elements, even if they are actually specified in A attributes.
What do you mean with this? The fact that IE don't understand coords
attribute for a element?
> This could simply be standards implementation shortfall, but one has to
> admit, just what the working group intended is completely unclear.
I think it is compromise.
> The first quote might lead us to think that included block level stuff
> can be the basis of the map instead of an image. In fact it does not
> render this way - bad standards conformance?
What you mean with this? I don't get it. Opera 7-8 at least supports
these things as they should be, If I have understood spec correctly.
Unsurprisingly, IE won't.
> Maybe, but I don't think
> that's it. Your supposed to be able to include block-level stuff in the
> map when you are using an image, not simply as an alternate to using an
> image. Why you would want to is the mystery.
Why you wouldn't want it? I can't think anything, exept that image map is
used for some stylistic thing (for which you shold use CSS), instead of
something sensible.
--
Lauri Raittila <http://www.iki.fi/lr> <http://www.iki.fi/zwak/fonts>
Utrecht, NL.
Support me, buy Opera:
https://secure.bmtmicro.com/opera/buy-opera.html?AID=882173
|
|
Posted by Alan J. Flavell on June 9, 2005, 12:25 am
Please log in for more thread options
On Thu, 9 Jun 2005, laurence wrote:
> I am implementing a comprehensive image-map generator utility, so have been
> studying W3C HTML 4.01 Specification
> (http://www.w3.org/TR/html4/struct/objects.html#h-13.6) on image maps (among
> other things).
Just for a bit of background, the client-side imagemap was originally
introduced by RFC1980. Typical browsers never quite implemented
everything that was in the original spec. Over the years this has
shifted a bit one way and a bit the other, and now the W3C have a
specification in HTML4, but there's always been a bit of a gap between
what the spec hopes for and what browsers actually implement.
> I note the document specifies that block level content can be
> included within a <map>. Testing this in order to discover why one
> might wish to do this, I find the block level content is rendered in
> page flow order anyway, and not magically associated with (say) the
> image that uses the map.
That sounds about right, yes. You can put the MAP wherever it's
convenient, and refer to it from elsewhere with USEMAP=
The HTML spec emphasises the use of OBJECT here, which is a fine idea
in principle, but like so many attempts to move forward, has got
tripped up by poor browser implementations, meaning author reluctance
to use it instead of the now-traditional IMG - for all its faults.
> Does any W3C guru have answers for these mysteries?
(don't look at me...)
> (Or is it just that my testing has been conducted with IE? - even if
> that is the problem, block content in maps still needs explanation).
You definitely need to consider at least one www-compatible browser
before worrying about IE.
Whether or not you agree with him, Hixie has some excellent
discussions of implementation issues for Mozilla that can help in
understanding and illustrating possible usage of HTML4 constructs.
When I have questions of this kind I'd look at those discussions as an
early part of any investigation. No guarantees on this particular
topic but I'd start at http://www.hixie.ch/ and look for his test
suites and rationales.
Sorry if this seems over cryptic, but like so many things that have a
past history, there are some rough edges and it looks as if you've
spotted some of them.
And yes, even if one knows how it's *supposed* to work it would still
be necessary to do a reality check with IE. My point is that IE
is best not used as a starting point.
hope this is of some use.
|
| Similar Threads | Posted | | In HTML spec,are "href" and "style" called "attribute"?....@@ | January 29, 2005, 11:14 am |
| Multiple-level Table of Contents | April 6, 2006, 9:59 am |
| Help with multi level category navigation | April 11, 2006, 1:50 pm |
| Double-spacing 1st List Level, but not Nested Levels | July 9, 2006, 8:24 pm |
| XHTML DOCTYPE breaks JavaScript x.style.top and x.style.left? | July 5, 2005, 12:58 pm |
| Is Html4.01 spec(http://www.w3.org/TR/REC-html40/) downly compatible to older editions such like Html4.0? | April 20, 2005, 3:26 am |
| table inside div block - no joy | April 2, 2006, 6:26 pm |
| What's causing the gap between the logo and the next block? | November 9, 2008, 8:56 am |
| How to make block elements flow? | May 15, 2005, 6:50 pm |
| DTD? Is address element block or inline? | December 15, 2005, 10:16 pm |
|
XML Sitemap