- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Wed, 19 Oct 2011 16:19:25 -0700
- To: "www-style@w3.org" <www-style@w3.org>
Summary:
- 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 ======
Present:
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
Administrative
--------------
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
published
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
explodes.
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
level.
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
level.
+arno
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
WAI/WCAG
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