Re: 48-Hour Consensus Call: Issue-194 Change Proposal

If it is agreeable, I will make some further changes to the CP in the
next 12 hours, so we have a better CP that addresses Ben's issues.

Regards,
Silvia.

On Wed, May 30, 2012 at 11:51 AM, Silvia Pfeiffer
<silviapfeiffer1@gmail.com> wrote:
> Hi Ben,
>
> Many things to address, so I want to do this early. Shouldn't stop
> anyone else to provide feedback, too.
>
>
> On Wed, May 30, 2012 at 8:13 AM, Benjamin Hawkes-Lewis
> <bhawkeslewis@googlemail.com> wrote:
>>
>> I have some objections to the CP in its current form.
>>
>> + Objection 1
>>
>> The CP is missing critical edit instructions, such as proposed
>> verbiage for what a transcript element "represents" or what it means
>> if a @transcript attribute points to an idref that isn't a
>> <transcript> element, perhaps amongst other idrefs that are! Please
>> make it clear what text needs to be added to the spec.
>
> I can provide explicit edit instructions, but I know that Ian prefers
> to write those himself to keep with the style. I know there is another
> round of discussions at the HTML WG to come before we get there
> anyway.
>
> As for the problem of @transcript pointing to non-transcript
> elements... that is a very good point. I think the suggestion from
> Mozilla to use an attribute that is more like @mediagroup makes a lot
> of sense. Maybe it would be better to associate a <transcript> element
> with a media controller if they are associated and introduce the
> concept of a slaved transcript element. This would work particularly
> well with an interactive transcript. For non-interactive transcripts
> we have not timeline to slave towards, so that could be a bit weird.
>
>
>> + Objection 2
>>
>> I don't understand the point of mentioning @aria-label in "Satisfying
>> [UC1] linked transcripts". Seems redundant with good link text and
>> there's seemingly no new requirements for authors or user agents here,
>> so it's confusing to mention it.
>
> The main use case for @aria-label is to provide text to render in the
> menu that browsers will want to render on top of the video to link to
> a transcript.
> You could regard it as redundant and just use the link text for UC1,
> but then it won't work for the other use cases.
>
> Likely @aria-label is not the best choice of attribute name for this
> use, since it also has an existing different use. Maybe we should
> replace that with @label (just like on the <track> element)?
>
>
>> The CP proposes very complicated
>> markup for the task of linking to transcripts in multiple languages in
>> "Satisfying [UC2] on-page transcripts":
>>
>> <video transcript="t1 t2" src=video.mp4></video>
>> <transcript id=t1 lang=en aria-label="English transcript">
>>  <a href="transcript.html">Transcript for the video</a>
>> </transcript>
>> <transcript id=t2 lang=de aria-label="German transcript">
>>  <a href="transkript.rtf">Transkript fuer das Video</a>
>> </transcript>
>>
>> Why not just let UAs make use of the @lang and @hreflang attributes
>> and generate appropriate UI text?
>
> We don't do automated text creation for the caption track menu either
> - we have @label on the <track> element for this. The use of
> @aria-label follows this pattern.
>
> As for keeping separate transcripts in their own transcript element:
> the use case for this is to allow their identification as separate
> entries in the video player menu. If we mash all of the links together
> under one <transcript> element and mix it with text and headers etc,
> then it's pretty difficult for the browser to identify them as
> separate transcripts. They need to be individually identified through
> a @transcript IDREF to get a separate menu entry.
>
>
>> <video transcript="t1 t2" src=video.mp4></video>
>> <transcript>
>>  <a href="transcript.html">Transcript</a>
>> </transcript>
>> <transcript id=t2 lang=de>
>>  <a href="transkript.rtf">Transkript</a>
>> </transcript>
>
> (I assume you're missing id=t1 on the first <transcript> element?)
>
> Also, the text can likely be created from the <a> elements in this
> case, but not in the other use cases.
>
> Finally: what is written on the page may be more verbose than what you
> want to put into a menu item, e.g.
>
> <video transcript="t1 t2" src=video.mp4></video>
> <h3>Transcripts</h3>
> <ul>
> <li><transcript id=t1 label="Transcript - English">
>     <a href="transcript.html">Full-text English transcript</a>
>     <input type="button" value="Download Now"/>
>    </transcript>
> </li>
> <li><transcript id=t2 lang=de label="Transcript - German">
>     <a href="transkript.rtf">Volltext deutsches Transkript</a>
>     <input type="button" value="Herunterladen"/>
>    </transcript>
> </li>
> </ul>
>
>
>> + Objection 3
>>
>> The reasons given in "Advantages in comparison to a plain IDREFs
>> @transcript attribute only" are often dubious. To address them point
>> by point …
>
> Yeah, that section may need a clean-up - I just threw together what
> came to mind without having fully thought it through. That's why
> having this discussion is good.
>
>
>> "There is no explicit semantic element that allows for the
>> identification of transcripts - it all has to go through the
>> video/audio element. Transcripts being semantically hidden and not
>> explicitly called out on the page make them second-class citizens on
>> the Web. This is particularly problematic for Use Case 4 where there
>> is no media element on the page, but possibly a download link close or
>> even part of the transcript element."
>>
>> The civil rights rhetoric being co-opted here is empty. Are <sentence>
>> and <argument> second-class citizens on the web because they don't
>> have an element? What's more semantic about an element than an
>> attribute anyway? Cite some plausible impacts on end-users of not
>> identifying standalone transcripts. As far as I can tell, for such an
>> element to be really useful you'd need to be able to reliably
>> associate some media somewhere with the transcript, and the CP doesn't
>> provide one.
>
> I don't understand - we introduced <article> and <footer> claiming
> these arguments. Why are they not acceptable for <transcript> ?
>
> The indirection problem is definitely a problem - whenever you want to
> identify transcripts on a page, you have to find the video or audio
> elements first and then link through to the other elements on the page
> that are referenced. That makes transcripts second-class.
> (It's not a civil rights argument - it's a technical argument.)
>
> If you forget to put the IDREF or the id on the elements on either end
> (as you did in the example above), you have no way of recovering. With
> a <transcript> element, you can at least identify intent. It's more
> robust.
>
>
>> "A <transcript> element can receive an aria landmark so you can jump
>> directly to them with AT - this is not possible for the indirect
>> identification of transcripts through a video/audio element and
>> impossible without a media element."
>>
>> Why can't the targets of @transcript can be exposed to navigation just the same?
>
> You'd have to introduce a new @role value and mark up the elements
> that are supposed to be transcripts with @role="transcript". That's a
> patch for the situation where we don't have a semantic element in
> HTML. Why not solve the problem properly?
>
>
>> "There is a multitude of markup possibilities (IDREF to anchor, div,
>> iframe, p, textarea, article, footer etc elements) but not a uniform
>> solution. This is particularly problematic when providing default
>> styling both by the browser and by the Web app developer. It is also
>> much harder to find when manually editing or when scripting."
>>
>> @transcript could be a uniform solution in this respect if we
>> introduced a CSS :transcript pseudo-element comparable to :target.
>
> So, above you've suggested to patch WAI ARIA roles, and now you're
> suggesting to patch CSS as well? Why should we have to make changes to
> all other specs, when a simple addition to the HTML spec would solve
> all of the issues?
>
>
>> "A <transcript> element would be "sectioning content" and thus define
>> the scope of headers, see
>> http://www.w3.org/TR/html5/content-models.html#sectioning-content ."
>>
>> This is true.
>
> OK.
>
>
>> "Marking <a>, <div>, <p>, &;lt;iframe>, or any other element as a
>> transcript-containing element is unclean and ugly - a <transcript>
>> element is elegant and extensible for further new transcript-related
>> features."
>>
>> Having to use an attribute plus an element of the same name doesn't
>> seem obviously less ugly than using just an attribute. It's also not
>> clear that the element supports new features whereas the attribute
>> does not, at least, not any that couldn't be supported by adding an
>> element later.
>
> The required introduction of a new @role value and of a new CSS
> pseudo-selector, and the lack of ability to provide a specific label
> for a menu on the video seem to me enough ugliness.
>
> The most outstanding new feature is the interactive transcript
> rendering from <track> elements. How would you do that with just an
> @transcript attribute?
>
> Finally, why add an element later and thus introduce different
> solutions for transcripts, when one element now would cover them all
> and be extensible?
>
>
>> "There is no obvious means to provide a label for the
>> transcript/transcript link that could be provided in a menu in the
>> video element. For a <transcript> element we can use @aria-label (or
>> something else more adequate)."
>>
>> This doesn't make sense. @aria-label designates the accessible name
>> for a container, it doesn't matter whether the container is a
>> <transcript> or a <div>.
>
> Yeah, @aria-label is not a good choice. Let's use @label instead.
>
>
>> "A @transcript pointing to a div or p element is essentially the same
>> as pointing @aria-describedby at a div or p - these uses may become
>> confused if transcripts are not more explicitly dealt with."
>>
>> This seems implausible. More likely users will incorrectly imagine
>> that @transcript will work the same way as @aria-describedby and not
>> require a seemingly redundant element too.
>
> We could argue about developer expectations forever. ;-)
> Should probably remove this argument.
>
>
>> "Automated rendering of interactive transcripts from a TextTrack file
>> is not possible with such a solution"
>>
>> A :transcript CSS pseudo-element would enable this.
>
> How would that work?
>
> Would you have a <track> element inside the <video> element that
> references the transcript vtt file, then a div that is linked through
> @transcript from the video element into which the browser is expected
> to render the vtt file? Then video :transcript would allow you to
> style the div's content?
> This is the first time that we'd have a div element's content in HTML
> being rendered by the browser - would it be in the shadow DOM? What do
> you do when the linked element is not a div element?
>
> I am indeed waiting for a counter-CP that explains how to do all of
> these things with just IDREFs - I've failed to make it work, which is
> why I ended up with a <transcript> element.
>
>
>> "Even if the user forgets to mark up the video with an @transcript
>> attribute, a <transcript> element will still be announced as
>> transcript content to AT, thus being more robust."
>>
>> I think this should say "might be announced" not "will".
>
> OK.
>
>> Redundancy
>> provides more opportunities for people to get things wrong as well as
>> right. For example, authors might not realize they need to markup the
>> transcript with an element as well as pointing to it with an
>> attribute.
>
> That's a problem with a @transcript attribute alone, too: people may
> continue to do what they do today without providing the linkage.
>
> It's much easier to advertise and learn the availability of an
> explicit <transcript> element: I simply remember that whenever I want
> to publish a transcript, I put it in a transcript element. If I want
> to link it to a video element, I add the @transcript attribute on the
> video. This works if my video is published in an <embed>, in an <a> or
> in any other form.
>
> In comparison: If I want to publish a transcript, I put @transcript
> attribute on a video element. Hmm, but I don't have a <video>
> element... what now?
>
> This is particularly a problem if I am authoring the transcript code
> on the page, but have nothing to do with the video publishing. What if
> the video comes from a different Website and I can't even provide the
> linkage? At least in this way I can mark up my transcript area as
> such. Search engines will be clever enough to find a <transcript>
> element, see a video on the page and provide that linking through
> heuristics.
>
>
>> "Transcript-specific features can be introduced more easily with an
>> explicit <transcript> element, e.g. automatically download with the
>> video page for offline viewing."
>>
>> Why should that be easier?
>
> Same kind of heuristics apply as for search engines where the
> @transcript has been forgotten on the video element, or the video is
> provided through a different means (e.g. <embed>, <a>).
>
>
>> "Using an explicit <transcript> element actually encourages publishers
>> to keep their transcripts visible on page and include them in their
>> published content to the advantage of all users."
>>
>> I don't see how it does anything of the sort.
>
> OK, not worth arguing about intent.
>
>
>> "It makes it a first class feature."
>>
>> There's nothing first-class about elements and second-class about
>> attributes. Are <abbr> and <address> and <ins> somehow more
>> first-class than @class and @lang and @onclick?
>
> It's the indirection that makes it second-class. @transcript does not
> contain the transcript itself (which would be "first-class"), but
> links to another element that has the transcript.
>
> Thanks for the great feedback!
>
> Cheers,
> Silvia.

Received on Thursday, 31 May 2012 08:41:27 UTC