comments: DOM Level2 19991210 (long)

Hi,

It's the 19th so here are some issues and comments with regard  to
implementing the DOM W3C Candidate Recommendation 10 December, 1999.
Apologies for the length of the post, but I wanted this material to be
archived. 

I've been working on the CSS and Stylesheets OMs. The issues are divided
into General, CSS and Stylesheets. In context, the OM  implementations are
concerned with accessing CSS, not with how end UA's display CSS. 

Happily there are no showstoppers that I've come across in either OM. A
number of the issues raised can be dealt with without adjusting the
interface signatures, but rather by clarifying the intended semantics and
behaviours of certain methods, in the draft and interface comments.
Anyway...


General.

issue gen-1: 
There should be a  more user friendly way for clients to determine whether a
CSSOM or Stylesheet object is read only other than forcing clients to guess
and then handle NO_MODIFICATION_ALLOWED_ERR. A cleaner, less brittle
approach is to allow a query to the objects using an isReadOnly() method
prior to attempting a write call, and this could be specified as a general
policy. 


Stylesheets.

issue stylesheets-1
Remove the value 'all' from MediaList. I've posted on this subject before
(http://lists.w3.org/Archives/Public/www-dom/1999OctDec/0249.html), with no
response (from this list or www-style). 
Again. The value 'all' is logically dubious, if not absurd. It seems
expedient to just eliminate 'all' from both the Stylesheets OM and the CSS
specs, and assume that any CSS/stylesheet rule that is not media targeted is
applicable to <any> available end-media that the client UA has available to
it. In implementation it requires mucking about with list members, and is
dependent on one's interpretation of the semantics of 'all'. 


CSS.

issue css-1:
In CSSRuleList.item() why not throw an exception (INDEX_SIZE_ERR), instead
of returning null? There is a method available to determine the number of
rules in the list, and thus no reason to accommodate erroneous clients in
this regard. 

issue css-2
DOMImplementationCSS.createCSSStyleSheet() accepts a string of media as its
argument, but does not specify that this list is comma delimited, whereas
the MediaList object that presumably stores this list insists on a comma
separated values. Specifying that createCSSStyleSheet() use a CSV string
avoids the inefficiency that the string be parsed and rebuilt before sending
it to the MediaList.

issue css-3
In CSSStyleSheet a new rule can inserted using insertRule() but there is no
corresponding insertion method available for CSSRuleList, which means you
can't use the CSSRuleList interface to delegate inside an implementation of
CSSStyleSheet, and thus decouple the implementations.

issue css-4
CSSMediaRule rule has a deleteRule() method (that applies to a RuleList
field), but there is no corresponding deletion method to order a RuleList to
delete a rule. This is essentially the same problem as described in issue
css-3.

issue css-5
CSSPageRule and CSSStyleRule have precisely the same method signatures. This
would imply refactoring to a common interface, or renaming the methods if
maintaining a logical mapping between interfaces and CSS rules is highly
desirable.

issue css-6
Can CSSStyleDeclaration.setText(String) be used to add new properties? The
method is not discussed in the draft. I think that it can, but a more
explicit description would help. 

issue css-7
CSSStyleDeclaration.setText(String) again. Is this method essentially an
iterated version of setProperty()? If so, while a result of the IDL, it's
unnecessary, since a client can simply iterate on setProperty(). Removing it
also avoids asking the CSSOM to perform an initial parse into separate
arguments for setProperty(). Taking things a little further, why specify how
this object stores its properties at all? That is, remove the attribute
cssText and turn this interface into a list.

issue css-8
The availability of a CSSProperty interface would be useful. CSSProperties
would be stored by a CSSStyleDeclaration styled as a list, which simplifies
the construction and adjustment of CSSStyleDeclaration greatly and eliminate
issues CSS-7 and css-8.

issue css-9
CSSPrimitiveValue has a convoluted way of setting its values when its a
Counter, RGB or Rect instance, essentially:
  XX.getRGBValue().getBlue().setFloat(float);
  XX.getRGBValue().getRed().setFloat(float);
  XX.getRGBValue().getGreen().setFloat(float);
What is the reason for this as opposed to supplying set methods for the
three complex instances?

issue css-10
CSSStyleDeclaration.removeProperty() returns the empty string if it has been
given an invalid CSS2 property. It seems preferable that an
exception(SYNTAX_ERR) is used to inform the client explicitly that it is
passing in junk.


Regards,

Bill

__________________________________________

    Bill de hOra    :    Cromwell Media    :    London

  bill@cromwellmedia.co.uk  :  +44 (0)20 8817 4039  
__________________________________________

Received on Wednesday, 19 January 2000 10:09:44 UTC