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

[CSSWG] Minutes Seoul F2F 2014-05-19 Part IV: Values and Units

From: Dael Jackson <daelcss@gmail.com>
Date: Sun, 8 Jun 2014 19:40:34 -0400
Message-ID: <CADhPm3sD7HofSOrOw84CC7tgCqcOXwpq+0nN3P4sM5bKfbGygQ@mail.gmail.com>
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

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