- From: Dean Jackson <dean@w3.org>
- Date: Tue, 2 Nov 2004 22:15:46 +1100
- To: "L. David Baron" <dbaron@dbaron.org>
- Cc: www-svg@w3.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." http://www.w3.org/mid/ Pine.LNX.4.61.0411011906440.25029@dhalsim.dreamhost.com 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 grateful 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. Dean > -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