W3C Spec: Block level content within <map>? Style in <area>? Why?

[laurence]

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).

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.

Among elements which might be included within the <map> is specifically
mentioned the anchor (<a>) element. Testing this, I find the anchors are
rendered as normal anchors, again, in page flow order.

It is not clear to me how any advantage is gained by placing such content
within an image map. Indeed, such inclusion appears only to confuse the
organisation of the file. Does anybody know the intended use of this
facility?

Related to this, I note that anchor tags may include the 'shape' attribute,
presumably intended for use in the same way as this attribute in <area>
tags. Testing it, I find I cannot get <a> elements to express any shape but
that of their normal content.

Related to this also is the facility to provide both <map> and <area> tags
with style, either inline or with class attributes. Testing has yielded no
discernible effect with any style properties one might think to apply.

Does any W3C guru have answers for these mysteries? (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).

Thanks in advance

Laurence

[David Dorward]

Re: W3C Spec: Block level content within &lt;map&gt;? Style in &lt;area&gt; ? Why?

laurence wrote:
[color=blue]
> 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.[/color]

"The MAP element may be used without an associated image for
general navigation mechanisms."
-- http://www.w3.org/TR/html4/struct/objects.html#edef-MAP


--
David Dorward <http://blog.dorward.me .uk/> <http://dorward.me.uk/>
Home is where the ~/.bashrc is

[David Dorward]

Re: W3C Spec: Block level content within &lt;map&gt;? Style in &lt;area&gt; ? Why?

laurence wrote:
[color=blue]
> 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.[/color]

"The MAP element may be used without an associated image for
general navigation mechanisms."

"Block-level content. This content should include A elements
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."

-- http://www.w3.org/TR/html4/struct/objects.html#edef-MAP

i.e. Its the image map version of the alt attribute.

--
David Dorward <http://blog.dorward.me .uk/> <http://dorward.me.uk/>
Home is where the ~/.bashrc is

[Lauri Raittila]

Re: W3C Spec: Block level content within &lt;map&gt;? Style in &lt;area&gt; ? Why?

in comp.infosystem s.www.authoring.html, David Dorward wrote:[color=blue]
> laurence wrote:
>[color=green]
> > 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.[/color]
>
> "The MAP element may be used without an associated image for
> general navigation mechanisms."
>
> "Block-level content. This content should include A elements
> 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."
>
> -- http://www.w3.org/TR/html4/struct/objects.html#edef-MAP
>
> i.e. Its the image map version of the alt attribute.[/color]

Not in sence of alternative. Block level content is always displayed.
This usually makes sence on cases image map is supposed to be used... but
does not for the most common case, which is textual links in one image.
(inherited such site, orginal images long gone, everything in one
giant jpg...)


--
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

[Harlan Messinger]

Re: W3C Spec: Block level content within &lt;map&gt;? Style in &lt;area&gt;?Wh y?

laurence wrote:

[question about the newer format for the contents of the MAP element]

It lets you provide a single set of navigation elements *as* a single
set in your content while presenting them in two alternative ways, each
preferred by a particular set of users. See

http://www.gavelcade.com/tests/imagemaps.html

The idea is that you present your navigational elements in an
accessible, text-based format, but that by wrapping them in a MAP
element, you are making them available for *reuse* as an image map for
those users who will benefit from one.

A thought occurred to me, that they ought to have done the same thing
with <map name="..."> that they did with <a name="...">, that is, make
it unnecessary. Instead of requiring

<img ... usemap="#mymap" >
<!-- ... -->
<map name="mymap" ...>
<div ...>
<!-- ... content ... -->
</div>
</map>

they ought to have made it possible to write

<img ... usemap="#mymap" >
<!-- ... -->
<div id="mymap" ...>
<!-- ... content ... -->
</div>

because the MAP tag serves no real purpose.

[laurence]

Re: W3C Spec: Block level content within &lt;map&gt;? Style in &lt;area&gt; ? Why?

David wrote:[color=blue]
> laurence wrote:
> [color=green]
>> 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.[/color]
>
> "The MAP element may be used without an associated image for
> general navigation mechanisms."
>
> "Block-level content. This content should include A elements
> 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."
>
> -- http://www.w3.org/TR/html4/struct/objects.html#edef-MAP
>
> i.e. Its the image map version of the alt attribute.[/color]

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

[laurence]

Re: W3C Spec: Block level content within &lt;map&gt;? Style in &lt;area&gt; ? Why?

>> i.e. Its the image map version of the alt attribute.[color=blue]
>
> Not in sence of alternative. Block level content is always displayed.
> This usually makes sence on cases image map is supposed to be used... but[/color]

Thanks Lauri. Can you explain how it usually makes sense?

Laurence.

[David Dorward]

Re: W3C Spec: Block level content within &lt;map&gt;? Style in &lt;area&gt; ? Why?

laurence wrote:
[color=blue]
> 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.[/color]

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

[Lauri Raittila]

Re: W3C Spec: Block level content within &lt;map&gt;? Style in &lt;area&gt; ? Why?

in comp.infosystem s.www.authoring.html, laurence wrote:[color=blue]
> David wrote:[/color]
[color=blue][color=green]
> > -- http://www.w3.org/TR/html4/struct/objects.html#edef-MAP[/color][/color]
[color=blue]
> 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.[/color]

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)
[color=blue]
> The means to provide accessibility for imagemaps
> is provided with alt attribute in areas, accesskey attributes etc.[/color]

Exept those don't work too well, which is problem.
[color=blue]
> Moreover, in fact, geometric regions are not successfully specified
> within A elements, even if they are actually specified in A attributes.[/color]

What do you mean with this? The fact that IE don't understand coords
attribute for a element?
[color=blue]
> This could simply be standards implementation shortfall, but one has to
> admit, just what the working group intended is completely unclear.[/color]

I think it is compromise.
[color=blue]
> 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?[/color]

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.
[color=blue]
> 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.[/color]

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

[Lauri Raittila]

Re: W3C Spec: Block level content within &lt;map&gt;? Style in &lt;area&gt; ? Why?

in comp.infosystem s.www.authoring.html, Harlan Messinger wrote:[color=blue]
> laurence wrote:[/color]
[color=blue]
> they ought to have made it possible to write
>
> <img ... usemap="#mymap" >
> <!-- ... -->
> <div id="mymap" ...>
> <!-- ... content ... -->
> </div>
>
> because the MAP tag serves no real purpose.[/color]

But then you couldn't have to map elements with same name? Wouldn't that
be shame? (no, I have no idea why it is allowed in HTML4...)

Anyway, I assume reason is of course backwards compatibility. And I think
that the map element is maybe worst defined in whole spec...

--
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

[laurence]

Re: W3C Spec: Block level content within &lt;map&gt;? Style in &lt;area&gt; ? Why?


"Harlan Messinger" <hmessinger.rem ovethis@comcast .net> wrote in message
news:3gp6ebFd00 moU1@individual .net...[color=blue]
> laurence wrote:
>
> [question about the newer format for the contents of the MAP element]
>
> It lets you provide a single set of navigation elements *as* a single set
> in your content while presenting them in two alternative ways, each
> preferred by a particular set of users. See
>
> http://www.gavelcade.com/tests/imagemaps.html
>
> The idea is that you present your navigational elements in an accessible,
> text-based format, but that by wrapping them in a MAP element, you are
> making them available for *reuse* as an image map for those users who will
> benefit from one.[/color]

That's great Harlan, thanks. This dual use of the links is apparently not
supported in MSIE, but works a treat in Firefox. Good info, and great
example.
[color=blue]
> A thought occurred to me, that they ought to have done the same thing with
> <map name="..."> that they did with <a name="...">, that is, make it
> unnecessary. Instead of requiring
>
> <img ... usemap="#mymap" >
> <!-- ... -->
> <map name="mymap" ...>
> <div ...>
> <!-- ... content ... -->
> </div>
> </map>
>
> they ought to have made it possible to write
>
> <img ... usemap="#mymap" >
> <!-- ... -->
> <div id="mymap" ...>
> <!-- ... content ... -->
> </div>
>
> because the MAP tag serves no real purpose.[/color]

Could it be that maps will not always contain renderable content (apart from
hotspots on image/object), and so should not then make their presence felt
on a page in the form of a div?
Also, maps can be used by more than one image; their location in a div, at
some particular page location doesn't make much sense.

In experimenting with your code, I found that adding <area> elements to the
map (for it is decreed you can mix these elements within a map) appear to
cancel out the A regions in Firefox. Only the AREA regions work as
hot-spots. Interesting.


Thanks for the explanation Harlan,
and thanks to other contributors too.

Now, if only someone would enlighten me as to style being applied to map &
area tags...
Laurence.

[Alan J. Flavell]

Re: W3C Spec: Block level content within &lt;map&gt;? Style in &lt;area&gt;?Wh y?

On Thu, 9 Jun 2005, laurence wrote:
[color=blue]
> 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).[/color]

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.
[color=blue]
> 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.[/color]

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.
[color=blue]
> Does any W3C guru have answers for these mysteries?[/color]

(don't look at me...)
[color=blue]
> (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).[/color]

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.

[laurence]

Re: W3C Spec: Block level content within &lt;map&gt;? Style in &lt;area&gt; ? Why?

David wrote:[color=blue]
>
> http://www.cs.tut.fi/~jkorpela/html/mapalt.html might explain why alt
> isn't
> sufficient.
>[/color]
Thanks David. An excellent link.
Laurence

[Harlan Messinger]

Re: W3C Spec: Block level content within &lt;map&gt;? Style in &lt;area&gt;?Wh y?

Lauri Raittila wrote:[color=blue]
> in comp.infosystem s.www.authoring.html, Harlan Messinger wrote:
>[color=green]
>>laurence wrote:[/color]
>
>[color=green]
>>they ought to have made it possible to write
>>
>> <img ... usemap="#mymap" >
>> <!-- ... -->
>> <div id="mymap" ...>
>> <!-- ... content ... -->
>> </div>
>>
>>because the MAP tag serves no real purpose.[/color]
>
>
> But then you couldn't have to map elements with same name? Wouldn't that
> be shame?[/color]

:) Right, if you had two MAP elements with the same name, the browser
wouldn't know which one to use. It would be like having two A tags with
the same name on the same page,

<a name="myanchor" >

To which of these would a hyperlink tagged

<a href=#myanchor" >

go? And yet it's not a spec violation.

Oh, wait: the spec *does* say that the NAME attribute for an A tag needs
to be unique. It doesn't say that for the MAP tag, though. It should.
[color=blue]
> (no, I have no idea why it is allowed in HTML4...)
>
> Anyway, I assume reason is of course backwards compatibility. And I think
> that the map element is maybe worst defined in whole spec...[/color]

[Harlan Messinger]

Re: W3C Spec: Block level content within &lt;map&gt;? Style in &lt;area&gt;?Wh y?

laurence wrote:[color=blue]
>
> Could it be that maps will not always contain renderable content (apart from
> hotspots on image/object), and so should not then make their presence felt
> on a page in the form of a div?[/color]

You have to have the DIV, or some other block-level element, and its
contents inside the MAP anyway, and it will display anyway, if you're
following the approach that uses A tags instead of AREA tags. I'm saying
that in that case, the MAP tag itself is serving no purpose except as a
place to hang the identifier, but the block itself can be used for that.
[color=blue]
> Also, maps can be used by more than one image; their location in a div, at
> some particular page location doesn't make much sense.[/color]

Eh? You're making the same set of shapes and coordinates available, to
as many images as you want, via the A tags, whether or not you wrap the
DIV inside a MAP.
[color=blue]
>
> In experimenting with your code, I found that adding <area> elements to the
> map (for it is decreed you can mix these elements within a map) appear to
> cancel out the A regions in Firefox. Only the AREA regions work as
> hot-spots. Interesting.[/color]

Interesting, that's not what's supposed to happen. The spec says that
when a block and a set of AREA tags are both present, the AREA tags are
meant for use by older UAs that won't know what to do with the A tags
that have SHAPE and COORDS attributes. Compliant UAs that understand
what to do with the A tag's image-map attributes are supposed to use the
block and ignore the AREA tags.