[html5] (no subject)

John S. Urban urbanjost at comcast.net
Thu Feb 12 03:50:00 PST 2009


Thanks; but I'm surprisingly familar with SVG, Adobe PDF, PostScript, Display PostScript, VML,  ...;
this is about making image maps able to cope with rescaled pixmaps;  and making it easier to generate
and maintain the coordinates needed to create an image map. -- it doesn't have much to do with the
image data itself.  I have done the equivalent using SVG,
VML, and JavaScript. The result for me was not a simple intelligible clear-text HTML document; with this
approach (HTML Imagemap, but with percent units for coordinates) it would be as close to such a simple ideal as I can imagine it to be, given you are describing an image's internal borders with
numeric values.

If pressed, one could convert any HTML document entirely into SVG; with far more control of text at the
graphic level ( the same being true more-so of PostScript/PDF). But this costs you. The day that HTML is no longer
"hand-writable" would be a sad day indeed; that is one of it's great beauties. CSS (Cascading Style Sheets)
saved it from that path of destruction once already. 

Ironically, I eschew imagemaps whenever possible. But sometimes a picture is worth a thousand words. Especially if you
can point and click on parts of it. A great public site for demonstrating that is the FOTW (Flags Of The World) site at http://flagspot.net
One example out of thousands -- http://flagspot.net/flags/sk(.html . That being said ...

Imagine HTML didn't have image maps until today and that you were going to add the feature. Unlike when image maps
were originally introduced, you know that plain images are easily and frequently  displayed at different sizes on devices of very different scale (instead of being able to assume everyone is using an X11 Windows display with a large monitor and mapping their pixmap files one-to-one to display pixels). I'd bet 
you would end up supporting percent units for your image map regions' coordinates. 

I jotted something together ( I tend to think things out by prototyping them) that provides more context for the discussion
a while ago at http://home.comcast.net/~urbanjost/IMG/semaphore.html. 

That reminds me -- visual cueing by changing the opacity of the region you are currently hovering over would be a nice enhancement;
that's one significant advantage SVG/PDF/VML/CANVAS methods would still have. 


  ----- Original Message ----- 
  From: Jim Meehan 
  To: Ian Hickson 
  Cc: John S. Urban ; help at lists.whatwg.org ; Dorde Nenezic 
  Sent: Wednesday, February 11, 2009 10:52 AM
  Subject: Re: [html5] (no subject)


  The discussion about images sounds like you're slowly re-inventing PostScript with its inline images. There is an elaborate commenting system, the Document Structuring Convention, that added more and more information in these "comments." Just as things were getting really crazy with the DSC, PDF came along and solved all those problems in a much cleaner way, and it pretty much marked the end of hand-written PostScript. (The Acrobat Distiller compiled PostScript into PDF, and the Acrobat Reader converted PDF into PostScript for sending to PostScript printers.)


  So I second Ian's suggestion to consider SVG, which was a post-PostScript, post-PDF invention. I'm not familiar with the details of SVG, and in a quick look at some documents on the Web (e.g., Wikipedia), I didn't see anything about inline images (image = "raster image," which is the opposite of "vector graphics"), or even scalable non-inline images, but perhaps they're there. In any case, there's already a pretty good wheel; no need to re-invent it.


  --Jim Meehan
  (@Adobe 1993-2004)


  On Wed, Feb 11, 2009 at 1:37 AM, Ian Hickson <ian at hixie.ch> wrote:

    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?


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

    --
    Ian Hickson               U+1047E                )\._.,--....,'``.    fL
    http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
    Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
    _______________________________________________
    Help mailing list
    Help at lists.whatwg.org
    http://lists.whatwg.org/listinfo.cgi/help-whatwg.org


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/help-whatwg.org/attachments/20090212/f9b7ec45/attachment-0002.htm>


More information about the Help mailing list