- From: Kurt Cagle <kurt@kurtcagle.net>
- Date: Mon, 01 Nov 2004 14:02:07 -0800
- To: www-svg@w3.org
- Message-ID: <4186B25F.7070900@kurtcagle.net>
* === 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