[CSSWG] Minutes and Resolutions 2011-10-19

   - RESOLVED: Do not rename voice-volume (css3-speech issue-3)
   - RESOLVED: No change to list of at-risk properties (css3-speech issue-4)
   - Clarifying edits assigned for voice-rate (css3-speech issue-5)
   - RESOLVED: Not adding 'play-during' to CSS3 Speech; may consider for later
               level. (css3-speech issue-6)
   - Example edits assigned for voice-stress (css3-speech issue-7)
   - Bert to fix CSS specs' indexer for better accessibility; needs suggestions
     on exact markup to change to.
   - RESOLVED: Recommended styling of ARIA out-of-scope for CSS Speech
               (css3-speech issue-10)
   - RESOLVED: Improve informative wording on using decibel offsets in
               voice-volume. (css3-speech issue-11)
   - RESOLVED: Do not drop 'silent' value of 'voice-volume' (css3-speec issue-12)
   - RESOLVED: Proposal to re-merge 'speak' and 'speak-as' rejected, for reasons
               that they were split. (css3-speech issue-13)
   - RESOLVED: Not adding <time> value restrictions to 'voice-duration' to
               enforce good authoring practices. (css3-speech issue-14)
   - RESOLVED: Media Queries feature request for user-capability-querying is
               out-of-scope. (css3-speech issue-14)

====== Full minutes below ======

   César Acebal
   Kimberly Blessing
   Bert Bos
   Arron Eicholz
   Elika Etemad
   Sylvain Galineau
   Daniel Glazman
   Arno Gourdol (late)
   Koji Ishii
   John Jansen
   Brad Kemper
   Hĺkon Wium Lie
   Peter Linss
   Eric Mueller
   Anton Prowse
   Alan Stearns
   Daniel Weck
   Steve Zilles

<RRSAgent> logging to http://www.w3.org/2011/10/19-css-irc

   glazou: Regrets from Apple reps, company event
   glazou: Peter is sick. I might need a fallback chair during the AC meetings at TPAC.
   glazou: Any extra items?

CSS Speech

   <danielweck> http://wiki.csswg.org/spec/css3-speech
   danielweck: I think we need a bit more discusison on issue 1
   danielweck: 2 is resolved last week

   danielweck: issue 3
   <danielweck> http://lists.w3.org/Archives/Public/www-style/2011Sep/0109.html
   danielweck: Christoph proposes to rename voice-volume to volume-voice.
               I rejected on consistency with other voice-* properties; his
               arguments didn't seem convincing enough.
   danielweck: Where does the WG stand?
   glazou, fantasai, szilles agree with danielweck
   RESOLVED: Do not rename voice-volume

   danielweck: Issue 4, Gregory was saying that some of the properties we
               marked at-risk should not be dropped
   danielweck: That's not really up to us, it's up to implementations, so
               I marked this as an invalid concern
   glazou: Absolutely, at-risk does not mean it's dropped
   RESOLVED: No change for issue 4

   danielweck: issue-5
   danielweck: Gregory put forward some concerns with voice-rate, but it
               seems to me that the prose is correct, what he wants is
               already in the spec.
   danielweck: There is an error in the prose, which I fixed.
   <danielweck> http://lists.w3.org/Archives/Public/www-style/2011Oct/0011.html
   danielweck: Maybe I misunderstand his point, or maybe he misread the spec.
   szilles: I think he was asking to use "slow" when talking about cutting
            the speed by half and "fast" when multiplying it > 100%
   szilles: "For example, 50% means the speaking-rate gets multiplied by .5 ..."
   danielweck: Ok, I will add that in my tracker
   * glazou notices voice-rate does not have 'slower' nor 'faster'

   danielweck: Issue 6 is proposal to add 'play-during'
   danielweck: I wasn't there when first CSS3 Speech drafts were produced.
               What I did notice was that play-during, which was in CSS2.1,
               disappeared in CSS3 Speech from the first draft that was
   danielweck: play-during is similar to <bgsound>
   danielweck: This feature would introduce concurrency in the CSS Speech
               audo output -- currently everything is sequential
   danielweck: Apply 'play-during' to nested elements, and the complexity
   danielweck: So my proposal is to reject reintroducing this property
   <danielweck> http://lists.w3.org/Archives/Public/www-style/2011Oct/0423.html
   glazou: CSS2.1 Aural Appendix is informative, says something about
                adding aural capabilities later
   danielweck: Also, I think this mixes aural styling with speech synthesizing,
               which is the scope of CSS Speech
   fantasai: I think it's fair to reject feature requests. CSS Speech should
             be feature-frozen at this point. We can consider it for a future
   szilles: I agree with fantasai, but not sure I buy the argument it doesn't
            belong here.
   danielweck: CSS Speech was intended to focus on speech synthesis
   glazou: play-during is not strictly related to speech
   fantasai: I can imagine use cases for sound as you hover over elements,
             focus them, scroll them into view, etc. But that's a different
             set of use cases.
   fantasai: Still I don't think it's entirely out-of-scope for Speech. You
             might want, for example, the themes from Peter and the Wolf
             to play as the TTS engine narrates it.
   fantasai: However this does bring in a lot of complexity: do you overlay
             nested elements' sounds or switch the tracks? How do you transition
             from one sound to another? It's not a simple feature.
   szilles: It might be a reasonable request, just not for this version
   RESLVED: Not adding 'play-during' to CSS3 Speech; may consider for later

   danielweck: Issue 7 about using SPAN element in examples, also to create an
               HTML5 default stylesheet
   danielweck: I think the default stylesheet for HTML5 is out-of-scope for
               the spec, should be tackled cross-wg after HTML5 settles down
   danielweck: I note CSS2 includes an HTML4 style sheet
   szilles: So who's responsible for that?
   glazou: HTMLWG, of course
   glazou: It's not our role to define a default stylehsheet for all dialects
   glazou: You could add an example that styles em / strong
   fantasai: I don't think you need to give an exhaustive HTML stylesheet,
             but I think it's fair to replace the SPAN in the example with EM

   issue 8 is editorial

   danielweck: Issue 9 is about cryptic hyperlink text
   danielweck: This applies to all the specs in CSS: the CSSWG preprocessor
               generates poor index text for screen readers
   Bert: I can change it, but I don't know what to change it to.
   Bert: I will email Gregory and ask for suggestions
   fantasai: Because this is a spec that's targetted at people who have
             trouble with this kind of indexing, I think it's fair to accept
             that this is an issue that must be fixed for CR, even though
             it's editorial.
   ACTION: Bert fix indexer to be speech-friendly
   <trackbot> Created ACTION-372

   danielweck: issue 10 is about ARIA attributes, and how to exploit that
               info from the CSS perspective
   danielweck: This is about recommending authoring practice; selectors
               can already do their part.
   danielweck: I closed this as out-of-scope, seems more appropriate for
   danielweck: There were a number of issues that were about similar concerns
   glazou: I guess this would be an excellent item for the HCG
   glazou: So when you are ready, even if you don't have an answer from
           Greg, let's raise this to the HCG
   danielweck: Ok, I will compile a list of the suggestions people have made
   danielweck: When I talked to the Audio WG, they weren't aware of the
               existence of CSS Speech
   RESOLVED: Issue 10 (recommended styling of ARIA) out-of-scope

   danielweck: Issue 11 is a suggestion to introduce 'louder' and 'softer'.
   danielweck: We already have keywords including loud and soft, and a
               decibel value that offsets from the keywords
   danielweck: I'm reluctant to introduce these kewyords when decibels
               are pretty easy to use already
   danielweck: We already note that +/- 6db is approximately twice as loud.
   danielweck: We'd also have to introduce a mapping to SSML, since such
               keywords don't map directly
   szilles: font-size has 'smaller' and 'larger' keywords
   fantasai: Don't those key up and down the keyword scale?
   fantasai: You could have 'louder'/'softer' compute to different keywords
   danielweck: Usually audio systems use decibels
   danielweck explains how the keywords work and why they are UA/user-defined
   szilles: Some authors don't want to understand audio physics and work it out
   danielweck: We have a note about +/- 6db in the prose already. We could
               define what increasing the sound to make it louder or softer
               means in decibels, without referring to any keyword
   danielweck: These terms mean something to authors, so that would help
   glazou: similarly we don't have faster/slower for voice-rate, maybe a note is needed
   fantasai: If we introduce these keywords, they shouldn't map to fixed
             decibels -- we can already do fixed decibels. They should
             operate on the keyword scale
   fantasai: Didn't we used to have a numeric scale?
   fantasai: e.g. 0-100 would map to the keyword range
   glazou: I don't think 0 silent 1 x-soft makes sense
   fantasai: You could make 0 x-soft
   glazou: that would be confusing
   glazou: authors will always interpret 'voice-volume: 0' as silent
   szilles: I think the best thing would be to improve the note for authors
            to explain how to make the sound louder or softer
   RESOLVED: For issue 11, improve informative wording

   danielweck: Proposal to drop voice-volume: silent
   danielweck: Commenter notes that setting silent, the element doesn't
               disappear from the audio stream, it just has zero amplitude
               while the speech output lasts.
   danielweck: Equivalent to visibility: hidden
   danielweck: By contrast we have speak: none / display: none, which remove
               the element from the stream
   danielweck: The commenter says this is dangerous wrt accessibility/usability
   danielweck: I argue that it's a typical case for the author to set silent
               on a long piece of content, just as it's stupid to have a page
               with large swaths of blank space
   danielweck: There are use cases where, e.g. animating from silent, or
               leaving gaps in the audio stream and scripting that to read
               or not
   danielweck: I don't think we should be dropping the feature because someone
               might to something obviously stupid with it

   glazou: I have a side-comment wrt silent
   glazou: Usually muting / unmuting reverts to original values
   glazou: You can't retrieve that value, except programmatically
   danielweck: Yes, but I don't think we can easily solve that in CSS3 Speech
   smfr: This is a common problem with display: none
   fantasai: The 'speak' property does not have the 'display' none problem --
             we dealt with that by splitting it from speak-as
   fantasai: wrt silent / not-silent switch, you could solve that by
             preserving the inherited value along with the 'silent'
             keyword, and introducing a 'restore' value that removes
             the 'silent' part
   danielweck: I think adding that would complicate the spec's mapping to SSML
   RESOLVED: no change for issue 12

   danielweck: issue 13
   fantasai explains speak /speak-as issue
   RESOLVED: Proposal to re-merge 'speak' + 'speak-as' rejected, for reasons
             that they were split.

   danielweck: pause properties take <time>, there's a proposal to restrict
               the range of values allowed in <time>
   danielweck: I proprose to reject that
   danielweck: I don't want to define good authoring practice by restricting
               the values
   szilles: You should respond saying that some of the things they're asking
            for should go into authoring guidelines
   RESOLVED: No change for issue 14 request to restrict <time> values

   danielweck: Someone also made a point about using MQ to address specific
               speech contexts, explain e.g. what kind of disability user
               might have, etc.
   danielweck: I've worked in device adaptation, and this seems very risky
   danielweck: and definitely out-of-scope for CSS Speech
   danielweck: MQ addresses hardware requirements, not user capabilities
   RESOLVED: MQ feature request for user-capability-querying out-of-scope

Meeting closed.

Received on Wednesday, 19 October 2011 23:20:00 UTC