Re: SVG 1.2 Comment: 4 Flowing text and graphics

At 07:25 AM 11/1/2004 +0000, Ian Hickson wrote:

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

Again, not all documents use text in this way and it is not always the 
intent to express semantics (we still use even plain ASCII files, after 
all). Moreover SVG 1.1 already has semantics-free text elements, new SVG 
1.2 elements add absolutely nothing there. The ONLY thing which is added is 
different text PRESENTATION (text in the box with automatic line breaking). 
Adding these features will IMPROVE accessibility because now the same text 
flows are represented by a bunch of tspans (or even worse, text elements) 
whose the only job is to break text into lines (check out any drawing tool 
output).


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

I agree that this would be beneficial, but it has to be done in the 
Compound document activity not in SVG WG. It can be done in future without 
any problem, e.g. by replacing the content of flowDiv or taking your 
proposal as a foundation.

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

So far I am not sure how exactly your proposal would differ in terms of 
glyph positioning. It appears that your proposal effectively rephrases SVG 
1.2 algorithm. (Even if it does not, it could be fixed to do it). The only 
non-syntactic implications that I see so far have to do with fine-grain 
imaging model integration (per-element clipping, masking, gradients, 
filters) and lack of region features (exclusions and per-region references 
as flowRef does). However I do not see anything in current SVG 1.2 proposal 
that would prevent integration later.


> > Your proposal does not seem particularly neat
>
>Could you be more specific? What is it about the single new value that is
>not neat?

See above.



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

Everyone I know agrees that there should be only a single text layout 
engine in a well-designed UA and that exact syntax is not very relevant.



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

Translating it to more practical language you proposing to DROP line 
breaking features in SVG 1.2 and wait several more years before these 
integration issues are resolved even though there is a strong 
implementation feedback that there is nothing in the current SVG 1.2 
proposal that would negatively impact integration in future.



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

Again, the only overlap that I see here is line breaking (which even for 
rectangular shapes is not fully specified in CSS: not where you can break, 
nor how you determine when exactly to break - and given resistance from 
existing implementations - that part of CSS is unlikely to ever be fully 
specified IMHO). This purely has to do with presentation and it should not 
be a problem for SVG to define. Moreover, SVG WG specifically defined line 
breaking in such a way that it is compatible with CSS and a single engine 
can be used to do line breaking for both specs (which is much more 
important than exact syntax) and the success of this design goal has been 
validated in implementations.

Text _flow_ is already a part of SVG 1.1, but flow layout is limited either 
to a single line or text on the path. SVG 1.1 already includes sematic-free 
text/span elements. That is indeed a slight overlap with CSS (which is 
needed for drawing any internationalized text at all if nothing else), and 
this overlap is not increased by SVG 1.2 spec.

Peter


>[snip]

Received on Monday, 1 November 2004 09:02:05 UTC