W3C home > Mailing lists > Public > www-svg@w3.org > August 2007

Authoring SVG, and the SVG Language (was: opacity, animate and mask)

From: Doug Schepers <schepers@w3.org>
Date: Sun, 05 Aug 2007 12:50:37 -0400
Message-ID: <46B5FFDD.40603@w3.org>
To: ~:'' ありがとうございました。 <j.chetwynd@btinternet.com>
Cc: SVG List <www-svg@w3.org>

Hi, Jonathan-

~:'' ありがとうございました。 wrote (on 8/4/2007 2:56 AM):
> 
> I take your points, however it seems to me you may be imagining this 
> issue from a developer and implementer viewpoint rather than a naive 
> coder or someone using a design or drawing tool.
> 
> In this instance the naive user might well discover the suggested 
> special significance of zero or "none".
> (other values such as 0.000001 providing for current use cases)
> 
> However it's a significant hurdle for the naive user to add an extra 
> attribute, even when they understand this is necessary.

I simply do not believe this.  Adding a single attribute is a 
"significant hurdle"?


> Perhaps you are aware of how easy it is to set up a slideshow with apple?
> how is this done with inkscape or another SVG tool?

How easy is it to set up a slideshow with Adobe Photoshop or CorelDraw? 
  Like them, Inkscape is not intended to create slideshows (as far as I 
know).  There have been several small open-source projects demonstrated 
at SVG Open that let you author slideshows in SVG.  There's also an 
easy, pragmatic, and very usable commerical application to do it too: 
SVGmaker, by Software Mechanics.  It lets you export to SVG from MS 
Powerpoint (or any other MS Office tool).  So, you make your slideshow 
in Powerpoint, and then save it as SVG for publishing on the Web.  It 
includes its own controls, as well.

I've used this many times myself, and I find it very simple.  To make 
fancier presentations that I could never make in Powerpoint, I also 
handcode SVG myself (and once I created my template, it was easy to make 
new ones).  There is nothing in the SVG language that presents a major 
problem for slideshows, so far as I can tell.

But neither of us wants you to set up strawmen for me to knock down.


> This issue isn't even raised in the generally excellent "SVG Essentials" 
> neither indeed is pointer-events afaik

Perhaps the author thought it was too obvious to point out.  Seriously, 
why would something that is transparent also lose its sensitivity to 
pointer-events?  They are 2 completely different properties.  The author 
does have sections on opacity and masks, and 'pointer-events' are 
mentioned on page 297 (and maybe elsewhere).

But more germane to the point, this book is a brief overview of some of 
SVG's functionality.  The map is not the territory.


> I'm concerned by the lack of usability testing with naive users, when 
> creating W3 specifications.
> in particular I'd like to see an SVG specification designed around a 
> simple to use authoring tool for ordinary people, currently known as 
> "chalk"

Any specification that we made would have to match the behavior of the 
whole specification, so you're essentially asking us to subset the 
specification.  I don't believe this would be a valuable use of the SVG 
WG's limited resources, which are already stretched very thin.

A much more valuable use of time and effort would be to create a set of 
tutorials, which is something that we discuss from time to time.  I 
think this would be a good idea, but again, we have limited time and 
energy.  There are community-created resources out there, but it would 
be nice to pull them together in a coherent way, much like Mozilla has 
done with their knowledge base.

As for authoring, most (or all) of the problems you've described can be 
addressed by an authoring tool, in the same way that Inkscape allows 
authors to create star and spirals although there are no explicit 
elements for those common shapes in the SVG language.

While the SVG WG (and the W3C in general) is certainly interested in
promoting the creation of authoring tools for our technologies, it is
outside the scope of this mailing list, this group, or even this
organization to mandate that such tools be created, or to dictate what
the features of such tools would be (outside of certain conformance
requirements). [1] Concrete suggestions about what those conformance
criteria should be are, of course, welcome on this list, but bear in
mind that different authoring tools will have wildly different uses and
target audiences, so the criteria must be sufficiently broad.  Of 
course, implementors reading this list could benefit from the suggestions.

Finally, over the course of a few years, I have read your comments to
this list (and responded to many of them).  Your advocacy for authors
and for accessibility is admirable, and you raise many interesting,
imaginative, and useful points about both topics.  But you do also have
a tendency to blur the lines between what is relevant to the SVG
specification and features of the language, and what is a matter of 
derivative works (implementations, authoring tools, books).

For example, I've heard you complain about some lack of functionality in
the spec, when the feature is actually specified, but is simply not
implemented in a particular user agent; to be fair, I know you are also
a tireless reporter of bugs and unimplemented features to those user
agents, as well, which is a vital role in the community.

Similarly, you frequently complain about the lack of authoring tools, or 
about the failings of particular authoring tools... but the SVG 
specification has nothing to do with this.  It's like complaining to 
your grammar teacher that you didn't like the plot of a particular book.

Finally, you cite above that an SVG feature was not explained in an 
O'Reilly book from 5 years ago.  What of it?  It's not a product of the 
W3C... complain to O'Reilly.

If I may make a suggestion, it would be a better use of everyone's time 
if you were to first identify what aspects of your problem are germane 
to the the SVG language itself, and direct only those comments and 
questions here.

It's not that your issues are falling on deaf ears, it's that you aren't
directing them to the right place.  It's not what we do, and given the
limited resources we have available, it's not something we *can* do.  It
would be more productive by far to direct these energies into a 
pragmatic project to do some of the things that you complain noone is 
doing; maybe you could get a grant to  start an organization that would 
create the tools you think are needed (or modify Inkscape, for example).


[1] http://www.w3.org/TR/SVG11/conform.html

Regards-
-Doug Schepers
W3C Staff Contact, SVG, CDF, and WebAPI
Received on Sunday, 5 August 2007 16:50:52 GMT

This archive was generated by hypermail 2.3.1 : Friday, 8 March 2013 15:54:37 GMT