- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Wed, 02 Feb 2011 15:24:01 -0800
- To: "www-style@w3.org" <www-style@w3.org>
Summary:
- Reviewed status of CSS2.1: some edits to be made, issues list needs updating,
some tests need updating
- RESOLVED: Remove 'mark' properties from CSS3 Speech
- Discussed 'speak: none' and replacing it with an independent property. See
fantasai's messages for problem and possible solution:
http://lists.w3.org/Archives/Public/www-style/2011Jan/0204.html
http://lists.w3.org/Archives/Public/www-style/2011Jan/0483.html
- Discussed phonemes property. Key question is whether it is stylistic and
belongs in CSS.
====== Full minutes below ======
Present:
César Acebal
Tab Atkins
David Baron
Bert Bos
Arron Eicholz
Elika Etemad
Simon Fraser
Koji Ishii
John Jansen
Brad Kemper (via IRC)
Hĺkon Wium Lie
Peter Linss
Alex Mogilevsky
David Singer
Daniel Weck
Steve Zilles
<RRSAgent> logging to http://www.w3.org/2011/02/02-css-irc
Scribe: sylvaing
CSS2.1 status
-------------
arronei: my updates are done. emails on changes will follow today
dbaron: I've checked in all my updates as well
plinss: any other updates ?
fantasai: I have some bidi and outline test updates coming
fantasai: I should be able to fix these today.
plinss: someone needs to remove run-in. who does that ?
arronei: testcases or spec prose ?
plinss: both
arronei: I can remove the run-in testcases
plinss, fantasai: run-in needs to move to CSS3 Box
<Bert> I can hardly hear what Elika says, but I could probably propose
an edit for CSS 2.1.
<Bert> (And move the def to Box, of course.)
ACTION: Bert to propose CSS2.1 edit to remove run-in and move to CSS3 Box
<trackbot> Created ACTION-291
<johnjan> bert, what's your ETA on that?
plinss: the test harness runs on top of nightlies
fantasai: we still have open issues on the issues list
arronei: I haven't added anything to the CSS21 issues list
ACTION: fantasai to review and update the CSS21 open issues list
<johnjan> sounds like Bert's edit and the list of open issues are the
only things blocking PR.
<johnjan> as long as the test harness shows passes correctly.
CSS3 Speech
-----------
Topic: publication request for CSS3 Speech
<danielweck> http://dev.w3.org/csswg/css3-speech/
danielweck: the current draft is being updated as we speak. I think it
is ready for LC
danielweck: three issues at this point
danielweck: in order for the document to reach LC, do I have to remove
all issues currently in document as well as editor's comments ?
chrisl: you can keep editor's comments but you must deal with all open
issues to reach LC
danielweck: there is no consensus to remove the phonemes property so I
would keep it in there. there are strong views both ways
fantasai: we should attempt to discuss and resolve the issue in the WG
danielweck: objections we had included the inability to bind a w3c PLS
to an HTML document and this was the only way to do it.
others thought this did not constitute styling.
<dbaron> Is it possible to replace "(the actual arithmetics involved are
beyond the scope of this specification, please refer to existing
literature on that subject)" with "(the twelfth root of two)"? :-)
danielweck: as this is well-defined, I would rather go to LC with the feature
<Bert> q+ to ask if the list of editors is still correct, or are they
rather "former editors."
<dbaron> Also, I wonder if the 'st' unit should be described in a separate
section rather than defined only within the definition of a
property's value.
next issue: the mark element. I feel specifying this is out of scope for
CSS. It is also not implemented
last issue: speak:none
danielweck: I think we should remove the none value from the speak property.
whether something is spoken or not would be controlled elsewhere
<dbaron> speak:none is more like visibility:hidden than like display:none
<ChrisL> so, an audio equivalent of 'display', then?
<Ms2ger> display:none should apply to audio IIRC
<fantasai> http://lists.w3.org/Archives/Public/www-style/2011Jan/0204.html
<fantasai> http://lists.w3.org/Archives/Public/www-style/2011Jan/0483.html
danielweck: semantically visibility:hidden is similar to opacity:0.
whereas speak:none does not imply silence for that particular
content
danielweck: we are really pruning the 'spoken tree'
dbaron: ok, but why do you need an additional property ?
dbaron: does display apply to speech ?
danielweck: it does but I don't think it's appropriate
danielweck: I would rather have the ability to decide whether display
affects speech
* bradk thinks that things which are not displayed should also not be spoken.
<fantasai> is that true for skip links, bradk?
<sylvaing> brad, that may be a reasonable default but there are likely
use-cases where that doesn't work
<Bert> (You can always change the 'display' back in an @media rule, if
they *do* need to be spoken.)
<bradk> I can't tab to links when they are in something with display:none.
<dbaron> yeah, so the proposal in 0483.html seems ok (though I'm not crazy
about the names).
fantasai: display hides an entire subtree. visibility can be overriden.
there is no parallel for the latter in the speech module if it
depends on display. if this scenario is important for speech
then you would need another property similar to visibility
fantasai: and I don't think it should happen with speak:none, see email above
danielweck: one can achieve that using voice volume but you then have the
aural equivalent of visibility:hidden where the quiet content
still takes space
danielweck: so the first problem with speak:none is that it could be
replaced with display:none. but there remains a need to
allow speech even if the content is not displayed
* bradk is reading about skip links.
<Bert> (I'm reminded of <details> in HTML5: how to hide the element but
show/speak its <summary> child.)
<fantasai> (That's a good example.)
<bradk> Volume = opacity?
szilles: the concern that hidden content would result in long pauses could
be addressed with other markers such as a beep indicating missing
content
danielweck: today we don't have any relationship between visibility:hidden
and the aural rendering. but I'm in favor of indicating whether
something should be expected there
szilles: I think visibility:hidden should have implications in the aural
space as well
<smfr> maybe we should take this discussion to the list
<bradk> We want Skip links that render aurally, but are display:none
visually, eh?
<fantasai> right
szilles: the use-case I understand is that the underlying HTML includes
nodes that are solely intended for speech only and I need a
mechanism to allow them to be spoken even though they will never
be displayed
<bradk> Yeah, @media for that, I would think.
<fantasai> That doesn't solve the <details> case Bert was talking about
<fantasai> display: none removes the entire subtree. If you want to
override part of that, you can't
<bradk> Hmm.
(speak:none discussion to be continued in the mailing list)
<ChrisL> I wonder if, instead of a single 'hidden' we need two values,
'silent' and 'skipped'
<ChrisL> skipped is not possible currently except with display none
which also prevents children overridding it
danielweck, fantasai: you can get "silent" by setting volume to zero
danielweck: any objections to removing the mark properties ?
<bradk> Can you post a Link to mark props?
<fantasai> http://dev.w3.org/csswg/css3-speech/#mark-props
<bradk> Thnx
danielweck: I think mark duplicates an HTML feature and it is meant to
generate events which should be out of scope here
<szilles> +1 to remove
RESOLUTION: remove mark properties from CSS3 Speech
danielweck: as for phonemes, the arguments in favor of keeping it are
good and the feature is well defined so I am happy to keep it
fantasai: I don't think "but HTML doesn't have this so we should put it
in CSS" to be a good argument.
fantasai: I'd like to see an issue raised on the HTML side
bert: could you use the content property ?
danielweck: you would need intimate knowledge of your speech system to
get the right value
<fantasai> content: phonemes(...)
danielweck: but then you would replace content in the visual rendering as well
<Bert> (Might be useful to distinguish Ian (eye-un) from Ian (ee-un) :-) )
<fantasai> <span id="tomato">tomato</span>
szilles: so this is aural styling
danielweck: yes, you can bind a particular pronunciation - aural styling -
to an element
danielweck: as opposed to choosing a general speech dictionary for the
entire document
<ChrisL> link rel="lexicon" would see to fix that for html
<fantasai> danielweck explains that if you want to associate a pronunciation
lexicon to the document, you use PLS. It will affect all words in
the document. This feature is for changing one particular instance
to be different from what's in the dictionary.
chrisl: there is a possible maintenance problem here where the stylesheet
is out of synch with the content
szilles: this issue already exists with the content property
fantasai: Not really, 'content' is designed for and can be stylistic only
<bradk> Aural style sheet: #toe { content: "t\0252" }
plinss: we should take this issue back to the mailing list
szilles: I think we need to agree whether this is a styling feature; then
what's the best way to assign the phonemes to the content
<Bert> (I guess we're out of time, but how about a *conditional* phonemes
property: 'phonemes: "tomato" -> "...", "patato" -> "..."')
<fantasai> (Bert, that's handled by PLS)
<fantasai> (Although if you want to change the mapping per-element, you
might need something else ...)
Meeting closed.
<fantasai> danielweck: btw, did you catch ChrisL's comment about associating
a lexicon in HTML?
<fantasai> danielweck: you would use <link> with a particular 'rel' value.
You just need to agree on and standardize the rel value.
<danielweck> right, this would be useful, but doesn't address the per-element
use-case
<fantasai> right
<danielweck> ("element" in the broad sense)
<danielweck> authors need a way to customize whatever the default pronounciation
rule is
<fantasai> danielweck: I think that should be handled in HTML
<fantasai> Just because there's an existing draft of a feature to handle this
in CSS doesn't mean it has to be done in CSS
<danielweck> (regardless of whether it comes from a PLS lexicon attached to
the HTML document, or from the default TTS engine phonetics)
<fantasai> Has there been an issue raised against HTML for this?
<danielweck> for PLS, yes
<danielweck> (long time ago)
<fantasai> but not for this?
<danielweck> no
<fantasai> I think that's the right way forward.
<danielweck> why do you think it is not related to styling ? (what about the
'speak' property then ?)
<danielweck> after all, it "styles" the audio output
<fantasai> phonemes is very specific to the content being styled
<fantasai> I don't think it belongs in the style sheet
<ChrisL> its not clear that an issue needs to be raised against html5. the
list of rel values for the link element is open ended
<danielweck> right, just like "speak" then. No ?
<fantasai> ChrisL: For the lexicon, no
<fantasai> ChrisL: but for phonemes, probably
<ChrisL> right
<fantasai> danielweck: You're right that speak is close to that fuzzy boundary
of style and content. But I change a word with its synonym, I don't
need to update speak
<fantasai> I see 'speak' being used like
<fantasai> .productnum { speak: digits; }
<fantasai> .code { speak: literal-punctuation }
<danielweck> Fantasai: "it's very specific to the content being styled"----
I am trying to understand what you mean: the 'speak' property
defines "how text should be spoken out" (spelling, etc), which
is semantically equivalent to "styling in the aural dimension"
<danielweck> I see phonemes pretty much in the same ballpark
<fantasai> "how text should be spoken out" is "rendering in the aural
dimension" not necessarily "styling in the aural dimension"
<fantasai> speak keys off of the structure of the document and the semantics
of the tagging
<fantasai> not the actual content
<fantasai> that's the key distinction here, to me
<danielweck> ok
<danielweck> I'll revive the public discussion, hopefully we can articulate
this issue to remove the "fuziness" of its definition. ;)
<danielweck> PLS:
<danielweck> http://www.w3.org/Bugs/Public/show_bug.cgi?id=7601
<danielweck> http://wiki.whatwg.org/wiki/RelExtensions
<danielweck> Ian Hickson says the keyword should be deployed first, then
taken into consideration
<danielweck> chicken and egg...
<Ms2ger> Just add it to the wiki as a proposal
<fantasai> danielweck: no, not really. Rel values do not need to be
standardized through W3C in order to be used
<fantasai> They are defined as an extension mechanism
<fantasai> as Ms2ger says, just add it to the wiki as a proposal
<danielweck> Hixie:
<danielweck> Proposals should go here:
<danielweck> http://wiki.whatwg.org/wiki/RelExtensions
<danielweck> You'll need to write a spec first, and demonstrate that people
are using the keyword.
<danielweck> Please let us know once this keyword is deployed, for
reconsideration.
<fantasai> Right
<fantasai> so you write the proposal and the spec for the proposal there
<fantasai> and then people can use it
<fantasai> no problem
<fantasai> if it becomes popular enough, it might get added to the list
in the HTML spec
<fantasai> but it doesn't need to be there
<Ms2ger> Or at IANA
<fantasai> quite a few of the rel values in the official list started at
microformats.org
Received on Wednesday, 2 February 2011 23:24:37 UTC