- From: Kurt Cagle <kurt@kurtcagle.net>
- Date: Wed, 17 Nov 2004 23:04:32 -0800
- To: Robert O'Callahan <robert@ocallahan.org>, www-svg@w3.org
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