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

[CSSWG] Minutes Telecon 2014-04-02

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 2 Apr 2014 20:03:38 -0400
Message-ID: <CADhPm3t1C6A6fp3vBdS+7iN5iXxX=Yx8VBk4NGf5ux0sw8YZkg@mail.gmail.com>
To: www-style@w3.org
Publications requests

  - RESOLVED: FPWD for will-change.
  - RESOLVED: FPWD for CSS-scoping with the short name Scoping.

Follow up on Namespace

  - RESOLVED: Modification of the validity of an unknown prefix in
        selectors and insertion of namespace rules.

Follow up on subgrid

  - Fantasai expressed that she still believes moving subgrid to
        level 2 of grid would create accessibility issues that would
        be hard to rectify even after level 2 is released. TabAtkins
        stated that he still believes that the inclusion of subgrid
        in level 1 will cause too much of a delay to implement
        before shipping.
  - The discussion will continue on the mailing list with sylvaing
        recommending a focus on use-cases instead of general
        speculation on what adopters may or may not do.


  - RESOLVED: Use percentage values for key arguments and map
        from/to keywords to 0% and 100% respectively.
  - RESOLVED: Keytext on setting invalid value should throw an error.
  - The various other questions concerning keyframes all revolved
        around reaching consensus on how browsers implement the spec.
        Sylvaing will solicit feedback from the browsers to
        ascertain the best path to compatibility and then move to
        solve the other issues.


  - It was agreed that global keywords should be excluded as <custom-
        ident> values, but there still isn't a clear path on how to
        decide what other keywords should be excluded. Discussion
        will continue on the mailing list.

q unit

  - RESOLVED: Add q unit to Values and Units.


  Glenn Adams
  David Baron
  Bert Bos
  Dave Cramer
  Bruno de Oliveira Abinader
  Elika Etemad
  Sylvain Galineau
  Daniel Glazman
  Rebecca Hauck
  Koji Ishii
  Dael Jackson
  Brad Kemper
  Philippe Le Hégaret
  Peter Linss
  Anton Prowse
  Matt Rakow
  Simon Sapin
  Greg Whitworth
  Steve Zilles

  Tantek Çelik
  Edward O'Connor
  Simon Pieters
  Florian Rivoal
  Dirk Schulze,
  Alan Stearns
  Lea Verou

  scribenick: dael

  glazou: Let's start
  glazou: First thing, any extra items?

  SimonSapin: I'd like to talk about <custom-ident>
  glazou: Anything else?

Publications requests

  <glazou> http://tabatkins.github.io/specs/css-will-change/
  glazou: First is will-change

  TabAtkins: We talked about this at the last F2F. It hasn't been
             published, it's just on my github.
  TabAtkins: I'd like to publish it officially as a FPWD if possible.
  Glazou: Did you say ED or FPWD?
  TabAtkins: I'd prefer FP, but if I can't get that ED is fine, but
             I'd like to just publish if possible.

  glazou: What do people think?
  * fantasai defers to dbaron ;)
  Bert: I still think it's strange and wonder if there's better
        approaches, but no objection. It might help solve my issues.
  glazou: I still think it's weird, but I'm okay to publish. I'd
          like to have this in the charter and reviewed, plh an
  plh: We're reordering the list in the charter, but we can add this.

  glazou: Other opinions?
  glazou: Microsoft, what do you think?
  glazou: Ah, dbaron joined. We're discussing will-change from
  dbaron: I'm in favor.

  glazou: Other browser vendors?
  gregwhitworth: I'm not too keen, but go ahead and publish. Will-
                 change just tells the broswer what's coming, right?
  TabAtkins: Yes, it tells the browser a layer will change.
  gregwhitworth: Go ahead and publish and we can hash it out later.
  sylvaing: I think it's weird, but go ahead. People are doing
            things to activate the GPU and this is better than that.

  glazou: It seems we agree on FPWD, yes?
  SimonSapin: Just a question, what does it require?
  SimonSapin: Isn't it a hint, rather than dictating anything?
  TabAtkins: It'll sometimes create stacking, but any other action
             is UI's discretion and purely a hint.
  <sylvaing> It seems odd right now but is really no weirder than
             setting translateZ to force elements into their own
             layer on some browsers.
  <gregwhitworth> yeah

  glazou: Any objection?

  RESOLVED: FPWD for will-change

  action plh to add will-change to charter
  * trackbot is creating a new ACTION.
  <trackbot> Created ACTION-623 - Add will-change to charter [on
             Philippe Le Hégaret - due 2014-04-09].

  glazou: Next is scoping
  TabAtkins: Same deal, krit requested an extra week before FPWD so
             we can get extra comments, we haven't had any.
  fantasai: Is plh on the call?
  fantasai: plh can you approve css-scoping shortname?
  glazou: plh? He's probably away.
  plh: Yes. yes I can.
  fantasai: The goal is to publish tomorrow so I have to submit
            right away.
  glazou: We have nothing from krit and we left a week.

  RESOLVED: FPWD for CSS-scoping with the short name Scoping

Follow up on Namespace

  <glazou> http://lists.w3.org/Archives/Public/www-style/2014Mar/0502.html
  glazou: The thread www-style ended up discussing behavior of OM
          when we insert in a style sheet.
  glazou: I understand the comments about reparsing the whole thing.
          I would have considered that a mistake 10 years ago, but
          didn't detect it.
  glazou: I still think we can make an errata to allow name
          insertion because it'll be rare and won't impact rendering
          engine or webpages.
  glazou: I'd like to hear from other vendors and see if we can
          start an errata.

  TabAtkins: I agree. We can change to not throw away and changing
             namespace just makes it not normal.
  glazou: Others?
  SimonSapin: I think this is fine because we have selector fixed in
              OM anyway so probably need to start as text and that's
              easy to reparse.
  glazou: I'm not sure. Selector text is stored only in case of a
          rule you reserved and you're not reserving a rule if
          prefix is unknown.
  dbaron: So you're saying if prefix is unknown, rule stays.
  glazou: Rule stays but selects nothing.
  TabAtkins: That single type selector selects nothing, not the
             whole thing.
  TabAtkins: So you could use it in a not expression and it would
             become null?

  SimonSapin: Are you proposing rules with invalid selectors show up
              in the OM?
  glazou: Change the validity rule of selectors with unknown prefix.
          They're currently invalid, I say valid and selecting
  SimonSapin: Okay.

  TabAtkins: So will the whole selector match nothing, or just that
             simple type selector?
  glazou: The case where one thing invalidates a whole group is for
  TabAtkins: What I mean is this :not(unknown|foo)
  TabAtkins: That should match nothing, but does that mean the whole
             selector matching nothing, or the type selector matches
  glazou: It should be consistent. So :not should select everything.
  TabAtkins: That's fine, I just wanted to be clear

  ??: We just wanted it to be matches nothing at all.
  glazou: It seems there's agreement on what we want if we want
  glazou: Is there consensus about writing an errata, which I can do?
  glazou: Any objection?
  <sylvaing> no objection

  glazou: Then I will do it and we'll change the behavior of unknown
  TabAtkins: I can make the edits to selectors and name space if
  TabAtkins: Well, where ever it is.
  SimonSapin: I think it goes into selectors.
  glazou: Not only that.

  SimonSapin: Namespace should be invalid for other specs.
  SimonSapin: Namespace spec says...
  <SimonSapin> CSS qualified names can be used in (for example)
               selectors and property values as described in other
               modules. Those modules must define handling of
               namespace prefixes that have not been properly
               declared. Such handling should treat undeclared
               namespace prefixes as a parsing error that will cause
               the selector or declaration (etc.) to be considered
               invalid and, in CSS, ignored.
  SimonSapin: This bit talks about other specs and it has a should
              for the specs.
  glazou: This is a hole in all the specs and everything derives
          from a 14 year old spec. We'll have to modify in multiple
  SimonSapin: Okay with updating both.

  RESOLVED: Modification of the validity of an unknown prefix in
            selectors and insertion of namespace rules

  SimonSapin: You say insertion?
  glazou: They're currently throwing an exception if there's
          anything beyond insertion point?
  SimonSapin: So they're only allowed to insert where valid?
  glazou: Yes yes.
  glazou: We're not saying they're allowed anywhere
  * sylvaing wonders if there are other cases where we'd want
             selectors to stay valid and match nothing rather than
             dropping an entire rule

Follow up on subgrid

  glazou: Anything to say?
  TabAtkins: Is fantasai there?
  fantasai: Yes.
  glazou: And is she willing to discuss?
  fantasai: I maintain position as started before.
  glazou: So that was short.
  TabAtkins: We brought it up so we can resolve one way or another.
             Subgrid into level 1 or move to level 2
  fantasai: I'll object if we punt.

  SimonSapin: Does it make sense to mark as at-risk?
  fantasai: I'm not sure. It's accessibility, not something just
            nice to have.
  sylvaing: What do you mean accessibility?
  fantasai: Let's say you have a form with grid layout and in order
            to use it you remove structural elements to make a list,
            you've removed the structural stuff and now people can't
            understand without the grid.
  fantasai: That structure is gone and you had to remove it to use
  sylvaing: You don't need to do it for flex?
  fantasai: No. You may need extra spans and divs, but that's adding
            extra not removing.
  sylvaing: Yes, but that you need to alter your markup doesn't mean
            it doesn't have value.
  fantasai: If we ship as-is people will strip their markup because
            they want grid, not caring about it working for non-
            visual consumers.
  sylvaing: So you establish grid isn't super-cool, there's still
  fantasai: Even where you have something like a front-page, you'll
            still have problems. I have examples listed and they're
            common cases.
  <gregwhitworth> Can you link to the examples?
  <gregwhitworth> Of the accessibility problems?

  fantasai: This will be worse than what we have today.
  fantasai: Today with the layout hacks it's bad, but they don't
            strip things.
  sylvaing: I'm not sure stripping stuff is the only way.
  sylvaing: I've seem things added.

  TabAtkins: Point remains it's still complex and if we want to
             implement before shipping, it'll slow the feature.
  fantasai: But if you don't you'll have a whole class of webauthors
            learn without subgrid and they'll just keep doing it.
  TabAtkins: People will learn as time goes on and subgrid is easier
             so when it's there it'll be used.

  glazou: You guys are disagreeing and I don't think we'll solve it
          in the next 25 min.
  glazou: I suggest we go to e-mail and we move-on.
  sylvaing: I think we should stay on use-cases and the before and
            after. We shouldn't speculate on what people will do.
            Early adopters will adapt.
  sylvaing: If we fear people won't pick up a level 2 thing, we fear
            the benefits won't be obvious. Let's not speculate,
            let's look at use cases.

  glazou: Topics still left we have something from sylvaing on
          animations and one from SimonSapin.  Let's do animations.


  sylvaing: Let me pull them.
  <sylvaing> https://www.w3.org/Bugs/Public/show_bug.cgi?id=25107
  sylvaing: This should be the easier one.

  sylvaing: So this one is about the format of the string argument
            for findRule() and deleteRule()
  sylvaing: The spec said it's a number between 0 and 1, but that's
            only implemented in IE.
  sylvaing: Everyone else never did that. Gecko, webkit, and blink
            use percentage.
  sylvaing: That's consistent with how you write it and how it's in
            the OM so it's more usable.
  sylvaing: So I think we should change to Gecko approach. I think
            IE can keep it, but everyone should support percentages.

  glazou: What about keywords from and to?
  sylvaing: They work. I think they match their corresponding values
  glazou: I support the change.
  dbaron: In Gecko we use the same parsing that we do when they
           appears on the style sheet.

  sylvaing: So any concern from Microsoft?
  MaRakow: Sounds reasonable.
  sylvaing: Anyone using IE needs to patch in the numbers, so as
            long as you guys support both it'll work.
  sylvaing: I think you want to keep the old one and add support.

  RESOLVED: Use percentage values for key arguments and map from/to
            keywords to 0% and 100% respectively.

  sylvaing: That's one.
  sylvaing: Next one.
  <sylvaing> http://lists.w3.org/Archives/Public/www-style/2014Mar/0497.html

  sylvaing: This was also one of glazou's issues. Clarifies keyframe
            rules when they get keys.
  sylvaing: Spec says if multiple keyframe rules have same keyvalue
            the last one is accepted.
  sylvaing: In the e-mail what we expect from the prose and the
            browsers is what the text says.

  sylvaing: Gecko is doing interesting cascading in the rule. It's
            doing on a property basis.
  dbaron: I feel what Gecko is doing is correct. We discussed this a
          few years ago and maybe had a resolution.
  sylvaing: I tried to look, but don't remember. Can you elaborate?
  dbaron: It's hard for me to switch this into my head.
  TabAtkins: One example as to why it's better, if you're doing
             several loosely related animations and want to do all
             width at one point and all background at a different
             and they land on same keyframe, it's nice to keep
  sylvaing: If you want to change the width on the keyframe and you
            don't lose the rest, though.

  glazou: I understand the usecase, but we have problem with object
  glazou: When you find something from keyframe, you get one rule
  sylvaing: That's another issue. Some of your questions, you cannot
            expect the OM to give you everything. When you look at
            browser you get a bunch of text you edit.
  sylvaing: We can talk about that with findRule() question.
  glazou: I mentioned it since whatever you pick there is an OM
  sylvaing: Maybe, but there might be other reasons to change.
  sylvaing: So only Gecko does cascade thing right now. Sounds good
            to me, but it's a significant change and I'd like to
            hear from other vendors.
  TabAtkins: I can ask around about compatibility. I'm fine.
  glazou: Anyone from Apple on call? I'd like to hear from them.
  sylvaing: IE too.

  MaRakow: For the OM question, I'd like to think about that more.
  sylvaing: I'm less concerned about OM since there's so much compat
            issues. It's more that we're changing the concept so
            something may break. But there's a lot of breakage so we
            could talk to Firefox.
  glazou: Okay, so do you want an action to investigate?

  action sylvaing investigate the opinions of other browsers
  * trackbot is creating a new ACTION.
  <trackbot> Created ACTION-624 - Investigate the opinions of other
             browsers [on Sylvain Galineau - due 2014-04-09].

  sylvaing: I have one question for webkit and blink engines:
            everyone agrees about appendRule, but they still have
            insertRule for legacy reasons.
  sylvaing: If they can fix it, that's awesome.
  TabAtkins: I'll ask about compat.
  sylvaing: You could add append to the old one.
  TabAtkins: We can add. There's nothing wrong with that.
  sylvaing: It's more supporting both.

  <sylvaing> https://www.w3.org/Bugs/Public/show_bug.cgi?id=25035
  sylvaing: Next one.
  sylvaing: keytext property again. It's handling values in the spec.
  sylvaing: It's also not compat. You have keytext for the rule and
            when you put something invalid Gecko doesn't do anything,
  sylvaing: Blink and IE throw and do not update,
  sylvaing: Webkit just applies it.
  * TabAtkins Le sigh. I have no idea how the spec ended up so
              different from the WK/Blink impl, when they were the
              first impl and wrote the spec.

  sylvaing: So we have three possibilities and they're all out there.
  sylvaing: Honestly, I don't have a strong opinion. Webkit seems
            silly, but I understand it.
  glazou: I ended up doing the same test and from editor view I'd
          prefer throwing.
  dbaron: So this interacts with two issues back?
  glazou: Yes, you can set invalid and something existing.
  dbaron: So sylvaing's e-mail is about the invalid?
  sylvaing: Let's keep the issues separate. So bogus values first.
  sylvaing: What do we do if you put foobar as a keytext value?
  sylvaing: I'm okay with anything, but Gecko doing nothing seems
            the worst since you don't know what happens.
  dbaron: I didn't throw since the spec didn't say it, but it's a
          one line change.

  TabAtkins: Related, but should I make counterstyle rules throw?
  glazou: For consistency, yes.

  glazou: So does anyone object to throwing an error when keytext is
  sylvaing: That's the most common
  <dbaron> throwing sounds fine as long as you say what exception to
           throw :-)
  * TabAtkins SyntaxError, certainly?
  RESOLVED: Keytext on setting invalid value should throw an error

  sylvaing: Okay, now you set a keytext to a valid value that
            already exists in rule.
  sylvaing: What I've seen in browsers is that the rule is updated
            in place.
  sylvaing: Order is what's specified and not effected.
  sylvaing: I guess I want to know what we would do...It's easier if
            you're not on Gecko model and you're not cascading.
  glazou: I think we have to solve the older issue before that one.
  sylvaing: That okay. Sounds like a good F2F topic.
  sylvaing: Okay.

  glazou: Anything else on animations?
  sylvaing: Let me see
  sylvaing: One more.

  <sylvaing> https://www.w3.org/Bugs/Public/show_bug.cgi?id=25034
  sylvaing: This one about which rule gets found when you have
            duplicate keys.
  sylvaing: You have 3 20% rules, so which do you pick?
  sylvaing: No compat. IE removes the one than it applies
  sylvaing: Blink and Webkit do the first one first so they endup
  sylvaing: Gecko is complex from cascade.

  glazou: This also depends on order. We need a model before
          instructing the API.
  sylvaing: I have one more, but it'll also depend on the discussion.
  sylvaing: I'll start a new thread on the ML and ask for specific
            compat feedback from browsers


  <SimonSapin> http://lists.w3.org/Archives/Public/www-style/2014Mar/0582.html
  SimonSapin: A few weeks ago we discussed a change to the values in
              the spec.
  SimonSapin: We made a change and people disagreed on what the
              change should end up being.
  SimonSapin: This is about what keyword should be disallowed to be
  SimonSapin: Right now CSS-wide keywords are defaults for being
  SimonSapin: In addition anything that might be ambiguous is
  SimonSapin: After I discussed with fantasai we thought it might be
              good to have the same rule for all <custom-ident>.
  SimonSapin: It seems like we don't have consensus on what behavior
              should be.

  fantasai: Makes sense to exclude global keywords. For other cases
           such as gridlines where in the definition they're
           unambiguous. but in use they're ambiguous. I think the
           spec will have to call out explicitly
  fantasai: I don't think we can make a universal rule. If there's a
            more indirect connection between ambiguous and invalid
            such as with grid, I think that will need to say so
  fantasai: We may want a note in one spec that other specs should
            consider those for invalid values. One thing I'm not
            sure of is shorthands.
  fantasai: It could be one thing if it is unambiguous in longhand,
            but ambiguous in shorthand.
  TabAtkins: We can't do much generally anyway because we
             occasionally make longhands into a shorthand.
  TabAtkins: So if we make something that will automatically walk up
             the tree it might not work.
  TabAtkins: If you use it in longhand vs using it in shorthand,
             different values might be excluded.
  TabAtkins: It might be okay to define a counter style in one place
             but not somewhere since it conflicts with the keyword.

  fantasai: Alternatively, we could have a rule where the shorthand
            unless otherwise said you parse from start to end and
            try your best so you would prioritize keyword over
  fantasai: So style is found first and than we look at <custom-

  dbaron: There's a bunch with parsing issues like this that we've
  dbaron: One is list style shorthand where two properties take a
          none value.
  dbaron: So we have to allow two nones. If you're parsing you can't
          find a none and decide. You find a none, count the number,
          and see if you have more nones than unspecified properties
          that can take nones.
  dbaron: Similar for animations and transitions except worse.
  dbaron: Transition and animation accept arbitrary things and in
          Gecko we attempt to parse the other things first. Only if
          they haven't already been found.
  dbaron: I think you can see it in animation ease-in ease-in
  dbaron: The first is timing, second is name and that makes dynamic
          changes messy.
  dbaron: And I don't know how inter-operable that is; thought the
          list-style thing is inter-operable

  <sylvaing> What happens with new global keywords?
  TabAtkins: Do we just conclude exclude global keywords and discuss
             more about ambiguities on the list?
  glazou: I think that's a fair conclusion to the discussion.
  SimonSapin: If we can't come up with a general rule, we can decide
              about line names.
  TabAtkins: We can do that on the mailing list, that's fine.
  glazou: So we'll continue discussing this.
  glazou: Anything else on this SimonSapin?

q unit

  glazou: So we have 4 minutes. Anything to discuss?
  fantasai: The q unit?
  <fantasai> http://lists.w3.org/Archives/Public/www-style/2013Nov/0302.html
  fantasai: There's a proposal on the ML about adding a q unit since
            that's common in Japanese, but it didn't go anywhere.
  fantasai: Since we have to pass through LC for values and units,
            do we want to add it?
  sylvaing: I don't think there were any major objections except the
            usual suspects.
  fantasai: So any opinions? I can just add it in.
  TabAtkins: I'm fine with adding it.
  SimonSapin: I'm fine with adding.
  RESOLVED: Add q unit to Values and Units

  glazou: Okay. Anything else?
  <fantasai> http://dev.w3.org/csswg/css-values/issues-cr-2013
  fantasai: We should publish again for values once we resolve the
  glazou: I suggest we close for now. I'll miss the next call, but
          I'll talk to you next time.
Received on Thursday, 3 April 2014 00:04:06 UTC

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