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

[CSSWG] Minutes Tucson F2F Monday Morning 2013-02-04: Case-sensitivity, Transitions, Syntax, F2F Scheduling

From: fantasai <fantasai.lists@inkedblade.net>
Date: Fri, 08 Feb 2013 17:26:11 -0800
Message-ID: <5115A5B3.3030500@inkedblade.net>
To: "www-style@w3.org" <www-style@w3.org>

   - RESOLVED: User-defined things continue to be matched CS.
               CSS-defined things continue to be matched ASCII-CI,
               *even when* defined to exist through UA stylesheet
               rules or equivalent.

   - RESOLVED: Font-family names are matched Unicode CI against the
               font, using C+F casefolding rules with no normalization
               or locale-specific mappings.

   - We expect CSS-defined syntax to remain ASCII-only.

CSS3 Syntax

   - RESOLVED: Closing brackets in the wrong places are just invalid
               tokens in the context they're in; they don't get special

   - Discussed non-use of grammar productions in CSS3 Syntax,
     specifically potential concerns for:
       - inadvertent incompatibility with various parser architectures
       - understandability of spec to authors or others who want a
         high-level view of the general structure
       - connecting syntax defined by other modules into the CSS syntax


   - RESOLVED: Defer keypath syntax to next level of Transitions

   - RESOLVED: No slash in transition shorthand

   - RESOLVED: Do whatever we did for Animations for Transitions wrt
               init*Event methods.

   - RESOLVED: Computed interpolated value of repeatable lists is
               least common multiple of the interpolated lists' lengths.

   - RESOLVED: Use rounding rather than flooring for interpolating integers.

F2F Scheduling

   - RESOLVED: Meet at TPAC, possibly TPAC-adjacent.

   - RESOLVED: Summer meeting in Europe week of 9th September.
               Tentatively scheduled for Mozilla in Paris, other options
               on the table.

====== Full minutes below ======

   Glenn Adams
   Rossen Atanassov
   Tab Atkins (departed Wednesday mid-Morning)
   Bert Bos
   David Baron
   Tantek Çelik
   John Daggett
   Elika Etemad
   Simon Fraser
   Daniel Glazman
   Molly Holzschlag
   Koji Ishii
   Taichi Kawabata (NTT)
   Peter Linss
   Simon Sapin
   Kazutaka Yamamoto (NTT)
   Steve Zilles (arrived Monday mid-morning)

[discussing agenda]

Scribe: TabAtkins

   jdaggett: I think we had a rough consensus on the mailing list, but
             Tab didn't agree with it.
   TabAtkins: I'm okay with the consensus now.
   jdaggett: the specific issue in question is the case-sensitivity of
             user identifiers.
   jdaggett: They show up in counter names, @font-feature-values, etc.
   jdaggett: Of those, the counter styles spec is the one that's the
             stickiest situation, because you have a mix of predefined
             (CSS-defined) and user-defined counter styles.
   jdaggett: Depending on the CS matching rules, the two groups might
             match differently.
   jdaggett: We got a recommendation from i18nWG that CS matching made sense.
   jdaggett: But if we're really set of doing a form of CI, we should do
             the Unicode-aware type that they describe.
   jdaggett: One caveat - if we're matching keywords, we're generally using
             ASCII CI, so only alphabetic characters.
   jdaggett: Otherwise there are weird cases, like the Kelvin character
             matching "k".
   jdaggett: So I think we should follow i18n's recommendation: use CS
             matching for user idents, and ASCII CI matching for CSS-defined

   jdaggett: Only difference is font-family matching - if I put "arial",
             it'll match the "Arial" font.
   glenn: I think you mean that the platform has a font-name matching algo
          that was unspecified, and it looks to be CI in some cases.
   jdaggett: Let me put it more clearly - browsers match fonts CI.  But
             they can have localized names.
   jdaggett: And so for font names specifically, I think we should use
             Unicode-aware CI matching.  We can't rely on the platform's
   glenn: Are you saying that we should define the whole font-matching
   jdaggett: It's a name.
   glenn: Right now, how the name maps to the font has been platform-specific,
          and under the covers.
   glenn: I'm wondering if what you're suggesting is biting off a larger
          problem than we can solve here.
   jdaggett: I think you're getting at that font name-matching is platform
   jdaggett: Right now it's not - it's CI, with an edge case for localized names.
   glenn: What I mean is that they're unspecified - if they have similar
          behavior, it's due to reverse engineering, not a spec.
   jdaggett: CSS3 Fonts has a specific line that says you must match against
             the localized name.  But until now it used the locale of the OS,
             which introduced inconsistencies.
   jdaggett: We need to clarify what the CI matching rules are for font-family
             names, where font-family names on a platform can include localized
   glenn: Where's the font matching rules?  2.1?
   jdaggett: Fonts 3.2.1 just says "case insensitive".

   jdaggett: So are people okay with this?
   [general agreement]
   plinss: Aren't counter names CI?
   jdaggett: No, CS on all browsers.
   fantasai: It's counter *styles* that are the issue - currently they're
             all CSS-defined, but we're going to be adding user-defined ones.
   fantasai: So anything in the former set is going to have to be case-folded
             into ASCII lowercase.
   jdaggett: So when we're matching CSS-defined things, it's ASCII CI.
             When we're matching user idents, it's CS.
   <fantasai> It's not just that we're adding user-defined ones, we're
              redefining the CSS-defined keywords to be stylesheet-defined
              keywords, as @-rules in the UA style sheet.
   <fantasai> That is why this issue exists; otherwise we'd have only the
              same considerations as counter-reset

   jdaggett: When matching font-family names, it looks like we have to specify
             Unicode caseless matching.  The parameters are that we use the
             C+F casing rules.
   jdaggett: No normalization, no tailoring.
   TabAtkins: And that's what the i18nWG recommended.
   glenn: We should word it so that it's extensible.
   glenn: So that we don't lock ourselves in later.
   TabAtkins: We can override ourselves later if necessary.  We can just
              be clear with a general rule now.
   jdaggett: We need to make it clear to developers that special exceptions
             for Turkish or Greek aren't a part of this.  That's important.
   TabAtkins: So font-face matching rules are more complicated due to legacy?
   [missed minutes: it's due to existing platform conventions]
   fantasai: I'm curious why we're using C+F rather than C+S.
   TabAtkins: That's what i18nWG said to do.

   Bert: I'm not sure I like matching two different ways.  We should be
         case-insensitive everywhere.
   TabAtkins: You can't.  CSS already has a mix of CI and CS.
   <glazou> that sounds soooooo 1997...
   jdaggett: The general rule on the platform right now is that anything
             the author creates (class names, ids, counter names, etc.)
             are CS.
   tantek: That matches all other modern languages.
   RESOLVED: User-defined things are matched CS.
             CSS-defined things are matched ASCII CI, even when defined to
             exist through UA stylesheet rules or equivalent.
             Font-family names, for "legacy" reasons, are matched Unicode CI
             (C+F casing rules, per i18n recommendation).

   [discussion about variables]
   <dbaron> discussion that in 'var-foo', the "var" is CI and the "foo" is CS

   molly: [question about class names being CS]

   fantasai: There's an issue about CSSOM serialization. The APIs return
             the lowercase form.  That should be clearly specified.
   fantasai: The interesting thing about counter styles is that if you do
             @counter-style for a predefined name, it will be matched
             ASCII CI; but otherwise CS.

   [more kvetching about what "unicode case folding" means]

   jdaggett: The resolution also needs to say there's no normalization and
             no language-specific tailorings
   RESOLVED: (appending to the previous resolution) Font matching is done
              without normalization, without language-specific tailorings.
   Bert: Is font-matching up for us to define? Is it for the system?
   jdaggett: it's possible to say it's for the UA, but...
   jdaggett: Nobody implements a caseless matching that you can point at
             specified anywhere.  They're all ad-hoc.
   jdaggett: HTML5 has one case where they say "use this type of caseless
             matching, for legacy reasons". They're basing it off of unicode,
             but the way they're doing it (based on how IE matches radio
             group names) has oddities regarding diacritics.
   * Ms2ger notes that it's not actually clear if that unicode caseless
            match is required
   Bert: I have a problem font-matching sometimes, but it's about which
         font name the browser is using.
   jdaggett: I think that's a Windows-specific issue that'll be less of a
             problem going forward.

   [Bert has concerns about Unicode-range keywords being matched ASCII-CI]
   Bert: I want to ensure that we don't have any cases in the spec where
         some letters in a word are case-insensitively matched, but others
   Bert: I don't like the word "ASCII case-insensitive".  That word should die.
   Bert: The words "ASCII case-insensitive" should never appear in ou
   jdaggett: If you say "it's matched as unicode case-insensitive, but we'll
             only use ASCII chars for our idents", that is *actually different*.
   fantasai: Unicode case-folding maps characters outside the ASCII range
             into the ASCII range.
   <fantasai> http://www.w3.org/TR/CSS21/syndata.html#characters
   <fantasai> "All CSS syntax is case-insensitive within the ASCII range
               (i.e., [a-z] and [A-Z] are equivalent)"
   * fantasai proposes we resolve that CSS will not introduce keywords that
              include bicameral letters outside the ASCII range, to satisfy
              Bert's concern about future caseless keyword matchings
   Peter: There's no point in the CSS WG resolving that the CSS WG can't
          do something in the future, since we can just change that
          resolution in the future.
   Bert: I just don't want us to suggest that sometimes in the future
         we'll have a CSS-defined thing with unicode letters.
   jdaggett: HTML has actually gone through and extinguished a lot of places
             that were ASCII CI.
   jdaggett: New things, and old things they could get away with, are all
             CS now.  That's a wonder.
   jdaggett: What we're doing today, what we're resolving on, is compatible
             with what they're doing.
   Bert: I just want to make sure that nobody ever considers that in the
         future, if we introduce an ident that has Unicode chars, it's
         still done ASCII CI.
   <fantasai> Proposed resolution: CSS-defined identifiers will always be
   <dbaron> "Proposed resolution: The current intent of the working group
             is that future CSS identifiers will be ASCII-only" ?
   * tantek aggress with both fantasai and dbaron
   <dbaron> I'm fine with dropping the issue too, but I'd rather either
            resolve or not resolve, and move on.
   glazou: We shouldn't make resolutions against future things.

   <Bert> (There are two intentions that merit being recorded: properties
          are case-insensitive and properties are expected to be ASCII-only.)

CSS3 Syntax
Scribe: fantasai

   <SimonSapin> http://lists.w3.org/Archives/Public/www-style/2013Feb/0040.html
   TabAtkins: Simon raised an objection to this on the mailing list
   TabAtkins: Syntax spec has slighly different handling of syntax errors
              depending on where they occur
   <SimonSapin> @media ], all {…}
   TabAtkins: This type of syntax error, where there is an unmatched square
   TabAtkins: The way I have it written already, syntax throws out the block
              entirely immediately
   TabAtkins: Other types of syntax errors continue, and then @media (e.g.)
              would do its own error-handling
   TabAtkins: In this case, the entire rule would be dropped because syntax
              catches it as a generic syntax error
   TabAtkins: A different type of error, e.g @media foo, all { ... }
   TabAtkins: Syntax considers it valid, and @media will drop that part of
              the media query

   dbaron: Why are there two layers of processing?
   TabAtkins: Not necessary, but seemed to make sense to me
   TabAtkins: Just seemed like a good idea
   fantasai: In CSS2.1, we consider something like this to just be an invalid
             token in the context it appears.
   dbaron: Agree with fantasai. Would rather not do the multi-level thing.
   TabAtkins: Wanted to do that because a } in a top-level rule would show
              up that way
   TabAtkins: Whereas in a nested rule would close the outer rule. It has
              different behavior there
   fantasai: That's the way it works currently, no? Shouldn't it just continue
             to do that then.
   dbaron: Even with this change, the behavior is still dramatically different
   dbaron: You start up in different places
   TabAtkins: The consistency is that you drop the entire rule both times
   dbaron: Don't think it's worth adding an extra layer of validation for this.
   RESOLVED: Closing brackets in the wrong places are just invalid tokens
             in the context they're in; they don't get special handling.

   Glenn: Given history of flex etc...
   Glenn: WebKit still uses Bison for parsing
   Glenn: Want to make sure that whatever behavior we prescribe can be
          represented in Bison
   TabAtkins: Several things I'm trying to resolve in this area didn't match
              CSS2.1 grammar
   SimonSapin: Another option, instead of having various kinds of invalid
               tokens, just have one
   Discussion of handling closing brackets at parsing vs. scanner
   TabAtkins: Simon is suggesting we spit out "invalid token" token
   dbaron: You're proposing an intermediate stage?
   SimonSapin [ explains this ]
   SimonSapin: Component values are similar to tokens.
   dbaron: I'll need to read it again to remember what's going on.
   <TabAtkins> component values are tokens, except functions and blocks
               are put together.

   Bert: In general, when you're parsing, assuming a top-down LTR parser,
         you encounter a symbol you don't expect, e.g. closing square
         bracket, you can do 2 things
   Bert: You have to get back to continue parsing
   Bert: You can start inserting symbols until your invalid token is valid,
         e.g. inserting curly brace, opening square bracket, then closing
         square bracket becomes valid. Then throw it away b/c not valid
   Bert: Alternatively you start throwing things away until you find
         something that is valid.
   Bert: Which of those two methods you use are kindof hard to define
         because depends on which parser you're using.
   Bert: if you're using Bison-generated parsing, it has a built-in way of
         deciding between throwing away vs. inserting
   Bert: So, do you want to specify all that in detail, which makes it hard
         to use certain kinds of parsers?
   TabAtkins: I would like to specify in sufficient detail that the
              author-visible behavior is defined.
   TabAtkins: Other than that, can do anything. Just have to produce the
              same output.
   Bert: I'm afraid we're specifying too much, so locking out certain
   TabAtkins: I'm much more concerned with making sure authors have
              consistent behavior
   Bert: Somewhat concerned that we don't report CSS errors to the author
   TabAtkins: Reported to the console
   Bert: If you're treating parens different from other invalid tokens,
         that makes me uncomfortable.
   TabAtkins: Just resolved not to.

   TabAtkins: One more questions. What do I need to do to make people
              sufficiently happy that we can publish WD and start referencing
              this draft elsewhere?
   dbaron: I would like a chance to review it in sufficient detail when
           it's not changing constantly
   TabAtkins: I approach asymptotic stability.
   fantasai: I think once SimonSapin has verified that it matches his
             understanding of CSS2.1 and Kozea's implementation, then it's
             probably stable enough for dbaron to review
   fantasai: At which point it will probably become less stable again :)
   SimonSapin: I think the only remaining issues are in the an+b notation

   Bert: but there's no grammar!
   TabAtkins: CSS2.1's grammar was incomplete. It didn't specify handling
              of every byte stream.
   Bert: Grammar is much easier to see what the language looks like.
   TabAtkins: We can provide any possible byte stream as a style sheet:
              should get consistent results out of implementations.
   SimonSapin: We should define error recovery.

   fantasai: I think it's a valid concern to want a grammar that shows what
             the valid syntax look like, just to help people grok the language.
   <TabAtkins> For grokkability, I have token diagrams: http://dev.w3.org/csswg/css3-syntax/#token-diagrams
   TabAtkins: The tree structure is described as well.
   TabAtkins: CSS tree is quite trivial. Think spec handles grokkability
              from author's perspective.
   TabAtkins: I can provide railroad diagrams for parser constructions
   Bert: It's nice, but not copy-pasteable.
   TabAtkins: Grammar in CSS2.1 doesn't handle error-handling. Making it
              do so would make it unreadable.
   fantasai: Totally agree that having a grammar that tries to handle
             error-recovery would be unusuable.
   fantasai: Might be nice to have a grammar that defines only what is valid,

   Bert: If someone is writing a module, and adding syntax e.g. media queries
   TabAtkins: Plan is to switch those from using token-based grammar to use
              the property grammar syntax
   TabAtkins: This lets you omit spacing details, etc. and has greater
   TabAtkins: Going to define grammar productions here to make that easier.
   TabAtkins: Would show e.g. how to do @supports rule using property grammar
   TabAtkins: This way don't have to worry about getting spacing issues
              correct: all taken care of by property grammar.
   fantasai: For @supports, we require spaces around the 'and' and 'or';
             we might not have noticed that issue if we were writing it
             at a property grammar level.
   [ some meta conversation ]
   TabAtkins: My plan is to move towards using the property grammar.
   TabAtkins: This means that some details of those valid grammars would change.
   dbaron: Or we can find a way to represent that.
   SimonSapin: Just have a way to write in the property grammar for @supports
               that whitespace is required at a certain point.
   TabAtkins: ok, that works
   TabAtkins: Ok, so syntax is blocked waiting for dbaron's review, and I
              need to figure out upgrading grammars
   Bert is still parsing Tab's sentence
   smfr: Your railroad diagrams have abbreviations that are not described
         in the spec

[discussion of what to discuss next; a lot of topics are required on
  later days for various reasons]
[contemplating some animations issues]
dbaron: Part of the problem is that nobody understands what WebKit does.
smfr: Webkit just does animations last
dbaron: But we resolved we wanted other htings last
dbaron: Worth scheduling this as a separate item.
dbaron: Have a bunch of transitions things we could go through before lunch


   <dbaron> http://lists.w3.org/Archives/Public/www-style/2013Feb/0124.html
   dbaron: Email I just pasted is list of the 9 issues currently listed
           in spec and what I think we should do with them.
   dbaron: For issue one, keypath syntax, propose to defer
   RESOLVED: Defer keypath syntax to next level of Transitions

   dbaron: Next is proposal wrt transition shorthand, using a slash to
           separate duration and delay
   dbaron: Might have been nice, but seems too late for that
   plinss: What would the slash buy you?
   fantasai: I think we only use slash where it's needed for disambiguation
   fantasai: Seems like both it's not needed, and too late. So answer is no.
   plinss: Is serialization order specified to be the less confusing one?
   Serialization is not specified.
   RESOLVED: No slash in transition shorthand

   dbaron: Issue 3 is waiting for Tab to write a JS simulation.

   dbaron: Issue 4 is wrt new events having init*Event methods.
   dbaron: I think we resolved this for Animations, propose to copy whatever
           we resolved there.
   TabAtkins: Define a constructor instead. Just copy-paste Animations.
   RESOLVED: Do whatever we did for Animations for Transitions wrt init*Event
   dbaron: This causes issue 5 to magically disappear.

   dbaron: Fun next set of issues is 6 & 7
   dbaron: Thought we had resolved these, but couldn't find any record of it.
   dbaron: Rounding vs. flooring of integer animations.
   dbaron: We had a discussion in March, where we created the issues.
           Thought we discussed at TPAC, but couldn't find in minutes
   [various thought we resolved on rounding]
   TabAtkins: Required to match up with non-animatable properties, which
              flip over halfway , no?

   dbaron: let's come back to this
   dbaron: Issues wrt long list of properties.
   dbaron: I propose making these list to be properties in CSS2.0, plus
   dbaron: maybe not marker-offset
   dbaron: And push everything else to the various modules
   dbaron: This will require edits to multi-col and UI
   dbaron: css3-background already has this info
   dbaron: And require edits to Fonts
   jdaggett: Just tell me what you think needs to happen
   [discussion of process/publication]
   RESOLVED: Do that.

   dbaron: Other issue I think we can resolve straightforwardly is proposal
           I sent to list for transitions with multiple backgrounds
   <dbaron> http://lists.w3.org/Archives/Public/www-style/2013Feb/0129.html
   dbaron: If the list lengths mismatch for the various background properties,
           we use the length from background-image.
   dbaron: And we either truncate or repeat the values in other lists
   dbaron: There were authors who were upset when lists of different lengths
           for no-image properties prevented an animation
   dbaron: Right now have definition of animating lists, where lists must
           match in length.
   dbaron: Propose adding a second concept of repeateable list, which is a
           list that can be repeated arbitrarily without change in semantics
   dbaron: Useful in some cases, like background properties, and 'stroke-array'
   dbaron: The interpolated value is the least common multiple of the other
           two list lengths.
   dbaron: This is how you smoothly interpolate between them.
   dbaron: Animating background-origin, don't know how many images you have.
           No matter how many images you have, this rule always works.
   * fantasai thinks this makes sense
   dbaron: Truncation of these lists happen after computed value.
   [dbaron explains why you need least common multiple, rather than max;
    deriving this is left as an exercise to the reader]
    * sylvaing hopes authors don't need to figure out least common multiples
               to understand how something works...

   glazou: This is to avoid figuring out how many images you have?
   dbaron: Some weird cases, e.g. if you inherit to child
   glazou: So if you have 2 bg images, but 3-4 origins. It's truncated,
           but in the style sheet
   glazou: It's worth the extra work?
   dbaron: Yes, and relatively general rule that works for a whole bunch
           of things
   TabAtkins: There are cases where you have a repeatable list where there
              is not a master list
   TabAtkins: If you're inheriting the value, you can't do an early truncation.
   dbaron: The normal cases here are going to be lists of the same length,
           or a single value animating to a list.
   dbaron: The 2 vs. 3 case is going to be very unusual
   dbaron: So in almost all cases, wouldn't increase size of list.
   [dbaron gives an example of interpolating two lists and why this behavior
           is needed]
   <TabAtkins> @keyframes foo { from { background-position: 0px, 2px; }
                                  to { background-position: 10px, 20px, 30px; } }
   <TabAtkins> computed value of background-position during the animation
               is a six-element list, animating between
                 " 0px,  2px,  0px,  2px,  0px,  2px" and
                 "10px, 20px, 30px, 10px, 20px, 30px"
   RESOLVED: Do what dbaron says.
   smfr: Would be nice if spec gave justification for why it is this way,
         e.g. showing inherit case.

   <dbaron> http://lists.w3.org/Archives/Public/www-style/2013Feb/0129.html
   dbaron: Should we try to go back to floor vs. round stuff?
   dbaron: We all think we resolved it before. What do we all think we
           resolved it to?
   Bert, Tab: switched from floor to round
   RESOLVED: Round rather than floor for interpolating integers

   dbaron: That leaves cascading (action on Dean) and reversing (action on Tab)
   dbaron: Other things are deferring to other specs
   dbaron: Though there are a few more issues I need to go through
   <dino> I never did my action on cascading. But Simon could talk to it
          now if he wanted to.
   <fantasai> Nope, you don't get off the hook! We're switching topics so
              you have time to do it :D

F2F scheduling

   dbaron: discuss TPAC first
   <dbaron> TPAC in mid/late November in Shenzhen, China
   Discussion of problems with Shenzhen
   Concerns about price, visa, hacking,  attendance, network connectivity
   szilles: AB queried group chairs wrt attendance, and seemed like attendance
            wouldn't suffer
   jdaggett: Behind Great Firewall. Randomly things won't work.
   Rossen: Is there an alternative?
   dbaron: Other option is to not meet at TPAC, schedule a normal other meeting
   plinss: I'm personally going there whether or not we do
   glazou: If we go to TPAC, that's 2 meetings in Asia this year.
   jdaggett: Are there people who would attend / not attend depending on
   Bert: Not sure I can travel twice.
   plinss: Anyone who *will not* go to TPAC due to location?
   glazou: not sure yet
   tantek: me,  on principle
   tantek: NYT hacking stuff unacceptable
   <dbaron> Chinese visa prices are
   fantasai: Could meet in Hong Kong, then people going to TPAC could get
             a single flight
   Bert: 1.5hrs between them
   Option A: Go to TPAC
   Option B: Meet in Hong Kong right before TPAC
   RESOLVED: Meet at TPAC, possibly TPAC-adjacent.

   Discussing summer meeting
   <dbaron> discussion of September 9-10-11
   <dbaron> (or later???)
   possibly at the Mozilla Paris office
   possibly at Sophia-Antipolis
   TabAtkins: Google might be able to host in Paris, Zurich, Brussels
     September 2013
   Su Mo Tu We Th Fr Sa
   1  2  3  4  5  6  7
   8  9 10 11 12 13 14
   15 16 17 18 19 20 21
   22 23 24 25 26 27 28
   29 30
   RESOLVED: Summer meeting in Europe week of 9th September
   Tentatively schedule for Mozilla in Paris, other options on the table

<br type="lunch">
Received on Saturday, 9 February 2013 01:26:40 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:26 UTC