Re: Coments - last call draft

On Thu, 31 Mar 2005 23:15:29 +1000, <Johnb@screen.subtitling.com> wrote:

> [[[
> 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.
>
> In general I support your view - but I would prefer that scalar values  
> were ONLY relative rather than absolute - such that all expressions of  
> dimension
> were always in terms of proportions of either the target canvas, or of a
> selected font. The use of absolute scalar values creates files that are
> tightly bound to a specific target display (which is hardly fitting for  
> an interchange mechanism). Moving to an em unit as a default could be
> problematic, as sizing then becomes dependent on the font not the canvas
> (thus when canvas size is fixed - overflow/clipping may occur).

For most cases it should be possible to specify a canvas in relative units  
too. The proposal for constraint-based CSS of many years ago would have  
been great in this situation (you coul select various constraints, as the  
name suggests). There is a less-powerful version of the same thing  
available in CSS 3.

But the major concern is that px are a relative unit in the sense that  
they are not the same size on different platforms, if not in the sense  
that the user can readiy configure the actual rendered size. So you get  
the worst of both worlds.

> frameRateMultiplier (et al)
>
...
> The requirement for most of these timebase attributes only arises
> by allowing 'dur' as an attribute, since this necessitates the  
> calculation
> of effective end values, which in term requires an understanding of
> framecounting in different timebases.
>
> It would be helpful if the spec said what happens when the begin/end and
> the dur attributes don't agree.
>
> Or if it said that you can use begin + dur, and begin + end, but not  
> begin + end + dur!
>
> IMO - drop dur as an attribute - it can be equivalently expressed using
> begin and end - and the above issues can then be simplified.

I think it is useful to have dur, so I guess it makes sense that all this  
stuff is there if you want intrinsic timing with the complexity of TV  
models.

> Quite a lot of work went into CSS. It is also considered pretty normal to
> style XML with CSS.
>
> 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.
>
> No argument here! - but DFXP uses the XSL-FO model as a foundation not  
> CSS.

My point is really that it is trivial to assoiate CSS with any XML (there  
is a W3C recommendation on this) and that text is the kind of thing where  
this is particularly useful from a user perspective. Currently the Spec  
does not describe how the user might override styles (e.g. for  
accessibility purposes) and consequently fails to alert developers to this  
possibility. (CSS itself describes how to mix it with intrinsic XML  
styling properties, so there isn't much to make up, just explaining what  
actually happens).

cheers

Chaals

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

Received on Friday, 1 April 2005 07:08:25 UTC