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

Re: SVG 1.2 Comment: Flowing text and graphics

From: Philippe Lhoste <PhiLho@GMX.net>
Date: Wed, 01 Dec 2004 14:53:07 +0100
Message-ID: <41ADCCC3.60009@GMX.net>
To: Peter Sorotokin <psorotok@adobe.com>
CC: Boris Zbarsky <bzbarsky@MIT.EDU>, www-svg@w3.org

Peter Sorotokin wrote:
> At 01:11 PM 11/30/2004 -0600, Boris Zbarsky wrote:
> 
>> Peter Sorotokin wrote:
>>
>>> I think you are missing the point. I am not talking about semantics 
>>> or concepts.
>>
>>
>> I realize that you were not.  I believe they are something to keep in 
>> mind when making such decisions, however.
>>
>>> I am saying that new attribute *syntax* is not as good as new markup 
>>> *syntax*.
>>
>> That's a vast generalization.  In this case, why have any attributes 
>> at all? Why not do everything via markup?

It is an old problem in XML, where to use attributes, where to use pure 
markup... IMHO, attributes are OK if using simple syntax (pure number, 
simple string, etc.).

> Things that are not human-readable text basically must be attributes. 
> And it is OK to reuse attribute microsynax where it is already defined 
> (e.g. css length).
> 
>>> This is a generally accepted rule for SVG and the only deviation from 
>>> it is path data (where XML syntax was too verbose).

Well, there is the list of points for polyline or polygon, but they are 
actually a simple variant of path syntax.
There is also CSS, which is a microsyntax not so easy to parse...
Plus some other stuff, like viewBox parameters, transform syntax, and 
some I might forget...
But except perhaps for for transform, these are quite trivial to parse, 
so it doesn't invalidate your point...

>> And you don't feel that it is for this case, I suppose?
> 
> Certainly not. It is not going to cause file size explosion (as path 
> data did).

Exactly, the problem of path data is that it can contains a lot of 
information (hundreds, thousands of points), where full XML markup of 
each point would be an overkill.

Note that an alternative syntax would have been possible, perhaps, like:
<path x="10" y="10">M 100,100 120,100 C 150,120 120,150 120,120 L 
100,120 Z</path>

But it is contradicting your point: "Things that are not human-readable 
text basically must be attributes"
Indeed, currently you can extract relevant data (metadata, text, etc.) 
just by stripping all XML tags.

>>   If not, perhaps you _should_ calculate the shape instead of forcing 
>> every UA implementor to have code to do so?
> 
> There are more users than user agent implementors. And implementation is 
> not hard.

Again, that is the problem of hand-coding SVG vs. tool generated one. 
With a good authoring tool, you can compute unions, intersections, etc. 
of shapes, so there is no real need of these operations. But for 
hand-coding, these operations are really useful.

-- 
Philippe Lhoste
--  (near) Paris -- France
--  Professional programmer and amateur artist
--  http://Phi.Lho.free.fr
--  --  --  --  --  --  --  --  --  --  --  --  --  --
Received on Wednesday, 1 December 2004 13:56:21 GMT

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