- From: Sebastian Zartner <sebastianzartner@gmail.com>
- Date: Fri, 14 Sep 2012 07:34:14 +0200
- To: John Daggett <jdaggett@mozilla.com>
- Cc: www-style list <www-style@w3.org>
> > 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