Re: TV profile comments (WD-css-tv-20020515)

On 6/4/02 12:13 PM, "Etan Wexler" <ewexler@stickdog.com> wrote:

> 
> The following are comments on the CSS TV profile working draft
> (<http://www.w3.org/TR/2002/WD-css-tv-20020515>).

Etan,

Thanks for your feedback and thorough review!

I will try to address the issues/questions you raise.


> [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:

 1. @charset (section 5)
 2. @import (section 6)
 3. @media (section 7)

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

I do agree however with your statement "A table for at-rules
 would be helpful".  I will add a profile table of at-rule support (similar
to the profile table of selectors support) to the CR draft of CSS TV Profile
1.0.

Note that the CSS TV Profile was derived from the CSS Mobile Profile [1],
which also lacked such a table.  I will forward your suggestion 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.[2].  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 I would like to
keep it consistent.  And again, CSS Mobile Profile has the same wording.
For clarity and consitency 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".

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.


> "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 I
don't know how this difference crept in.

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

I think 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).

FWIW I believe 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).

I will add the pseudo-elements 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.

I'm not certain it is 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.

I fully expect such devices to advance of course, and we already have
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
encourage to post your requests to this 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.

Primarily due to the insufficient implementation/interoperability of the
aural properties.  We are hoping to see a much improved iteration of the
aural properties in the CSS3 Audio (and/or Voice) module(s).

> 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',

I believe 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 I presume the same reasons -
performance.

> '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.

I hope my explanation 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 "rgab()" 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:

1.    The TV-UA SHALL support priorities specified in [CSS2] to determine a
document's character encoding.
2.    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".

I agree that "rules" in that sentence could be potentially confusing.  I'm
not sure that "regulations" provides the correct semantic however.

I will change the word 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.  I will note that in the CR draft.


Thanks again for all your feedback Etan.


Tantek

[1]
 http://www.w3.org/TR/css-mobile/

[2]
 http://www.w3.org/TR/REC-CSS2/conform.html#conformance

Received on Friday, 14 June 2002 02:40:07 UTC