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

Re: SVG 1.2 Comment: 4 Flowing text and graphics

From: Jim Ley <jim@jibbering.com>
Date: Mon, 1 Nov 2004 02:06:28 -0000
To: www-svg@w3.org
Message-ID: <cm45ni$i2n$1@sea.gmane.org>

"Ian Hickson" <ian@hixie.ch> wrote in message 

> 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.

HTML contains virtually no semantics for text here, your examples above used 
DIV, SPAN, they're semantically empty.

> 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.

The relevant parts of text flow, are not the text, but the flowing to 
arbitrary shapes, this doesn't exist anywhere else, your proposal does not 
seem particularly neat, and re-uses no semantics from HTML - DIV and SPAN 
being empty of semantics, or requires all semantics from HTML, since as 
you've noted in the past requiring a complete implementation of one spec in 
another is inappropriate, it puts too high a burden on implementors (which 
is why CSS2 putting text-shadow in was reasonable)

I agree flowPara is unnecessary, you can see my full comments later, but I 
do not see the point of having html:div and html:span re-used as they offer 
nothing at all but a proliferation of namespaces without any sound 
motivation, or would you argue that html:span be better than svg:text too?

> 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.

I understand from your blog Ian, that you are a member of the SVG WG, so 
it's up to you to review it as much as anyone else, from your comments it's 
obvious that you feel the SVG 1.2 is not ready for Last Call, could you 
explain your reasons for abstaining from the vote to move to LC rather than 
voting against?  It might help us understand the motivations for these 
comments, and the long delay in sending comments against parts of the spec 
that have been unchanged in many months.

> 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.

The requirement to have the text styled by CSS is an undue burden, there are 
very few SVG implementations that also do CSS (not surprisingly, it's 
optional, and not very useful to svg authors)  Personally I would rather the 
dependency in CSS be removed entirely, there's no motivation that I can see 
for having a rendering language styled by another rendering language - one 
layer is plenty.

> 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.

You're working from the premise that SVG+HTML+CSS is a goal of the SVG 1.2 
specification, that's a compound documents issue, and we can see from the 
compound documents charter that this is some way off, they've only just 
started work.  Currently this isn't specified at all, there are no shipping 
implementations that attempt this, and all the current attempts have run 
into considerable problems.  I do not think SVG1.2 is the right place to 
suddenly decide to fix these issues - there's a whole working group 
currently doing this.


Received on Monday, 1 November 2004 02:06:49 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 March 2017 09:47:00 UTC