Re: SVG 1.2 Comment: 4 Flowing text and graphics

On Mon, 1 Nov 2004, Jim Ley wrote:
>>
>> 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.

That is rather my point. My examples were showing how SVG currently maps 
to HTML and CSS, showing how there is a strong mapping, but how that 
mapping has poor accessibility due to its lack of rich semantic markup.

If the SVG working group instead encouraged use of semanic HTML markup, 
authors could use the strong semantics of elements such as <cite>, <em>, 
<blockquote> and the like.


> [partly rephrased to use actual english punctuation. I couldn't quite 
> work out what you were trying to say at the end though.]
>
> The relevant parts of text flow are not the text, but the flowing to 
> arbitrary shapes. This doesn't exist anywhere else.

Indeed -- extending the presentation level of the flowing text 
specifications to allow for arbitary shape layouts would be a great idea. 
However, that's very different from the SVG 1.2 proposal, which consists 
of extending the presentation level to actually have (limited, for now) 
text semantics itself.


> Your proposal does not seem particularly neat

Could you be more specific? What is it about the single new value that is 
not neat?


> and re-uses no semantics from HTML -- DIV and SPAN being empty of 
> semantics --

It allows the use of any markup language, in particular HTML. HTML is 
semantically rich. Therefore I don't understand what you're talking about.


> 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'm not 100% sure what this run-on sentence was supposed to say, but if 
you are saying that requiring full HTML support in an SVG processor is 
inappropriate, then you seem to have missed the fact that the SVG working 
group charter indicates that support of orthogonal W3C specs in one UA is 
the expected use scenario for SVG. The fact that many SVG working group 
members are now taking part in the CDF work would suggest that this is not 
a contentious issue.


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

You appear to be attacking a straw man here. I haven't proposed replacing 
flowPara with <html:div>. I have proposed reusing existing specifications 
to perform the same role they have been designed for since the early 90s, 
with a small extension to the relevant styling language to allow SVG 
shapes to be used in the same context.


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

I have already corrected you on this matter _multiple_ times in different 
forums. I am not a member of the SVG working group except in so far that I 
am an editor of a spec that is being written in a joint CSS+SVG task force 
but published through the SVG working group.


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

I was not involved in the vote (assuming there even was one), as I am not 
a member of the SVG working group per se.


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

I had not had the time to examine SVG 1.2 in depth until the move to last 
call precipitated my making the matter a priority. Given the state of the 
draft, I had assumed that SVG 1.2 was a long way from reaching last call, 
and that the issues I had raised would have been spotted within the 
working group itself and been resolved long before last call was reached.

I have been informally giving feedback on the matter (especially my 
concern that SVG 1.1's test suite is highly inadequate) for some time.


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

Like I said in a reply to Peter, it seems ridiculous for the SVG working 
group to say that features that overlap with SVG (such as gradient 
backgrounds) must not be introduced to CSS, while the SVG working group 
happily introduces many features that overlap with CSS.


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

This is exactly the attitude that I raised in my last call comments as 
being a cop-out solution. The SVG charter says:

   The working group will be chartered to extend the SVG 1.1 format, 
   producing a modular XML tagset usable in mixed-XML namespace documents.
   ...
   The principal request is greater integration with other W3C 
   specifications, such as XForms (to allow SVG form controls); CSS and 
   XSL (to allow wrapping styled text inside graphics); and to ensure that 
   SVG graphics can be placed inline in multi-namespace XML documents.
   ...
   The architectural constraints on the technology to be developed are:
    # compatible with the principles of the Architecture document
    ...
    # be widely implementable in browsers
    ...

This all seems to strongly indicate that SVG being used in HTML contexts 
is indeed a goal of SVG 1.2 and the SVG working group in general.

Just because there is a demand for a profile that will define which parts 
of W3C specifications should be used together does not mean that these 
specifications should go out of their way to not reuse other work or to 
not be good citizens in mixed-namespace contexts.


> Currently this isn't specified at all

What is it that is unspecified? The interaction of XHTML and SVG is by and 
large straight-forward.


> there are no shipping implementations that attempt this, and all the 
> current attempts have run into considerable problems.

Hyperbole notwithstanding, I assure you that there really aren't that many 
problems. In fact with the exception of SVG 1.1 having an incompatibility 
with CSS syntax (unitless numbers are not lengths, despite what the SVG 
specifications claim), I am not aware of any. Could you explain what 
issues you are referring to?


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

This is a straw man argument. I have not requested that the SVG WG solve 
compound document issues, I have merely asked that the SVG WG not 
introduce overlap between specifications, as per the SVG WG charter.

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

Received on Monday, 1 November 2004 07:25:41 UTC