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

Re: Towards resolution of SVG 1.2 Flowing text

From: Dean Jackson <dean@w3.org>
Date: Tue, 2 Nov 2004 22:15:46 +1100
Message-Id: <8B4EC86D-2CC0-11D9-A2F5-000393B3CA5E@w3.org>
Cc: www-svg@w3.org
To: "L. David Baron" <dbaron@dbaron.org>

On 2 Nov 2004, at 17:45, L. David Baron wrote:

> On Tuesday 2004-11-02 15:46 +1100, Dean Jackson wrote:
>> - SVG is a presentational language and, unlike CSS, we are required to
>>   specify as far as possible an exact output result. Therefore we have
>>   to provide simple (and standard) algorithms to achieve this.
> How is SVG's line layout algorithm more exact than CSS's?

If you read closely, you'll see that I said the output result must
be exactly specified in SVG.

To quote Ian: "CSS2.1 intentionally leaves much of the line breaking
algorithm to the user agent, since interoperability on the exact line
breaking algorithm is not required for optimum user experience."

Does that answer your question?

> Also, required by whom?

By the people that want SVG to be interoperable. You, for example.

>  I don't think it's required for the Web any
> more than it is for CSS.

Interoperability between implementations?

> I often get the feeling that SVG is designed
> for something other than the Web

I think it depends on what you consider the Web to be, and what
you consider the Web to become.

> .  If that's the case, fine, but don't
> complain when Web browsers don't implement it.)

Thanks for the advice. I assume you mean I shouldn't complain
when Web browsers don't implement SVG? I've implemented
a fair amount of SVG - I don't think it is that hard (IMO orders
of magnitude easier that implementing HTML to be compatible with IE).
But I won't complain if other people don't implement it.
My major complaint about the Web is the lack of interoperability
between the browsers' CSS implementations.

>> We get many proposals for new features. We do look at them all (and
>> in this case we are required to look at it for Last Call).
>> However, we are probably too late in the cycle to add new features
>> or to make substantial changes. As this feature is required for
>> SVG Tiny 1.2, it makes it even more difficult to consider. This
>> means that we probably don't have the time to engage in a detailed
>> discussion for feature that we already have (and already have spent
>> a long time designing and implementing). Of course, we welcome input
> There's a reason that the last call phase comes before the candidate
> recommendation phase.  The W3C process is that you get input from  
> others
> before declaring a specification ready for implementation.  I would  
> note
> that the last call draft says only the following regarding its  
> stability
> [1]:
>   Publication as a Working Draft does not imply endorsement by the W3C
>   Membership. This is a draft document and may be updated, replaced or
>   obsoleted by other documents at any time. It is inappropriate to cite
>   this document as other than work in progress.

Exactly as it is required to do, but I don't understand your point.
I didn't promote the specification as complete, just that we discussed
this issue many times over the past few years.

> But it's also worth noting that this issue was raised well before last
> call [2].

Again, if you read what I wrote, you'll see that I accept the comment,
and that I guarantee that we'll look at it. Just as we were very  
to Robert for raising his issues. We would have done this even if
we were not in Last Call. Being new or old doesn't matter.

We'll also look at the proposal made by Ian. Maybe we'll drop what we
have and accept it but, as I said, we've spent a lot of time designing
this feature and have rejected similar proposals in the past. As I also
said, I was one of the people that made a similar proposal.


> -David
> [1] http://www.w3.org/TR/2004/WD-SVG12-20041027/#status
> [2] http://lists.w3.org/Archives/Public/www-svg/2004May/0019.html
> -- 
> L. David Baron                                <URL: http://dbaron.org/  
> >
Received on Tuesday, 2 November 2004 11:15:53 UTC

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