Re: Deprecating <tref>

Hi,

partial reason for the low usage is surely
<https://bugzilla.mozilla.org/show_bug.cgi?id=273171>. Authors on
the web don't bother with it, since it's not supported in Firefox.

I actively vote for keeping it. There's, for example, one use
case, that <tref> can handle and <text> not: localization with
a remote text server:

<tref
xlink:href="http://example.com/translate/My%20hovercraft%20is%20full%20of%20eels"/>

Actually, I'm waiting for years for Firefox to fix #273171 so I
can finally use <tref> on the web.

Cheers,
Manuel

> 
> On Jun 26, 2013, at 8:00 PM, Doug Schepers
<schepers@w3.org> wrote:
> 
>> Hi, folks-
>>
>> Philip's concerns seem reasonable, but I also I
hear reluctance to
>> deprecate a feature that's in use, which
I share; I've used <tref> quite
>> a bit myself back when
Adobe still supported their plugin, though less
>> so in
browsers, since support is spotty.
>>
>> When we
look at <tref>, it largely seems like a special case of
<use>,
>> exclusive to text. Since we are revamping
<use> as an application of the
>> component model, it
makes sense to me that we would do the same for
>>
<tref>; that way, it would share a mostly unified code base and
security
>> model with <use>, which itself would derive
from the component model,
>> making it easy to maintain.
>>
>> Does that seem like a reasonable solution?
> 
> I think so. If there is content using it and enough
implementations
> supporting it, we should not deprecate it IMO.
We will revisit this anyway
> when we want to get to CR. I support
using the same component model for
> <tref> as for
<use>.
> 
> Greetings,
> Dirk
> 
>>
>> Regards-
>> -Doug
>>
>> On 6/26/13 8:38 PM, Rick wrote:
>>> Dear Working
Group:
>>>
>>> Thank you for your efforts and
hard work in advancing SVG and in
>>> maintaining a robust
and important specification.
>>>
>>> I ask you
to consider that, while this proposal may not effect most
>>> content, it definitely will break leading edge SVG
applications
>>> currently deployed in the air traffic
industry.
>>>
>>> <tref> is useful for
shadowing text.
>>>
>>> Consider an
application that uses a cursor with coordinates following
>>> over a multicolored display for mapping, image editing or
CAD.  Having
>>> to set only one element speeds the process
up and improves the look,
>>> feel and functionality of the
application.
>>>
>>> /S/hadowed text with
<tref> is used in many less critical areas that
>>>
benefit from this convenience.
>>>
>>> If this
feature is deprecated, it will affect software used in high
>>> profile engineering mapping displays deployed at major
international
>>> airports on five continents, soon to be
six.
>>>
>>> It's a good feature.
>>>
>>> Cheers!
>>>
>>>
>>> On Wed, Jun 26, 2013 at 5:15 PM, Philip
Rogers <pdr@google.com
>>>
<mailto:pdr@google.com>> wrote:
>>>
>>>    www-svg,
>>>
>>>    I would
like to propose deprecating <tref> from SVG2. I would also
>>>    like to field your opinion on removing it from Blink.
>>>
>>>    Our numbers show <tref> use in
the wild is virtually nonexistant:
>>>    less than
0.0000003% of pages. Furthermore, the supporting code is
>>>
   complex and has been a source of many security bugs in Blink and
>>>    WebKit. Of the 24 tref bugs that have ever been filed
against
>>>    Chrome, 14 have been stability or security
related.
>>>
>>>    What do you think of
slimming up both the spec and implementations
>>>    by
removing <tref>?
>>>   
https://svgwg.org/svg2-draft/single-page.html#text-TRefElement
>>>
>>>    Philip
>>>
>>>
>>>
>>>
>>> --
>>> /Rick Graham.
>>> /
>>> /Senior
Applications Architect, NAVCanada <http://www.navcanada.ca/>.
>>> /
>>> /Contributing Author, Scalar Vector
Graphics (SVG)
>>> /
>>> /grahari@navcanada.ca
<mailto:grahari@navcanada.ca>
>>> /
>>>
/graham.rick@gmail.com <mailto:graham.rick@gmail.com>
>>> /
>>>
>>
>>
>>
> 
> 
>

Received on Thursday, 27 June 2013 07:02:51 UTC