- From: Karandikar, Shailesh <Shailesh.Karandikar@dendrite.com>
- Date: Wed, 10 Nov 2004 11:56:39 -0500
- To: <PhiLho@GMX.net>
- Cc: <www-svg@w3.org>
Agree with your comments. I believe things are getting a little mixed up a moving from SVG 1.1 to SVG 1.2 onwards. I see a distinction between scalable vector graphics and dynamic/layout/interactive vector graphics (If I may use that term). Features like vector/filter effects are quite useful and belong to the first category. But these could be treated as separate and optional modules. Constraint based graphical and text layouts, text editing, UI controls represent next level of graphics (in terms of usability) would seem to belong to dynamic vector graphics. Flow* elements are powerful and tend to blur the line between the two and may cause some confusion amongst authors on its 'graphical nature' or 'document-nature'. In terms of implementation, text is also graphics for high end outlined text rendering algorithms, but it is typically optimized for 'text-layout'. Again the text layout could be made optional module in SVG spec. Based on the implementation and user feedback it could be included in the next version as a requirement. One would see a similar debate amongst XSLT and XQuery camps where there is quite an overlap of features but now the distinction is quite clear: Data query language (XQuery) and document transformation language (XSLT). A successful (?!) example of separating concerns into modules is Web3D, which clearly identifies an application domain and modularizes it. It allows various components to specialize orthogonally. Regards, Shailesh -----Original Message----- From: www-svg-request@w3.org [mailto:www-svg-request@w3.org] On Behalf Of Philippe Lhoste Sent: Wednesday, November 10, 2004 4:04 AM To: David Woolley Cc: www-svg@w3.org Subject: Re: SVGAccessibilityWG: has-been-clicked or a:visited David Woolley wrote: > [alt] >> It doesn't make much sense in SVG where the images are part of the >> document, so are not likely to be absent or not displayed. Of course, > > I think there is a real danger that SVG will be used for the whole > document. Most commercial web pages already strive to use HTML as > a page description language. I am not sure to fully understand your comment or if it really fits to my prose... But I think I agree with what I understood: Basically, SVG is meant to describe/define graphics with more or less textual content (from nothing (pure graphics) to lot of text (diagrams)). That's what I call document, ie. the SVG image itself. I saw a demo SVG showing off a long text formatted in columns. This is fine as demo, but as Ian would rant, this is an abuse of the format, as such use would much more fit to HTML+CSS... I believe that SVG should be used either as standalone image/application (sorry Ian ;-) with sparce text, or inside an HTML document, as complementary image, not as main document. It is a problem a bit like using Flash to make full Web sites. There are several pages on the Web ranting against this use, its lack of accessibility, of bookmarking capability, etc. Some Web sites I saw, fully made in SVG, suffer less of this problem, partly because text is text, not graphics, partly because links are links, going to a separate SVG file, partly because they are mostly show off (see what I can do) or with content mainly made of graphics (Peepo), hence the fitting with the SVG paradigm (?). But obviously, if you have a lot of things to express in textual fashion, HTML+CSS+SVG is the best way to go. The problem is with authors, which are quick to "pervert" provided tools into unexpected ways. That's why SVG 1.2 goes into ways Ian despise: text formatting, widgets for applications, etc. Because authors are already stretching SVG 1.1 into these uses, but since it doesn't fit well to these uses, it mades poor results. By providing official support of these practices, at least it can / may add some standardization, accessibility, better use, clean practice. Perhaps this should go with some recommendations / guidelines how to avoid abuses of the format. Necessarily generic/partial, as author imagination is always richer than anything we can expect/anticipate. -- Philippe Lhoste -- (near) Paris -- France -- Professional programmer and amateur artist -- http://Phi.Lho.free.fr -- -- -- -- -- -- -- -- -- -- -- -- -- --
Received on Wednesday, 10 November 2004 16:57:15 UTC