Re: SVG Tiny 1.2 is now a Candidate Recommendation

On Aug 22, 2006, at 5:15 PM, Peter Sorotokin wrote:

>>
>> Great, is there any way I can try the code and see how well it works?
>
> Not yet, put hopefully it will be possible at some point.
>
>> Or do you have stats on how much of the CSS 2.1 test suite it passes
>> or how well it works for real-world web browsing?
>
> 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(*). 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.

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.

The bigger problem is having two different models for flowing text  
layout for content authors that need to deal with both HTML and SVG.

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

>>> [... snip ...] this does not necessarily tell us that combined
>>> engine is impossible
>>
>> I would not claim it is impossible. I do think it is more complicated
>
>> to implement, and more complicated conceptually for authors working
>> in both formats.
>
> It is unfortunate that you chose to cut it at that particular point.

I just wanted to be clear that I don't think it is impossible (and I  
think I never made such a claim). I do still think it is harder,  
despite your claims.

> What I wrote was: "this does not necessarily tell us that combined
> engine is impossible or even much harder to produce". In my  
> experience,
> it is not much harder. It is certainly much, much easier than to write
> separate CSS and SVG engines (for instance, combined XSL:FO and CSS
> engine would be far more complex to produce).

I'm sure it's easier than writing two separate text layout engines,  
but I still think it's harder than writing a correct text layout  
engine with one mode.

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/

Received on Wednesday, 23 August 2006 01:01:16 UTC