Hello SMIL working group,
some comments on chapter 8
8.3.1
'inherit
The effective value of this attribute is used.'
-> What is an 'effective value'?
-> Define or reference definition...
-> or something like this:
'inherit
The textWrapOption value of the parent element
is used.'?
--------------
typo?
'This time is defines as being relative ...'
->
'This time is defined as being relative ...'?
---------
typo? (missing whitespace)
'no preceding tev/clearelement'
->
'no preceding tev/clear element'
---------------
'Examples'
-> shouldn't this be inside the informative box?
---------------
8.3
smilText element content:
'The smilText element may contain character content.'
->
'The smilText element may contain the elements tev, clear, br
or character content.'?
---------------------------
8.4
- The p element in XHTML has a semantic meaning
of a paragraph and has nothing to do with styling, but
with the meaning of the content. It is maybe not a
good idea to define it here without a meaning just for
styling purposes. Wouldn't it be sufficient to note
that a div can be within a div (but maybe not
more then one level of nesting)?
- Another idea to get a little bit more meaning
to the meaningless elements of this module is
to add for example an attribute to smilText, div and span
like textSemantics or textMeaning with a comma or
space separated list as value with list items
like h'digit', p, q, abbr, em, strong, pre, article, abstract,
poem, stanza, line etc
(some more are available in the drafts for 'HTML5' or XHTML2),
partly similar to (X)HTML elements with semantic meanings
or of semantic structures, currently not represented with
(X)HTML elements, but nice for SMIL presentation.
Author defined semantic value fragments could start with
'-' for example to expand this a little bit.
Of course authors can use (X)HTML right
from the start to avoid meaningless text
elements, but SMIL adds an additional
feature like timing to the text, therefore there
might be a reason to use this instead of
(X)HTML.
Therefore one can write
<div textMeaning="stanza em"> ... </div>
or
<div textMeaning="p poem -concretePoetry"> ... </div>
This is not much more to implement, because there
is no need to have a default styling for all these
things, anyway the meaning of the content is
machine readable and identificable as an author
expects from a good markup language.
If the author needs more than this
'minimal semantics', XHTML can be used, but even
with ideas like 'microformats' this will not be
much better for many text types as poems...
And if CSS is available, authors can use this
for styling too, using a selektor like
div[textMeaning~="-concretePoetry"] or
the styling attributes of smilText of course.
Anyway these presentational attributes move
smilText a little bit in the direction that
presents text as a graphical object, as it is
in SVG, is this intended? If not, it would
be sufficient to style it with CSS, isn't it?
-------------------------
div element:
'This element accepts as content zero or more characters to which the
specified styling is applied.'
->
'This element accepts as content p or span elements or zero or more characters
to
which the specified styling is applied.'?
-> etc for the p element ...?
----------
-> I think, textWrapOption is useful for div, this avoids further
fragmentation of text, if the author needs for example a container
of non wrapping text as pre in XHTML inside a larger text
fragment. I think, without the textWrapOption for div the
author has to divide his text in three smilText elements to
get the same effect. But often this three fragments of text
belong together as one text inside one large text container.
---------------------
8.4.1
Example
typo?
"... as is shown in line 30'w ..."
-> what is the meaning of 'w?
'Finally, the text element on line 35 illustrates that it is
possible to mix in-line and external text in a single document.'
-> line 36?
------------------------------
8.5.1
textRate
-> Because luckily the textFontSize is given in
absolute or relative sizes, units like em, ex,
glyphs are much more useful for authors to guess
some useful rate as px, because the relation between
the size of a glyph and a pixel is not known by
the author.
To get something useful, we have to know, how
reading works, maybe we need something like
words per second to get an even more useful
guess for a textRate appropriate for a slow reader
as glyphs per second...
Maybe one has to ask some experts on psychology
or behaviour research or something like this to
get some information about a useful unit for
textRate concerning typical reading strategies and
rhythms including a hint for authors about a
useful value range for textRate for
accessibility reasons.
Looking for this at wikipedia something like
word fragments per second can be a useful
unit - a word fragment is either a complete
word if below say 10 glyphs or for longer
words a fragment of the word of about 7
glyphs.
A typical range would be around
2-5 word fragments per second for normal reading.
Because it is more difficult to read moving
text or specific fonts or sizes, this can
be used as a hint for authors for a maximum
value of a useful textRate.
This applies only to alpabetical scripts,
only in parts to syllabary or Scripts
using symbols. Maybe for them the approximation
withs glyphs per second is more useful...
Of course to get a smooth motion or a paced
change of text position, viewers might
transform the textRate again in an
average value in px per second, because the
viewer knows the size of a glyph in px and
can determine a presentational textRate similar
as this is done for font-size in CSS.
-> lines per second continuous or in jumps are
not very useful too, because the number of
glyphs or words in a line depend on the font
size and authors cannot guess some useful
rate in lines per second, except maybe for
poems with short stanzas and lines, in such a case
it maybe very useful to give information
about the rhythm of the poem with a textRate
in lines per second, else this normally will
reduce readability of the text...
-> for accessibility reasons there should be
a simple method for readers to manipulate
this textRate to their personal abilities in
each user agent, else such a feature is
more a method to torture readers...
(I really dislike such moving text sections
in movies in TV with tooooo tiny fonts and
toooo fast motion, one has to manipulate the
player and has to use a lens/magnifier to
separate the glyphs from noisy pixels ;o)