This document:Public document·View comments·Disposition of Comments·
Nearby:SYMM Working Group Other specs in this tool
Quick access to LC-1920 LC-1921 LC-1922 LC-1923 LC-1924 LC-1925 LC-1926 LC-1927 LC-1928 LC-1929 LC-1930 LC-1931 LC-1932 LC-1933 LC-1934 LC-1935 LC-1936 LC-1937 LC-1938 LC-1939 LC-1940 LC-1941 LC-1942 LC-1943 LC-1944 LC-1945 LC-1946 LC-1947
Previous: LC-1932 Next: LC-1923
Hello SYMM Working Group, just a few post-deadline questions, I'd like to ask: 1) If several external, internal timesheets are provided and the document contains for example some SMIL animation inside (like SVG) - how are the priorities? Similar to CSS priority rules/specifities? Priority by timing or in case of collisions the order in the source code of the host document? 2) I think, for details about the interaction with CSS for example something like the SMIL animation sandwich model is applicable as usual? 3) What about adopting animateTransform from SVG? Because many 'designers' seem to like to rotate, to distort content for decorative purposes, this might be a useful feature especially for timesheets to cover more of the stuff people might be interested in. I think, there were already some efforts from apple to integrate such feature into CSS, could be better covered by SMIL/SYMM of course... 4) Why no path-animation for animateMotion (SplineAnimation Module)? and could be useful to adopt keyPoints from SVG ... With only values-animation there are no really smooth paths available and some 'designer' might prefer the soft trajectories more than the hard edges of values-animations. 5) Because animate anyway animates any property or attribute, is animateColor really required for timesheets - if yes, why? 6) Now something like '<link href="timesheet.smil" rel="timesheet" type="application/smil+xml">' is allowed in the current draft for non-XML. This is pretty nice. Why not to add something like this for XML: <?xml-stylesheet href="timesheet.smil" type="application/smil+xml" title="timed styling" alternate="yes" ?> In both cases it is already defined by the type attribute, what the user-agent has to expect, therefore I cannot see a specific problem with this variant for XML and it avoids confusing messages from validators without the ability to validate multiple namespaces in one document.