CSS TV Profile 1.0 Disposition of Comments

This document details the responses made to issues in the CSS TV Profile 1.0 last call specification. The comments were raised by the public (via www-style@w3.org) or other W3C Working Groups.

Introduction

This document describes the disposition of comments in relation to the Last Call Working Draft of CSS TV Profile 1.0 that were made during the last call period which ended 14 June 2002. Each issue is described by the name and contact information of the commentator, a description of the issue, and either the resolution or the reason that the issue was not resolved.

Actionable statements from comments are shown with a light gray background like this.

Items that are accepted are shown with a light green background like this. Such items typically imply that as a result of the comment, a change was made in the specification.

While items declined are shown with a light red background like this.

Items deferred to a subsequent version (such as feature requests) are shown with a light yellow background like this.

Finally, simply informative responses (answers to questions, elaborations, etc.) to non-actionable comments are styled with a light blue background like this.

Comments Received

Comments from ARIB (by way of Akihiko Handa <handa@krhm.jvc-victor.co.jp>) 4 Mar 2002 [W3C Members only hyperlink] and Responses [W3C Members only hyperlink]
#	Comment	Answer
1	We found CSS-TV specifies the all and the tv as the normative media types, while ARIB STD-B24 specifies tv media type alone as normative. We believe that the tv is sufficient as the normative media type.	Perhaps this is only a misunderstanding. The CSS TV Profile 1.0 does normatively define what the 'tv' media type means and implies in terms of support for authors. The CSS TV Profile 1.0 explicitly specifies that CSS TV Profile implementations must support the 'all' media type as all CSS2 implementations (and HTML4 implementations for that matter) are required to. This is not a new requirement, and is stated merely to make it clear.
2	We noticed that in CSS-TV there are some properties which are NOT applied in certain portion of ARIB STD-B24.?(Let me refer to such specification as "ARIB operational guideline" hereinafter. The "operational guideline" specifies regulations and limitations for actual broadcasting services and operations in Japan.) One of the reasons why ARIB operational guideline does not apply such properties is to minimize the processing power in the receiver. We therefore propose that W3C consider drop unnecessary properties in CSS-TV specs as much as possible. For example, the current CSS-TV applies "border-top/bottom/left/right-width", while ARIB operational guideline does not, since such properties can be substituted by "border-width" only.	It is difficult to specify support for a shorthand property like "border-width", and explicitly not support its elemental properties: "border-top-width, border-bottom-width, border-left-width, border-right-width". From an implementation perspective, there is little additional work required to support the elemental properties, and that work is only when parsing. Even if only the "border-width" property is supported for parsing, all the other properties must effectively be supported by an implementation for cascading, formatting, and drawing. Therefore the effort to parse the elemental properties is an very small addition.
3	We added external properties to describe actions for focus movements during cursor operations with a remote controller. As long as we can see, there is no such external property in the current CSS-TV, so we propose CSS-TV incorporate similar properties or functionalities.	There is a need for external properties to describe actions for focus movements during cursor operations with a remote controller. DVB-HTML has introduced the properties "nav-up", "nav-down", "nav-left", "nav-right", and the editor of "CSS3 module: basic user interface" plans to include in its next draft a proposal for these properties for exactly the said purpose. Since the CSS TV Profile 1.0 refers only to CSS2 which is already a W3C Recommendation, and to CSS3 Color which we expect to be in Last Call and a Candidate Recommendation very soon, it would delay the CSS TV Profile 1.0 significantly to introduce a dependency upon the CSS3 Basic UI module. When "CSS3 module: basic user interface" is entering Last Call or Candidate Recommendation, it is likely the "nav-*" properties will be added to a future version of the CSS TV Profile 1.1.
4	We noticed that CSS-TV specifies a variety of units like px, em, ex, in, cm, mm, pt as normative, while ARIB operational guideline defines px only as normative. We propose CSS-TV incorporate this simplified specification for units.	These units have been well established in standards since CSS1 (1996 Recommendation), and widely implemented. In addition, these units are all incorporated in the CSS Mobile Profile 1.0 which is also intended for small implementations, albeit for mobile/handheld devices. Finally, the CSS TV Profile 1.0 is currently a proper superset of the CSS Mobile Profile 1.0 which has a great advantage in that content authored for the mobile profile will also be supported by implementations of the tv profile. The mobile profile contains these units, so the tv profile does as well.
5	We noticed that CSS-TV applies percentage(%) description, which is dropped in ARIB STD-B24. One of the reasons why ARIB operational guideline does not apply percentage is that it may affect prohibited display area during the image out procedure. So we propose W3C consider the elimination of percentage description in CSS-TV.	The percentage(%) unit is quite critical for a number of applications. The limitations of display area are covered by the prose in the Conformance section in the CSS TV Profile which states: "The inability of a TV-UA to implement part of this specification due to the limitations of a particular device (e.g., a TV-UA cannot render colors on a monochrome monitor or page) SHALL NOT imply non-conformance." In addition, some TV declarative standards (e.g. DVB-HTML) have proposed other mechanisms (e.g. @viewport rule) for handling display area issues.
6	The followings are just your information: As we understand it, CSS is not defined for making profiles, so we recognize that some of the values in CSS do not match TV application when trying to create CSS profiles.	It is true that CSS was not originally defined for making profiles, however, vendors of mobile devices found that they could define the CSS Mobile Profile, and as such the CSS TV Profile is similarly modeled.
7	Let me inform you that CSS handling in ARIB STD-B24 has already been incorporated into more than one million sets of set-top boxes for digital TV in Japan, and that it is up and running fine.	That is quite an admirable accomplishment! The CSS Working Group would be very interested to learn how those current set-top boxes handle the CSS1 Test Suite, http://w3.org/Style/CSS/Test/CSS1/current/ as most of that test suite will be used for the CSS TV Profile 1.0 test suite, which will be used to check CSS TV Profile implementations in order to pass the Candidate Recommendation exit criteria for the CSS TV Profile 1.0.
8	We hope the comments described above would be of your help.	Yes, the comments were helpful and will help shape future work on the CSS TV Profile. One note: it is expected that content developed using CSS TV may be transcoded with a reasonable approximation of the rendering for acceptance by already deployed HTML-based TV systems; however it is still beneficial to have a single TV profile for application developers and tools moving forward, especially considering the variety of declarative TV content standards efforts in various markets.
Comments from "Kynn Bartlett" <kynn@idyllmtn.com> 23 May 2002 and Responses
#	Comment	Answer
9	I am very confused and troubled by the complete redefinition of the TV media in this document, compared to the CSS 2 definition.	CSS2 loosely defined the tv media type, without any actual industry experience coming to bear with respect to using implementing CSS for TV devices, and authoring CSS for TV devices. Just as the CSS Mobile Profile [http://www.w3.org/TR/css-mobile/] updates the definition of the 'handheld' media type, the CSS TV Profile updates the definition of the 'tv' media type. In both cases, domain experts that have experience with CSS in their domains have provided a much more detailed and thought through profile of CSS for their respective domains. Please also see the reply to issue 16 which provides a summary response to issues 9 through 16 inclusive.
10	In CSS 2, it states quite clearly (emphasis mine): tv Intended for television-type devices (low resolution, color, limited-scrollability screens, SOUND AVAILABLE)	Yes, and at the time that was written, there was no experience with either implementing or authoring CSS for TV devices. Essentially, CSS2 did not have the benefit of "reality-checking" through the CR phase which was adopted in W3C process years after CSS2 was published. As a result (and this is not the only case), CSS2 contains many "good ideas" which never came to fruition for one reason or another. The CSS Working Group is deprecating, or in most cases, relabeling as informative such "good idea - little or no implementation" CSS2 features in CSS2.1. One particular such area is the definition of the media types - those definitions are for the most part all being made informative - since such definitions would not successfully satisfy the implementation requirements and thus exit CR. The only thing normative about media types that is being kept is the set of names of the media types, and the definition of the 'all' media keyword. Please also see the reply to issue 16 which provides a summary response to issues 9 through 16 inclusive.
11	Under media groups, tv is defined as "visual, AURAL", unlike screen which is "visual." Television is universally understood to be a true multimedia medium, combining video and audio. However, the proposed TV profile does not acknowledge this.	The CSS TV Profile 1.0 refers to the appropriate CSS properties (and selectors) from CSS2 that have either been demonstrated to be of use for TV content specifically, or have been widely implemented and understood. For now, the profile doesn't include any aural properties as you noted, but the profile doesn't preclude the addition of multimedia support in a future version. Please also see the reply to issue 16 which provides a summary response to issues 9 through 16 inclusive.
12	All aural properties are unsupported in this profile, and aural values likewise are unsupported.	Unfortunately your evaluation of aural properties not only applies to the TV profile, but in general. Other than emacspeak (which only implemented a draft of the aural properties - not the final REC, and which doesn't run on a TV device), the CSS working group doesn't know of any implementations, certainly not any interoperable implementations. In order to encourage forward progress in the area of CSS Audio/Speech, members of the CSS Working Group, along with other W3C audio/speech experts (e.g. Dave Raggett, T.V. Raman etc.) discussed a course of action at the most recent W3C plenary this past February/March. There were several decisions made. First, it was widely acknowledged that the aural properties in CSS2 were a good first cut, useful for exploring the field, but did not do a really thorough job of solving actual problems, while containing esoteric ("neato") features (e.g. all the 3d audio stuff) that were found to distract from the usefulness of the rest. Thus, second, it was decided to place the aural properties into an informative chapter of CSS2.1, including documentation on what subset of those properties and values had implementation experience (specifically T.V. Raman's implementation experience), and what that experience has taught us. Finally, third, it was decided that there should be a CSS3 Voice Module that coordinated better with the VoiceML efforts, and that Dave Raggett would be the editor for that module. Please also see the reply to issue 16 which provides a summary response to issues 9 through 16 inclusive.
13	In addition wrongly identifying the tv medium,	The definition and identification of the tv medium in CSS TV Profile 1.0 is more of a practical identification of the constraints of TV devices in use today and in the near future. Please also see the reply to issue 16 which provides a summary response to issues 9 through 16 inclusive.
14	ignoring the audio aspects in this profile while accentuating only the visual will further relegate aural styles to the realm of "nice idea, never implemented beyond emacspeak."	It is actually the other way around. Because the meeting in Cannes explicitly decided to relegate the first generation of aural properties as a "nice idea" as you say, it made sense to keep the 1.0 version of the CSS TV Profile simple, with the hopes that once there is a "reality-checked" updated set of aural properties in the CSS3 Voice Module, then a future version of the CSS TV Profile can reference those. Please also see the reply to issue 16 which provides a summary response to issues 9 through 16 inclusive.
15	This can and will prove to be a detriment to users with visual disabilities.	Given that aural properties have not been widely implemented/deployed, and certainly not on TV devices, it is difficult to see how simply acknowledging that fact could be detrimental. On the contrary, what would be more detrimental is trying to make something work which has failed to take off for one reason or another. It is expected that Dave Raggett will assist with and produce a much better CSS3 Voice Module than the ACSS chapter in CSS2. Please also see the reply to issue 16 which provides a summary response to issues 9 through 16 inclusive.
16	This draft should be sent back and rewritten to reflect the multimedia nature of the tv media type, as noted in CSS 2.	This statement is a response not only to issue number 16, but also a summary response to issues 9 through 16 inclusive. CSS2 aural provisions lack the implementation experience that would today be required to enter PR; consensus at Cannes Technical Plenary was that there are some problems with this design and a fresh look is required. Hence, future. Regarding multimedia styling, there is a lack of sufficient experience with multimedia styling to have a firm approach. This is also yet to be developed in consultation with MMI et al. Audio styling and coordination of styling in multimedia contexts have to be left as topics for future work in this release. Yes, they are on the agenda; no, it is not possible to publish solutions to these questions in this profile at this time, and the profile proposed here with its limited scope and use case is needed to avoid splintering of efforts to use declarative styling in the TV industry. When support for multimedia properties is well defined in a CSS3 module and at least at last call (preferably CR), then it may make sense to write a new revision of the CSS TV Profile which refers to those multimedia properties. The input is accepted as a suggestion for a future version of the CSS TV Profile - once multimedia properties have been properly improved, they should be added to the next version of the CSS TV Profile. These additions won't conflict with what is CSS TV Profile 1.0, and therefore it may proceed with what works today as 1.0, while keeping in mind the ideal future for future versions.
17	Section 6 of the proposal states that: 4. The TV-UA SHALL support author originating style sheets. The TV-UA MAY support user or user-agent originating style sheets. User and user-agent style sheets are essential to ensuring equal access to CSS-based documents by people with disabilities, and are a critical part of the cascade. The word MAY should be replaced by SHALL.	Please be aware of the application context for this profile. The TV in question is generally not a Web user agent, is not Web-enabled. This is not typically a WebTV implementation, but a TV set that is playing a pure-push stream of content in most situations. User control over content is more or less limited to channel selection which includes turning on or off closed caption sub-channels. Control over presentation is on the order of device controls such as screen brightness and sound volume (level plus mute). User style sheets are very beneficial to the user, but for the user to employ their choice of style sheet, there would have to be either web access from the TV to somewhere they could point at their preferred stylesheet on the Web, or a stylesheet authoring capability, or a removable media or data communications capability in the device. Adding any of these capabilities to many of these TV devices would be significant functional change and not readily achieved. So it is not reasonable to demand this support from all implementations of this profile. Creating a common profile of CSS use in TV applications around the globe will increase the use by TV content of accessible text plus style for some sub-channels that might otherwise be streamed as sub-pictures. This in itself would be accessibility progress. We cannot mandate in a CSS profile that all TVs should suddenly become Web devices.
Comments from Etan Wexler <ewexler@stickdog.com> 4 Jun 2002 and Responses
#	Comment	Answer
18	[1.] The document lacks a summary of at-rule support. A table for at-rules would be helpful. As things stand, 'font-face', 'page', and 'color-profile' at-rules receive no mention.	The CSS TV Profile explicitly mentions that the a TV-UA SHALL support: @charset (section 5) @import (section 6) @media (section 7) No other at-rules are mentioned, therefore no other at-rules are required by CSS TV Profile 1.0. A table for at-rules would be helpful. A profile table of at-rule support (similar to the profile table of selectors support) has been added to the CR draft of CSS TV Profile 1.0. Note that the CSS TV Profile was derived from the CSS Mobile Profile, which also lacked such a table. Your suggestion has been forwarded to the editors of the CSS Mobile Profile to keep the format of the profiles consistent.
19	2. Conformance "If a TV-UA encounters a property that applies for a supported media type, the TV-UA MUST parse the value according to the property definition." Change the first occurrence of "property" to "declaration".	That would not make sense, as the sentence would read: "If a TV-UA encounters a declaration that applies for a supported media type" Each property in CSS2 defines whether or not it applies to a particular media type (or set of media types). No where is there any concept of a declaration as a whole applying to a specific media type or not.
20	"TV-UA MUST ignore rules that apply to unsupported media types." What does "rules" mean here? It could mean at-rules, rule sets, at-rules and rule sets, declarations, and more.	All forms of rules per the CSS grammar. Declarations by themselves are not rules - at a minimum they need to be wrapped in curly braces and prepended by a selector in order to become a rule.
21	"If the source document comes with alternate style sheets (such as with the "alternate" keyword in HTML 4.0 [HTML40]), the TV-UA SHOULD allow the user to select one from among these style sheets and apply the selected one." Allowing just one style sheet at a time is more restrictive than the HTML4 model. Change to "If the source document comes with alternate style sheets (such as with the "alternate" keyword in HTML 4.0 [HTML40]), the TV-UA SHOULD allow the user to select from among these style sheets and apply the selected style sheets."	The HTML4 model of alternate style sheets was updated in and superceded by CSS2. The text in the CSS TV Profile is derived from CSS2 Section 3.2 subpoint 5. [http://www.w3.org/TR/REC-CSS2/conform.html#conformance]. Similarly, the CSS Mobile Profile has the same wording.
22	"Values MAY be approximated when required by the TV-UA." For clarity, change to "A TV-UA MAY approximate computed values when assigning actual values."	Again, this wording was taken from CSS2 Section 3.2, and it is better to keep it consistent. And again, CSS Mobile Profile has the same wording. For clarity and consistency we should keep the same wording.
23	"Authors should be able to use style properties with an understanding that the cascading rules are processed correctly" Change "style properties" to "declarations".	This does not semantically change the sentence. Unless there is an advantage to the change, the wording should stay as is - this is another instance where CSS Mobile Profile has the same wording.
24	"A TV-UA that can process the 'run-in' value for the 'display' property will process the first display specification and then "write over" that value with the second display specification. A TV-UA that cannot process the 'run-in' value will process the first display specification and ignore the second display specification." The word "process" is too general and the word "specification" is but another way of writing "declaration". Change to "A TV-UA that accepts the 'run-in' value for the 'display' property will accept the first 'display' declaration and then replace that declaration's value with the value from the second 'display' declaration. A TV-UA that does not accept the 'run- in' value will accept the first 'display' declaration and ignore the second 'display' declaration."	Agreed that the use of the word "specification" in that text should be "declaration" - in fact, that is what the CSS Mobile Profile has, and it is unclear how this difference crept in. The text has been corrected. As far as the word "process" - that is what the CSS Mobile Profile has, but in this case, your suggestion of using the word "accept" instead is clearer, more indicative of the intent, more precise, and more like what CSS2 says. Your suggestion to change the text makes sense. The CSS Mobile Profile should probably make the same change.
25	3. Selectors Are the unsupported selectors to be parsed as valid but ignored during property assignment? Are the unsupported selectors to be parsed as invalid (which would affect valid selectors in the same group)?	The latter. The same as if a CSS1 UA were to encounter CSS2 selectors.
26	All pseudo-elements are missing from the table.	Oops. This seems like an unintended omission (same problem in the CSS Mobile Profile). The intent was that :first-letter and :first-line are supported, but that :before and :after are not (as can be implied by the lack of support for the 'content' property). The pseudo-elements have been added to the selectors table in the CR draft.
27	I ask for another column in the table to provide a rationale for the rejection of selectors. The rejection of the 'hover' pseudo-class is obvious to me (television sets have no hovering cursor) but the other rejections are far from obvious.	Some of the reasoning has taken place on this list, some of it has taken place on the CSS working group mailing list, some during CSS working group teleconferences, and some during face to face meetings. Several experts who have worked on interactive television content and devices provided their views and opinions based on their experience as to which features should be in the profile and which shouldn't. It is not possible to go back and recreate the thread of reasoning for each and every feature independently. In general as the abstract says, the subset is "tailored to the needs and constraints of TV devices." The omission of features is typically due to well known / accepted processor constraints, memory constraints, or display constraints of TV devices in use today and in the near future. Such devices are fully expected to advance of course, and there are already requests for more features to add in CSS TV Profile 1.1 to take advantage of such more advanced TV devices. If you know of features you would like to see in a future version of the CSS TV Profile (1.1 or later), please feel encouraged to post your requests to the www-style@w3.org list.
28	4. Properties Again, rationale columns would be most helpful.	Same comment as above.
29	The Working Group has decided to cast television as a visual-only medium, so the rejection of aural properties is obvious.	This is primarily due to the insufficient implementation/interoperability of the aural properties at this time. If and when there is a much improved iteration of the aural properties in the CSS3 Audio (and/or Speech/Voice) module(s), the working group will consider adding them to a future version of this module.
30	Apparently, television may decline to support tables and generated content, which, though a choice requiring its own explanation, provides a rationale for many of the remaining property rejections.	Yes.
31	However, properties like 'background-attachment',	This was for drawing performance reasons. Fixed backgrounds are slower to draw (and require more memory) when scrolling the page.
32	'direction',	Also missing from the CSS Mobile Profile, and for the same reasons - performance and memory.
33	'font-size-adjust', 'font-stretch', 'letter-spacing', 'text-shadow', 'Unicode-bidi', and 'word-spacing'	On set-top boxes, there are typically a very limited number of font choices (if even more than one). It made more sense to leave out these properties rather than to tell people that they may (probably will) always revert to some initial setting due to platform constraints.
34	the 'max' and 'min' dimensions, 'overflow',	There was a request from some implementers of user agents for TV devices to omit them.
35	require some explanation, at least as far as this non-psychic is concerned.	Hopefully these explanations helped at least a little.
36	Why are color values containing an alpha component not accepted while the 'opacity' property is accepted?	In fact, another reviewer explicitly asked for the "rgba()" color value to be accepted, and the working group has agreed. The CR draft of the TV Profile will include "rgba()" color values.
37	5. CSS Syntax What character encoding schemes are mandatory or suggested for acceptance by a TV user agent? What character encoding schemes are mandatory or suggested for a TV Cascading Style Sheet?	From section 5. " Similarly, the CSS TV Profile requires that conforming user agents support the character encoding mechanisms specified in [CSS2]. Specifically: The TV-UA SHALL support priorities specified in [CSS2] to determine a document's character encoding. The TV-UA SHALL support the CSS2 @charset rules. " In short, the same as CSS2.
38	6. Assigning Property Values, Cascading, and Inheritance "2. The TV-UA SHALL support inheritence as described in CSS2 ([CSS2] Section 6.2)." Change "inheritence" to "inheritance".	Thanks for the catch!
39	"4. The TV-UA SHALL support author originating style sheets. The TV- UA MAY support user or user-agent originating style sheets ([CSS2] Section 6.4)." This imbalance of control is a nasty surprise. What is the rationale for divesting users of their stake in the cascade? If I could rewrite this requirement, it would read "The TV-UA SHALL support user-originating style sheets. For some TV-UAs, this will necessitate retrieval of user style sheets from the Web. The TV-UA SHOULD support author- originating and user-agent-originating style sheets ([CSS2] Section 6.4)."	It did not make sense to place such user interface requirements on what essentially may be (and typically are) embedded systems which allow for very little user customization in general. It is certainly not feasible to necessitate a TV-UA to do anything with the Web as a TV-UA may never see or have access to the Web. May such devices receive only a 1-way stream of data over a broadcast signal for example. This change was explicitly made by the working group for both the CSS Mobile Profile and CSS TV Profile.
40	"5. The TV-UA SHALL support all CSS2 cascading rules ([CSS2] Sections 6.4.1-6.4.4)." To disambiguate, change "rules" to "regulations".	The word "rules" in that sentence could be potentially confusing. It is unclear whether "regulations" provides the correct semantic however. The word "rules" is changed to "mechanisms" which has been used in CSS2. Note: The CSS Mobile Profile should also be similarly updated.
41	"Appendix A. References" Please give the status of each reference as either normative or non- normative.	All references are normative. This is noted in the CR draft.
Comments from Joel Zdepski <joel.zdepski@opentv.com> 7 Jun 2002 and Responses
#	Comment	Answer
42	There is, however, one small change that we believe will be necessary to achieve adequate performance on today's set-top boxes. This change has to do with the properties from CSS-3's Color Profile that are required and those that are optional. It has been our experience that content designers demand the ability to specify transparency on a per-color basis rather than on a per-element basis. CSS-3's RGBA would satisfy this demand, yet it is excluded from the CSS TV Profile 1.0, while support for CSS3's opacity property is required. It has been our experience that content providers would not typically be satisfied with this single transparency attribute; it appears to us to be impossible to obtain adequate performance if this property is used in conjunction with RGBA on most set-top boxes; and that some lower end set-top boxes that are very important in today's market cannot support the opacity property while they can support at least one semi-transparent color in their hardware palette.	From this, we (the CSS working group) gathered that you proposed adding the "rgba()" color value from the CSS3 Color Module to the CSS TV Profile 1.0. The editors agree with your proposal. Your feedback was brought to the CSS Working Group, and the Working Group accepted your proposed change at our teleconference dated 10 June 2002. [ http://lists.w3.org/Archives/Member/w3c-css-wg/2002AprJun/0239.html [W3C Members only hyperlink]] The "rgba()" color value will be added to the CR draft of the CSS TV Profile 1.0. Regarding the difficulty to obtain adequate performance of the implementation of the "opacity" property on some (or perhaps today most) set-top boxes, there is agreement with your statement, and that is specifically why the opacity property in the CSS3 Color module [ http://www.w3.org/TR/css3-color/#transparency ] takes an optional <priority-index> value. The intent of this is to take advantage of hardware acceleration for opacity rendering on boxes that have that capability. Additionally, it is implied (but not explicitly stated) in the conformance section of CSS TV Profile 1.0 [ http://www.w3.org/TR/css-tv#section-conformance ] that it is acceptable for an implementation to ignore the opacity property due to the [performance, video etc.] limitations of a particular device: "The inability of a TV-UA to implement part of this specification due to the limitations of a particular device (e.g., a TV-UA cannot render colors on a monochrome monitor or page) SHALL NOT imply non-conformance." This portion of the conformance statement should be sufficient. If you think an explicit statement about opacity is needed, please let reply as such.
Comments from Etan Wexler <ewexler@stickdog.com> 14 June 2002 and Responses
#	Comment	Answer
43	Tantek Çelik responded to my comments on the CSS TV Profile 1.0: Each property in CSS2 defines whether or not it applies to a particular media type (or set of media types). No where is there any concept of a declaration as a whole applying to a specific media type or not. A declaration only and always contains one property name, so the determination of whether the declaration applies to a medium is trivial.	The determination may be trivial to those well versed in the language of the specification, however using the term 'declaration' is still an additional level of semantic separation that is unnecessary. Thus it makes more sense purely for readability (never mind that more authors know the term "property" than the term "declaration") to directly use the term 'property' as the text does currently.
44	"TV-UA MUST ignore rules that apply to unsupported media types." What does "rules" mean here? It could mean at-rules, rule sets, at-rules and rule sets, declarations, and more. All forms of rules per the CSS grammar. Which CSS grammar?	http://www.w3.org/TR/REC-CSS2/grammar.html
45	The CSS2 grammar defines a "statement" as either a rule set or at-rule. Where is the term "rule" defined?	The above-mentioned grammar uses the production "ruleset" to refer to what in the prose of the specification is called a "rule".
46	Anyway, how could a rule set apply to unsupported media types (or any media types)? To paraphrase, nowhere is there any concept of a rule set as a whole applying to a specific media type or not.	There are at least two examples of rules that only apply to particular media types: @page only applies to page media. @media foo { ... } only applies to media foo, where foo is one of the valid media types as defined in CSS2.
47	The HTML4 model of alternate style sheets was updated in and superceded by CSS2. Wow, that's a leap. Where does CSS2 claim to update, much less supercede, HTML4's model of alternate style sheets?	The reference is in my next statement which you quoted: The text in the CSS TV Profile is derived from CSS2 Section 3.2 subpoint 5.
48	The text in the CSS TV Profile is derived from CSS2 Section 3.2 subpoint 5. That subpoint comes after the notice, "This section defines conformance with the CSS2 specification only. There may be other levels of CSS in the future that may require a user agent to implement a different set of features in order to conform." You are saying that there has been a decision to stick to CSS2 wording, but not saying why.	If there had been a change there would be a need to say why. There is no need to justify use of what is already there, other than perhaps "because it is in a W3C REC".
49	Similarly, the CSS Mobile Profile has the same wording. Well, if need be, change that, too.	Sounds like you are requesting a change in CSS in general (that is, a change in CSS TV Profile, a change in CSS Mobile Profile, and potentially a change in CSS2 (which would likely be need to be made in CSS2.1)). The scope of this change is outside the CSS TV Profile. If you wish to pursue this change, please propose it as a change (in a separate email) to CSS2 to be then adopted by other specifications which depend or reference CSS2.
50	"Values MAY be approximated when required by the TV-UA." For clarity, change to "A TV-UA MAY approximate computed values when assigning actual values." Again, this wording was taken from CSS2 Section 3.2, and I would like to keep it consistent. Is keeping a specification consistently hazy better than clarifying matters?	From a specification standpoint, yes.
51	Is it possible to change wordings in the CSS TV Profile and, by way of CSS2.1, in level 2?	Yes, this would be possible too - and that is what is being suggested you ask for above.
52	And again, CSS Mobile Profile has the same wording. As the CSS Mobile Profile has yet to reach Recommendation and is open to change,	It has however reached Candidate Recommendation, and the changes that can occur during CR are much more restricted. It will be up to the group to decide if the change you propose can be accepted during CR.
53	I see no reason to let its wording dictate the wording of the CSS TV Profile.	Again, consistency. There is no reason for CSS TV Profile to break from CSS2 or CSS Mobile Profile in this way. There is at least one good reason to keep it consistent however, and that is that an implementation implementing both should not have to be different in this way.
54	For clarity and [consistency] we should keep the same wording. For clarity, we should choose the clearest wording, regardless of past wordings. For consistency, we should stick to past wordings, regardless of clarity. I choose clarity.	This kind of wordsmithing has introduced bugs into the specifications in the past - for that reason alone it is best to avoid this practice. Changes introduced to wording in a spec which are intended to have no semantic difference, often result in many many authors, developers, programmers spending hours of time trying to divine why the change was made, and assuming that because the change was made there must be something subtly different being implied, and going to all sorts of contortions of logic to justify a difference in implementation however small. Your argument for clarity is strongly outweighed by the amount of time wasted by many many individuals as a result of reading the before/after wordsmithed text.
55	"Authors should be able to use style properties with an understanding that the cascading rules are processed correctly" Change "style properties" to "declarations". AFAICT this does not semantically change the sentence. Unless there is an advantage to the change, the wording should stay as is - this is another instance where CSS Mobile Profile has the same wording. The advantage is that "declaration" is well defined, while "style property" is used here only. The advantage is that authors write declarations, not properties.	The advantage is that authors understand the term "properties" much more so than "declarations". Readability is important - authors already complain that W3C specs are difficult to read because of their spec-ese, let's not make it any worse than it needs to be.
56	3. Selectors Are the unsupported selectors to be parsed as invalid (which would affect valid selectors in the same group)? [Yes.] The same as if a CSS1 UA were to encounter CSS2 selectors. Please add a note explaining this effect.	Agreed.
57	'font-size-adjust', 'font-stretch', 'letter-spacing', 'text-shadow', 'Unicode-bidi', and 'word-spacing' On set-top boxes, there are typically a very limited number of font choices (if even more than one). It made more sense to leave out these properties rather than to tell people that they may (probably will) always revert to some initial setting due to platform constraints. Given the limitations on fonts, why does the CSS TV Profile include any font properties?	It is not an all or nothing situation. Typically, there is some ability to specify fonts - just not nearly enough to imply the level of control implied by the abovementioned properties.
58	What character encoding schemes are mandatory or suggested for acceptance by a TV user agent? What character encoding schemes are mandatory or suggested for a TV Cascading Style Sheet? [...] In short, the same as CSS2. So there are no mandatory encoding schemes. If I have a style sheet in UTF-8, I have no guarantee that a user agent conforming to the CSS TV Profile will accept the style sheet. That saddens me.	It is no worse than CSS2 or CSS1 for that matter, yet this [questions about character encoding schemes] doesn't appear to have been an obstacle for the implementation or wide adoption of CSS. If you think this is something that could be improved in CSS2 (perhaps for a CSS2.1), you should propose it as such. Thanks again for the additional well thought out thorough feedback Etan. All the issues you mentioned which were germane to the CSS TV Profile have been resolved, and the CR draft will benefit from the input you have provided.
Comments from fantasai <fantasai@escape.com> 14 June 2002 and Responses
#	Comment	Answer
59	Tantek Çelik wrote: On 5/23/02 1:42 PM, "Kynn Bartlett" <kynn@idyllmtn.com> wrote: Section 6 of the proposal states that: 4. The TV-UA SHALL support author originating style sheets. The TV-UA MAY support user or user-agent originating style sheets. User and user-agent style sheets are essential to ensuring equal access to CSS-based documents by people with disabilities, and are a critical part of the cascade. The word MAY should be replaced by SHALL. User style sheets are very beneficial to the user, but typically this is true only on devices such as desktop computers that have a keyboard etc. In fact, UAAG 1.0 explicitly recognizes this appropriate targeting for itself, and states it clearly. If the device allows any sort of user preferences that affect the rendering of a page, such as choosing link colors, these are considered part of the user style sheet whether or not they are implemented as a style sheet. CSS2:6.4 - "the user agent may provide an interface that generates a user style sheet (or behave as if it did)" CSS2 requires a user agent to have a UA style sheet for the document or to behave as if it did. There's no reason to change this for any device; a style sheet /can/ be blank. And I'm sure any UA that claims to read HTML will have, or behave as if it had, a default user agent style sheet. CSS2:6.4 - "Conforming user agents must apply a default style sheet (or behave as if they did) prior to all other style sheets for a document." I conclude that all of CSS2:6.4 can be applied to the TV profile as it stands.	Agreed on both counts.

Comments from ARIB (by way of Akihiko Handa <handa@krhm.jvc-victor.co.jp>) 4 Mar 2002 [W3C Members only hyperlink] and Responses [W3C Members only hyperlink]

Comment

Answer

We found CSS-TV specifies the all and the tv as the normative media types, while ARIB STD-B24 specifies tv media type alone as normative. We believe that the tv is sufficient as the normative media type.

Perhaps this is only a misunderstanding.

The CSS TV Profile 1.0 does normatively define what the 'tv' media type means and implies in terms of support for authors.

The CSS TV Profile 1.0 explicitly specifies that CSS TV Profile implementations must support the 'all' media type as all CSS2 implementations (and HTML4 implementations for that matter) are required to. This is not a new requirement, and is stated merely to make it clear.

We noticed that in CSS-TV there are some properties which are NOT applied in certain portion of ARIB STD-B24.?(Let me refer to such specification as "ARIB operational guideline" hereinafter. The "operational guideline" specifies regulations and limitations for actual broadcasting services and operations in Japan.) One of the reasons why ARIB operational guideline does not apply such properties is to minimize the processing power in the receiver. We therefore propose that W3C consider drop unnecessary properties in CSS-TV specs as much as possible. For example, the current CSS-TV applies "border-top/bottom/left/right-width", while ARIB operational guideline does not, since such properties can be substituted by "border-width" only.

It is difficult to specify support for a shorthand property like "border-width", and explicitly not support its elemental properties: "border-top-width, border-bottom-width, border-left-width, border-right-width".

From an implementation perspective, there is little additional work required to support the elemental properties, and that work is only when parsing. Even if only the "border-width" property is supported for parsing, all the other properties must effectively be supported by an implementation for cascading, formatting, and drawing. Therefore the effort to parse the elemental properties is an very small addition.

We added external properties to describe actions for focus movements during cursor operations with a remote controller. As long as we can see, there is no such external property in the current CSS-TV, so we propose CSS-TV incorporate similar properties or functionalities.

There is a need for external properties to describe actions for focus movements during cursor operations with a remote controller. DVB-HTML has introduced the properties "nav-up", "nav-down", "nav-left", "nav-right", and the editor of "CSS3 module: basic user interface" plans to include in its next draft a proposal for these properties for exactly the said purpose.

Since the CSS TV Profile 1.0 refers only to CSS2 which is already a W3C Recommendation, and to CSS3 Color which we expect to be in Last Call and a Candidate Recommendation very soon, it would delay the CSS TV Profile 1.0 significantly to introduce a dependency upon the CSS3 Basic UI module.

When "CSS3 module: basic user interface" is entering Last Call or Candidate Recommendation, it is likely the "nav-*" properties will be added to a future version of the CSS TV Profile 1.1.

We noticed that CSS-TV specifies a variety of units like px, em, ex, in, cm, mm, pt as normative, while ARIB operational guideline defines px only as normative. We propose CSS-TV incorporate this simplified specification for units.

These units have been well established in standards since CSS1 (1996 Recommendation), and widely implemented. In addition, these units are all incorporated in the CSS Mobile Profile 1.0 which is also intended for small implementations, albeit for mobile/handheld devices. Finally, the CSS TV Profile 1.0 is currently a proper superset of the CSS Mobile Profile 1.0 which has a great advantage in that content authored for the mobile profile will also be supported by implementations of the tv profile. The mobile profile contains these units, so the tv profile does as well.

We noticed that CSS-TV applies percentage(%) description, which is dropped in ARIB STD-B24. One of the reasons why ARIB operational guideline does not apply percentage is that it may affect prohibited display area during the image out procedure. So we propose W3C consider the elimination of percentage description in CSS-TV.

The percentage(%) unit is quite critical for a number of applications. The limitations of display area are covered by the prose in the Conformance section in the CSS TV Profile which states:

"The inability of a TV-UA to implement part of this specification due to the limitations of a particular device (e.g., a TV-UA cannot render colors on a monochrome monitor or page) SHALL NOT imply non-conformance."

In addition, some TV declarative standards (e.g. DVB-HTML) have proposed other mechanisms (e.g. @viewport rule) for handling display area issues.

The followings are just your information:

As we understand it, CSS is not defined for making profiles, so we recognize that some of the values in CSS do not match TV application when trying to create CSS profiles.

It is true that CSS was not originally defined for making profiles, however, vendors of mobile devices found that they could define the CSS Mobile Profile, and as such the CSS TV Profile is similarly modeled.

Let me inform you that CSS handling in ARIB STD-B24 has already been incorporated into more than one million sets of set-top boxes for digital TV in Japan, and that it is up and running fine.

That is quite an admirable accomplishment!

The CSS Working Group would be very interested to learn how those current set-top boxes handle the CSS1 Test Suite,

http://w3.org/Style/CSS/Test/CSS1/current/

as most of that test suite will be used for the CSS TV Profile 1.0 test suite, which will be used to check CSS TV Profile implementations in order to pass the Candidate Recommendation exit criteria for the CSS TV Profile 1.0.

We hope the comments described above would be of your help.

Yes, the comments were helpful and will help shape future work on the CSS TV Profile. One note: it is expected that content developed using CSS TV may be transcoded with a reasonable approximation of the rendering for acceptance by already deployed HTML-based TV systems; however it is still beneficial to have a single TV profile for application developers and tools moving forward, especially considering the variety of declarative TV content standards efforts in various markets.

Comments from "Kynn Bartlett" <kynn@idyllmtn.com> 23 May 2002 and Responses

Comment

Answer

I am very confused and troubled by the complete redefinition of the TV media in this document, compared to the CSS 2 definition.

CSS2 loosely defined the tv media type, without any actual industry experience coming to bear with respect to using implementing CSS for TV devices, and authoring CSS for TV devices.

Just as the CSS Mobile Profile [http://www.w3.org/TR/css-mobile/] updates the definition of the 'handheld' media type, the CSS TV Profile updates the definition of the 'tv' media type.

In both cases, domain experts that have experience with CSS in their domains have provided a much more detailed and thought through profile of CSS for their respective domains.

Please also see the reply to issue 16 which provides a summary response to issues 9 through 16 inclusive.

In CSS 2, it states quite clearly (emphasis mine):

tv

Intended for television-type devices (low resolution, color, limited-scrollability screens, SOUND AVAILABLE)

Yes, and at the time that was written, there was no experience with either implementing or authoring CSS for TV devices.

Essentially, CSS2 did not have the benefit of "reality-checking" through the CR phase which was adopted in W3C process years after CSS2 was published.

As a result (and this is not the only case), CSS2 contains many "good ideas" which never came to fruition for one reason or another.

The CSS Working Group is deprecating, or in most cases, relabeling as informative such "good idea - little or no implementation" CSS2 features in CSS2.1. One particular such area is the definition of the media types - those definitions are for the most part all being made informative - since such definitions would not successfully satisfy the implementation requirements and thus exit CR. The only thing normative about media types that is being kept is the set of names of the media types, and the definition of the 'all' media keyword.

Please also see the reply to issue 16 which provides a summary response to issues 9 through 16 inclusive.

Under media groups, tv is defined as "visual, AURAL", unlike screen which is "visual."

Television is universally understood to be a true multimedia medium, combining video and audio.

However, the proposed TV profile does not acknowledge this.

The CSS TV Profile 1.0 refers to the appropriate CSS properties (and selectors) from CSS2 that have either been demonstrated to be of use for TV content specifically, or have been widely implemented and understood.

For now, the profile doesn't include any aural properties as you noted, but the profile doesn't preclude the addition of multimedia support in a future version.

Please also see the reply to issue 16 which provides a summary response to issues 9 through 16 inclusive.

All aural properties are unsupported in this profile, and aural values likewise are unsupported.

Unfortunately your evaluation of aural properties not only applies to the TV profile, but in general. Other than emacspeak (which only implemented a draft of the aural properties - not the final REC, and which doesn't run on a TV device), the CSS working group doesn't know of any implementations, certainly not any interoperable implementations.

In order to encourage forward progress in the area of CSS Audio/Speech, members of the CSS Working Group, along with other W3C audio/speech experts (e.g. Dave Raggett, T.V. Raman etc.) discussed a course of action at the most recent W3C plenary this past February/March.

There were several decisions made. First, it was widely acknowledged that the aural properties in CSS2 were a good first cut, useful for exploring the field, but did not do a really thorough job of solving actual problems, while containing esoteric ("neato") features (e.g. all the 3d audio stuff) that were found to distract from the usefulness of the rest. Thus, second, it was decided to place the aural properties into an informative chapter of CSS2.1, including documentation on what subset of those properties and values had implementation experience (specifically T.V. Raman's implementation experience), and what that experience has taught us. Finally, third, it was decided that there should be a CSS3 Voice Module that coordinated better with the VoiceML efforts, and that Dave Raggett would be the editor for that module.

Please also see the reply to issue 16 which provides a summary response to issues 9 through 16 inclusive.

In addition wrongly identifying the tv medium,

The definition and identification of the tv medium in CSS TV Profile 1.0 is more of a practical identification of the constraints of TV devices in use today and in the near future.

Please also see the reply to issue 16 which provides a summary response to issues 9 through 16 inclusive.

ignoring the audio aspects in this profile while accentuating only the visual will further relegate aural styles to the realm of "nice idea, never implemented beyond emacspeak."

It is actually the other way around. Because the meeting in Cannes explicitly decided to relegate the first generation of aural properties as a "nice idea" as you say, it made sense to keep the 1.0 version of the CSS TV Profile simple, with the hopes that once there is a "reality-checked" updated set of aural properties in the CSS3 Voice Module, then a future version of the CSS TV Profile can reference those.

Please also see the reply to issue 16 which provides a summary response to issues 9 through 16 inclusive.

This can and will prove to be a detriment to users with visual disabilities.

Given that aural properties have not been widely implemented/deployed, and certainly not on TV devices, it is difficult to see how simply acknowledging that fact could be detrimental.

On the contrary, what would be more detrimental is trying to make something work which has failed to take off for one reason or another. It is expected that Dave Raggett will assist with and produce a much better CSS3 Voice Module than the ACSS chapter in CSS2.

Please also see the reply to issue 16 which provides a summary response to issues 9 through 16 inclusive.

This draft should be sent back and rewritten to reflect the multimedia nature of the tv media type, as noted in CSS 2.

This statement is a response not only to issue number 16, but also a summary response to issues 9 through 16 inclusive.

CSS2 aural provisions lack the implementation experience that would today be required to enter PR; consensus at Cannes Technical Plenary was that there are some problems with this design and a fresh look is required. Hence, future.

Regarding multimedia styling, there is a lack of sufficient experience with multimedia styling to have a firm approach. This is also yet to be developed in consultation with MMI et al.

Audio styling and coordination of styling in multimedia contexts have to be left as topics for future work in this release. Yes, they are on the agenda; no, it is not possible to publish solutions to these questions in this profile at this time, and the profile proposed here with its limited scope and use case is needed to avoid splintering of efforts to use declarative styling in the TV industry.

When support for multimedia properties is well defined in a CSS3 module and at least at last call (preferably CR), then it may make sense to write a new revision of the CSS TV Profile which refers to those multimedia properties.

The input is accepted as a suggestion for a future version of the CSS TV Profile - once multimedia properties have been properly improved, they should be added to the next version of the CSS TV Profile. These additions won't conflict with what is CSS TV Profile 1.0, and therefore it may proceed with what works today as 1.0, while keeping in mind the ideal future for future versions.

Section 6 of the proposal states that:

4. The TV-UA SHALL support author originating style sheets. The TV-UA MAY support user or user-agent originating style sheets.

User and user-agent style sheets are essential to ensuring equal access to CSS-based documents by people with disabilities, and are a critical part of the cascade. The word MAY should be replaced by SHALL.

Please be aware of the application context for this profile. The TV in question is generally not a Web user agent, is not Web-enabled. This is not typically a WebTV implementation, but a TV set that is playing a pure-push stream of content in most situations. User control over content is more or less limited to channel selection which includes turning on or off closed caption sub-channels. Control over presentation is on the order of device controls such as screen brightness and sound volume (level plus mute).

User style sheets are very beneficial to the user, but for the user to employ their choice of style sheet, there would have to be either web access from the TV to somewhere they could point at their preferred stylesheet on the Web, or a stylesheet authoring capability, or a removable media or data communications capability in the device. Adding any of these capabilities to many of these TV devices would be significant functional change and not readily achieved. So it is not reasonable to demand this support from all implementations of this profile.

Creating a common profile of CSS use in TV applications around the globe will increase the use by TV content of accessible text plus style for some sub-channels that might otherwise be streamed as sub-pictures. This in itself would be accessibility progress. We cannot mandate in a CSS profile that all TVs should suddenly become Web devices.

Comments from Etan Wexler <ewexler@stickdog.com> 4 Jun 2002 and Responses

Comment

Answer

[1.] The document lacks a summary of at-rule support. A table for at-rules would be helpful. As things stand, 'font-face', 'page', and 'color-profile' at-rules receive no mention.

The CSS TV Profile explicitly mentions that the a TV-UA SHALL support:

@charset (section 5)
@import (section 6)
@media (section 7)

No other at-rules are mentioned, therefore no other at-rules are required by CSS TV Profile 1.0.

A table for at-rules would be helpful. A profile table of at-rule support (similar to the profile table of selectors support) has been added to the CR draft of CSS TV Profile 1.0.

Note that the CSS TV Profile was derived from the CSS Mobile Profile, which also lacked such a table. Your suggestion has been forwarded to the editors of the CSS Mobile Profile to keep the format of the profiles consistent.

2. Conformance

"If a TV-UA encounters a property that applies for a supported media type, the TV-UA MUST parse the value according to the property definition."

Change the first occurrence of "property" to "declaration".

That would not make sense, as the sentence would read:

"If a TV-UA encounters a declaration that applies for a supported media type"

Each property in CSS2 defines whether or not it applies to a particular media type (or set of media types). No where is there any concept of a declaration as a whole applying to a specific media type or not.

"TV-UA MUST ignore rules that apply to unsupported media types."

What does "rules" mean here? It could mean at-rules, rule sets, at-rules and rule sets, declarations, and more.

All forms of rules per the CSS grammar. Declarations by themselves are not rules - at a minimum they need to be wrapped in curly braces and prepended by a selector in order to become a rule.

"If the source document comes with alternate style sheets (such as with the "alternate" keyword in HTML 4.0 [HTML40]), the TV-UA SHOULD allow the user to select one from among these style sheets and apply the selected one."

Allowing just one style sheet at a time is more restrictive than the HTML4 model. Change to "If the source document comes with alternate style sheets (such as with the "alternate" keyword in HTML 4.0 [HTML40]), the TV-UA SHOULD allow the user to select from among these style sheets and apply the selected style sheets."

The HTML4 model of alternate style sheets was updated in and superceded by CSS2. The text in the CSS TV Profile is derived from CSS2 Section 3.2 subpoint 5. [http://www.w3.org/TR/REC-CSS2/conform.html#conformance]. Similarly, the CSS Mobile Profile has the same wording.

"Values MAY be approximated when required by the TV-UA."

For clarity, change to "A TV-UA MAY approximate computed values when assigning actual values."

Again, this wording was taken from CSS2 Section 3.2, and it is better to keep it consistent. And again, CSS Mobile Profile has the same wording. For clarity and consistency we should keep the same wording.

"Authors should be able to use style properties with an understanding that the cascading rules are processed correctly"

Change "style properties" to "declarations".

This does not semantically change the sentence. Unless there is an advantage to the change, the wording should stay as is - this is another instance where CSS Mobile Profile has the same wording.

"A TV-UA that can process the 'run-in' value for the 'display' property will process the first display specification and then "write over" that value with the second display specification. A TV-UA that cannot process the 'run-in' value will process the first display specification and ignore the second display specification."

The word "process" is too general and the word "specification" is but another way of writing "declaration". Change to "A TV-UA that accepts the 'run-in' value for the 'display' property will accept the first 'display' declaration and then replace that declaration's value with the value from the second 'display' declaration. A TV-UA that does not accept the 'run- in' value will accept the first 'display' declaration and ignore the second 'display' declaration."

Agreed that the use of the word "specification" in that text should be "declaration" - in fact, that is what the CSS Mobile Profile has, and it is unclear how this difference crept in. The text has been corrected.

As far as the word "process" - that is what the CSS Mobile Profile has, but in this case, your suggestion of using the word "accept" instead is clearer, more indicative of the intent, more precise, and more like what CSS2 says.

Your suggestion to change the text makes sense. The CSS Mobile Profile should probably make the same change.

3. Selectors

Are the unsupported selectors to be parsed as valid but ignored during property assignment? Are the unsupported selectors to be parsed as invalid (which would affect valid selectors in the same group)?

The latter. The same as if a CSS1 UA were to encounter CSS2 selectors.

All pseudo-elements are missing from the table.

Oops. This seems like an unintended omission (same problem in the CSS Mobile Profile).

The intent was that :first-letter and :first-line are supported, but that :before and :after are not (as can be implied by the lack of support for the 'content' property).

The pseudo-elements have been added to the selectors table in the CR draft.

I ask for another column in the table to provide a rationale for the rejection of selectors. The rejection of the 'hover' pseudo-class is obvious to me (television sets have no hovering cursor) but the other rejections are far from obvious.

Some of the reasoning has taken place on this list, some of it has taken place on the CSS working group mailing list, some during CSS working group teleconferences, and some during face to face meetings. Several experts who have worked on interactive television content and devices provided their views and opinions based on their experience as to which features should be in the profile and which shouldn't.

It is not possible to go back and recreate the thread of reasoning for each and every feature independently.

In general as the abstract says, the subset is "tailored to the needs and constraints of TV devices."

The omission of features is typically due to well known / accepted processor constraints, memory constraints, or display constraints of TV devices in use today and in the near future.

Such devices are fully expected to advance of course, and there are already requests for more features to add in CSS TV Profile 1.1 to take advantage of such more advanced TV devices. If you know of features you would like to see in a future version of the CSS TV Profile (1.1 or later), please feel encouraged to post your requests to the www-style@w3.org list.

4. Properties

Again, rationale columns would be most helpful.

Same comment as above.

The Working Group has decided to cast television as a visual-only medium, so the rejection of aural properties is obvious.

This is primarily due to the insufficient implementation/interoperability of the aural properties at this time. If and when there is a much improved iteration of the aural properties in the CSS3 Audio (and/or Speech/Voice) module(s), the working group will consider adding them to a future version of this module.

Apparently, television may decline to support tables and generated content, which, though a choice requiring its own explanation, provides a rationale for many of the remaining property rejections.

Yes.

However, properties like 'background-attachment',

This was for drawing performance reasons. Fixed backgrounds are slower to draw (and require more memory) when scrolling the page.

'direction',

Also missing from the CSS Mobile Profile, and for the same reasons - performance and memory.

'font-size-adjust', 'font-stretch', 'letter-spacing', 'text-shadow', 'Unicode-bidi', and 'word-spacing'

On set-top boxes, there are typically a very limited number of font choices (if even more than one). It made more sense to leave out these properties rather than to tell people that they may (probably will) always revert to some initial setting due to platform constraints.

the 'max' and 'min' dimensions, 'overflow',

There was a request from some implementers of user agents for TV devices to omit them.

require some explanation, at least as far as this non-psychic is concerned.

Hopefully these explanations helped at least a little.

Why are color values containing an alpha component not accepted while the 'opacity' property is accepted?

In fact, another reviewer explicitly asked for the "rgba()" color value to be accepted, and the working group has agreed.

The CR draft of the TV Profile will include "rgba()" color values.

5. CSS Syntax

What character encoding schemes are mandatory or suggested for acceptance by a TV user agent? What character encoding schemes are mandatory or suggested for a TV Cascading Style Sheet?

From section 5.

" Similarly, the CSS TV Profile requires that conforming user agents support the character encoding mechanisms specified in [CSS2]. Specifically:

The TV-UA SHALL support priorities specified in [CSS2] to determine a document's character encoding.

The TV-UA SHALL support the CSS2 @charset rules.

"

In short, the same as CSS2.

6. Assigning Property Values, Cascading, and Inheritance

"2. The TV-UA SHALL support inheritence as described in CSS2 ([CSS2] Section 6.2)."

Change "inheritence" to "inheritance".

Thanks for the catch!

"4. The TV-UA SHALL support author originating style sheets. The TV- UA MAY support user or user-agent originating style sheets ([CSS2] Section 6.4)."

This imbalance of control is a nasty surprise. What is the rationale for divesting users of their stake in the cascade? If I could rewrite this requirement, it would read "The TV-UA SHALL support user-originating style sheets. For some TV-UAs, this will necessitate retrieval of user style sheets from the Web. The TV-UA SHOULD support author- originating and user-agent-originating style sheets ([CSS2] Section 6.4)."

It did not make sense to place such user interface requirements on what essentially may be (and typically are) embedded systems which allow for very little user customization in general.

It is certainly not feasible to necessitate a TV-UA to do anything with the Web as a TV-UA may never see or have access to the Web. May such devices receive only a 1-way stream of data over a broadcast signal for example.

This change was explicitly made by the working group for both the CSS Mobile Profile and CSS TV Profile.

"5. The TV-UA SHALL support all CSS2 cascading rules ([CSS2] Sections 6.4.1-6.4.4)."

To disambiguate, change "rules" to "regulations".

The word "rules" in that sentence could be potentially confusing. It is unclear whether "regulations" provides the correct semantic however.

The word "rules" is changed to "mechanisms" which has been used in CSS2.

Note: The CSS Mobile Profile should also be similarly updated.

"Appendix A. References"

Please give the status of each reference as either normative or non- normative.

All references are normative. This is noted in the CR draft.

Comments from Joel Zdepski <joel.zdepski@opentv.com> 7 Jun 2002 and Responses

Comment

Answer

There is, however, one small change that we believe will be necessary to achieve adequate performance on today's set-top boxes. This change has to do with the properties from CSS-3's Color Profile that are required and those that are optional. It has been our experience that content designers demand the ability to specify transparency on a per-color basis rather than on a per-element basis. CSS-3's RGBA would satisfy this demand, yet it is excluded from the CSS TV Profile 1.0, while support for CSS3's opacity property is required. It has been our experience that content providers would not typically be satisfied with this single transparency attribute; it appears to us to be impossible to obtain adequate performance if this property is used in conjunction with RGBA on most set-top boxes; and that some lower end set-top boxes that are very important in today's market cannot support the opacity property while they can support at least one semi-transparent color in their hardware palette.

From this, we (the CSS working group) gathered that you proposed adding the "rgba()" color value from the CSS3 Color Module to the CSS TV Profile 1.0.

The editors agree with your proposal.

Your feedback was brought to the CSS Working Group, and the Working Group accepted your proposed change at our teleconference dated 10 June 2002. [ http://lists.w3.org/Archives/Member/w3c-css-wg/2002AprJun/0239.html [W3C Members only hyperlink]]

The "rgba()" color value will be added to the CR draft of the CSS TV Profile 1.0.

Regarding the difficulty to obtain adequate performance of the implementation of the "opacity" property on some (or perhaps today most) set-top boxes, there is agreement with your statement, and that is specifically why the opacity property in the CSS3 Color module [ http://www.w3.org/TR/css3-color/#transparency ] takes an optional <priority-index> value. The intent of this is to take advantage of hardware acceleration for opacity rendering on boxes that have that capability.

Additionally, it is implied (but not explicitly stated) in the conformance section of CSS TV Profile 1.0 [ http://www.w3.org/TR/css-tv#section-conformance ] that it is acceptable for an implementation to ignore the opacity property due to the [performance, video etc.] limitations of a particular device:

This portion of the conformance statement should be sufficient. If you think an explicit statement about opacity is needed, please let reply as such.

Comments from Etan Wexler <ewexler@stickdog.com> 14 June 2002 and Responses

Comment

Answer

Tantek Çelik responded to my comments on the CSS TV Profile 1.0:

Each property in CSS2 defines whether or not it applies to a particular media type (or set of media types). No where is there any concept of a declaration as a whole applying to a specific media type or not.

A declaration only and always contains one property name, so the determination of whether the declaration applies to a medium is trivial.

The determination may be trivial to those well versed in the language of the specification, however using the term 'declaration' is still an additional level of semantic separation that is unnecessary. Thus it makes more sense purely for readability (never mind that more authors know the term "property" than the term "declaration") to directly use the term 'property' as the text does currently.

"TV-UA MUST ignore rules that apply to unsupported media types."
What does "rules" mean here? It could mean at-rules, rule sets, at-rules and rule sets, declarations, and more.
All forms of rules per the CSS grammar.

Which CSS grammar?

http://www.w3.org/TR/REC-CSS2/grammar.html

The CSS2 grammar defines a "statement" as either a rule set or at-rule. Where is the term "rule" defined?

The above-mentioned grammar uses the production "ruleset" to refer to what in the prose of the specification is called a "rule".

Anyway, how could a rule set apply to unsupported media types (or any media types)?

To paraphrase, nowhere is there any concept of a rule set as a whole applying to a specific media type or not.

There are at least two examples of rules that only apply to particular media types:

@page only applies to page media.
@media foo { ... } only applies to media foo, where foo is one of the valid media types as defined in CSS2.

The HTML4 model of alternate style sheets was updated in and superceded by CSS2.

Wow, that's a leap. Where does CSS2 claim to update, much less supercede, HTML4's model of alternate style sheets?

The reference is in my next statement which you quoted:

The text in the CSS TV Profile is derived from CSS2 Section 3.2 subpoint 5.

That subpoint comes after the notice, "This section defines conformance with the CSS2 specification only. There may be other levels of CSS in the future that may require a user agent to implement a different set of features in order to conform." You are saying that there has been a decision to stick to CSS2 wording, but not saying why.

If there had been a change there would be a need to say why. There is no need to justify use of what is already there, other than perhaps "because it is in a W3C REC".

Similarly, the CSS Mobile Profile has the same wording.

Well, if need be, change that, too.

Sounds like you are requesting a change in CSS in general (that is, a change in CSS TV Profile, a change in CSS Mobile Profile, and potentially a change in CSS2 (which would likely be need to be made in CSS2.1)).

The scope of this change is outside the CSS TV Profile.

If you wish to pursue this change, please propose it as a change (in a separate email) to CSS2 to be then adopted by other specifications which depend or reference CSS2.

"Values MAY be approximated when required by the TV-UA."
For clarity, change to "A TV-UA MAY approximate computed values when assigning actual values."
Again, this wording was taken from CSS2 Section 3.2, and I would like to keep it consistent.

Is keeping a specification consistently hazy better than clarifying matters?

From a specification standpoint, yes.

Is it possible to change wordings in the CSS TV Profile and, by way of CSS2.1, in level 2?

Yes, this would be possible too - and that is what is being suggested you ask for above.

And again, CSS Mobile Profile has the same wording.

As the CSS Mobile Profile has yet to reach Recommendation and is open to change,

It has however reached Candidate Recommendation, and the changes that can occur during CR are much more restricted. It will be up to the group to decide if the change you propose can be accepted during CR.

I see no reason to let its wording dictate the wording of the CSS TV Profile.

Again, consistency. There is no reason for CSS TV Profile to break from CSS2 or CSS Mobile Profile in this way. There is at least one good reason to keep it consistent however, and that is that an implementation implementing both should not have to be different in this way.

For clarity and [consistency] we should keep the same wording.

For clarity, we should choose the clearest wording, regardless of past wordings. For consistency, we should stick to past wordings, regardless of clarity. I choose clarity.

This kind of wordsmithing has introduced bugs into the specifications in the past - for that reason alone it is best to avoid this practice.

Changes introduced to wording in a spec which are intended to have no semantic difference, often result in many many authors, developers, programmers spending hours of time trying to divine why the change was made, and assuming that because the change was made there must be something subtly different being implied, and going to all sorts of contortions of logic to justify a difference in implementation however small.

Your argument for clarity is strongly outweighed by the amount of time wasted by many many individuals as a result of reading the before/after wordsmithed text.

"Authors should be able to use style properties with an understanding that the cascading rules are processed correctly"
Change "style properties" to "declarations".
AFAICT this does not semantically change the sentence. Unless there is an advantage to the change, the wording should stay as is - this is another instance where CSS Mobile Profile has the same wording.

The advantage is that "declaration" is well defined, while "style property" is used here only. The advantage is that authors write declarations, not properties.

The advantage is that authors understand the term "properties" much more so than "declarations".

Readability is important - authors already complain that W3C specs are difficult to read because of their spec-ese, let's not make it any worse than it needs to be.

3. Selectors Are the unsupported selectors to be parsed as invalid (which would affect valid selectors in the same group)?
[Yes.] The same as if a CSS1 UA were to encounter CSS2 selectors.

Please add a note explaining this effect.

Agreed.

'font-size-adjust', 'font-stretch', 'letter-spacing', 'text-shadow', 'Unicode-bidi', and 'word-spacing'
On set-top boxes, there are typically a very limited number of font choices (if even more than one). It made more sense to leave out these properties rather than to tell people that they may (probably will) always revert to some initial setting due to platform constraints.

Given the limitations on fonts, why does the CSS TV Profile include any font properties?

It is not an all or nothing situation. Typically, there is some ability to specify fonts - just not nearly enough to imply the level of control implied by the abovementioned properties.

What character encoding schemes are mandatory or suggested for acceptance by a TV user agent? What character encoding schemes are mandatory or suggested for a TV Cascading Style Sheet? [...]
In short, the same as CSS2.

So there are no mandatory encoding schemes. If I have a style sheet in UTF-8, I have no guarantee that a user agent conforming to the CSS TV Profile will accept the style sheet. That saddens me.

It is no worse than CSS2 or CSS1 for that matter, yet this [questions about character encoding schemes] doesn't appear to have been an obstacle for the implementation or wide adoption of CSS.

If you think this is something that could be improved in CSS2 (perhaps for a CSS2.1), you should propose it as such.

Thanks again for the additional well thought out thorough feedback Etan. All the issues you mentioned which were germane to the CSS TV Profile have been resolved, and the CR draft will benefit from the input you have provided.

Comments from fantasai <fantasai@escape.com> 14 June 2002 and Responses

Comment

Answer

Tantek Çelik wrote:

On 5/23/02 1:42 PM, "Kynn Bartlett" <kynn@idyllmtn.com> wrote:
Section 6 of the proposal states that:
4. The TV-UA SHALL support author originating style sheets. The TV-UA MAY support user or user-agent originating style sheets.
User and user-agent style sheets are essential to ensuring equal access to CSS-based documents by people with disabilities, and are a critical part of the cascade. The word MAY should be replaced by SHALL.
User style sheets are very beneficial to the user, but typically this is true only on devices such as desktop computers that have a keyboard etc. In fact, UAAG 1.0 explicitly recognizes this appropriate targeting for itself, and states it clearly.

If the device allows any sort of user preferences that affect the rendering of a page, such as choosing link colors, these are considered part of the user style sheet whether or not they are implemented as a style sheet.

CSS2:6.4 -

"the user agent may provide an interface that generates a user style sheet (or behave as if it did)"

CSS2 requires a user agent to have a UA style sheet for the document or to behave as if it did. There's no reason to change this for any device; a style sheet /can/ be blank. And I'm sure any UA that claims to read HTML will have, or behave as if it had, a default user agent style sheet.

CSS2:6.4 -

"Conforming user agents must apply a default style sheet (or behave as if they did) prior to all other style sheets for a document."

I conclude that all of CSS2:6.4 can be applied to the TV profile as it stands.

Agreed on both counts.

Special thanks to Al Gilman for his significant assistance with the responses to issues 9 through 17.

CSS TV Profile 1.0 Disposition of Comments

Abstract

Introduction

Comments Received