[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