- From: Peter Sorotokin <psorotok@adobe.com>
- Date: Mon, 29 Nov 2004 14:45:56 -0800
- To: Boris Zbarsky <bzbarsky@MIT.EDU>
- Cc: www-svg@w3.org
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