Re: Reconsider SVG 1.2

I'm in the midst of writing an editor using Firefox's XUL 
implementation. Really very powerful, but yeah, its still definitely a 
work in progress, so I understand about the crashes.

The flow model seems to be the central point of contention here, so 
getting away from all the grand rhetoric (and cooling down a little 
bit), I am trying to figure out why specifically there is such a strong 
argument over the flow features. To summarise what I know, the CSS 
model, if I read Ian Hixie's proposal correctly, assumes the notion of a 
columnated container, though nothing in the specification specifically 
addresses the question of overflow yet (given that this proposal is 
still being written, I understand the rationale for this).  I presume 
that there is some provision in place for handling such features as 
floats, multiple column sizes and so forth. The SVG model, on the other 
hand, makes the correlation between a given bounding region and columnar 
flow one to one - if you have need three columns of text, SVG 1.2 
requires that you specifically declare three regions. Content within the 
region, presumably within the <flowDiv> elements, could very well 
consist of multiple flow elements - blocks and spans - that could 
potentially be HTML, if ASV 6.0 is any indication of the behavior.

The CSS flow model presumably is strictly rectilinear. Floats complicate 
the model somewhat because while the bounding space is still 
rectilinear, it is no longer made up of uniform rectangles. This is much 
the same problem that the XSL-FO implementers have had - the flow model 
is fairly similar, and for all the work on FOP and even a couple of the 
commercial FO implementations, floats are a fairly recent innovation at 
best.

The challenge with the SVG model comes from the fact that because it 
utilizes a monocolumnar approach, the CSS flow namespace is meaningless 
for a number of properties when applied to the SVG model.  Because of 
absolute positioning, you lose localization capabilities (you can't 
switch from rt-lb to lt-rb, for instance), whereas the CSS flow model 
would preserve this. There's also the issue of having tl-br text, such 
as vertical Japanese kanji, entering into a very complex flow pattern in 
SVG, whereas it should be properly preserved in CSS.

To me, the logical solution would be to apply CSS columnar attributes on 
an SVG <flowDiv> element, so that you could define a specific region as 
being made up of multiple columns that would fill according to the 
relevant flow model for the type of text involved. Thus, rather than 
having five SVG rects, each of which contains a single column and a 
sixth SVG circle acting as an overflow, you'd have one SVG rect with 
five columns defined within the <flowDiv> element and the circle staying 
the overflow. This would give you the CSS property support/SVG attribute 
support mix without seriously impeding on either model. You WOULD have 
minor differences in implementation for knockouts and floats (a CSS 
flow-region-exclude  attribute would provides a space delimited list of 
elements using selector notation and would echo the <flowRegionExclude> 
element within SVG, for instance) but I tend to be a big fan of the 
notion that you can maintain both a CSS and SVG notation of the same 
underlying property. Finally behavior of excluded regions wrt bounding 
rects vs. exterior paths would have to be determined - possibly a UA issue.

So is this where the underlying conflict lies? If this is specifically 
what you are referring to when you talk about CSS vs. SVG flowText 
issues, then I agree that the SVG specification needs to be extended to 
accomodate the notion of multiple (presumably rectilinear) columns 
within <flowDiv> regions along with any attendant properties for 
determining individual column characteristics. If not, would you mind 
showing me where else the issues reside?

One of the reasons that his is such a hot button issue for me is because 
I have felt strongly for some time that SVG is "almost" complete, but is 
just missing enough functionality to make it less than a complete win in 
the marketplace. Flowing text is a big part of that, and I suspect if 
some resolution can be made with the CSS team, then people such as Ronan 
Oger, Michael Bolger and myself, who I consider as evangelists of the 
technology rather than specification developers can be in a much better 
position to go to our clients or audiences sooner rather than later with 
a solid specification and the attendant implementations and conforming 
suites; as this same audience is likely to defect to something like XAML 
if nothing is forthcoming, I think it would be a major blow to the SVG 
community and the open standards process in general.

-- Kurt Cagle


Robert O'Callahan wrote:

> We understand that completely, and that's why we're implementing SVG. 
> But it won't be useful to us unless we can put that 90% and 10% 
> together in a single document with a unified scripting and styling model.
>
> The SVG WG seems to be saying "Let's finalize SVG 1.2, and then we'll 
> let the CDWG figure out how to make it work in compound documents". 
> Given that SVG 1.2 probably has features that do not work well in 
> compound documents, that seems a foolish approach --- unless 
> SVG-in-compound-documents is allowed to diverge from SVG 1.2, as I 
> have suggested. Two different, but nearly identical, languages for 
> flowing text counts as "not working well".
>
> I still feel it would be a waste of effort for specifiers, 
> implementors, and authors to respecify floats, tables, and all the 
> other CSS flowing layout features in SVG, but I'm less concerned about 
> that if we can avoid having those features appear in 
> SVG-in-compound-documents. I wouldn't object at all to some sort of 
> XML syntax for CSS properties as long as the behaviour of those 
> properties doesn't change.
>
> Rob
>

Received on Thursday, 18 November 2004 07:05:23 UTC