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

[CSSWG] Minutes Telecon 2016-03-09 [css-values] [css-writing-modes] [css-ui-4] [css-scoping] [css-grid]

From: Dael Jackson <daelcss@gmail.com>
Date: Thu, 10 Mar 2016 06:39:43 -0500
Message-ID: <CADhPm3tKge0R84i866R7NdpfFVQ69Co4FC4F73zRGir4b-wSGw@mail.gmail.com>
To: www-style@w3.org
  These are the official CSSWG minutes.
  Unless you're correcting the minutes,
 Please respond by starting a new thread
   with an appropriate subject line.

F2F Meetings

  - There's work being done to get bigger spaces for the May F2F.
      Currently Wednesday has the worst space constraints.
  - The TPAC meeting day request will be for the Monday/Tuesday slot.

Ideographic Character Unit

  - There are two different views about how the proposed ideographic
      character unit should behave; one describing what
      Firefox/Safari does and the other what Chrome does.
  - The use cases with examples will be posted to the mailing list
      where discussion will continue. If needed, this will be added
      to the May F2F where a whiteboard can be used to explain

user-select property

  - There was broad agreement around having -webkit-user-select be
      an alias, but leaving it undefined as to how the alias works.

New York Grid Workshop

  - fantasai gave a brief overview of the feedback that came from
      the New York grid workshop. She'll be updating the spec and
      filing issues to the list.

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

Agenda: https://lists.w3.org/Archives/Public/www-style/2016Mar/0138.html

  Rossen Atanassov
  Bert Bos
  Tantek Çelik
  Alex Critchfield
  Elika Etemad
  Daniel Glazman
  Tony Graham
  Koji Ishii
  Brian Kardell
  Thierry Michel
  Michael Miller
  Anton Prowse
  François Remy
  Florian Rivoal
  Hiroshi Sakakibara
  Alan Stearns
  Lea Verou
  Greg Whitworth

  Dael Jackson
  Brad Kemper
  Peter Linss

Scribe: fantasai

F2F Meetings

  astearns: Working hard to get space that will fit.
  astearns: Confirmed for SF for May 9-15 for CSS + Houdini
  astearns: Lots of space Tues/Fri.
  astearns: Less-bad for Mon/Thurs.
  astearns: Wednesday is difficult- still looking for a slightly
            bigger space.
  astearns: Might have to split into tracks or have constrained
            number of people attending.
  astearns: Will try to arrange agenda to match.
  astearns: Will put up a wiki page for meeting today.

  Florian: We can start booking tickets?
  astearns: Yes. Definitely.

  tantek: Are these Google's offices in SF?
  Rossen: We'll have the details with hotels/whatnot up pretty soon.
  tantek: May 15th after F2F is Bay to Breakers, one of the most
          epic races of the year, in case you want to stay the
          weekend and participate in 12K :)

  astearns: Yes, we are going to meet at TPAC in September!
  astearns: Guessing we should ask for standard M/T meeting slot?
  Florian: No reason not to.
  <gregwhitworth> yes, since we don't have one in Aug.

  Rossen: Did we want to discuss January?
  Rossen: Not yet ready to talk about it, but would be good to ask
          for general location?
  Rossen: And if anyone is thinking about hosting?
  Rossen: There was interest expressed for April in Japan.
  Rossen: and for January, or soon after December.
  Rossen: Alan and I were discussing Seattle;
  Rossen: winter here is relatively mild.
  Rossen: This will be our backup, unless someone has a different
  Rossen: Think this is more of a call for where do y'all want to
          meet in January?
  Rossen: If North America, given Europe and Japan before/after that
  Rossen: Where in America?
  <Florian> +1 for Hawaii
  Rossen: Don't have to close on this. Just put a pin on it and
          discuss next week.
  astearns: Yes, so if anyone can host elsewhere, let us know.
            Otherwise we have back up in Seattle.

Ideographic Character Unit

  <astearns> https://lists.w3.org/Archives/Public/www-style/2016Mar/0078.html
  Florian: Discussed this at Sydney.
  Florian: For various reasons, would be good to size things
           according to CJK ideographic characters.
  Florian: Talked about either 2 units or 1 unit.
  Florian: In practice only need one.
  Florian: So should have something like ch unit, except based on a
           CJK character instead of zero.
  Florian: I noticed that the ch unit is not clearly defined how it
           works with writing modes.
  Florian: Earlier on IRC, fantasai wrote what I think is the right
           thing to do.
  [fantasai's comments:
     ch should always be "advance measure"
     sorry "advance measure of zero"
     and ic should always be "advance measure of water character"
     Which dimension is the advance measure depends on writing-mode
         and text-orientation
     and what the advance measure is depends also on the fonts
  Florian: This is currently what Firefox does and Safari IIRC, not
  Florian: Dunno about IE.

  fantasai: [missed]
  fantasai: Does anyone have issues with this, or can I put it into
            the spec?
  fantasai: So, proposal is use the advance measure, which will
            depend on writing-mode and text-orientation
  fantasai: I can edit details into the spec.
  <fremy> fantasai: ch is dependent on writing modes, this one
          should be consistent with that
  koji: I think ideographic character unit should just be the width.
  koji: But ch is average of characters.
  fantasai: No it's not, it's measured from zero.
  koji: ic unit would be same as em.
  [no it wouldn't]
  Florian: If you have a font with non-square characters, it would
           not be the same as an em.
  Florian: If you look at snap proposal you have, if you don't have
           this unit it doesn't work.
  koji: It works.
  Florian: Not for all fonts.
  Florian: We can make it work 100% of time by having this unit.
  Florian: Both ic and ch need to disambiguate the use of "advance
  Florian: I propose we define ic exactly as we define ch, except
           defined against different character.
  Florian: Fallback values being .5em and 1em respectively.
  Florian: Both based on "advance measure", which should be
           writing-mode and text-orientation dependent.

  koji: ch should remain width
  Florian: What do you mean "remain"?
  koji: ...
  Florian: Why do you think it's useful for ch to not match the
           advance measure in vertical writing?
  koji: ch being somewhat narrower than em is my general
  Florian: If you want 0.5em use 0.5em. If you want the advance of a
           character, use the ch.
  koji: ch doesn't match characters.
  Florian: It exactly matches to zero.
  koji: That's not useful.
  Florian: In monospace fonts its the same for all characters.
  astearns: It's also useful for numerals when you're using the
            opentype feature that makes them tabular.
  fantasai: Nobody is arguing that you should use ch instead of
            ideographic, that is clearly wrong.
  fantasai: ch matches to width of narrow characters in monospace
            fonts, and of numbers when they're tabular.
  koji: I want to keep that definition in vertical, too.
  koji: If want ideographic height, can use em today, don't need ch.
  koji: ch character then would be 1em always
  fantasai: I think you're confused, no one's saying to use ch
            instead of ideographic.
  fantasai: If you have numbers in vertical writing mode, and you
            have a phone number and you want the input to take 7
  fantasai: The ch is not for CJK.
  fantasai: That's not necessarily true, if you have a font that
            puts in vertical metrics then it will not be 1 em, it
            will be less than 1em and you'll want to reduce the
            spacing by the descent height.
  fantasai: It depends again if it's monospaced or not.

  Scribe: gregwhitworth

  astearns: I'm wondering if it makes sense, with what Florian
            described a while ago with a proposal, put the formal
            proposal on the mailing list and have the discussion
  florian: The writing is there on the mailing list.
  astearns: Is the ambiguity fixed in spec text?
  florian: Yes somewhat, we'll need prose but there is no more
  astearns: ahh
  florian: I think fantasai and I agree, that's what Safari/FF do.
           Chrome/Koji agree.
  fantasai: They do have an equivalent, the glyph orientation
  astearns: Maybe some examples would be helpful in actual use cases
            to make the best decision.
  fantasai: The most common is input.

  fantasai: The use case for the behavior Florian is advocating is
            "I want this input element to contain approximately X
  fantasai: I would like the usecase that Koji is advocating for.
  koji: I explained on the mailing list that ch is like em.
  florian: If you want 0.6 em, write that.
  koji: The same applies to you.
  florian: No I can't, I want something in a measure that isn't
  fantasai: I don't see any use case for the behavior Koji is
  <Bert> (So if I understand correctly: a 'width: 5ch; height: 5ch'
         box is always square, but it becomes twice as wide when you
         set 'writing-mode: vertical-rl'?)

  astearns: This discussion is not productive, I suggest take it to
            the list.
  astearns: Please put use cases with possible visuals, if not we'll
            use white boards in May.
  florian: While we're on this topic, do we agree that there should
           be an IC unit?
  fantasai: We already have a resolution on that from Sydney.

user-select property

  <astearns> https://lists.w3.org/Archives/Public/www-style/2016Feb/0050.html
  florian: This is common in webkit prefix form.
  florian: We agreed to add this to the spec and we left some
           functionality open.
  <zcorpan> there's https://compat.spec.whatwg.org/#css-prefixed-aliases
  florian: Should the values accepted be just what is supported by
           webkit, leave it undefined, be the alias for their prefix
  florian: If you do Mozilla values that aren't supported by
           -webkit-user-select is supported.
  florian: I'm not really interested in speccing something that
           should change, just reality.
  florian: I'm in favor of leaving it up to the UA
  <fremy> +1

  <tantek> I'm going to note https://compat.spec.whatwg.org/#-webkit-user-select
  tantek: The web compat spec says it's just an alias, this is the
          current state
  tantek: I think that's why you're seeing what you're seeing.
  florian: No, I don't think so - that was added recently.
  tantek: They are consistent, which is a good place to be.
  tantek: Treating it as a prefix property does not imply, prefix
          property value aliases.
  tantek: We can specify that part of the detail.
  florian: That was my point of the second question, do we need to
           define aliasing?
  florian: They're very close, but not exactly identical.
  tantek: That section defines how aliases are supposed to be treated.
  florian: I would argue that we should not define how aliasing
           works, while it's slightly different I'm not sure it
  florian: I've done the best to find the differences, but I'm not
           sure it's worth going into that.
  <zcorpan> isn't it defined somewhere already how aliasing should
  tantek: There are two issues there, I'm fine leaving the
          definition of aliasing undefined in the UI4, or just link
          to the compat spec.
  tantek: I'm not passionate one way or the other.
  tantek: The other is the behavior in webkit-user-select, if the
          functionality is quite different from just aliasing we
          should document that, but I suggest to add that to the
          compat spec.

  florian: [reads his testcase regarding transitions with
  florian: I feel this is unimportant.
  florian: I was told to investigate, and browsers don't narrow it
  tantek: I'm fine leaving it undefined until someone finds a compat

  florian: As for the values to be supported, I'm not in favor of
           restricting to what just webkit supports as that is not
           what FF/Edge do and I don't want to spec what they're not
           doing unless they're willing to change.
  <tantek> https://compat.spec.whatwg.org/#css-prefixed-aliases
  tantek: Yeah, I think this answers that question.
  tantek: I'm fine with how it's defined there.
  tantek: Let's wait for a concrete reason.
  tantek: Are we done?

  tantek: Do we want to spread this compat information across specs,
          or just in the compat spec?
  florian: Not sure I want it just in the compat spec.
  florian: Propose webkit-user-select as an alias, without specing
           how browsers do it which is good enough for compat reasons.
  fantasai: Explicitly say it is undefined.
  florian: I don't detail it out, that should imply that it is
  tantek: I think you should link to the compat spec as it may not
          be obvious to everyone.
  fantasai: I think you should say that how alias is done is
  florian: ok, I'll leave it undefined.
  fantasai: I'm happy with that.
  tantek: I can live with that.
  astearns: alright
  <fantasai> should *either* say exactly how to do the aliasing or
             *explicitly* leave it undefined
  <ChrisL> not happy with it but won't object
  <ChrisL> wolliness+1
  <tantek> fantasai - my point is, don't say exactly how to -
           instead reference compat for that, if that's what you
           want to do
  <fantasai> Proposed Resolution: -webkit-user-select is aliased,
             it's undefined how

  ChrisL: The explicitly undefined, if everyones doing it we should
          specify that.
  rossen: Regardless of what we say as an implementer we're not
          going to change how we alias stuff. Any additional work
          added, we're not going to do. If you make it explicitly
          undefined leaving then that is fine.
  rossen: Making it more rigorous though is different.
  ChrisL: ok
  fantasai: If this was on the standards track then I think we would
            define it, but it's just there for web compat and we
            hope it will disappear.
  tantek: That's why I suggest moving it to the compat spec.

  fantasai: There was another discussion about this in Sydney, but
            keep it in spec with just one line of prose that state
            you should implement the webkit as an alias for web
  fantasai: We want it to be obscure, but close to the definition so
            the implementations can be web compatible.
  florian: It disappearing from the web would be nice, but since
           every browser has seen a need to implement it that's
  SteveZ: My issue with this, is the people having issues with this
          is by people who have implemented it, the specs are for
          people that will implement it.
  Florian: There will not be two definitions since the people of the
           compat spec will remove it as soon as we have it.
  astearns: I think we should move on.

Scoping and Shadow DOM

  astearns: Tab said he's fine adding it to scoping and we should
            comment on the spec text
  astearns: I brought it up because there has been no response
  <bkardell> Ok to comment on the spec text, I missed it and
             actually need time to wrap my head around it.

New York Grid Workshop

  astearns: It seems, at least on twitter, is there a simpler
            subgrid solution. I'm curious what that entails.
  fantasai: Two things happened, the implementers got an idea how
            important subgrid is, and the authors said they would
            rather wait 8 months for subgrid than have grid earlier.
  fantasai: They had issues with min/max dimensions and those aren't
            issues since those are restricted on subgrids.
  Rossen: Who were the implementers?
  fantasai: Igalia
  fantasai: There were some cases where we need to define what
            happens when a subgrid overflows its grid area, and that
            seems to be difficult to implement and we're happy to
            change that in the spec.
  fantasai: I'll need to go through the subgrid spec and open issues
            to figure out the easiest way to handle the edgecase
            rather than just a way to handle them.

  astearns: It would be good to get list info on these changes since
            there was only one implementer in the room.
  fantasai: I agree.
  astearns: I love these workshops, and like the feedback you get -
            it would be great to get that feedback to the list and
            would be important going forward. Get the minutes of the
            group if possible.
  fantasai: Normally what happens are very editorial, but if there
            are actual issues I file them against the list.

  rossen: One more thing, I want to reinforce the point is that
          these are awesome.
  <glazou> +1 to what rossen said
  rossen: In this particular case there was a lot of hype.
  rossen: I don't want to see statements that look like WG
          resolutions and see tweets from influential authors saying
          we're going to need to wait to ship until subgrid is in.
  rossen: I think the workshops are great for feedback from the
          community but I want to keep the resolutions of the WG
          within the WG, and keep the public confusion to a minimum
          if possible.
  fantasai: To respond to that, I don't have any control over what
            other people say, so I don't see what I can possibly do.
            Do you want me to tell people to not write about it?
  rossen: No, I'm not asking you to do that, just set the stage from
          the beginning possibly that nothing coming out of these
          discussions are not in stone until their reviewed by the
  glazou: Rossen, I'm not sure if that is a problem since they're
          not part of the WG.
  glazou: Maybe we should reach out to Igalia to join the CSSWG, we
          would benefit from having them on the group.
  astearns: They have provided feedback to the list and helped out
            on CSS Shapes.
  tantek: That's still not membership.
  rossen: Good feedback, I'll reach out again

  astearns: I'm looking forward to seeing the spec update.
  fantasai: Me too.
  astearns: Adjourned.
Received on Thursday, 10 March 2016 11:40:44 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:09:01 UTC