- From: Peter Sorotokin <psorotok@adobe.com>
- Date: Tue, 22 Aug 2006 20:32:10 -0700
- To: "Maciej Stachowiak" <mjs@apple.com>
- Cc: <www-svg@w3.org>
> > > -----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