RE: Coments - last call draft

As currently defined em's are defined in terms of ttm:cellsize, which is
a fixed portion of the canvas (default = the whole canvas). So em's are
a relative measure in the same way that pixels are. The problem is that
we currently have no way of recording how many pixels are expected to be
in the canvas, probably we should define meta data which defines this,
as we do for cells. I recall we discussed that in the WG, so I'm not
sure why its not in the draft. 

-----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: Johnb@screen.subtitling.com; public-tt@w3.org
Subject: 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 16:01:45 UTC