- From: Dael Jackson <daelcss@gmail.com>
- Date: Sun, 8 Jun 2014 19:40:34 -0400
- To: www-style@w3.org
Values and Units
----------------
- RESOLVED: Any new properties with a custom-ident, make them
positionally unambiguous.
- RESOLVED: We handle the list-style custom-ident in the fashion
of Animation.
- RESOLVED: Use [a? b?]! for the one+ in-order grammar
- RESOLVED: Publish an update of Values and Units
==== FULL MINUTES BELOW ======
Agenda: http://wiki.csswg.org/planning/seoul-2014#agenda
Scribe: dael
Values and Units
----------------
TabAtkins: How to handle custom identifiers.
fantasai: Didn't we say this was wording?
TabAtkins: No.
TabAtkins: Custom-idents are used in ways where they can't be
distinguished just from position.
TabAtkins: For example: animation-name or list-style-type.
TabAtkins: You can provide an animation-name “backwards” or you can
do a list-style called “inside”.
TabAtkins: How to handle those is something we want to establish
generally.
TabAtkins: There's three cases. Some where custom-idents are
completely separated.
TabAtkins: Examples are line names in grid shorthands.
TabAtkins: You can say for example 10px (foo) 20px (bar)
TabAtkins: The only rule is that they can't be global words.
TabAtkins: There's nothing else they can be ambiguous with.
TabAtkins: But if you do grid-row: span foo and that could be
potentially weird if you called “foo” “span”.
TabAtkins: grid-row: span span 2;
TabAtkins: This could be weird, but not ambiguous because there's
strict ordering.
TabAtkins: So because of positioning it's not technically ambiguous
<fantasai> [Tab edits s/foo/span/g to make the example more
illustrative]
TabAtkins: The harder case is @counter-style inside {...} and
later say list-style: inside url();
TabAtkins: What option does this mean?
TabAtkins: It's not ambiguous if you say list-style-type: inside;
TabAtkins: But shorthanding can move this into a property where
it's ambiguous.
TabAtkins: There's two options. We take the closure of all values
in the shorthands that the value may appear in and
disallow them.
TabAtkins: You could still use counter-style inside a counter
where it's ambiguous.
TabAtkins: The other option is to let it stay and have generic
handling rules. We have those and we could use those,
even though they're not great.
TabAtkins: I believe animation handling rules are: you look for a
keyword that matches all the names and if you can't
find one you use the last one.
dbaron: I think it matters what you've used values for. You can
say animation: backwards backwards.
dbaron: Or forwards backwards. I think it says that the first value,
since you don't have a direction, is a direction ('forwards').
And the second value, since you have a direction, is your
animation name ('backwards').
TabAtkins: In the related case of 'forwards infinite'...
dbaron: In that case forwards is direction and infinite is...??
TabAtkins: But wouldn't that be invalid?
dbaron: Maybe.
TabAtkins: I'm not sure what the spec requires.
dbaron: No, it doesn't. Maybe it should.
TabAtkins: It should. The property doesn't define anything without
a name.
dbaron: Well it's none.
astearns: It says if ambiguous you can't interpret as none.
* fantasai hopes we are consistent in the use of plurals for all
forwards and backwards in CSS
<hober> that would be awfully forward-looking of us, fantasai
<hober> forwards-looking, sorry
<fantasai> nope: http://www.w3.org/TR/css3-marquee/#the-marquee-direction
dbaron: [reads example 4] That's serialization
TabAtkins: If none of the list are animation names, that's fine.
dbaron: None is a value of animation-fill-mode.
dbaron: So you can have none in the animation name properties.
dbaron: Even better, none is the value of another value in
animation shorthand.
TabAtkins: And do we disambiguate that?
dbaron: I know what I would write...[reads spec]
dbaron: So it doesn't explain forwards backwards.
TabAtkins: So the animation: forwards backwards is weird.
TabAtkins: Animation in general is weird but I'm okay with it.
dbaron: I'm not crazy about it. It makes serialization hard.
TabAtkins: You always have to serialize animation name last.
TabAtkins: And that makes...
dbaron: You not only have to serialize last, but you have to
serialize anything that takes a keyword value of what your
animation is.
zcorpan: Doesn't font keyword have a similar issue?
TabAtkins: They have positional knowledge that makes it unambiguous
zcorpan: If you specify small-caps small-caps...
TabAtkins: You can't, it's invalid.
dbaron: I don't like the animation shorthand and maybe should have
pushed back more.
TabAtkins: I agree.
TabAtkins: I tried to push for a change and we couldn't.
hober: It was too late.
<SimonSapin> Was custom-ident just a bad idea?
dbaron: Animation and transition do the same with times.
dbaron: So 0s without units aren't valid times.
TabAtkins: Time and duration aren't ambiguous for transition.
TabAtkins: So with the clarification that animation: forwards
backwards should take the last.
TabAtkins: A property with a custom-ident will look to assign to
everything but the custom-ident first.
TabAtkins: Or, if the custom is required, it would take the last
value.
dbaron: The last rule could require a lot of look ahead.
dbaron: If animation-name was required and you see keywords you
might have the number in twice.
TabAtkins: Yes. Unlike in this case where it would work.
TabAtkins: Maybe we require that if a custom-ident is required it
must be disambiguated via position.
TabAtkins: I just want some rules here.
astearns: To be clear we're discussing this as option 2 where
option 1 is not allow those keywords as idents
TabAtkins: Yeah. In places where the closure of grammar would
create problems.
TabAtkins: I don't like it.
TabAtkins: Regardless of the option, there will be problems.
TabAtkins: If we take option 1 every time we add a value, it would
then become an error where previously it was valid.
TabAtkins: Option 2 could cause you to parse funky.
TabAtkins: Option 1 is take the closure of all the value keywords
that could show up and disallow them as custom idents
in that position.
TabAtkins: Option 2 is parse like animation-name and we make sure
it's well defined for corner cases
fantasai: Isn't that similar to list style for none?
TabAtkins: No. If it's none and a url it says it's a keyword, if
it's none and a style type, it says it's an image.
dbaron: So these examples can be parsed left to right and list=style
can't.
hober: Does option 1 require us to incompatibly change
animation-name?
TabAtkins: If we wanted to apply generically, yes. Obviously
that's not an option.
TabAtkins: If we go with this there's an animation exception.
TabAtkins: There's one more that I forgot to mention. Take the
closure. There's also disallow all keywords in given
context.
dbaron: So a problem with 1 is that it creates more compat risk
when adding keywords.
dbaron: In 2 we have a risk with the shorthand, but stuff that has
longhand is okay.
TabAtkins: There's also 1.5 that disallows in a given property
context.
TabAtkins: So if you try and do inside and there isn't a value you
get an empty string.
TabAtkins: In option 1 it's at risk. It's originally valid, but it
suddenly becomes invalid.
dbaron: We still have risk that shorthand will get parsed into new
properties.
dbaron: Some structures are less likely to trigger.
dbaron: If you fully spec we can do that last.
TabAtkins: We can add a long hand to the short hand that overlaps
the custom ident.
<fantasai> 1. Disallow keywords from closure of shorthands
<fantasai> 2. Disallow keywords in the individual current context
<fantasai> 3. Whatever 'animation' does
TabAtkins: I don't like #1. Option 2 is less bad, but means you
can't always serialize shorthands.
TabAtkins: Option 3 is weird but somewhat familiar from animation.
TabAtkins: A lot of changes won't have an effect.
hober: I prefer 3, but it's because it's under defined
hober: 1 and 2 are easy to explain but three is a little washy.
astearns: You said 3 was more familiar, but you can't define it
easily?
dbaron: 3 is you define as you find properties and leave custom to
the end. Your preference puts custom-idents last.
dbaron: As part of that you don't consider properties you've
already assigned to.
TabAtkins: That requires we adopt a rule that you never have a
required ambiguous custom-ident.
TabAtkins: If you have a requirement it must be positionally
unambiguous.
dbaron: In general having positioning requirement for complex
shorthands is good.
hober: Do we think option 3 can be explained in a way for spec
authors to follow?
TabAtkins: Yes. It's easy to say here's what you do. Writing
grammar is easier than parsing grammar.
TabAtkins: I'm happy to do 3.
TabAtkins: Once animation defines animate: forwards infinite;
correctly.
zcorpan: For new things isn't it better to require the order?
TabAtkins: Yes. That will be part of spec guidelines. Try and make
it positionally unambiguous.
zcorpan: So whatever we choose here, new things won't use this.
TabAtkins: Yes.
hober: Should we resolve on that first?
TabAtkins: Only time it'll happen is like when you retrofit.
TabAtkins: Whatever we decide shouldn't apply here.
TabAtkins: So. Proposed resolution: Any new properties with a
custom-ident, make them positionally unambiguous.
RESOLVED: Any new properties with a custom-ident, make them
positionally unambiguous.
<SimonSapin> Is that a "should" for new specs?
TabAtkins: Second thing is we handle the list-style custom-ident
in the fashion of animation.
TabAtkins: In general for any custom-idents that violate the
above, we use the animation style
fantasai: So what about the grid stuff?
TabAtkins: Grid is unambiguous
dbaron: And at the break you'll help me fix the animation spec?
TabAtkins: Yes.
TabAtkins: So for grid you can just put whatever you want except
global keywords.
fantasai: There may be other cases where we want to disallow.
TabAtkins: There are places you can disallow individual things.
TabAtkins: In general, the rule being there's nothing that's
auto-disallowed.
fantasai: From a spec prospective, you may want to figure out what
keywords you want.
fantasai: So we should have a note in custom values.
TabAtkins: Any obj to that resolution?
RESOLVED: We handle the list-style custom-ident in the fashion of
animation.
TabAtkins: That's the...ah yes. Order combinator
<astearns> http://lists.w3.org/Archives/Public/www-style/2014Apr/0230.html
TabAtkins: We have combinators for grammar for five of the six
common combinations.
TabAtkins: we have { zero+, one+, all+} x {in-order, any-order}
TabAtkins: So we can address these so there's a big question mark
that can't be addressed without grammar contortions.
<dbaron> (the question mark being one+, in-order)
TabAtkins: You can do a | a? b
TabAtkins: This is showing up in enough grammar that we should
have it. Background position, image function, it's
happening a lot.
TabAtkins: For now I propose it being a ?? b, but we can do
anything we want.
TabAtkins: So do people think we should add this or if we do what
combinator should this be?
zcorpan: I thought we concluded this couldn't work because of
combinator issues.
TabAtkins: Is there a better idea than ?? or any issue with adding
this to the grammar
jet: Is whitespace required?
TabAtkins: Yes.
hober: How common is this?
TabAtkins: It shows in several places and it is always weird to
read.
hober: Does anyone have this where we can borrow it from?
dbaron: I'm not crazy about having the thing in between.
The in-order ones use space separated stuff
TabAtkins: Another suggestion was [a? b?]!
dbaron: I think it's less crazy from reading view.
TabAtkins: So you like the symmetry of the in-orders?
hober: There's other cases that might have complex sub production
that needs to be non-empty.
TabAtkins: That is possible. I'm not sure we need it, but it's
possible.
<clilley> [a? b?]±
<liam> a b? | b might be clearer
TabAtkins: I want to express this somehow. I just don't know how.
TabAtkins: While we usually use white space, we do sometimes use
commas. It's verbose to use commas which is why we use
the # multiplier.
TabAtkins: Having a way to handle commas in these productions
would be nice, but I don't know how.
dbaron: It applies to all of them.
TabAtkins: Commas are easy for a b but hard for the rest
TabAtkins: If you're doing multiple of these it would be nice to
have a comma.
* dbaron thought it was all the ones in the first two columns, but
it's indeed 5 of the 6
zcorpan: Would it work to put the comma in the grammar for all and
say the comma must be there if left or right keywords are
there, elsewise you omit?
TabAtkins: I like that. I like simple, but I'm not sure where to
put the comma for all of them.
TabAtkins: I like that you need to comma if you need to
disambiguate, but elsewise leave it off.
zcorpan: Is there grammar that uses the comma for the space?
TabAtkins: I don't think there is in CSS
zcorpan: So we can add the comma thing.
TabAtkins: Yeah. We could have the comma just show up there and
deal with the any-orders later.
TabAtkins: I think you didn't like [a? b?]!, fantasai
fantasai: It doesn't seem like a multiplier.
TabAtkins: Well, it's not really.
plinss: It seems like the ? are redundant with []
TabAtkins: No, the [] are grouping not functional.
hober: So the [] are to group and the ! is to say it has to return
something?
TabAtkins: I'm okay with a form like [a? b?]!
fantasai: It seems like a lot of punctuation.
hober: It avoids the redundancy.
hober: It doesn't read to me that a or b are optional.
TabAtkins: Or that order matters.
hober: The grouping with the ! says that the order matters
TabAtkins: So add something in place of the ?.
TabAtkins: We're not bound by characters.
hober: Use the interrobang
<dbaron> ‽
TabAtkins: You'd have to use grouping.
hober: That does highlight the the existing syntax does matter.
TabAtkins: It says the quasi-optional things are quasi-optional in
the group.
* dbaron offers ¡ a? b? !
* jdaggett egads
* hober ¡important
* dbaron ¡important!
zcorpan: I don't like the ??
TabAtkins: Should we eliminate the ‽? I guess we should.
<dbaron> group eliminates a ?? b and eliminates a‽ b‽
<liam> sometimes a less expressive grammar is easier for people to
learn and use, even if it's sometimes cumbersome.
TabAtkins: So [a? b?]! ?
TabAtkins: The other alternative is a grouper besides square
brackets.
TabAtkins: We have the whole ascii space to work with.
TabAtkins: We could use <a? b?>
TabAtkins: So remaining brackets are {} << >>
hober: Why are we doing new groupers?
hober: Oh, I see the new grouper implies the bang.
dbaron: I'm happy with the square brackets and exclamation mark.
TabAtkins: So does anyone object to the exclamation mark?
shans: What happens if there are things in there without question
mark?
TabAtkins: It's required to be non-empty.
TabAtkins: So a?! = a.
fantasai: I guess we could do ?!
TabAtkins: If we do a single modified we need the grouping.
plinss: So how about ! instead of ?
TabAtkins: That's implicit grouping. So we'd have to do it as
a! b! || c, how to we sort that?
hober: You get it but it's harder to read.
TabAtkins: Here's a more ambiguous case: a! b! c d! e!
TabAtkins: The answer is that if you have something vaguely
ambiguous you need groupers
fantasai: So in that case is there a situation where you'd want
at least one of a b d and e?
fantasai: So you'd want a multiplier grouper.
hober: So are you talking about the case where a c is okay a d is
okay but a e isn't?
TabAtkins: She's saying where if you have this (above) just c is
no good, but one of the ! is required plus the
required c.
dbaron: It seems like it should be more important than not a !
fantasai: Idea: You take a character and within that level of
grouping you have to have at least one thing with that
character.
fantasai: So if you have multiple levels and you want to group it
would apply across the entire thing.
TabAtkins: And if a ! appears at least some of the !ed things
would be required.
fantasai: Instead of a grouping symbol, we need a symbol that says
this thing, at least one of the marked things, must
appear.
fantasai: I think interrobang would be better there.
hober: I suggested it because if you're using this in your syntax
it's already gone wrong. So in the case of [a? b?]! saying
the entire group must be non empty.
hober: We're not adding a feature that works inside of the group.
hober: So it's not a magical case where you need context to
understand.
TabAtkins: Right.
hober: Putting it on the group makes it clear it's for the whole
group.
* liam is lost as to why extra syntax is needed if the existing
grammar can express it and blames collective jetlag :)
glazou: Don't think of this (interrobang). We'll get questions.
fantasai: No one will type this.
dbaron: I agree that this feels too complicated.
TabAtkins: On the other hand you like having to interpret what
grammar means?
dbaron: I don't like action at a distance
hober: We suggested new groupers to limit characters, but this
adds even more characters.
plinss: That's because one is non-optional.
TabAtkins: I like the features, but I also like something simple.
TabAtkins: What I want is handling the simplest common case and
say anything fancier write it out.
<liam> [a? b?]! would be [a | b] yes?? or, [a+ b* | b+ ] instead?
<TabAtkins> liam, no, [a? b?]! === a | [ a? b ]
<TabAtkins> It's "a and/or b, in that order".
<liam> Maybe and/or would be a better symbol to add to the grammar
then.
TabAtkins: So it sounds like we could resolve on [a? b?]! for one+
in-order?
fantasai: I'm going to vote no and everyone else can vote yes.
hober: Can you live with it fantasai?
fantasai: I can live with it, but I'm unhappy with it.
fantasai: You lose an ability
TabAtkins: But you can always write in prose.
fantasai: I don't like the grouper has to match the multiplier etc.
fantasai: You have two levels of syntax to accomplish one thing.
astearns: The instance you wrote out doesn't have cases.
TabAtkins: That's true.
hober: Any objections?
fantasai: Where this shows up tends to be so complex, having one
less grouper would be good.
dbaron: But if the problem is too many groupers being explicit
would be better.
hober: The implicit grouping is just as cognitively complex as
this group.
fantasai: It's the same as a combinator and that doesn't add the
extra level.
RESOLVED: Use [a? b?]! for the one+ in-order grammar
TabAtkins: Related is zcorpan's comment about commas.
TabAtkins: So if I wanted a? b? you need to have the comma to
separate. If it's both you need the comma
dbaron: We can hyperlink the commas.
TabAtkins: We can do that.
TabAtkins: Sounds good. Can someone file an issue on bikeshed?
fantasai: The current template has the values.
TabAtkins: Yes.
plinss: So we can't use ,? because there's a patent on that (the ,
being in the space of the .)
* plinss http://worldwide.espacenet.com/publicationDetails/biblio?CC=WO&NR=9219458&KC=&FT=E&locale=en_EP
dbaron: I will file the bikeshed issue
TabAtkins: Anything else with values and units?
TabAtkins: Let's publish an update.
RESOLVED: Publish an update of Values and Units
TabAtkins: How long is the LC? 3 weeks?
clilley: We have to ask other chairs for opinions.
TabAtkins: Okay, are we fine with proposing three weeks?
Group: Yes.
[break = 10 minutes]
Received on Sunday, 8 June 2014 23:41:02 UTC