Re: [SVG1.0] no tspan allowed inside an anchor?

On Monday, August 19, 2002, 4:35:35 PM, Jim wrote:


JL> "Jon Ferraiolo" <jon@ferraiolo.com>

>> I haven't monitored this discussion that closely. However, you did
>> request that the WG review your idea that we should get rid of <tspan>.
>> (Isn't that what you are asking?) Here is my personal opinion

JL> That was my suggestion based on the fact that it achieves nothing,

As other people have pointed out, this basic axiom of your argument
was incorrect and thus, the rest of the discussion (and citing of HTML
DTDs) was somewhat moot.

Having reviewed the thread, I find the assertion that text and tspan
are duplicates to be without merit. To see the difference, consider
reading out a couple of blocks of text that have tspans inside them.
Also consider doing multiply nested BIDO switches inside them. Its
should then be apparent in what ways they are different.

JL> that
JL> text alone doesn't give, and is potentially confusing, the main issue
JL> though is the limiting of A which started the thread, and the fact that
JL> the suggestion is it's analgous to the span element of HTML when it is
JL> not.

The limiting of the content model of the 'a' element can be handled,
as has been pointed out, once we move from DTDs to richer schema
languages with contextual content models; trying to fix this agreed
deficiency with DTDs would merely create worse problems due to the
ultra-permissive content model that would be required.


>> As a content developer, it is very nice to be able to search for
>> the string 'text' within an SVG to aid in searching for distinct
>> text blocks. In fact, I would argue that from an accessibility
>> perspective, it is better to have separate elements.

Agreed.

>> (Thus, your opinion is not shared by all.)

JL> I've already demonstrated an accessibility problem with tspan
JL> currently, and proposed a solution,

You do not, however, seem to have noticed the accessibility problem
that would result (particularly for speech synthesis) from moving to a
'text inside text' content model with associated loss of semantics.

JL> it's not the only solution obviously, so a
JL> different resolution would be fine.

JL> Or alternatively you could identify the restriction in a different
JL> mechanism as you suggest, I don't see the particular value in
JL> this, but as I said this could be because of my being inable to
JL> understand the semantic difference between text and tspan.

I suggest you work on that aspect some more. I remember thinking the
same, that the only difference was the visual effect on rendering, but
its not like that at all as a little experimentation with a speech
synthesizer will rapidly demonstrate. XML markup in general always
needs to distinguish between phrasal and non-phrasal/block elements.
Whether these two types of elements happen to have the same of
different attrribute sets is largely orthogonal.

(Note to self, check what XAG says about theis once online again)

Here is an example. Sending the entire block to a speech synth, with
prosodic changes for the span-like (phrasal) elements gives verry
different results to sending each of the elements of pieces of PCDATA
separately.

<quote>
  <person>Dr. Smith</person>
  <emph>used</emph>
  to live at
  <addr>12 Laburnum Dr.</addr>
  but the
  <building>house</building>
  has not been used for ages.
</quote>
  



-- 
 Chris                            mailto:chris@w3.org

Received on Tuesday, 10 September 2002 14:33:49 UTC