RE: Coments - last call draft

On CSS like styling, this has been talked about a lot and it was a
deliberate decision to leave this out of DFXP, since it requires much
more knowledge of the whole tree. AFXP on the other hand will have an
applicative styling model which would allow user defined styles. DFXP
would be compiled out of AFXP post user choice.

Having said that, user styling for accessibility is not always very
successful, since to do it properly really requires knowledge of both
how the content is designed as well as the specific requirements of the
recipient. In an ideal world (which of course cannot exist since every
recipient is unique, but might be approximated) the author/designer
would provide a suite of style-sheets which can be swapped at a macro
level. Such a choice mechanism might be provided through something like
media queries.

For a signing 'timed text', while work has been done both in animated
avatars and codifying signing in a written form, to my knowledge this
work has not been very successful to date from a legibility point of
view. So I suspect that a video based approach is the only one that
makes sense for some time. In which case SMIL might be the better
starting point. 

-----Original Message-----
From: public-tt-request@w3.org [mailto:public-tt-request@w3.org] On
Behalf Of Charles McCathieNevile
Sent: 31 March 2005 23:08
To: Glenn A. Adams; public-tt@w3.org
Subject: Re: Coments - last call draft


On Fri, 01 Apr 2005 00:54:41 +1000, Glenn A. Adams <gadams@xfsi.com>
wrote:

> Thanks much for your comments. Following are some personal
> replies/comments. The TT WG will follow up with a consensus response.
>
>> -----Original Message-----
>> From: Charles McCathieNevile [mailto:charles@sidar.org]
>> Subject: Coments - last call draft
>>
>> 2. Validity
>
> Good catch. I had copied this language from another document and
> neglected to fine tune it for DFXP purposes. I expect this will be
> resolved by adding normative conformance requirements on certain
> attribute usage and semantics.

OK.

>> 3. Default length units
>>
>> Section 6.2.3 defining defaultLengthUnit says
>>
>> [[[
>> If not specified, the default length unit must be considered to be
> pixels.
>> ]]]
>>
>> For accessibility reasons, it seems better in a pure text format to
> use an
>> element based on font size, such as the em unit, as a default. I
> realise
>> this implies a small change in the practice of authors, who are
> probably
>> generally accustomed to working in pixels. But then they are probably
> not
>> generally accustomed to working on accessibility.
>
> All of the legacy distribution formats with which DFXP was designed to
> interoperate are based on pixel units as the default (and only) units.
> We expanded DFXP to support additional units, but made pixels the
> default for compatibility with these legacy formats.

Sigh. I'll think about this some more. I am not surprised by this. But I

am not sure that px are a good choice even given this situation.

>> 4. frameRateMultiplier
>>
>
> I agree this is somewhat hard to decipher, particularly if you have no
> background in Television Engineering. Nevertheless, these parameters
are
> essential information needed to communicate sufficient information to
> convert between a frame based temporal coordinate space (like SMPTE
12M)
> and a real-time or media time temporal coordinate space.

Yep.

> Regarding the default, NTSC is not defined as a default. The default
> frameRateMultiplier is defined as 1:1. The discussion of NTSC is an
> example of a frame rate which is (30 * 1000/1001). Do you think it is
> necessary to add another example that discusses another regional usage
> (such as PAL, where the frame rate is exactly 25, with multiplier
> remaining at the default 1:1)?

No, just anticipate that many people will stop reading at this point. It

might seriously be worthwhile giving a rough guide and then the detail
for  
this section, so people realise taht what comes after isn't such  
specialised gobbledygook.

>> Actually it seems strange that so much of this is in the spec. I
>> understand that it enables synchronisation with traditional
> television,
>> but it seems a lot of complexity.
>
> The most important use case for TT is related to its interoperation
with
> video media, thus it cannot be avoided. In fact, one way to look at
this
> is that it introduces into the W3C a more sophisticated formalization
of
> certain video related timing aspects (which were not formally
addressed
> in SMIL).

Fair enough.

>> 5. Duration and begin/end
>> 6. Compulsory xml:lang attribute

OK, consider me satisfied.

>> 7. Style, and user styling
>>
>> Quite a lot of work went into CSS. It is also considered pretty
normal
>> to style XML with CSS.
>
> Quite a lot of work went into XSL FO as well, which, in turn, is based
> on many CSS style properties.
>
> The WG decided fairly early to adopt XSL FO as our basic
> layout/formatting model, partly because it addresses I18N issues
better
> than CSS2, and we didn't want to be delayed waiting on the
finalization
> of CSS3 in which I18N issues have been addressed. We also wanted to
make
> use of a strict XML encoding of style information to enable
> transformations (I personally view this as a major negative for CSS in
> an XML world.)

On the other hand accessibility issues are not addressed by FO. It is
not  
at all clear how a user should expect to provide styling rules to meet  
their particular needs, as is trivial using CSS for text styling.

>> For accessibility purposes it is helpful to have something like the
> CSS2
>> Cascade rules (which represented a change from CSS1 for enhanced
>> accessibility). It turns out that text is about the only area where
it
>> is easy for user styles to make sense, so it seems a shame that there
is
>> no mechanism anticipated by the spec for using CSS and takng
advantage  
>> of
>> the cascading of rules that are important to the user, where  
>> appropriate.
>
> In general, the WG has tried assiduously to avoid defining UA
behavior.

In this case I think it is a mistake. There are some cases where it
makes  
sense to describe what User Agents MUST, SHOULD and MAY do, and this
case  
might be one of them (since otherwise it maynoteven get onto the radar  
ofmany developers, leading to a serious lack of accessibility in
practice).

>> 8. Timed text and sign language
>>
> Conceptually, there is certainly a relation between a signed media
> object and a caption/subtitle media object, both of which are
> alternative representations of information typically encoded in an
audio
> media object for hearing users. The focus of the TT WG has been on
> defining a TT media object. Perhaps the SVG WG might be interested in
> evaluating a specialized usage of SVG that would support a sign
language
> media object.

Hmmm. I am not sure if it would be an SVG object or a real video more  
often. Anyway, it is possible to put this stuff in with SMIL without too

much hassle (although the mechanism involves switching on languages and
I  
am not sure how well that is handled in the muliple language case).

>> (In other words, this could be done with a brief note in the
> introduction
>> or somewhere).
>
> Good idea.

OK.

cheers

Chaals

-- 
Charles McCathieNevile                      Fundacion Sidar
charles@sidar.org   +61 409 134 136    http://www.sidar.org

Received on Friday, 1 April 2005 16:27:54 UTC