W3C home > Mailing lists > Public > www-svg@w3.org > August 2002

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

From: Jon Ferraiolo <jon@ferraiolo.com>
Date: Mon, 19 Aug 2002 07:22:59 -0700
To: "'Jim Ley'" <jim@jibbering.com>, <www-svg@w3.org>
Message-ID: <00f101c2478b$ef0dcb00$09a8a8c0@JONDELL8200>

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. 

While I never was in love with SVG 1.0 choice for tag names for text
elements, I disagree with removing <tspan>. There is a clear difference
between something which identifies the start/end of a text block and
something which alters the attributes of a portion of a text block. 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. (Thus, your opinion is not shared by all.)

But most importantly, the cat is out of the bag. People have been
developing content using <tspan> for years now, and it is now almost a
year since SVG 1.0 became a Recommendation, so lots of content has been
developed since we officially said "go use <tspan>".

Overall, I don't believe that it is worth disrupting the SVG community
by deprecating <tspan>.

However, I think the working group should reevaluate the restriction on
<a> and <tspan>. Tobi (I think) pointed out that we might be able to do
something the XML Schema or at least via supplemental notes in the spec
to prevent this from being legal:


I'll forward your email with my response to the SVG working group.

Jon Ferraiolo
SVG 1.0 Editor

> -----Original Message-----
> From: www-svg-request@w3.org [mailto:www-svg-request@w3.org] On Behalf
> Jim Ley
> Sent: Monday, August 19, 2002 5:31 AM
> To: www-svg@w3.org
> Subject: Re: [SVG1.0] no tspan allowed inside an anchor?
> "Tobias Reif" <tobiasreif@pinkjuice.com>
> > Jim Ley wrote:
> >
> >  > Yes, but that's just a minor change to the text selection rules
> >  > (select
> >  > all text contents of the outer text element.) it's not something
> that
> >  > motivates the need for tspan:
> >  >
> >  > <text x="1em" y="1em">Hello <tspan dx="2em"
> >  > dy="2em">World</tspan></text>
> >  > Would seem to be identical to:
> >  >
> >  > <text x="1em" y="1em">Hello <text dx="2em"
> >  > dy="2em">World</text></text>
> >
> > I find Thomas' explanation of the reasons for tspan very sensible.
> >
> > A tspan ("inline", ~span) is something different from a text
> > ~p/div).
> DIV isn't a block element in HTML.
> I also don't agree that the distinction is particularly useful in SVG,
> and as it causes us the problems you've shown with the A element which
> disappear if text did follow the html's DIV element.  I certainly
> it's a lot more useful to have sensible link text rather than some
> supposed html crossover, and the inability to style portions of a link
> differently is totally limiting in that:
> Consider me wanting to link to Ian Hickson Weblog, using his style
> http://ln.hixie.ch ) I would use in HTML:
> <a href="http://ln.hixie.ch/"><span class="domain"><span
> class="subdomain">log<sub>e</sub></span><span
> class="hixie">hixie</span><span class="dot">.</span><span
> class="ch"><span class="c">c</span>h</span></span></a>
> So the direct conversion of span to tspan would give me this:
> <text x="100px" y="100px"><a xlink:href="http://ln.hixie.ch/">
> <tspan class="domain">
>  <tspan class="subdomain">ln</tspan>
>  <tspan class="dot">.</tspan>
>  <tspan class="hixie">hixie</tspan>
>  <tspan class="dot">.</tspan>
>  <tspan class="ch">  <tspan class="c">c</tspan>h</tspan>
> </tspan></a>
> </text>
> Of course as we note that isn't valid, what would be valid is too big
> me to contemplate writing here, and leads us into problems with WCAG (
> http://www.w3.org/TR/WCAG10-TECHS/#tech-divide-links ,
> http://www.w3.org/TR/WCAG10-HTML-TECHS/#link-text ).
> So whilst re-using the semantics of another mark-up language is
> that's not what we've done we can't translate our a+span in html to
> a+tspan in svg, so far from increasing understanding of SVG, we've
> increased confusion by having similarly named elements be different.
> If that's the only motivation for tspan, then I would certainly like
> see it removed, and have text an allowed child of text, as this link
> issue makes authoring accessible content difficult. [Issue: WG -
> acknowledge.]
> Jim.
Received on Monday, 19 August 2002 10:23:40 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:53:55 UTC