Re: SVG Tiny 1.2 is now a Candidate Recommendation

On Aug 22, 2006, at 8:32 PM, Peter Sorotokin wrote:

>
>> The actual end result is a pretty complex
>> piece of code, and adding complexity to support a separate mode is
>> pretty undesirable, even if it is not that much more complexity in
>> absolute terms.
>
> Well, any additional text layout feature fits this logic. Support for
> SVG text layout is not any different. Is it harder than new CSS3
> properties?

The cost is similar (conditionally adding a feature is a bit of extra  
code), but the benefit is not - if the text engines were the same  
then any feature would benefit both CSS and SVG text. But they have  
separate feature sets. As it is, any new CSS3 property that affects  
text probably ought to be ignored for SVG. I can't really tell from  
the spec though whether respecting standard CSS text properties for  
SVG would be a violation.

>> The bigger problem is having two different models for flowing text
>> layout for content authors that need to deal with both HTML and SVG.
>
> First of all, it is already there: SVG always had text, it just has to
> be broken into lines by the tool. Certainly you'd agree that SVG text
> model is better than "GIF text model" (I am seeing a lot of text
> rendered as bitmaps because people don't have sufficient control over
> its appearance).
>
> Secondly, I have not seen many people who really understand the
> differences between CSS inline layout and layout in, say, Word or  
> XSL:FO
> (even when they produce content in these formats). For most people
> precise rules are totally unimportant.
>
> And, of course, it is not all *that* different. Less different than
> either FO or Word.

The key difference here is that we do not expect content authors (or  
authoring tools) to create documents that combine [X]HTML with FO or  
Word content inline in the same document. If compound documents are  
to succeed, every little difference hurts. And of course the biggest  
difference is that in the SVG model, you can't use semantic markup.  
Which is a big problem - the W3C's big project is the Semantic Web,  
and yet SVG will encourage authors to create significant chunks of  
text with purely presentational markup. Worse still, there will be  
SVG-only text layout features that can't be used with semantic markup  
even when embedding semantic markup is possible (for example xhtml  
via foreignObject).

I hope the CSS working group remedies this by adding advanced  
presentational features such as text along a path, gradients,  
separate text stroke and fill, and text flowed to fit inside an  
arbitrary closed path. This way, authors will not need to choose  
between these presentational features and using semantic markup. I  
trust the SVG WG will not mind the overlap in functionality.

Regards,
Maciej

Received on Wednesday, 23 August 2006 05:20:57 UTC