- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Fri, 08 Feb 2013 17:26:11 -0800
- To: "www-style@w3.org" <www-style@w3.org>
Case-sensitivity
----------------
- 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
handling.
- 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
Transitions
-----------
- 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 ======
Present:
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]
Case-sensitivity
----------------
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
idents.
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
mapping.
glenn: Are you saying that we should define the whole font-matching
algorithm?
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
dependent?
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
names.
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
are.
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
specifications.
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
ASCII-only
<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
bracket...
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
implementations.
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,
informatively.
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
expressivity.
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
[scheduling]
Transitions
-----------
<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
methods.
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
'opacity'
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
http://lists.w3.org/Archives/Public/www-style/2012Mar/0655.html
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
location?
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
http://www.china-embassy.org/eng/hzqz/zgqz/t84247.htm
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