W3C home > Mailing lists > Public > www-svg@w3.org > November 2004

RE: SVGAccessibilityWG: has-been-clicked or a:visited

From: Karandikar, Shailesh <Shailesh.Karandikar@dendrite.com>
Date: Wed, 10 Nov 2004 11:56:39 -0500
Message-ID: <3101F58237A7CF468D6F1DB16778EB620FE0BFB0@diexus1.us.drte.com>
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

This archive was generated by hypermail 2.3.1 : Wednesday, 5 February 2014 07:14:52 UTC