[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [cgmo-webcgm] Comments on Style attributes [1 of 2]
--
Stuart Galt
SGML Resource
Group
stuart.a.galt@boeing.com
(206) 544-3656
[...part 1 of 2...]
From: Lofton Henderson [mailto:lofton@rockynet.com]
Sent: Monday, October 08, 2007 1:03 PM
To: cgmo-webcgm@lists.oasis-open.org
Subject: Re: [cgmo-webcgm] Comments on Style attributes [1 of 2]
Benoit et al --
Thanks again to Benoit for his thoughtful input on the DOM Style Properties question.
Per earlier message, I agree with his sentiment that it is not necessary, and is potentially wasteful of vendor resources, to give access through DOM Style Properties to all CGM V3 attributes. For requirements like simulating flow, for which we have use cases, there is no need.
Exposing all attributes might have a potential benefit related to Accessibility, but ... personally, I'd prefer not to go there now. I think the TC should answer an initial question before trying to list which specific Style Properties should be supported.
QUESTION: Is our motivation to expose as DOM Style Attributes all of those CGM attributes (etc) that can sensibly be altered through DOM? Or do we want to expose a restricted subset which support articulated use cases?
If the latter, then so far (at Seattle and since then) I have heard use cases for better supporting flow simulation, in wire-like things (implying some more stroke properties) and in tube-like things (implying more of either fill or line properties).
Part 2 to follow,
-Lofton.
At 11:43 AM 10/4/2007 -0400, Bezaire, Benoit wrote:
Hi All,
Here is my feedback on the Style attributes document:
http://www.oasis-open.org/committees/download.php/25270/Attributes_Table.pdf
I can't speak for other implementers, but exposing all those attributes in a DOM interface or declarative animation is a lot of work. Why not try and narrow down the list? So far, I just don't see how a good number of the attributes help us achieve our list of requirements. I think some examples would help me a lot. Now this is just off the top of my head, but I think that a number of suggested animatable styles require a lot of development work (for our viewer). In the table below, I list my own preference:
Stuart's suggestion Benoit's suggestions Comments
Line Type Ok Could be used to show flow
Line Cap remove Isn't line type sufficient?
Line Join remove Isn't line type sufficient?
Line Type Continuation remove Isn't line type sufficient?
Line Type Initial Offset Ok Useful, but unclear, hard to implement.
Marker Type Ok Hard to implement
Marker Size Ok Hard to implement
Marker Colour Ok Hard to implement
Text Score Type remove? Is anyone implementing this? test case?
Interior Style Ok
Hatch Index Ok
Pattern Index Ok
Edge Type Ok Never understood diff between line and edge.
Edge Visibility remove Never understood diff between line and edge.
Edge Cap remove Isn't Edge Type sufficient?
Edge Join remove Isn't Edge Type sufficient?
Edge Type Continuation remove Isn't Edge Type sufficient?
Edge Type Initial Offset Ok unclear and hard to implement.
Fill Reference Point remove Isn't changing the pattern/hatch enough?
Just a note. In my own personal opinion; I think I would dedicated resources to transparency and animation along a path as oppose to the Style attributes.
Feedback would be appreciated.
Regards,
Benoit
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]