Re: SVG 1.2 Comments

On Wed, 10 Nov 2004, Dean Jackson wrote:
> 
> For example, despite the really long and sometimes heated discussion on 
> flowing text, I'm fairly confident we can reach consensus sometime (eg. 
> Ian seems to be happier with the suggestion that we provide a method 
> that allows the UA to use its own algorithm). The opposite example is 
> Ian's suggestion to drop the entire spec, where I doubt the W3C would be 
> happy with any resolution that accepted that comment.

I would be satisfied if SVG 1.2 changed the text flow model so that 
instead of using all the new elements, it only added the ability for text 
to overflow from one <text> to another <text> (or similar -- basically, 
only adding one attribute, no new elements). In particular, I strongly 
believe SVG 1.2 should not in any way require line height calculations.


> You're right. I'd like Opera, Mozilla and Apple to join the Working 
> Group, where there is a much higher level of communication (we meet on 
> the phone and face to face for example). I'm sure it would help them, 
> and it would certainly help us.

The SVG working group simply does too much work for us (Opera) to be able 
to get involved. Opera is part of at least six separate working groups and 
task forces puerely at the W3C, not to mention other standards 
organisations; joining more simply isn't feasible at this time, 
unfortunately. If the SVGWG changed focus and instead of adding any new 
features, concentrated purely on correcting existing specs, removing 
features, and writing test suites, then we would probably be more inclined 
to get involved.


> However, it seems that getting SVG Full implemented on desktop browsers 
> is going to take a long time, or we *may* have to do something like what 
> CSS did (admit that CSS 2.0 didn't really work and come up with a CSS 
> 2.1 that is supposed to).

I would strongly, strongly urge the working group to do this. This is work 
that we (Opera) may even be able to find time to help with, especially 
given our experience doing exactly this with CSS.


> At the moment, we're more like CSS 3, which I assume is also targeted 
> for the Web, but doesn't look like it will be implemented (or even 
> finished) for many years. I'm not criticising CSS here, btw :)

Note that CSS3 has slowly (since CSS2.1 work started) been undergoing a 
shift. It probably isn't visible yet in the published CSS3 specs, but many
of the previously proposed CSS3 features are being dropped in favour of 
simpler, smaller extensions. As an example, a few years back the CSS 
working group's position on multiple backgrounds on elements was that the 
proposed multi-level ::outside(n) pseudo-element could be used. After 
receiving feedback that that would take much too much effort to implement, 
we instead are simply extending 'background' to support multiple images.

Sure, that means that dozens, if not hundreds, of possible other use cases 
were thrown out at the same time. ::outside(n) is incredibly powerful. But 
those many use cases were only 10%, and the simpler model targetted the 
90% cases with significantly lower cost to implementations and authors.

I believe the same can be done for many features in SVG (e.g. in 1.2: 
flowing text, vector effects; in 1.1: gradients, filter effects). Sure, 
that means you can't do quite as much, that some edge cases require more 
work or even scripting. But it makes the 90% common cases significantly 
easier to use, and it makes the spec significantly easier to implement, 
and both those points increase the likelihood of widespread adoption.


> In defence, SVG probably went to more effort than any other 
> specification to use existing Web technologies (including JPG, 
> Javascript, PNG, DOM, SMIL, XML).

The point is the other groups didn't go to much effort to reuse other 
specifications because they simply didn't overlap. For example, DOM3 Core 
doesn't reuse XML, or CSS, or HTML, or PNG -- it doesn't have to, it is 
completely orthogonal to those languages.

In the same vain, I don't think SVG should be "reusing" SMIL -- it simply 
shouldn't be overlapping, and where authors need SMIL features, they 
should just be using the SMIL namespace in conjunction with SVG.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Wednesday, 10 November 2004 11:27:07 UTC