[html5] (no subject)
jrm at google.com
Wed Feb 11 07:52:28 PST 2009
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
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
> > > 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
> > 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Help