W3C home > Mailing lists > Public > www-dom@w3.org > July to September 2000

Re: Expected behavior of CSSRule's setCssText.

From: Blaine Brodie <bbrodie@savagesoftware.com>
Date: Fri, 15 Sep 2000 16:08:36 -0700
Message-id: <fc.0085846d00011e573b9aca0023705192.11e5e@savagesoftware.com>
To: plh@w3.org
Cc: www-dom@w3.org
plh@w3.org writes:
>In that case, style.getPropertyCSSValue("ascent") will return null. The
>ascent 
>property can be only applied on the @font-face rule [1].
>Let me rewrite your example:
>fontfaceRule.setCssText("@font-face { ascent: 10 }");
>CSSValue fontfaceValue = fontfaceRule.getPropertyCSSValue("ascent");
>style.setCssText("@font-face {} "); /**** ascent property is removed
>eventhough
>                             a reference is outstanding ***/
>( (CSSPrimitiveValue)fontfaceValue).getFloatValue();
>
>Since the default value of the ascent font property is undefined,
>getFloatValue()
>will return INVALID_ACCESS_ERR. But I certainly don't recommend this kind
>of
>program
>since this depends on the CSS property. Some CSS properties can be a
>CSSValue
>or a CSSValue or a CSSValueList.
>Let's imagine a property "foo" with the following definition:
> inherit | <integer> | <ident>+
>
>Depending on the value, you'll cast the CSSValue in a different way.
>
>It becomes a nightmare if you invoke setCssText on the CSS*Value* after
>the cast.
>Some implementations can raise an INVALID_ACCESS_ERR, some others an
>invalid
>state exception, this depend on your implementation. I'm not sure we want
>to
>define
>these corners cases. It will add more constraints on the implementation
>of the
>interfaces and complexity in the spec for a bad practice.
>
>I recommend to change your program if you really want to do that as
>following:
>
>fontfaceRule.setCssText("@font-face { ascent: 10 }");
>CSSValue fontfaceValue = fontfaceRule.getPropertyCSSValue("ascent");
>style.setCssText("@font-face {} "); /**** ascent property is removed
>eventhough
>                             a reference is outstanding ***/
>if (fontfaceValue.getValueType() == CSS_PRIMITIVE_VALUE) {
>   // this raises an INVALID_ACCESS_ERR since it is really a
>CSSPrimitiveValue
>   ( (CSSPrimitiveValue)fontfaceValue).getFloatValue();
>}
Hello Philippe,

Thanks for the clarification.  One other question regarding expected
behavior of the setCssText method.  What is expected to occur when there
is an outstanding reference to a property value and then the property is
removed via the rule's setCssText method and then that property is added
back in via another call to the setCssText method.  Should the outstanding
reference be reenabled or will the reference remain in an invalid state
for the rest of its life?
Example:
	fontfaceRule.setCssText("@font-face { ascent: 10 }");  //property added
	CSSValue fontfaceValue = fontfaceRule.getPropertyCSSValue("ascent");
	fontfaceRule.setCssText("@font-face { }");  //property removed
	fontfaceRule.setCssText("@font-face { ascent: 10}");  //property re-added
	
Should 'fontfaceValue' become reactive after the last call?
---
Blaine
Received on Friday, 15 September 2000 19:08:47 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 22 June 2012 06:13:47 GMT