W3C home > Mailing lists > Public > www-svg@w3.org > November 2004

Re: SVG 1.2 Comment: 4 Flowing text and graphics

From: Kurt Cagle <kurt@kurtcagle.net>
Date: Mon, 01 Nov 2004 14:02:07 -0800
Message-ID: <4186B25F.7070900@kurtcagle.net>
To: www-svg@w3.org
* === Håkon writes
The problem lies in how different specs interact. Placing strings of
text on a line or on a path nicely complements vector graphics and
naturally belongs in SVG. When you add flowing text you turn SVG from
a vector graphics format to a generic document format. This may be a
simple change in your spec and code, but it has a huge impact on how
content is authored on the web. HTML has traditionally had this role
and making a second language duplicate the functionality seems to
create unnecessary competition between specifications that would be
better off collaborating. W3C's efforts in Compound Documents is a
welcome effort to ensure that specs can collaborate in this manner.

Another way to answer your question would be to turn it around: what
exactly is wrong with CSS4 introducing polygons, background gradients
and animation when we already have borders, background images and
text-decoration: blink?


I think it's wise to review last call comments before PR.

==== *

Håkon,

Redundancy in the graphical specifications is to be expected. XSL-FO 
performs many of the same functions that HTML does, but also performs 
many functions that HTML doesn't (and vice versa). The same thing can 
readily be said to be true about SVG - I have had numerous applications 
in SVG that required the ability to do multiline text without the 
awkward and limiting restriction of having to deal with overriding the 
default flow model manually. Does this mean that I am using SVG to 
replace HTML? No, of course not.

HTML is a device language - one that tells a particular application (a 
browser) how to flow specific content and how to link specific content 
so that it works well within the context of expectations that we call 
web browsing. HTML (even with CSS) has no notion of discontinuous flow 
models, one of the reasons why doing traditional newspaper/magazine type 
layouts is so notoriously difficult.

SVG is a more complex language, in great part because it posits many 
features that are not intrinsic to HTML - discontinuous flow models, 
paging, transformational frames of reference, and so forth, that are a 
staple of the lexicon that anyone who has dealt with Postscript has had 
to deal with since the early 1980s (former typesetter speaking here). It 
will not replace HTML precisely because of that complexity, though it is 
certainly a possibility that it could change the nature of some of the 
user agents that deal with HTML by creating an SVG bridge between core 
HTML and the final rendering surface. If you take a look at what is 
happening now on the Linux side with the X.org consortium, the pieces 
are definitely coming into place for this precise scenario to happen, at 
least within the Unix framework.

I am not a member of any W3C groups, and certainly am not privy to what 
is going on with CSS 4.0. There is certainly overlap, this is pretty 
much inevitable since both groups are tasked with needing to build 
presentation layers. It would be my hope that rather than attempting to 
build yet another graphical layer on top of CSS that CSS could instead 
shift into a mode of becoming increasingly a binding architecture, as is 
the case with XUL. This is not inconsistent with the sXBL model (and 
indeed, is one of the pieces of sXBL that seems to be weak, though I 
will readily admit that I"m still trying to come to terms with that 
specification).  Given the complexity of gradients and patterns, using 
CSS to bind SVG -

<html>
<head>
<style type="text/css" version="4.0" xml:space="preserve">
.myBlock 
{background-gradient:url('myBlock.svg#myGradient');foreground-pattern:url('myBloc.svg#myPattern');}
</style>
</head>
<body>
    <div class="myBlock">This has some interesting properties</div>
</body>
</html>

makes a great deal of sense to me, and I suspect that such a binding 
model would readily integrate into fallback situations quite easily.

Similarly, if you assume the emergent model of mixed namespaces, there 
is definitely room for both CSS binding and mixed usage scenarios. In 
current HTML+CSS, the coordinate system is translational only - there 
are no mechanisms with CSS to rotate or otherwise modify text, no 
mechanisms short of manual parsing to make text flow around obstacles, 
nothing that lets you create discrete connected blocks of text. To do so 
requires a more sophisticated data structure than a dictionary to make 
happen. Yes, you CAN define such things within a next generation CSS, 
but why do so when the mechanism to do so has already been defined and 
has gone through two formal iterations as SVG. Again, shifting CSS into 
a binding model:
.myBlock {
        background-gradient:url('myBlock.svg#myGradient');
        foreground-pattern:url('myBloc.svg#myPattern');
        clip-path:url('myBloc.svg#myTextFlowContainer');
        }
accomplishes the same thing, and has the added advantage of abstracting 
out the need to know the specific geometry of the paths or flow model 
(in the assumption that <elt id="myTextFlowContainer"/> is a discrete 
block of regions).

-- Kurt Cagle
Received on Monday, 1 November 2004 22:03:19 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 5 February 2014 07:14:52 UTC