Re: SVG 1.2 Comment: 4 Flowing text and graphics

On Sun, 31 Oct 2004, Peter Sorotokin wrote:
> 
> I am puzzled. What exactly does it reinvent in HTML or CSS? Line breaks?

  SVG 1.2               HTML or CSS
  --------------------------------------------------
  <svg:flowDiv>         <html:div>
  <svg:flowPara>        <html:p>
  <svg:flowSpan>        <html:span>
  <svg:flowRegionBreak> 'page-break-after: always'
  <svg:flowLine>        :after { content: '\A'; }
  <svg:flowLine/>       <html:br>
  <svg:flowImage>       <html:img>


> Why is it somehow OK to have single line text flow with all complex 
> internationalization features (baselines, bidi, vertical text, glyph 
> orientation) and text-on-the-path and somehow not OK to have (much 
> simpler to implement!) text in the shape?

Text, especially when there is more than just one line's worth, is 
content. Content should be marked up in a semantically-rich fashion for 
accessibility reaosns. HTML is the language for this.

It is acceptable for a specification to introduce simple alternatives for 
complex specifications (for example, the way CSS2 allows authors to 
perform simple 'text-shadow' effects without using the full SVG model) but 
when it comes to reinventing large parts of other specifications, one has 
to draw the line.

For example, members of the SVG group frequently warn against CSS 
reinventing gradient effects. Gradient effects are a feature with much 
demand, but the CSS working group has accepted that HTML+CSS UAs must 
implement all of SVG's model to provide that feature.


> Note that SVG text features are designed in such a way that single text 
> engine can easily be designed to handle both CSS and SVG text layout 
> (this is what Adobe SVG Viewer 6 preview does).

I don't really see how. The CSS inline box model and the SVG 1.2 text flow 
model are _radically_ different.


> As for your proposal, given our experience on text layout feature 
> design, it is unlikely that we have enough time to review it before PR.

It is a W3C process requirement that you review all input before 
progressing from Last Call to Candiate Recommendation. (Process section 
7.3.) Several people have already reviewed my proposal, it's actually 
pretty simple. I have no doubts that the SVG working group will be quite 
capable of reviewing my proposal.


> These are problems I see immediately:
> 
> - you proposing that we do exactly the thing (extending overflow 
> property) that you say is wrong in other places (extending cursor 
> property)

I would recommend that the SVG group propose my suggestion to the CSS 
group, not that the SVG group incorporate it into the SVG spec.


> - you propose different algorithm than is in the current draft (which is 
> based on SVG 1.1) - what is your justification for that?

The algorithm currently in SVG 1.2 doesn't handle the CSS inline box 
model, floats, multiple containing blocks, full vertical alignment 
requirements, etc. My proposal is a simple extension to the existing CSS 
model so that any existing CSS-styled content can be poured into an SVG 
shape. For example, it would be possible to use my proposal to mould any 
existing HTML Web page using an SVG shape.


> - it does not integrate with SVG drawing model (clipping, masking, 
> gradients, patterns, filter effects)
> - it does not allow one to change order (and other properties, say, 
> opacity) in which regions are drawn

In what way do you believe the text flow model should integrate into the 
above processes? My understanding is that my proposal supports all the SVG 
integration features of <foreignObject>, which is an SVG 1.0 feature, and 
which, I believed, was fully part of the SVG drawing model.


> - it effectively forces SVG 1.2 implementor to implement full CSS box 
> model which is unwarranted

On the other hand, the SVG 1.2 solution forces HTML+CSS implementors to 
implement the full SVG model, and doesn't provide any way for existing 
content to be restyled using SVG features.

And like I said above, HTML+CSS UAs have to implement the whole SVG model 
to provide gradient backgrounds, so why shouldn't SVG UAs implement the 
whole CSS model to provide flowed text, which HTML and CSS have been doing 
since the mid 90s?


> Your proposal might be a good basis for integration between XHTML and 
> SVG, though.

Are you suggesting that the SVG working group is not, in its development 
of SVG1.2, considering multiple document formats to be the primary use 
case? If this is the case, one is forced to question the extent to which 
SVG1.2 is addressing the SVG charter's requirement to produce "a modular 
XML tagset usable in mixed-XML namespace documents" [1].

[1] http://www.w3.org/2003/07/svgwg-charter.html

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Monday, 1 November 2004 01:10:27 UTC