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

[CSSWG] Minutes Telecon 2014-03-12

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 12 Mar 2014 20:33:10 -0400
Message-ID: <CADhPm3uAEO2NFLoW=J+Lqk2ZGno7j4J4QYJC66mv5KgVO0RLmA@mail.gmail.com>
To: www-style@w3.org
Shapes to CR
------------

  - RESOLVED: Take Shapes to CR

Namespaces update
-----------------

  - RESOLVED: Update namespaces spec

Writing modes: Rename extent/measure to block-size/inline-size?
---------------------------------------------------------------

  - RESOLVED: Rename measure and extent to inline-something and
        block-something with something TBD ASAP.
  - SimonSapin will lead the conversation on the mailing list to
        decide what word will replace something.

Lists WD
--------

  - RESOLVED: Publish a new WD of Lists

Shadow Styling
--------------

  - TabAtkins brought his proposal to the group to resolve the
        discrepancy between using combinators and using pseudo
        classes in Shadow DOM by creating redundancy.
  - There was a lot of disagreement about the value of building
        redundancy and about the need to keep to the time-table
        requested by Google.
  - There was lack of consensus from the working group about a final
        solution and therefore none of TabAtkins' proposals were
        resolved upon.

:Changed pseudo-class
---------------------

  - The group responded favorably to having a pseudo-class to track
        user changes, but wished to gather more information about
        use cases.
  - TabAtkins will head up gathering use cases.

<custom-ident>
--------------

  - Some issues with last week's resolution were discussed to
        further clarify/refine the restrictions on custom-ident.
  - A desire was raised to have a global list of restricted values
        as well as a desire to ensure that the solution minimize
        opportunity for confusion for authors or spec writers.

=====FULL MINUTES BELOW======

Present:
  Glenn Adams
  Rossen Atanassov
  Tab Atkins
  David Baron
  Bert Bos
  Tantek Çelik
  Dave Cramer
  Bruno de Oliveira Abinader (IRC only)
  Elika Etemad
  Sylvain Galineau
  Daniel Glazman
  Rebecca Hauck
  Koji Ishii
  Dael Jackson
  Brian Kardell
  Brad Kemper
  Philippe Le Hégaret
  Edward O'Connor
  Matt Rakow
  Simon Sapin
  Dirk Schulze
  Alan Stearns
  Leif Arne Storset
  Greg Whitworth
  Steve Zilles

Regrets:
  Chris Lilley
  Peter Linss
  Anton Prowse
  Lea Verou

ScribeNick: dael

  glazou: Let's start
  glazou: Any extra items?
  astearns_: I'd like to take shapes to CR.
  Bert: One more, fantasai asked for namespaces to be updated.
  glazou: Okay.
  glazou: Is that all?
  glazou: Since TabAtkins is part of almost all this, lets start
          with Shapes.
  glazou: fantasai are you there?
  [silence]

Shapes to CR
------------

  astearns_: I got some feedback from the WG and I changed an
             example based on howcome's feedback.
  astearns_: He hasn't responded, but that's all the feedback we've
             had so we should transition to CR.
  glazou: I agree. Other opinions?

  leif: I haven't read the feedback. I'm not sure if I'm comfortable
        without review.
  astearns_: Howcome's feedback was discussed on call last week with
             some resolutions. The only part of the feedback
             actionable was something to stop using empty divs.
  astearns_: I made those changes and the rest of the issues the WG
             decided to postpone.
  leif: So the feedback was addressed? In that case I'm fine.

  astearns_: Any other opinions on the CR transition?
  glazou: I guess we can resolve?

  RESOLVED: Take Shapes to CR

  glazou: Who will do the transition process? Bert?
  bert: I guess, yes.
  glazou: I'm available for the call.
  ??: I think we have calls on Monday if we can move for that.
  glazou: I'm okay with that.
  bert: I'll send the transition request today.

Namespaces update
-----------------

  bert: I just wanted to know how we're going to approach it. It was
        brought up on the mailing list
  fantasai: We can do it on the call. Any objections to updated
            namespaces?
  glazou: I want to see the dev doc. Give me a second.
  <Bert> -> http://dev.w3.org/csswg/css-namespaces/#css-qnames
         Namespaces grammar rules.

  glazou: There were a lot of issues. We extracted everything we
          needed to from the doc, right? Yes. Ok. So I have no
          objections.

  glenn: I just wanter to verify that the changes don't affect
         conformance.
  SimonSapin: Correct.
  glenn: So there's no need for a PER process in other words?
  SimonSapin: I think that's what fantasai was suggesting.
  glazou: We lost fantasai.
  <Bert> (No need for a PER review, as far as I can see.)
  <fantasai> Sorry, I lost connection
  <fantasai> trying to get back on

  glazou: Any objections about updating the document?
  glazou: Okay. Bert?
  bert: Ok. If that's the conclusion I'll make sure it get published.
  glazou: I hear no objections so I think there's consensus.

  RESOLVED: Update namespaces spec

  Action bert to update namespaces spec
  * trackbot is creating a new ACTION.
  <trackbot> Created ACTION-621 - Update namespaces spec [on Bert
             Bos - due 2014-03-19].

  glazou: TabAtkins are you on call?
  glazou: Not yet.
  <TabAtkins> I'm here, one sec.
  <TabAtkins> Dunno why you can't hear me.
  <TabAtkins> Let me re-call.

Writing modes: Rename extent/measure to block-size/inline-size?
---------------------------------------------------------------

  <glazou> http://lists.w3.org/Archives/Public/www-style/2014Feb/0822.html
  * fantasai is in favor

  SimonSapin: There's 2 items.
  SimonSapin: We have in the spec. extent is the height and measure
              is width.
  SimonSapin: I get them wrong because it's hard to tell which is
              which.
  SimonSapin: I propose we do inline-size and block-size.

  * Bert likes "measure" but doesn't mind inline size either.
  glazou: I kinda like it.
  glazou: Other comments?
  <astearns_> fine by me

  rossen: So your proposal is inline-size and block-size?
  rossen: My only objection is that size usually is both width and
          height.
  rossen: So using size is a bit misleading.
  rossen: I'd prefer to have one identifier for that.
  rossen: If measure and breatdh doesn't work, I'm fine with finding
          something better, but size isn't good.
  <Bert> (Box uses inline dimension and block dimension, inspired by
         XSL's {inline,block}-progression dimension.)
  <TabAtkins> We use "size" as a generic term for, well, sizes, all
              over the place.
  <TabAtkins> It's not exclusive to width/height.

  SimonSapin: That was from the mailing list. I agreed that it could
              be inline dimension, not just size.
  rossen: How about length?
  <fantasai> We decided against length because of mixup with <length>
  rossen: Inline-measure and block-measure would be good.

  TabAtkins: I tried to object in chat. We use size all over as a
             generic word.
  TabAtkins: It's not width/heigh specific.
  Rossen: Generically I agree, but usually it's both.
  TabAtkins: Yes, but we use size for all kinds of things. It's not
             tied to a fragment width or height.
  Rossen: Again, I think we make mistakes, but why keep going with
          them?
  TabAtkins: I don't think it's a mistake. I think it's good. I
             don't want to use measure and length isn't much longer
             a word.

  <glenn> how about "length"
  <glenn> or "dimension"
  <SteveZ> How about "block-extent" and "inline-extent"?
  <glenn> don't like "size"
  <dbaron> I'm in favor of inline-size and block-size as well,
           though I'd also be fine with inline-X and block-X for
           some other X.
  <tantek> bikeshedding on the call FTW!
  <fantasai> SteveZ, block-extent & inline-measure? :)
  <SteveZ> I like the "block-X" and "inline-X" terminology

  glazou: I'm not sure that this is the best use of our time.
  glazou: SimonSapin can you continue the conversation over e-mail?
  SimonSapin: Yes.
  SimonSapin: I think we agree block-something and inline-something,
              we just need the something.
  TabAtkins: Can we resolve that?
  glazou: I'm okay with that.

  rossen: What's the resolution for?
  TabAtkins: Rename measure and extent to inline-something and block-
             something with something TBD ASAP.
  glazou: rossen, you okay what that?
  rossen: Mostly. I don't see the point of resolving without the
          something.
  rossen: But if we need a sub resolution, that's okay.
  RESOLVED: Rename measure and extent to inline-something and block-
            something with something TBD ASAP.

Lists WD
--------

  <glazou> https://lists.w3.org/Archives/Member/w3c-css-wg/2014JanMar/0216.html

  TabAtkins: The current list spec on TR is from 2011
  TabAtkins: It still has old counterstyles. I just want to update
             TR with current ED.
  TabAtkins: I don't love it, but it's better then what's there now
             so I'd like to get rid of the obsolete one.
  fantasai: I think it's good to update even though the draft is
            shaky, but we should have notices on what's completely
            experimental and may have compat issues.
  fantasai: So if we take a week to label, I'm happy to publish.
  TabAtkins: We can spend time checking everything and doing
             disclaimers.

  glazou: We agreed a while ago to have changes from previous
          versions.
  glazou: There's only changes from CSS2.1.
  fantasai: I think this is appropriate because the old version is
            so out of date.
  fantasai: This is pretty much a rewrite.

  glazou: I agree, but we need to say exactly what you said.
  glazou: We're not the only ones to read the whole spec.

  glazou: Tweek the edits and do the reviews and everything?
  fantasai: So we'll aim for next Thursday to publish?
  glazou: So is that a decision to publish today or revisit next
          week?
  TabAtkins: Unless anyone needs to review our changes, I'd like a
             resolution and we'll post when it's ready
  glazou: Any objections?

  RESOLVED: Publish a new WD of Lists

Shadow Styling
--------------

  TabAtkins: I'd like to discuss what's I've added as a resolution
             to what we've discussed.
  TabAtkins: I agreed with fantasai that using a pseudo-class for
             the root is good, but shadow root was bad.
  TabAtkins: Our compromise is that the shadow pseudo exists, but so
             does shadow deep and a shadow combinator.
  TabAtkins: Reason for shadow combinator is because we don't think
             we'll have the shadow pseudo soon because it's hard to
             do pseudo-class and combinator.
  TabAtkins: I think redundancy allows a more reasonable timetable.
  fantasai: I don't think redundancy makes sense because it's going
            to ship.
  TabAtkins: We can't want a year to ship. We can do a combinator
             not a pseudo-class.
  <tantek> "not going to wait a year" <-- is that an extension of
            the "ultimatum" ?
  * sylvaing_ doesn't really care about anyone's shipping schedule.

  fantasai: Rather then hacking CSS to have two things that do the
            same thing, hack your parser and put it there.
  TabAtkins: That's a bad solution.
  fantasai: It doesn't make sense to say we want this, but we're
            doing this.
  TabAtkins: Shadow combinator isn't bad because what it does is
             consistent with shadow-deep.
  TabAtkins: Pseudo-class works with the rest of CSS, but not here.

  fantasai: Then we should do combinator. Both doesn't make sense.
  TabAtkins: I'm fine with doing just combinator. We don't lose power
  fantasai: Yes you do
  TabAtkins: That's what the :top one is for

  glazou: I feel we have to decide something under pressure due to
          TabAtkins's employers demands. That's a personal comment.
  glazou: As a member I don't care about that agenda. I want it the
          right way.
  glazou: I don't like the pressure and I don't like any of the
          proposed solutions.
  TabAtkins: I understand. I don't like this, but we need something
             in a reasonable time frame
  TabAtkins: We have something that would work and something that
             wouldn't.

  hober: TabAtkins you could always prefix now and implement later.
  TabAtkins: If we implement prefix it'll stick and we can't remove
             it later.
  TabAtkins: If we do that, we should pick a name and assume that'll
             go in a spec later.

  rossen: So is the combinator completely out of the question?
  TabAtkins: I'm fine with just combinators. I added pseudo-class
             for fantasai but I'm fine with any of the solutions in
             the draft.
  TabAtkins: Pure combinators are fine with me, but I can be flexible

  * sylvaing_ thinks Google is welcome to ship whatever it wants.
              And the WG is free to disagree and change its mind
              later. Life goes on.
  * fantasai "I'm flexible as long as I get what I want"
  * krit fantasai: "I can be flexible here because it is what I
         prefer"
  * tantek is leaning towards sylvaing_'s opinion.
  <bkardell_> I think pure combinators seems like a better idea...
              we can always add pseudo element later. you can't add
              combinators later here, they are kinda the thing that
              we need.

  glazou: So you're asking for the WG to agree to do something.
  glazou: I don't think we need more time on this discussion, I
          think we need to do an answer.

  glazou: Who agrees with TabAtkins? Let you publish this like the
          WG agrees with it.
  TabAtkins: What does agree with me mean?
  glazou: You're asking for a combinator decision.
  glazou: You want to WG to agree about the combinator.
  TabAtkins: We can do pure combinator or combinator and pseudo-
             class combination in the draft.
  TabAtkins: But I want a decision.

  glazou: So who objects?
  <SteveZ> I am unhappy with having a redundant feature.
  <sylvaing_> Google's shipping policy shouldn't force a decision on
              anything.
  <sylvaing_> If there isn't any consensus, there isn't.
  fantasai: I don't agree with that.
  fantasai: I don't agree with having two things that do the same
            thing with no better reason then Google wants to ship.
  TabAtkins: Are you okay with just combinators?
  fantasai: I think combinator and :top solution is pretty messy.
  fantasai: I don't think it's a good solution

  TabAtkins: Do you dislike enough to object?
  fantasai: I do enough given that the argument in the other
            direction is you want to ship.
  fantasai: I agree with sylvaing.

  glazou: There doesn't seem to be agreement and I'm not ready to
          agree to let this go.
  TabAtkins: Keep in mind this started in September. It didn't get
             much attention, but it's been there for a while
  glazou: I was saying that the statement no one is paying attention
          to is false.
  TabAtkins: I can show the lack of e-mail.
  glazou: That's a lack of discussion, not the lack of attention.
  <sylvaing_> How long the issue has been open is no grounds to
              force a decision either.
  TabAtkins: So if someone reviewed and gave no feedback, that's
             normally a check.
  glazou: That does happen all the time
  TabAtkins: It's hard to tell silent consensus from not caring.
  <sylvaing_> What part of 'no consensus' is unclear?
  <tantek> it IS hard to tell silent consent from silent apathy.
  * hober too
  <tantek> oh looks like hober also disagrees

  TabAtkins: I'd like a resolution.
  glazou: So sylvaing, fantasai, and myself don't like to have a
          resolution right now.
  glazou: I'd like to hear from others. hober too.
  <sylvaing_> I don't mind people requesting a decision. I do mind
              people demanding them. There is a huge difference.
  <glenn> -1
  <hober> I agree with sylvaing/fantasai/glazou
  <TabAtkins> sylvaing_, I 've been requesting a decision since the
              f2f...
  <sylvaing_> So what?
  * krit TabAtkins you just forgot to mention that you want to ship
         immediately at the F2F :P

  glazou: I'd like positive or negative, but I want more opinions.
  rossen: I would actually prefer to have a solution as well.
  rossen: I'd prefer something not forced by time, but I don't think
          we're too far from a conclusion.
  rossen: Saying we have to ship isn't great, but it will get a
          decision sooner or later.
  rossen: I'm for making progress and I think the shipping thing can
          be permitted.

  glazou: We have 4 people that don't want to make a decision, so
          there isn't consensus. I'm sorry

  TabAtkins: Just be aware that time will force us to decide
             something and ship it so no decision is a decision.
  glazou: So I can't care a a co-chair.
  TabAtkins: We tried to do this publicly so everyone was aware.
  glazou: I'm here to make the decision of the WG and the WG opinion
          is to not decide now.

  <tantek> Google threatening to ship reminds me of MS threatening
           to ship years ago.
  <sylvaing_> Tantek, yes. Google doing a super good job playing old-
              school MSFT.
  <hober> "Further, we will take on an active commitment to shepherd
           the feature through the standards process, accepting the
           burden of possible API changes."
  * tantek is grateful for MSFT's evolution.
  * tantek is hopeful Google will similarly mature/evolve.
  <krit> At least Google is transparent and open when they are
         threatening.

  bkardell: Can I ask a question of TabAtkins?
  bkardell: Could Google get away without :top pseudo-class?
  TabAtkins: I think it's needed to content combinator, but I'm not
             100% sure.
  TabAtkin: We could maybe get away without it.
  bkardell: It seems like you need a combinator, and I was wondering
            if we could narrow down and avoid controversy.
  fantasai: The idea of pseudo-class is you use it to avoid other
            combinators.
  fantasai: So shadow combinator is the same as the pseudo-class.
  fantasai: If you want the :top combinator you avoid using the
            pseudo-class.
  bkardell: So the shadow deep wouldn't make sense as a pseudo-class.
  TabAtkins: Yes.
  <fantasai> e.g. A /shadow/ B is equivalent to A::shadow B
  <fantasai> and A /shadow/ B:top is equivalent to A::shadow > B
  TabAtkins: Well, we can move on.

:Changed pseudo-class
---------------------

  TabAtkins: I can't pull up the thread because I don't have easy
             internet use.
  <SimonSapin> https://lists.w3.org/Archives/Member/w3c-css-wg/2014JanMar/0217.html
  <SimonSapin> Rather,
      http://lists.w3.org/Archives/Public/www-style/2014Feb/0511.html

  TabAtkins: The explanation is Dean asked for a pseudo-class for
             anything touched by the user since the form was done.
  TabAtkins: It's not about validity, but if the value was changed.
  TabAtkins: Seemed reasonable.
  TabAtkins: A use case was to color anything touched when modifying
             data so you can see what's changed and you know what
             will change with a submit button.

  <tantek> Yes we kind of need this,
  <tantek> Because existing valid/invalid pseudos are crap for
           actual decent UX.
  fantasai: Is this checking against initial state on DOM or if you
            change something twice?
  TabAtkins: I'd think against the DOM.
  TabAtkins: Value vs default value.
  dbaron: I think we want "has the user touched it" more than is
          that value different from default.
  <tantek> dbaron++
  TabAtkins: Question is what would revoke the user touched it? I
             can see where there's a revert button to stop match
             change.
  dbaron: I would think input reset should.
  TabAtkins: I think that clears things, but I'm not sure.

  dbaron: Did we agree to add UI invalid?
  TabAtkins: Yes.
  dbaron: I think this is less important than as the UI invalid is
          combined with invalid.
  dbaron: I still tend to think we want something where user hasn't
          touched it.

  dbaron: Feedback would be good from those with use cases.
  TabAtkins: I'd be happy to go into more detail with use cases.
  fantasai: We might want both.
  TabAtkins: Possibly.
  TabAtkins: I'll gather more info and bring up later.

  <tantek> BTW, re: :changed, I noted (1) that making it user-action
           sensitive is more useful (per the usecases), and (2)
           concern that :changed would/might mean something
           different that the ONCHANGE event. Said this on the phone
           but got disconnected.

<custom-ident>
--------------

  <glazou> https://lists.w3.org/Archives/Member/w3c-css-wg/2014JanMar/0218.html

  SimonSapin: We had the resolution last week.
  SimonSapin: It wasn't clear whether that also applied to css-wide
              keywords.
  SimonSapin: Fantasai made the point that we have different words.
              Some names that would be a problem, you couldn't use
              them in other properties.
  SimonSapin: So maybe we should exclude CSS keywords on both sides.

  * dbaron can't quite hear SimonSapin well enough
  <TabAtkins> Example: You jlicould maybe write "grid-template-rows:
              5px (inherit) 10px", but you couldn't then write "grid-
              row-start: inherit;"
  SimonSapin: fantasai is that a good explanation?
  TabAtkins: I can restate.
  TabAtkins: So the resolution we wanted was that you only had to
             exclude keywords in same context as you,
  TabAtkins: But global keywords, fantasai asked if we should always
             exclude.
  TabAtkins: Furthermore keywords that are limited in one property
             but used in another, if we should still recommend
             /require that they would be invalid because they would
             be invalid in other context.
  TabAtkins: In the example I put above you could use it there, but
             not in grid-row-start.
  TabAtkins: Should we say that's disallowed, or in some places you
             can define against a set of disallowed, even if it's
             invalid in a different place?

  <dbaron> It seems good to have the same invalidity rules for grid
           template line names in all contexts.
  dbaron: I think same rules everywhere is better.
  TabAtkins: The potential issue is that invalidates a lot.
  TabAtkins: For example counter styles has a lot of keywords so you
             have to exclude, for example, none.
  TabAtkins: There's another half dozen in list-style shorthand,
             should they all be excluded as counter style names?
  fantasai: Maybe short hand vs long hand difference, though that
            changes over time too.

  fantasai: What's clear is excluding global words would be better.
  TabAtkins: Yes, so anything in top level excludes.
  SteveZ: It's easier to exclude all of them. There aren't that many
          and it's easier to remember to exclude them all.
  TabAtkins: I'm not sure, though.
  TabAtkins: When someone tries to make a counter style named
             "outside" and it doesn't work, is that confusing?
  TabAtkins: I'm not certain.
  <dbaron> I'm fine with the shorthand/longhand distinction.

  SteveZ: Alternately is the person making it not sure it's valid or
          not sure it's invalid?
  SteveZ: The nice thing about a simple rules is even if it's
          obnoxious, it's easy to apply because you don't need
          context.
  SteveZ: That's why I advocate for it. There's times when people
          don't know how to use something because it's context based.
  TabAtkins: That makes sense, but what's simpler?
  TabAtkins: At this point we're talking spec author. Maybe we can
             resolve that we disallow global and recommend authors
             disallow any problem values.
  fantasai: It's a little bit looser, but it allows if you have a
            value with a required keyword and a custom-ident, that
            clearly makes its own linkspace.
  fantasai: It won't conflict so there's no need to exclude.
  fantasai: So I guess I'm going with more nuanced "context".

  TabAtkins: Only reason I'm not happy it doesn't have any default
             allowances.
  TabAtkins: It allows you to spec any custom-ident, I'd prefer a
             list of defaults and allow custom.
  fantasai: I think the idea was a general rule, but each spec
            explains in a more specific way,
  fantasai: Because the rule is a little subject to
            misinterpretation or incorrect thinking.
  fantasai: But if you could tell in this context, this is excluded.

  TabAtkins: I'm aiming for easier spec maintainer. I don't want to
             require spec authors to include more.
  TabAtkins: People will forget and it'll be missed.
  fantasai: Both these versions have a default rule.
  fantasai: If you give the authors an easy explanation, that's
            better.
  fantasai: My rule is about parsing.
  glazou: We should wrap up.
  TabAtkins: I'm happy with parsing ambiguity.
  dbaron: Which one is yours?
  TabAtkins: I don't recall, I was trying to remember from last week
             minutes.
  <fantasai> An identifier that could be interpreted as a pre-
             defined keyword in any position or multiplication of
             the <custom-ident> component value is excluded, and is
             invalid as a <custom-ident> matching to that component
             value even in positions where its use would be
             technically unambiguous. For example, if a keyword
             could be misparsed when specified as the first item of
             a ''<custom-ident>+'' list, it is invalid when
             specified in any position in that list.
  fantasai: [reads the above]

  fantasai: I'm happy with clearer wording, but I think that's a
            good rule.
  dbaron: It's possible that needs a short hand exception.
  * dauwhe I'm fine with any rule that could be built into a CSS
           validator.
  fantasai: Let's do this on the list as a thread, I have to go.
  <fantasai> http://lists.w3.org/Archives/Public/www-style/2014Mar/0127.html

  glazou: So I guess this is it for the day. We had one item left,
          subgrid, but no time to discuss.
  glazou: Thank you everyone, talk to you next week.
Received on Thursday, 13 March 2014 00:33:38 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 13 March 2014 00:33:38 UTC