- From: Dr. Olaf Hoffmann <Dr.O.Hoffmann@gmx.de>
- Date: Mon, 6 Aug 2007 11:55:08 +0200
- To: www-smil@w3.org
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)
Received on Monday, 6 August 2007 10:03:34 UTC