When experimenting with image maps, I sometimes ended up loosing track
of which map I was editing. Hence, some things to consider:
# SHORT VERSION: Two RFEs regarding @name of map elements:
* RFE 1: When user tries to activate the image map editor for a
currently selected area element (by clicking an area element next to
it), but the image map editor gives the user access to the area element
of another map (this can happen when two map elements have identical
@name values), XXE should issue a warning. In fact, any time a user
tries to edit a map for which there exists another map element with the
same @value, there should be a warning.
* RFE 2: XXe should try (harder) to help users to avoid that
duplicate map @name values accutally occurs (= could make RFE 1
unneeded);
# LONGER EXPLANATION
## A 2 step possible solution for RFE 2:
0. Whenever the user pastes a map that contains a non-empty @name;
1. the value of the name should immediately be updated (in the
background) by XXe;
2. if the pasting operation includes a img w/usemap: ask user if
@usemap needs to be updated, or let XXe update the @usemap value (to the
value of the name/id value in step 2) it in the background.
(Other options for RFE 2: a) warn user when pasting map w/duplicate
@name; b) ask user to fix duplicate @name once it has pasted;)
## Background: scenarios when current behavior is suboptimal:
1. Instance A: When using XXe’s img insertion tool to insert an
image map, the usemap link between the img element and the map element
is taken care of by the program - and the entire thing (map and img)
gets wrapped in a div element. Letus refer to this construction as
'instance A'.
2. Instance B: A user might then copy the entire 'instance A' and
paste it **after** 'instance A' - causing 'instance B' to be created.
3. Immediately after step 2, the user might now, by selecting the
'area' element of 'instance B', activate the image map editor.
* Expected: The user will be expecting to have activated image map
editor for the area element that (s)he selected - which was an area
element inside 'instance B'.
* Actually: The user has actually activated the image map editor for
the map of 'instance A'. The issue here is that the user clicks on the
area element of one image map, but actually ends up editing another map.
Also: When (as in this example) the two img elements contain the same
image, meaning that, even in the case of a veryu alert user, it would be
impossible for the user to understand what was going on.
4. Go back to step 2: Now paste the image map **before** 'instance
A' - causing 'instance C' to be created.
5. Immediately after step 4, select the area map of 'instance C' and
activate the image tool editor.
* Expected: The user will be expecting that the image map editor
will **only** affect the mappings of the current image - 'instance C'.
* Actually: But actually, because 'instance C' occurs earlier in the
source than 'instance A', the edits that the user performs of the area
element(s) of 'instance C', will also take effect in 'instance A'. (This
is because, case of duplicate id/name values, the web browser will use
the content of the map element that occurs first - this is standard
handeling of fragment ids: When more than one occurs, the first one will
be used - and XXe works the same way.)
With regards from
Leif Halvard Silli
--
XMLmind XML Editor Support List
xmleditor-support@xmlmind.com
http://www.xmlmind.com/mailman/listinfo/xmleditor-support
