[html5] (no subject)
John S. Urban
urbanjost at comcast.net
Wed Feb 11 20:59:00 PST 2009
Thanks for the encouraging news.
Just to make sure -- Will the definition be that percent units apply to
the displayed size, or to the pixmap size? I would hope they
apply to the displayed size, and adjust if the image changes size
dynamically. So if a square in a pixmap is displayed
as a non-square rectangle the units would cover the entire rectangle.
Assuming this is the case, a problem arises when a circle is scaled
non-uniformly. I would hope the definition would say in such a case that the
radius N
for the original undistorted circle in the pixmap is mapped to an
ellipse with a minor horizonal axis of N percent of
the displayed X size and a minor vertical axis of N percent of the
displayed Y size. The definition of what happens to a circle in HTML4
per http://www.w3.org/TR/html4/struct/objects.html#h-13.6 implies that
when using percent units that a circle defined in the pixmap would not be
mapped to it's stretched elliptical form but to the largest circle that
would fit centered into
the elliptical form. That is not the behavior I think the vast majority of
people would intuitively expect:
>From the document:
------------------------------------------------------------------------------------------------------------------------------------------------------------
coords = coordinates [CN]
This attribute specifies the position and shape on the screen. The
number and order of values depends on the shape being defined. Possible
combinations:
* rect: left-x, top-y, right-x, bottom-y.
* circle: center-x, center-y, radius. Note. When the radius value is
a percentage value, user agents should calculate the final radius value
based on the associated object's width and height. The radius should be the
smaller value of the two.
:
:
-------------------------------------------------------------------------------------------------------------------------------------------------------------
This seems a bit vague; but if I'm reading that right please don't carry
that concept forward into HTML5.
And if percent units are scaled to the X and Y dimensions seperately and
dynamically, what is the expected behavior of pixel values? That is, if I
had a pixmap that was 200x200 pixels and had a rectangle defined with
coords="0,0,200,200" and I displayed the pixmap at a non-default size
of 200x400 would I expect the rectangular area to be scaled to
"0,0,200,400"? This would be a change from current behavior, but a
reasonable
one. Because pixel values aren't currently scaled (by browers I tested, at
least) images with maps are probably never used except at the default size.
----- Original Message -----
From: "Ian Hickson" <ian at hixie.ch>
To: "John S. Urban" <urbanjost at comcast.net>
Cc: "Samer E. Ziadeh" <samerziadeh at gmail.com>; "Dorde Nenezic"
<djolenene at yahoo.co.uk>; <help at lists.whatwg.org>
Sent: Wednesday, February 11, 2009 4:37 AM
Subject: Re: [html5] (no subject)
> On Tue, 6 Jan 2009, John S. Urban wrote:
>> >
>> > Percents aren't allowed currently... what do browsers do with
>> > percentage
>> > values? Is it useful?
>>
>> As most browsers seem to implement them,percent values are useful in
>> that you do not have to redo the coordinates for different sizes of the
>> same image. So if you have a small map for small screens, and a large
>> one for accessibility purposes or for larger screens, the same <MAP> can
>> be used without re-doing the coordinates; whereas pixel values
>> (currently) need redone for each pixmap file.
>
> Fair enough. I've added a comment in the spec suggesting that we might
> want to add this at some future point. I haven't added it yet because
> image maps aren't resized that often as far as I can tell and I'm trying
> to not add new features at this point.
>
>
>> I find this behavior useful enough to have made a limited-case
>> JavaScript function to supply the desired behavior, which I use in
>> several projects. But this (seemingly simple?) behavior would make a
>> generic, clean and easily understood way to rescale maps to new images
>> sizes. I meant the example URI to show the usefulness of such a
>> feature; but I might have made the image too simple. The method shown in
>> the example has proven to be very useful with floor plans, maps of
>> geographic locations, ... .
>
> I can imagine it would be quite useful, yes. Have you considered using SVG
> for this kind of thing, by the way?
>
Yes, I have experimented with producing scalable maps with SVG;
Glad to hear one drawback I found while trying that will be overcome (by
allowing the SVG to be embedded); but at the time SVG support
was uneven (I need to revisit this) and a Javascript/pixmap mix (a prototype
is still at http://home.comcast.net/~urbanjost/IMG/resizeimg.html) was a
more workable solution.
>
>> PS: I have been experimenting with replacing the image maps with
>> <CANVAS> elements, but found I had to create my own routines to detect
>> if I was in a polygon or not to do so. SVG supports the features I need
>> to make a scaleable vector-based drawing with clippable regions, but
>> requires external files and so on. Am I correct, or is there a way to
>> use MAP and AREA with a CANVAS ? If there is, that would be another
>> reason to support scaling coordinates; as vector drawings are very well
>> suited to dynamic rescaling (and zooming and clipping, for that matter).
>
> There's no way to use <map> with <canvas> currently. We will be supporting
> <svg> embedded in the same HTML file though.
>
>
>> PSS: If you make multiple files displaying differently-sized images of
>> the same "picture", and put a single <MAP> in another file, experience
>> shows some browsers seem to have trouble with that. If the URI is
>> anything other than a "#NAME" reference, some browsers fail. This means
>> it is much more work to update an imagemap used in multiple documents.
>
> In HTML5, the usemap="" attribute is no longer a URI at all (just an ID
> ref with a leading "#" for historical reasons).
I think part of the reason that USEMAP= is no longer a URI escaped me is
that the #NAME syntax has been retained. That seems reasonable if
backward compatibility is maintained; but is very misleading. More
importantly it means each document that uses a pixmap also has to contain
all
the coordinates; so that if you change the pixmap and it's map you also
have to change the HTML of every document that uses the pixmap; and have to
duplicate
identical information (and duplication seems very much at odds with HTML
documents in general). I admit the URI usage is odd (no where else in early
HTML is there such
an "#include" feature of (potentially) just part of a file) but it seems
natural that a map for an image can be in a seperate file, much like the
image file itself.
So I thought I'd throw this out there -- how about still allowing URI's;
but if the URI points to an external document that document must be composed
only of MAP definitions? Coordinates would not need duplicated; the
#NAME syntax still clearly points to a URI; but the confusing idea that the
URI
may be pointing to a complete document that you just want a MAP
extracted from is eliminated. And you have one file ( maybe the files should
typically end in ".map"?)
to change all occurrences of the image map; much like the image file
itself . To me, much the same reasoning that leads to using .css files leads
to wanting coordinates
to be kept seperate from the body of an HTML document.
>
> --
> Ian Hickson U+1047E )\._.,--....,'``. fL
> http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
> Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
More information about the Help
mailing list