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

[CSSWG] Minutes Telecon 2014-05-07

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 7 May 2014 20:29:03 -0400
Message-ID: <CADhPm3tT8WAHSxNUussYKgxb2ycy8BKezcuEzLzczLgsygGQKw@mail.gmail.com>
To: www-style@w3.org
Grid Update/Publication

  - RESOLVED: Publish an update WD for Grid

Whitespace in calc()

  - There was basic agreement that when dealing with + the added
        whitespace wasn't needed, but there were concerns about -
        being confused with keywords.
  - There was agreement that the priority should be author
        readability/usability not tokenization.
  - TabAtkins will outline the exact proposal on the mailing list to
        solicit feedback with a goal of doing a poll of the working
        group on the next call (14 May)

Publish WD of GCPM

  - RESOLVED: Publish updated WD of GCPM
  - The new WD will maintain references to the items that were
        removed and what specs those items landed in.

:modal Pseudo-Class

  - RESOLVED: Add :modal to selectors level 4
  - There was some concern that a pseudo-class wasn't the best way
        to address modal, but not enough to block a resolution.
  - A few members of the group expressed an interest in eventually
        investigating and potentially creating a pseudo-class to
        query properties.


  - The editors asked for anyone with comments to submit them ASAP
        so that they can publish a new LC next week in order to
        garner input on the two different algorithms for resolving

Seoul F2F

  - Everyone was again reminded to add discussion topics to the wiki.

Line Layout

  - RESOLVED: Add fantasai and dauwhe as editors to line layout


  Rossen Atanassov
  Tab Atkins
  David Baron
  Bert Bos
  Dave Cramer
  Elika Etemad
  Sylvain Galineau
  Daniel Glazman
  Dael Jackson
  Brian Kardell
  Taichi Kawabata
  Brad Kemper
  Peter Linss
  Michael Miller
  Shinyu Murakami
  Edward O'Connor
  Simon Pieters
  Simon Sapin
  Dirk Schulze
  Alan Stearns
  Lea Verou
  Greg Whitworth
  Steve Zilles

  Anton Prowse

ScribeNick: dael

Grid Update/Publication

  plinss: Let's get started
  plinss: We have a short agenda. I saw the Flexbox addition from
          fantasai Anything beyond that?
  fantasai: I'd like to say that it would be good to publish grid
            next week.
  fantasai: I don't think there's significant changes, mainly just
            the algorithm. Does anyone want more changes?
  plinss: Just an update?
  fantasai: Yeah. Mainly it was fixing random bugs and the algorithm
  Rossen_: I'll take a look and give feedback
  fantasai: I'll try and create a formal comments list. It's mainly
            issues from SimonSapin

  plinss: Do folks want more time, or are we ready to publish an
  plinss: Anyone?
  plinss: So we're okay with publish an update? Any objections?

  RESOLVED: Publish an update WD for Grid

  SimonSapin: No objections but I sent some issues about grid to the
              mailing list.
  fantasai: I'll scan through and fix those or mark them as issues.
  SimonSapin: Okay

Whitespace in calc()

  <Rossen_> http://lists.w3.org/Archives/Public/www-style/2014Apr/0480.html

  TabAtkins: I talked about this more with zcorpan and I'm okay with
             making the grammar more complex to make it simpler for
  TabAtkins: I can at least make it so you can use + without the
             extra spaces
  TabAtkins: I can't figure out using - without killing keywords in
             the future.
  <TabAtkins> calc(auto-2em)
  TabAtkins: In particular I don't know how we'll get the above
             example to work.

  SimonSapin: I think it's fine if that particular case doesn't work.
  <TabAtkins> calc(1em-2em)
  TabAtkins: I'm not okay with that. If that (above) works I don't
             know why a keyword wouldn't. I hate rules where you
             need spaces with a keyword but else wise not. It's not
             great to add spaces, but at least it's only one rule
             they have to remember.
  <astearns> +1 for more consistent (if more limited) rules
  TabAtkins: So I still don't know what to do about this.

  TabAtkins: Is zcorpan on the call?
  plinss: I don't think so.
  TabAtkins: So I guess I have to keep talking to him about this.
             I'm not sure what he thinks about that case and it's
             not clear from his notes.
  TabAtkins: Okay. So I'll keep talking to zcorpan.

  plinss: Anyone else with ideas/thoughts?
  * fantasai agrees with astearns and dbaron
  SimonSapin: What if we remove the whitespace restriction, but we
              don't change ident. rules. So in your example it would
              be required but not if it's unique.
  <TabAtkins> calc(1-2)
  TabAtkins: So in other words calc (1px - 2px) would work?
  SimonSapin: Yes.

  glazou: I'd like to comment on my message. It seems like we're
          only looking at tokenization, not readability.
  glazou: The message from web authors is they don't care about
          tokenization so if we only care about that we make
  TabAtkins: This isn't just tokenization. Simplest to tokenize is
             using whitespace everywhere and I'm willing to change
             for readability, but there's one case that's
             intrinsically impossible, as far as I can tell.
  TabAtkins: Else wise I'm fine with technical grammar being harder
             to make it easier for authors.
  <TabAtkins> calc(1em+2px)
  TabAtkins: I'm fine that it's complex enough that the above works.
  TabAtkins: That's not valid today, but I'm fine making that valid
  glazou: I'm okay with that too.
  dbaron: Are you okay with making that work but -2px doesn't work?
  glazou: I want both.
  TabAtkins: There's an intrinsic issue.
  glazou: I want this to work on readability size.
  TabAtkins: Burdens on our side are insurmountable.
  glazou: I want this to work. It's implementation issue, not a
  <TabAtkins> calc(auto-min-content)
  TabAtkins: This is a blocker. There's no way to pull above apart
             into subtraction of two keywords.
  TabAtkins: We can do it in our brain, but not in implementation.
  glazou: If +1px works and -1px doesn't, people won't know why.
  TabAtkins: I agree. That's why I hesitate to change + because then
             - doesn't make sense.

  plinss: So maybe we need to think about making - work.
  plinss: If we're parsing keywords in calc() with - you would stop
          at shortest known keyword when you get a -.
  TabAtkins: That makes tokenization context dependent.
  plinss: It's ugly but could work.
  SimonSapin: So that's a reasonable definition of changing the style
  <TabAtkins> calc(1px-2em)
  TabAtkins: So you say allow the above because units can't have -,
             but keywords can. I'm somewhat against that because
             it's easy to trip over.
  SimonSapin: I agree, but is it worse than what we have now?
  TabAtkins: I don't know. Maybe?
  glazou: I don't think so.
  <astearns> if we had keywords 'foo' and 'foo-bar', you would not
             be able to use 'foo-bar'
  <TabAtkins> astearns: Good point.

  glazou: I think anything that increases intuitiveness on the
          author side is good. We have too many complaints about CSS
          getting complex with syntax and everything we can remove
          is good.
  TabAtkins: I agree, but there's a problem we can't solve and until
             we don't have that problem I'm probably not comfortable
             with making these changes.
  TabAtkins: I could be convinced about +, but I'm not sure.
  TabAtkins: I suggest we make no change for now and continue to
             discuss how to get around the keyword issues, since we
             know keywords will work in calc() eventually.

  <fantasai> Consistency is a tool for navigating complexity.
  <fantasai> We shouldn't break consistency in some cases but not
             others, that introduces more complication.

  SimonSapin: I still think the original proposal is the best.
  TabAtkins: That's the one that requires space with keyword, but
             else wise allows you to remove them.
  SimonSapin: Yes.
  TabAtkins: So it requires space when sub keyword from something.
  SimonSapin: Anywhere that you have a - that could be interpreted
              as a sign, but we only have a few properties where it
              happens. Where you need a + sign is okay.
  TabAtkins: The reason we don't have a problem is that it's
             traditional to add a space. People do it with binary
             math. The tokenization already exists, but no one hit
             it before.
  SimonSapin: People are used to inserting whitespace before a
  TabAtkins: No, they're not used to inserting between operator and
             arguments because they don't do it elsewhere. But
             because - is in as a valid namespace you have to in CSS.
  SimonSapin: Maybe.
  TabAtkins: That said, I could go with that if the rest of the WG
             goes with it. It's a nice win overall so it might be
  TabAtkins: I suppose we could poll.
  glazou: I'm willing to review.

  <bkardell_> can we see an example?

  TabAtkins: How about I outline the exact proposal in the ML, get
             feedback, and we poll in the next call and I'll accept
             the WG's decision.
  glazou: Fine with me
  plinss: Sounds like a plan.

Publish WD of GCPM

  dauwhe: Previous draft is from Nov 2011 and now there's a new
          editor and much has been moved to other specs
  dauwhe: What's left is based on the WG resolution in Paris so I
          think it's time for an up to date WD.
  dauwhe: An implementor has joined the WG so I think we can make

  plinss: Sounds good. Any objections?
  <fantasai> +1 for publishing
  <glazou> +1 for publishing

  Bert: So the parts not in GCPM, are they somewhere?
  Bert: I agree they don't belong, but they should be somewhere.
  dauwhe: I've made notes in the ED about changes from the last
          version. I could easily add something saying where the
          pieces ended up, some to Page, etc.
  dauwhe: Would that address it?
  bert: I see changes have some notes, maybe it should have a bit
  bert: Otherwise I think you can publish, yes.
  dauwhe: Instead of just saying something was removed, I can say
          where it ended up. That's easy.

  fantasai: One thing I would recommend is keep the section headings
            in for what was removed and add a note.
  fantasai: So people using the links land on the note.
  dauwhe: I can do that.
  fantasai: If anything that moved hasn't been publish as an updated
            WD we should do that, too.
  dauwhe: I'll look through that. I'll have to see about maintaining
          anchors to links and I think the structure is somewhat
  fantasai: Just make sure links don't break. When I split Text I
            have a bunch of anchor tags that got to a note saying it
            had moved.
  fantasai: Eventually you can remove the headings and have a note
            for all of it.
  dauwhe: I'll look at your examples. Sounds good.

  plinss: Are we okay to resolve with those changes, or does anyone
          want to review? Any objections?

  RESOLVED: Publish updated WD of GCPM

  plinss: dauwhe you've been writing tests?
  dauwhe: Yes, I have quite a few.
  dauwhe: I need to check to make sure it's covered.
  plinss: I don't see them in shepherd.
  dauwhe: I uploaded a bunch during TTWF, but I'm not sure what
          happened in that process. I'll look into it.
  plinss: Ping me off line if you need help.
  dauwhe: Okay. Thanks.

:modal Pseudo-Class

  TabAtkins: That was me
  TabAtkins: Hixie has been working on modal dialog and the dialog
             element can be modal or non-modal and it depend on how
             you call it.
  TabAtkins: There's not a CSS detectable way to tell if it was
             displayed as modal, but you clearly want to style
  TabAtkins: The suggestion is to add a pseudo-class to detect. The
             suggested name is :modal

  glazou: How do you make the difference in the dialog?
  TabAtkins: Dialog has .show and .show-modal
  glazou: It's unfortunate it's not an attribute.
  TabAtkins: It makes sense to display depending on circumstances.
             For example you'd want to display normally usually, but
             once in a while you want modal

  Bert: Doesn't it make sense to have it display.modal since you'd
        need to re-display?
  TabAtkins: Not really. A modal dialog may want to be styled in
             more attention getting ways. There's not particular
             ways out there where things want to be different.
  bert: So let's say I want to use JS and have some difs so I want
        it to display correctly.
  TabAtkins: Correct, you need JS.
  bert: So you need a property for that. You don't need a selector
  TabAtkins: You can do what you need for display. You don't need a
             new property.
  bert: We don't have pop-ups. We have position, but that's in the
        same window. Nothing says this is new.
  TabAtkins: Right, dialog is in new windows. That's another thing
             we're letting happen in the web.

  plinss: I agree we need a property, but this is a question of the
          behavior, not the display. The behavior could be either,
          but the modal can only be invoked through script.
  glazou: I'm not convinced we need two methods, I think I'd prefer
          an attribute, but I won't object.
  TabAtkins: You know that's been exposed, like do we do modal
             attribute, but because there are cases where you want
             to display as either, methods seemed more intuitive.
  glazou: You'll need something on dialog saying if it's modal or not
  glazou: It'll have to be somewhere so why not an attribute? At
          some point you'll need one, so I don't absolutely see need
          for a new pseudo-class
  TabAtkins: What do you mean?
  glazou: When you do dialog that can be open modal or not than you
          want to know how it was open so you need and attribute.
  TabAtkins: No you need a property.
  glazou: I was mentioning attribute on an interface
  TabAtkins: You can't access JS except through a pseudo-class
  <bradk> Why not 'display: dialog-modal?'

  plinss: The other alternative would be that we had a generic
          pseudo-class to let you query property.
  TabAtkins: A lot of properties have values that aren't
             strings/numbers and we couldn't do anything generically
             with them in CSS
  TabAtkins: We can do number or boolean, but not date.
  glazou: Date can be two strings.
  TabAtkins: But you can't query that usefully, but you can do that
             with past and future pseudo in queues.
  TabAtkins: So a lot of things can't be used generically. I'm not
             opposed to doing that as well, but it would need future

  <leaverou> btw one problem with :modal is that it applies to the
             dialog only, so doesn't help with e.g. adding an
             overlay (unless one adds it as a pseudo-element on the
             dialog but that's tricky)

  zcorpan: I think it seems scary to be able to select based on a
           property because that property can have a side effect.
  TabAtkins: Oh. That is true. In that case I don't want to get into
             that can of worms without a lot more thought.
  plinss: We don't want to just throw it in there, but it's worth
          exploring. Perhaps just as a note in a future level of
  plinss: Short term :modal may be way to go.
  TabAtkins: And I'm fine with adding a note that we'd like to
             explore generic property access.

  TabAtkins: So any objection to adding :modal or better names than
  Bert: I'd like to see a comparison to other things we might add
        like stretch text and tool tips.
  bert: I'd like to see a framework for all of those, not just add
        one and deal with the others later. Think of all the ways
        display might happen.

  glazou: I have a related inquiry. Modality can be dependent, a sub
          dialog, etc. Do you expect a pseudo for all these?
  TabAtkins: Dialog is on top of everything is already going on so
             it would be a property. We've discussed this
             internally, I just need to propose it.
  TabAtkins: Slaving an element or something will happen at the
  TabAtkins: That doesn't happen with modal because it's a strange
             interaction that can be flipped on or off.
  TabAtkins: More importantly you want to style differently and if
             modal is a property you can't do different.
  zcorpan: Modal is top layer.
  TabAtkins: That's something we anticipate baking into CSS, but
             it's not a magic switch, just a new value or property
             added to positioning
  TabAtkins: Basically, other aspects of dialogs that are magical
             will be done through styling, but if you're modal you
             want to base styling on that which is why we're asking
             to add it to selectors.
  plinss: So back to the question, any objections?
  TabAtkins: What I said also addresses Bert's comment. Other things
             like tool tips aren't what you want to be selecting on.
  TabAtkins: So back to any objections?

  plinss: Not hearing objections. Is this going into 3 or 4?
  TabAtkins: 4. Or did you mean between 4 and 5?
  plinss: Yes.
  TabAtkins: Given that it's being implemented now I think 4 is okay
             but if people object to that, I'm okay with 5.
  TabAtkins: This is something people want to expose in their

  RESOLVED: Add :modal to selectors level 4


  plinss: There's an open issue in the DoC?
  TabAtkins: You want to handle that fantasai?
  <fantasai> http://dev.w3.org/csswg/css-flexbox-1/issues-lc-20140325
  fantasai: Here's the issues list (above)
  fantasai: I think Rossen_ sent a comment that we need to add to
            the list.
  Rossen_: I have one more, too.
  fantasai: This is everything filed since last call. That one
            that's open is alternate wording for length.

  fantasai: So, before it was discontinuous between 0 and non-0 and
            we made a change and published the LC. However when
            TabAtkins made the change he shipped based on the
            concept of desired size
  fantasai: Rather than operating on flex values and normalizing
            them and once normal doing the multiplication.
  fantasai: That's a shift from the CR text but in implementation
            it's better dealing with rounding because you have a
            constrained range.
  <fantasai> http://dev.w3.org/csswg/css-flexbox/#resolve-flexible-lengths
  fantasai: Both are in spec with all the various bug fixes. We
            folded bug fixes into both options.
  <fantasai> http://lists.w3.org/Archives/Public/www-style/2014May/0028.html

  fantasai: Question is what's easier to read and did you notice any
            difference in results since that would indicates a bug?
  fantasai: We'd like review and don't want to CR today, but we
            likely need a 2nd LC since there were a bunch of
            normative changes to fix bugs.
  fantasai: There's the issue from Rossen_ right now and that's it
            for DoC.

  TabAtkins: So I think we're asking for LC with both algorithms and
             implementors will give us input on which to keep. We'll
             ask for CR after the next F2F.
  fantasai: If anyone is holding off on issues, we'd like to address
            those as well.
  krit: If this is feedback from all browsers, it sounds reasonable.

  plinss: So to be clear, you're asking for LC?
  fantasai: I'm asking if anyone has issues they haven't filed.
  TabAtkins: Except Rossen_'s.
  Rossen_: I'm filing it now.
  fantasai: Anyone expecting issues?
  Rossen_: Maybe. We haven't found anything jarring so I'm not
           expecting any major delay, but I'm not willing to say no
  fantasai: So I suggest we publish LC next week on Tues or Thurs
            and that will be a short LC since the things that have
            changed are all in this one page section.
  TabAtkins: So I suggest Thursday with a resolution on the next
  plinss: So you want to hold off on recording the resolution till
          next week?
  TabAtkins: Yes. If there are any issues, please record them ASAP
             so we can address before next week.
  TabAtkins: For a few more days we can address things with alacrity.

Seoul F2F

  plinss: Okay. That's the end of the agenda.
  plinss: F2F is coming quick, so please add topics. I know we get a
          flurry of comments at the end, but sooner would be better.

Line Layout

  fantasai: I have a question
  fantasai: Since we were working on baseline I was thinking of
            taking a pass on line-layout.
  fantasai: Does anyone have concerns about me editing?
  SimonSapin: I have comments, but no concerns.
  SteveZ: I don't have any concerns. I didn't e-mail.
  fantasai: Okay. I'll look it over. I'm not going to address
            issues, I'm just going to clean up.
  fantasai: I'll bring it more into alignment.

  dauwhe: I'm interested in the initial caps area.
  fantasai: I'll be mostly ignoring that.
  SteveZ: I would be too. I don't think it belongs.
  dauwhe: There's a lot of interesting in that in publishing since
          current is horrible.
  SteveZ: It involves problems of aspect ratio.
  dauwhe: And authors knowing height of a particular cap.
  SteveZ: Often you'll want to align to the form underneath and
          maybe with line grid it would be easier.
  dauwhe: Is there a natural way to have it fall out of grid, or
          does it need to be separate?
  SteveZ: I think separate. Main problem was you wanted to position
          baseline of initial cap and set distances so it covered
          even number of lines.
  dauwhe: Yes, there was a desire to get initial value of the cap
          lined up in advance.
  SteveZ: Body height and face height can be different for different
          fonts and that would affect appearance.
  TabAtkins: Sounds like something that can be automated with line
  dauwhe: I think I can get interest from implementors on this
          subject. People at iBooks are interested.
  sgalineau: As you know we've been playing with text flowing around
             a big cap. Seeing the author-facing notes would be very

  SteveZ: Since you want to do drop caps and fantasai doesn't, does
          it make sense to split it?
  fantasai: I'm not sure where it goes best, but we can co-edit.
  <fantasai> don't have to split the spec in order to both work on
             parts of it :)
  dauwhe: I was thinking I could do a rough-cut and get what's there
          to a point where it's easier to discuss.
  plinss: So dauwhe are you willing to be a co-editor?
  dauwhe: Yes. As long as I don't have to be expert on everything.
  TabAtkins: It's not like any of us are.
  dauwhe: Everything I've seen with this group leads me to believe

  plinss: So any objections to fantasai and dauwhe being added as
          editors to line layout?
  SteveZ: I assume I'm still there.
  TabAtkins: Yes.
  SteveZ: I think John dropped off
  krit: He doesn't reply to e-mails.
  * sgalineau will keep working on dropcaps until someone considers
              them harmful

  RESOLVED: Add fantasai and dauwhe as editors to line layout

  plinss: Should someone ping John to see if he wants to stay?
  SteveZ: Well he can't because he dropped from the group.
  plinss: Okay, he'll be a former editor.
  SteveZ: I think the process requires editors to be in the group.
  plinss: I guess that's it. Thanks everyone.

  dbaron: I won't be around next week.

  glazou: I have one more thing. Technically John Daggett is still
          in the WG.
  SteveZ: I thought he resigned
  glazou: We left daily work, but the Mozilla rep, dbaron, never
          removed him.
  glazou: So he's a member.
  SteveZ: Okay. So he can stay editor
  SteveZ: dbaron, would you find out if John wants to stay?
  dbaron: I can ask.

  plinss: Thanks everyone. We'll talk next week.
Received on Thursday, 8 May 2014 00:29:38 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:42 UTC