Re: ISSUE-303 (<a> link element): Permit HTML-style <a> elements to contain href links [TTML2]

Compatibility with HTML, longer typing with xlink format, lack of
implementation of xlink, active removal of support for xlink syntax from
some SVG UAs, etc.

I would also prefer to ditch xml:id in favor of straight 'id', or perhaps
restore 'id' as an alternative.


On Tue, Mar 25, 2014 at 10:12 AM, Nigel Megitt <nigel.megitt@bbc.co.uk>wrote:

>  Any pointers to technical reasons why unqualified href is preferred and
> xlink not?
>
>
>   On 25/03/2014 16:04, "Glenn Adams" <glenn@skynav.com> wrote:
>
>   FYI, the SVG WG is backing away from Xlink syntax, reverting to older
> unqualified @href. I would be reluctant to introduce Xlink features.
>
>
> On Tue, Mar 25, 2014 at 5:21 AM, Nigel Megitt <nigel.megitt@bbc.co.uk>wrote:
>
>>  Thanks for the suggestion Andreas. It looks as though the only change
>> needed to my proposal is to put the href and target attributes into the
>> xlink namespace in order to create xlink 'simple' links. This is very
>> similar to the approach taken by SVG with the <a> element [2], which seems
>> to be an appropriately close example to take inspiration from.
>>
>>  [2] http://www.w3.org/TR/SVG11/linking.html#Links
>>
>>  To complete the definition we could also consider adding in the xlink
>> behaviour attributes show and actuate.
>>
>>  This could be very helpful for extending TTML to permit referencing of
>> external image resources in place of text, for example, by setting
>> show="embed" actuate="onLoad". Note that the temporal extent of the
>> rendering of such an external resource would be identical to that defined
>> in TTML depending on the location of the <a> element, which does not itself
>> have begin and end attributes. This could be extended to audio clips noting
>> that the playback temporal extent would be clipped by the applicable
>> temporal extent, in the case that the audio clip has a longer temporal
>> extent than the applicable TTML temporal extent.
>>
>>  Links that the user may follow, to be loaded in a different context,
>> i.e. not replacing the TTML content, would have show="new" or show="other"
>> and actuate="onRequest". I would leave it up to implementations to define
>> how the request mechanism may work in terms of user interface, but add a
>> note that if more than one 'onRequest' link is simultaneously displayed
>> that may add unhelpful complexity due to the need to do more than simply
>> trigger a 'follow link' action in a time-constrained display, for example
>> requiring an interaction to decide which link to follow.
>>
>>  Links that are automatically followed but loaded in a different context
>> would have show="new" or show="other" and actuate="onLoad".
>>
>>  NB I don't propose to add a mechanism for linking *into* a TTML2
>> document.
>>
>>  Kind regards,
>>
>>  Nigel
>>
>>
>>   On 24/03/2014 16:31, "Andreas Tai" <tai@irt.de> wrote:
>>
>>   Because TTML is an XML Format you may consider XLink [1] for this
>> purpose.
>>
>> Best regards,
>>
>> Andreas
>>
>> [1] http://www.w3.org/TR/xlink11/
>>
>> Am 21.03.2014 16:23, schrieb Glenn Adams:
>>
>> We had a rule for TTML1: no references to external resources. We will
>> remove that rule for TTML2 for images and fonts, and perhaps now
>> anchor/links as well.
>>
>>
>> On Fri, Mar 21, 2014 at 8:24 AM, Timed Text Working Group Issue Tracker <
>> sysbot+tracker@w3.org> wrote:
>>
>>> ISSUE-303 (<a> link element): Permit HTML-style <a> elements to contain
>>> href links [TTML2]
>>>
>>> http://www.w3.org/AudioVideo/TT/tracker/issues/303
>>>
>>> Raised by: Nigel Megitt
>>> On product: TTML2
>>>
>>> Permit <a> elements with href and target attributes only, around content
>>> elements or text.
>>>
>>> This appears to be the minimal useful set of attributes around a link
>>> that may appear in a timed context.
>>>
>>> The purpose of the target is to permit the linked content to be loaded
>>> into an alternate context: one possible use case for this is to allow the
>>> linked content to be loaded into a different window or iframe without
>>> interrupting the flow of captions displayed against a video that's being
>>> watched.
>>>
>>> More concretely, this could be used for example for 'go here for more
>>> information' links or 'go here to vote for candidate X' links. A third
>>> example could be 'go here for these subtitles in language [xyz]'.
>>>
>>> I don't know if this has been raised before, but it seems so obvious
>>> that I'm surprised I couldn't find an issue for it - happy to be told where
>>> to look for it if this is a duplicate. Apologies if I'm opening a can of
>>> worms that everybody would rather stay closed...
>>>
>>>
>>>
>>>
>>
>>
>> --
>> ------------------------------------------------
>> Andreas Tai
>> Production Systems Television IRT - Institut fuer Rundfunktechnik GmbH
>> R&D Institute of ARD, ZDF, DRadio, ORF and SRG/SSR
>> Floriansmuehlstrasse 60, D-80939 Munich, Germany
>>
>> Phone: +49 89 32399-389 | Fax: +49 89 32399-200
>> http: www.irt.de | Email: tai@irt.de
>> ------------------------------------------------
>>
>> registration court&  managing director:
>> Munich Commercial, RegNo. B 5191
>> Dr. Klaus Illgner-Fehns
>> ------------------------------------------------
>>
>>
>>
>> ----------------------------
>>
>> http://www.bbc.co.uk
>> This e-mail (and any attachments) is confidential and may contain
>> personal views which are not the views of the BBC unless specifically
>> stated.
>> If you have received it in error, please delete it from your system.
>> Do not use, copy or disclose the information in any way nor act in
>> reliance on it and notify the sender immediately.
>> Please note that the BBC monitors e-mails sent or received.
>> Further communication will signify your consent to this.
>>
>> ---------------------
>>
>
>
>
> ----------------------------
>
> http://www.bbc.co.uk
> This e-mail (and any attachments) is confidential and may contain personal
> views which are not the views of the BBC unless specifically stated.
> If you have received it in error, please delete it from your system.
> Do not use, copy or disclose the information in any way nor act in
> reliance on it and notify the sender immediately.
> Please note that the BBC monitors e-mails sent or received.
> Further communication will signify your consent to this.
>
> ---------------------
>

Received on Tuesday, 25 March 2014 16:21:34 UTC