Re: [css3-fonts][cssom] proposal for revised definition of CSSFontFaceRule

> > For the sake of differentiating the @font-face descriptors from the
> > style rule properties are not the same and to avoid unnecessary
> > typing I suggest to remove "font" from the descriptor names. So
> > instead of "font-family", "font-style", "font-weight",
> > "font-stretch", "font-variant" and "font-feature-settings" we'll
> > just have "family", "style", "weight", "stretch", "variant" and
> > "feature-settings" inside @font-face.
>
> This is inconsistent with general usage -- the descriptors are named
> "font-weight", "font-family", "font-style", etc. so the properties
> should follow the existing pattern for style rules, i.e. "fontWeight",
> "fontFamily", "fontStyle", etc.  I think that consistency far outweighs
> the advantage of saving the typing of the 'font' prefix on these.
I am aware of that. That's why I suggested to keep "font-family",
"font-style", etc. as alias but primarily use "family", "style", etc.

> Aliases aren't zero-cost.
Why? I imagine the UA code not getting much longer and no performance
decrease (since "fontFamily" and "family" would internally call the
same function).

> I think 5 characters of prefix (or 4 in the OM) is insufficiently painful to worry about aliasing.
Well, this case is definitely not the only place aliasing (and
deprecating) existing properties/descriptors would make sense.

> > Also where's the "style" attribute? From the examples below all
> > descriptor attributes should be put in there. This raises the
> > question if we really need a "style" attribute (of type
> > CSSFontFaceDeclaration in accordance to CSSStyleRule ->
> > CSSStyleDeclaration) or if all descriptors should be put directly
> > into the CSSFontFaceRule as shown above.
>
> I'm proposing using a different interface here from the existing one,
> in effect dumping the old interface that used a 'style' property, the
> odd hybrid CSSStyleDeclaration/CSS2Properties amalgamation funkiness.
Right. That's why I pointed that out.

> We could put all the descriptors into a struct and but I'm not sure I
> see the advantage of that.  The examples would explicitly *not* work
> unless some form of .style.xxx aliasing was implemented.
Aliasing above would make sense, aliasing here IMO not. Again, there
should be a clear destinction between CSSStyleRules and
CSSFontFaceRules (i.e. @-rule definitions in general).

> > Because "font" in a CSSFontFaceRule != "font" in a CSSStyleRule, the
> > correct behavior is to ignore it.
Also I want to note that there is no shorthand "font" descriptor
defined. I believe OM attributes should always correspond to CSS
properties and descriptors. I.e. introduce a "font" descriptor or
remove the "font" attribute.

> Right, this example is simply showing the dangers of using the
> CSSStyleDeclaration as the container for font-face rule descriptors.
>
> > > Example 2: What should the code below do?
> > >
> > >     rule.style.fontFamily = "test1, test2";
> > Same reason as above, so ignore it. Will be even clearer that it's
> > not the same as a CSSStyleRule "fontFamily" when it's renamed to
> > "family".
>
> This *isn't* the same as example 1, it's trickier because the property
> *is* a font-face descriptor but the parsing rules are different for
> the descriptor compared to the property.
The difference between example 1 and 2 is that for the "fontFamily"
attribute there is a "font-family" descriptor while there is currently
no descriptor for the "font" attribute.
The parsing rules of both of them differ from the ones for
CSSStyleRules. And the different parsing rules are a clear sign that
the @font-face descriptor names should differ from the style
properties, as I mentioned above. Otherwise this will cause confusion.

Sebastian

Received on Friday, 14 September 2012 05:34:42 UTC