Re: [whatwg] Forced subtitles

2013-04-15 Thread Jonathan Garbee
I think it should be up to the developer to chose the default subtitles
they want. What if someone is trying to localize a page, and the default
subtitle is always English when they want Spanish? If not specified, the
default subtitle should be the language specified of the page or video.
But, if a specific subtitle language is told to the browser it should use
that.


On Thu, Apr 11, 2013 at 7:35 PM, Eric Carlson eric.carl...@apple.comwrote:


 On Apr 11, 2013, at 3:54 PM, Silvia Pfeiffer silviapfeiff...@gmail.com
 wrote:

  I think Eric is right - we need a new @kind=forced or
 @kind=forcedSubtitles value on track elements, because they behave
 differently from the subtitle kind:
  * are not listed in a track menu
  * are turned on by browser when no other subtitle or caption track is on
  * multiple forced subtitles tracks can be on at the same time (see
 discussion at https://www.w3.org/Bugs/Public/show_bug.cgi?id=21667 )
 
  I only wonder how the browser is meant to identify for which language it
 needs to turn on the forced subtitles. If it should depend on the language
 of the audio track of the video rather than the browser's default language
 setting, maybe it will need to be left to the server to pick which tracks
 to list and all forced tracks are on, no matter what? Did you have any
 ideas on this, Eric?
 
   I believe it should be the language of the video's primary audio track,
 because forced subtitles are enabled in a situation where the user can
 presumably understand the dialog being spoken in the track's language and
 has not indicated a preference for captions or subtitles.

 eric


 
  On Fri, Apr 12, 2013 at 4:08 AM, Eric Carlson eric.carl...@apple.com
 wrote:
 
   In working with real-world content with in-band subtitle tracks, I have
 realized that the spec doesn't accommodate forced subtitles. Forced
 subtitles are used when a video has dialog or text in a language that is
 different from the main language. For example in the Lord of the Rings,
 dialog in Elvish is subtitled so those of us that don't speak Elvish can
 understand.
 
   This is only an issue for users that do not already have
 subtitles/captions enabled, because standard caption/subitle tracks are
 expected to mix the translations into the other captions in the track. In
 other words, if I enable an English caption track I will get English
 captions for the dialog spoken in English and the dialog spoken in Elvish.
 However, users that do not typically have subtitles enabled also need to
 have the Elvish dialog translated so subtitle providers typically provide a
 second subtitle track with *only* the forced subtitles.
 
UAs are expected to automatically enable a forced-only subtitle track
 when no other caption/subtitle track is visible and there is a forced-only
 track in the same language of the primary audio track. This means that when
 I watch a version of LOTR that has been dubbed into French and I do not
 have a subtitle or caption track enabled, the UA will automatically show
 French forced subtitles if they are available.
 
   Because forced subtitles are meant to be enabled automatically by the
 UA, it is essential that the UA is able to differentiate between normal
 and forced subtitles. It is also important because forced subtitles are
 not typically listed in the caption menu, again because the captions in
 them are also in the normal subtitles/captions.
 
   I therefore propose that we add a new @kind value for forced subtitles.
 Forced is a widely used term in the industry, so I think forced is the
 appropriate value.
 
  eric
 
 
 




Re: [whatwg] Forced subtitles

2013-04-15 Thread Silvia Pfeiffer
Hi Jonathan,

All of what you're saying is indeed how it would work.

The existing mean of publishing subtitles and the developer choice to add a
@default attribute on a track that a developer wants activated by default
is not affected by a new @kind=forced. You can still do all the things that
you're taking about. @kind=forced kicks in only if neither the developer
nor the user has made any explicit choice about which track to activate.
Also, Eric's suggestion to activate the forced subtitle track that equals
the language of the video seems to meet your suggestion.

Silvia.



On Tue, Apr 16, 2013 at 7:25 AM, Jonathan Garbee jonat...@garbee.me wrote:

 I think it should be up to the developer to chose the default subtitles
 they want. What if someone is trying to localize a page, and the default
 subtitle is always English when they want Spanish? If not specified, the
 default subtitle should be the language specified of the page or video.
 But, if a specific subtitle language is told to the browser it should use
 that.


 On Thu, Apr 11, 2013 at 7:35 PM, Eric Carlson eric.carl...@apple.com
 wrote:

 
  On Apr 11, 2013, at 3:54 PM, Silvia Pfeiffer silviapfeiff...@gmail.com
  wrote:
 
   I think Eric is right - we need a new @kind=forced or
  @kind=forcedSubtitles value on track elements, because they behave
  differently from the subtitle kind:
   * are not listed in a track menu
   * are turned on by browser when no other subtitle or caption track is
 on
   * multiple forced subtitles tracks can be on at the same time (see
  discussion at https://www.w3.org/Bugs/Public/show_bug.cgi?id=21667 )
  
   I only wonder how the browser is meant to identify for which language
 it
  needs to turn on the forced subtitles. If it should depend on the
 language
  of the audio track of the video rather than the browser's default
 language
  setting, maybe it will need to be left to the server to pick which tracks
  to list and all forced tracks are on, no matter what? Did you have any
  ideas on this, Eric?
  
I believe it should be the language of the video's primary audio track,
  because forced subtitles are enabled in a situation where the user can
  presumably understand the dialog being spoken in the track's language and
  has not indicated a preference for captions or subtitles.
 
  eric
 
 
  
   On Fri, Apr 12, 2013 at 4:08 AM, Eric Carlson eric.carl...@apple.com
  wrote:
  
In working with real-world content with in-band subtitle tracks, I
 have
  realized that the spec doesn't accommodate forced subtitles. Forced
  subtitles are used when a video has dialog or text in a language that is
  different from the main language. For example in the Lord of the Rings,
  dialog in Elvish is subtitled so those of us that don't speak Elvish can
  understand.
  
This is only an issue for users that do not already have
  subtitles/captions enabled, because standard caption/subitle tracks are
  expected to mix the translations into the other captions in the track. In
  other words, if I enable an English caption track I will get English
  captions for the dialog spoken in English and the dialog spoken in
 Elvish.
  However, users that do not typically have subtitles enabled also need to
  have the Elvish dialog translated so subtitle providers typically
 provide a
  second subtitle track with *only* the forced subtitles.
  
 UAs are expected to automatically enable a forced-only subtitle track
  when no other caption/subtitle track is visible and there is a
 forced-only
  track in the same language of the primary audio track. This means that
 when
  I watch a version of LOTR that has been dubbed into French and I do not
  have a subtitle or caption track enabled, the UA will automatically show
  French forced subtitles if they are available.
  
Because forced subtitles are meant to be enabled automatically by the
  UA, it is essential that the UA is able to differentiate between normal
  and forced subtitles. It is also important because forced subtitles are
  not typically listed in the caption menu, again because the captions in
  them are also in the normal subtitles/captions.
  
I therefore propose that we add a new @kind value for forced
 subtitles.
  Forced is a widely used term in the industry, so I think forced is
 the
  appropriate value.
  
   eric
  
  
  
 
 



[whatwg] adjusted current node in 12.2.5.5

2013-04-15 Thread Michael Day

Hi,

Recently the spec has been changed to introduce the concept of the 
adjusted current node defined in 12.2.3.2 The stack of open elements.


The intention seems to be to handle the case of setting innerHTML on a 
MathML or SVG element, and hence triggering the fragment parsing 
algorithm in a foreign content context. Since the math or svg 
element will not be in the stack of open elements, this would otherwise 
cause problems with child elements not in the right namespace, and CDATA 
sections not being parsed properly.


However, 12.2.5.5 The rules for parsing tokens in foreign content 
still only refers to the current node, not the adjusted current node.


For example, the rules for parsing Any other start tag:


If the current node is an element in the MathML namespace, adjust MathML 
attributes for the token.


Since the current node in the fragment parsing case is still html, 
this will not have the desired effect.


Should this section be changed to refer to the adjusted current node?

Best regards,

Michael