- From: Charles McCathieNevile <charles@w3.org>
- Date: Thu, 5 Jul 2001 18:01:04 -0400 (EDT)
- To: David Woolley <david@djwhome.demon.co.uk>
- cc: <w3c-wai-ig@w3.org>
Well, I have a differnt approach. I still think that the support in the underlying languages is adequate. In the case of animated HTML you should use a tool to pick out the actually visible part of the image and apply a map to make that part the link, and then moving the image has no great effect, since the map applies relative to where you are in the image rendered, not where the image is rendered on the page. In SVG you define whatever part you want to be the link, so the idea os to define the link as the visible part(s) of the image. This does need to be better supported in authoring tools, and probably in the content guidelines - it is an extension of the principle that the stuff in a link is meaningful, as applied to what is meaningful in a picture (a transparent background generally isn't), but I think we should be more explicit about that. (Incidentally, yesterday I spent a bit of time in Geneva talking to some folks who are working on how to convey what is in an image to people who can't see it, and they have a similar kind of issue - identifying shapes and objects within the image is important to them.) cheers Charles McCN On Thu, 5 Jul 2001, David Woolley wrote: > Who should I take it up with? It more or less has to be CSS styles, when the content is HTML, because it arises from the use of position style attributes. It might also apply independently to SVG, as SVG can include bit mapped images. For styles, you would use www-style@w3.org, but note the previous discussion that I referenced in my addition to Bugzilla bug 88866. Please note that that thread was asking for exactly the opposite (so that one could have links that were invisible but still effective). Also check the latest CSS2 errata, to make sure there has been no clarification. For SVG, the list is www-svg@w3.org. Both lists are consultative only, there is no requirement to act on comments and there is no obligation to say why a decision was or was not made. In the case of HTML, my view would be that you are straying so far out of the remit of HTML (the T in HTML stands for text!) that the decision may well be to leave the behaviour as an implementor choice (like rather more things in HTML than most authors realise). If they do make a decision, and the de facto behaviour of Netscape and IE are consistent, I would expect them to specify the current behaviour. Given the de facto role of SVG (as a W3C replacement for Flash) I think clear specification of the behaviour would be important. I haven't read the specification thoroughly enough yet to be sure that the behaviour is not already defined. Note that SVG relies on style sheets in some areas, and uses existing attributes, where appropriate. Also, a bitmapped image in SVG can be clipped using vector commands, so the function does not require a particular interpretation of bit map transparency. (I see your problem with the concepts of splines and ellipses++ to be a user interface issue for authoring tools, not really an issue for viewing technology. All the examples on your home page are logically vector diagrams (and appear to have been created with vector tools, even if the tools couldn't save the vector description). It seems to me that the diagrams are always going to have an underlying abstraction (unless simple photos). If the people converting the images to concrete form have difficulty in externalising the abstraction, the tools to help them are tools that attempt to recognize and recreate that abstraction, not ones that simply allow unstructured imagery. This is a difficult problem (and one that people keep claiming to have solved. Although only a pale imitation of such a tool, it shouldn't be too difficult to post process a transparent image and construct a clipping path for it that is a good enough approximation to the outline. Tools for doing this sort of thing already exist for creating outline fonts from bitmapped fonts, and more generally for recovering vector diagrams from scanned drawings.) I think there are W3C people on the current list, and I'm sure they will contact you directly if they feel the need to raise the issue using internal channels. ++ I'm not sure that this has appeared on this list, but the reason why imaging mapping is a problem is that the image objects are hand drawn objects with non-rectangular boundaries, drawn by people who have difficulty with handling the abstraction of letters on paper for spoken words and presumably with externalising other abstractions. Actually, it is not just people officially classed as with "learning disabilities" who have difficulties externalising abstractions, which why one gets so much WYSIWYG HTML. Mainstream authoring tools could also do more to try and divine the underlying abstractions (MS Word does this in a limited way in that it detects the presentational form of lists and converts them into real lists). -- Charles McCathieNevile http://www.w3.org/People/Charles phone: +61 409 134 136 W3C Web Accessibility Initiative http://www.w3.org/WAI fax: +1 617 258 5999 Location: 21 Mitchell street FOOTSCRAY Vic 3011, Australia (or W3C INRIA, Route des Lucioles, BP 93, 06902 Sophia Antipolis Cedex, France)
Received on Thursday, 5 July 2001 18:01:05 UTC