RE: SVG Tiny 1.2 is now a Candidate Recommendation

> 
> 
> -----Original Message-----
> From: Maciej Stachowiak [mailto:mjs@apple.com] 
> Sent: Tuesday, August 22, 2006 6:01 PM
> To: Peter Sorotokin
> Cc: www-svg@w3.org
> Subject: Re: SVG Tiny 1.2 is now a Candidate Recommendation
> 
> 
> On Aug 22, 2006, at 5:15 PM, Peter Sorotokin wrote:
> [snip]
> > It certainly does not work for real-world browsing, being XHTML/ 
> > CSS, not
> > "street HTML" engine. If it helps to convince you, I can run files
and
> > send you back PNGs. There are certainly bugs in it, but I am  
> > absolutely
> > confident at this point that all inline layout issues can be
resolved
> > without any redesign.
> 
> OK, well, the first 90% of CSS is a lot easier to implement than the  
> second 90% or the third 90%, let alone what it takes to be compatible

> with actual web content(*).

These are all true points. CSS layout corner cases are pretty hard to
implement and the actual renderings can be surprising at times.
Actually, if it were all easy to implement and always gave intuitive
results, I'd bet it would have been just made mandatory part of SVG from
the day 1. I could afford to go through a lot of it, but I do not have
to fit my code on the cell phone. In comparison, textArea is much
simpler and takes much less code.

> 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? Text code is hard, much harder than people who never dealt
with it can imagine. Modifying it is not an easy task. But adding SVG
support is not harder than adding anything else there.

> 
> I don't think it's that useful to debate how easy it is to implement.

> It's pretty easy to say something is easy, especially if you don't  
> have to show the code.

Absolutely, saying something is easy either way ;-). My main point was
that there is an implementer out there who thinks that having CSS inline
layout and SVG textArea in the same piece of code is quite natural and
not much harder than implementing just CSS.

> 
> 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.

> 
> >>> But this particular conflict actually comes from the
> >>> differences between CSS2 and XSL:FO, not SVG itself, and, as far
as
> > I
> >>> remember, SVG 1.0 had no choice by to accept XSL:FO way of doing
it,
> >>> because it addressed internationalization problems that CSS2 had
in
> >
> >>> that
> >>> area. I bet as soon as you try to handle FO in your code, you'll
get
> >>> into the same (if not worse) troubles.
> >>
> >> I don't think the Working Group has made the claim that any of the
> >> design decisions for textArea date back to SVG 1.0 or are meant to
> >> align with XSL:FO. It would be pretty unusual to make this claim
> >> since textArea is new in 1.2.
> >
> > SVG had text since 1.0 and a lot of text properties were taken from
> > XSL:FO. We have to be compatible with existing SVG text, would not
you
> > agree?
> 
> I think it is inevitable that <textArea> will have some differences  
> in behavior from <text> if it exists at all. So I am not sure what  
> you mean by "compatible with".

I do not see why textArea has to have differences with text. I think it
should not.

What I mean are vertical alignment properties that ultimately cause
grief with the line height. SVG follows FO (and CSS3 draft) and has
baseline-shift, dominant-baseline and alignment-baseline properties.
CSS2 has vertical-align which works in a fairly different way. SVG could
not switch back to CSS2 vertical alignment model in 1.2, because it
already had CSS3/FO set of properties (which is much better designed) in
1.0. Again, in my experience, this is the hardest part to reconcile (and
you'd have to do it if you are to implement CSS3/FO vertical alignment,
so this is not really SVG's fault; there are also glyph-orientation
properties and vertical text in SVG Full, but those also come from
CSS3/FO).

> [snip]
> 
> Regards,
> Maciej
> 
> * - If you are curious how you're doing, you can try some of the .xht

> tests here: http://hixie.ch/tests/evil/css/css21/tests/
> 

Oh, yeah, these are worth their name! I have played with some of them,
found (and fixed) some bugs, of course. Only HTML versions were there
back then, so it was hard for me to run them. It's cool that Ian made
XHTML available; I'll certainly make use of those tests now. But these
are "evil" tests - even quite mature browsers had big troubles with them
when I last looked.

Peter

>

Received on Wednesday, 23 August 2006 03:32:22 UTC