W3C home > Mailing lists > Public > www-style@w3.org > June 2013

Re: [css3-fonts] @font-feature-values editorial

From: Sylvain Galineau <galineau@adobe.com>
Date: Wed, 5 Jun 2013 17:17:01 -0700
To: John Daggett <jdaggett@mozilla.com>, www-style list <www-style@w3.org>
Message-ID: <CDD52104.58EA%galineau@adobe.com>


On 6/5/13 2:46 PM, "John Daggett" <jdaggett@mozilla.com> wrote:

>
>Sylvain Galineau wrote:
>
>> >At a syntax level, or rather a Syntax level, they're at-rules, end of
>> >story.  There's no reason to distinguish them from "real" at-rules,
>> >because there's no such distinction - at-rules have all sorts of crazy
>> >rules for what can be put inside of them.
>> 
>> Right; they will be parsed and error handled as such. John does not
>> seem to think of them as such though. I'm not yet quite sure how the
>> difference matters for the user - more awkward CSSOM for at-rules? -
>> but if the downsides of treating them as at-rules do not justify an
>> alternative syntax then shouldn't they be at-rules?
>> 
>> Fwiw I doubt web developers will distinguish the two. (Most I've met
>> think of @font-face descriptors as properties and describe them that
>> way, fwiw)
>
>This sort of misconception is part of what motivates me to *not* want
>to call these @-rules.  Descriptors (or "properties") in @-rules are
>easily misconstrued with "normal" style properties.  The names of
>these descriptors are predefined and they can be used case
>insensitively (margin-top is the same as MARGIN-TOP).  Neither is
>true for feature value definitions which are a simple set of user-defined
>named value pairs with limited scope.
>
>My goal is simply to try to make the wording distinct and avoid equating
>them with other more general terms that follow a slightly different
>pattern,
>such as @-rule descriptor names.  I'm fine with whatever wording others
>think is needed to make the syntax handling rules match but I think it's
>important to use different wording to describe these.

That sounds fine generally speaking though I'm still not groking what this
 really means for implementations and web authors. Are you suggesting
browsers 
parse these differently than @-rules? That'd be rather confusing for
authors 
who run into different parsing failures for things behind a @ sign. Or are
they parsed like @-rules but you don't want a regular @-rule OM for them?

As for web authors, however harmful the misconception is, I'm not sure how
spec wording alone fixes it.

I don't mean to be slow; I'm really not getting what problem we're trying
to solve. But if a) you don't want these parsed as @-rules and b) you
don't 
want authors to think of them as @-rules I think it'll take more than spec
wording e.g. use something other than @ to prefix them? 

Received on Thursday, 6 June 2013 00:17:28 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:12 UTC