- From: David Woolley <david@djwhome.demon.co.uk>
- Date: Thu, 5 Jul 2001 21:27:49 +0100 (BST)
- To: w3c-wai-ig@w3.org
> 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).
Received on Thursday, 5 July 2001 16:36:03 UTC