Re: SVG 1.2 Comment: Flowing text and graphics

At 03:43 PM 11/29/2004 -0600, Boris Zbarsky wrote:
>Peter Sorotokin wrote:
>>>So the problem is that you need an order on your areas and an SVG shape 
>>>would not provide that?  But surely one can use an ordered list of SVG shapes?
>>Given a choice of inventing a new attribute syntax (list of URLs) or a 
>>new mark-up, I'd invent new mark-up.
>
>There are two issues with new mark-up:
>
>1)  Conceptual brain-print.  Instead of reusing an existing concept 
>(shapes) new
>     concepts are introduced.
>2)  Error-handling is much more complicated to define.  For example, there 
>is no
>     indication how flowRegions outside flowRoots are to be treated, nor
>     flowRegions that are children of random elements (eg <g>) that are 
> children
>     of flowRoots.  The RelaxNG schema is not sufficient for this purpose, 
> since
>     it's of no use to applications that use a non-validating parser and since
>     people _will_ produce documents that don't conform to the schema (it's
>     happening with XHTML, and I've commonly seen it happening with both 
> XUL and
>     XBL).  Further, DOM modification can easily produce a DOM that doesn't
>     comply with the schema even in an application with a validating parser.
>     Therefore, implementations will need to make sense of various DOMs 
> that may
>     arise, and how they do so needs to be specified.  Generally, the 
> complexity
>     of such specification grows exponentially in the number of
>     possibly-interacting element types... That may not be the case here, but
>     it's hard to tell, since no error-handling provisions at all are made in
>     this section.

I think you are missing the point. I am not talking about semantics or 
concepts. I am saying that new attribute *syntax* is not as good as new 
markup *syntax*. This is a generally accepted rule for SVG and the only 
deviation from it is path data (where XML syntax was too verbose). 
Gradients, filters, clip paths etc. are all done with XML syntax, not 
attribute/property syntax. There are many (quite obvious) reasons for it.


>>You propose there is another property for exclusion regions? How could I 
>>exclude something only from one region, but not others?
>
>Isn't that just a matter of appropriately defining your shape to not 
>include that region to start with?

But what if I want to fill with text only a shape which is not obscured by 
something else, and I don't want to calculate the shape which is my shape 
minus that something else (which might be dynamic).


>Or am I misunderstanding the question?
>
>>>flowRef does need something to reference, but it's not clear to me why 
>>>flowRef is needed...
>
>>flowRef is needed if you want to reference only something which is flown 
>>in a particular region, possibly multiple times.
>
>Yes, I realize that.  But what is the use case for this?

Export from any more or less modern authoring tool or many apps without 
breaking text into (inaccessible and non-searchable) pieces (which is the 
whole point of text in the shape). Suppose I want to draw a picture of a 
2-page document lying on a table. Than I have to draw page 2 on top of page 
1. Or suppose I want to apply different effects to different shapes (i.e. 
magnify it or fade in/out). flowRef decouples drawing from flowing, so it 
is needed almost in any case when shapes differ in any way.


>>>In other words, I think you can simply reference the CSS3 Text property 
>>>without placing additional restrictions on it, I believe.
>>Is it stable, though?
>
>CSS3 Text is in CR.  I don't recall what the state of CSS3 Text moving our 
>of CR is, and I recall there being possibilities of some features being 
>dropped or reworked due to lack of implementations.

Does it mean that if we reference it, we have to stay in CR until it moves 
to Rec?

Peter


>That said, I'm pretty certain that text-align is _not_ one of those 
>features. An email to www-style@w3.org to verify this may be in order, of 
>course.  ;)
>
>-Boris

Received on Monday, 29 November 2004 22:46:07 UTC