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

[CSSWG] Minutes Telecon 2016-08-31 [css-align][css-tables][css-flex][css-values][cssom-view][mediaqueries]

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 31 Aug 2016 20:38:34 -0400
Message-ID: <CADhPm3s2vHS5WE9568qHSBe5V1Jf8pCZz4JVUu58NFGr4SaRig@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.
=========================================


TPAC
----

  - A reminder that the registration closes and registration fees go
      up soon.
  - gregwhitworth will likely be the one to speak at the dev meet-up
      and he'll cover topics around Grid.

Synthesized baselines seems like a breaking change
--------------------------------------------------

  - The behavior of what we do when there isn't a natural baseline
      is inconsistent both between specs and between implementations.
  - The proposals of what to standardize around were:
      A. Make boxes without a natural baseline and boxes
          establishing an orthogonal flow synthesize a baseline.
          A.1 Base this synthesized baseline on the margin box edges
          A.2 Base this synthesized baseline on some other box edge
      B. Make boxes without a natural baseline and boxes
          establishing an orthogonal flow use start alignment
          instead of trying to synthesize a baseline.
      C. Something else.
  - RESOLVED: Accept option A2 with the modification that we're
              talking about the border box.

Add <number-optional-number> type
---------------------------------

  - Several people had reservations on adding a new syntax (+#) to
      make it easier to read a legacy behavior that could still be
      written as [ <foo>+ ]#
  - RESOLVED: Don't add any new syntax, just add a note explaining it.

Algorithm of `Element.offsetParent`
-----------------------------------

  - RESOLVED: Adopt the Gecko/Edge behavior and specify that
              .offsetParent is based on the nearest abspos
              containing block or table cell

Media Queries
-------------

  - RESOLVED: Accept the proposal (Proposal: Make the
              device-width/etc MQs use the same concepts as CSSOM is
              using for returning device dimensions.)
  - The group began discussing adding device-pixel-ratio but didn't
      have time to reach a decision
      - One opinion was that it shouldn't be added in order to
          encourage people to use 'resolution'
      - The other opinion was because '-webkit-device-pixel-ratio'
          didn't obviously translate to 'resolution' 'device-pixel-
          ratio' should be added to aid authors.
      - Right as conversation was wrapping up, smfr asked a question
          about 'window.devicePixelRatio' which he was asked to post
          on github to allow further conversation.

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

Agenda: https://lists.w3.org/Archives/Public/www-style/2016Aug/0086.html

Present:
  Rossen Atanassov
  Tab Atkins
  David Baron
  Bert Bos
  Tantek Çelik
  Dave Cramer
  Simon Fraser
  Daniel Glazman
  Dael Jackson
  Brian Kardell
  Brad Kemper
  Peter Linss
  Myles Maxfield
  Thierry Michel
  Michael Miller
  Edward O'Connor
  Simon Pieters
  Anton Prowse
  Matt Rakow
  François Remy
  Florian Rivoal
  Andrey Rybka
  Geoffrey Sneddon
  Alan Stearns
  Greg Whitworth
  Steve Zilles

Regrets:
  Rachel Andrew
  Jen Simmons

scribe: dael

TPAC
====

  Rossen: Let's get started.
  Rossen: Hello everyone.
  Rossen: Any additional agenda items to bring forward?
  fantasai: Is the grid baseline issue on there?
  Rossen: It is.
  Rossen: It's the first one on the agenda.

  glazou: A reminder about TPAC. Registration fee is about to
          increase and registration will soon close.
  glazou: If you haven't it's good to do ASAP.
  Rossen: Good point. Also please continue to add agenda topics.

  Bert: Is the dev meetup on?
  Rossen: I might have missed it. Let's start there.
  Bert: Can we propose someone to speak at the dev meeting on the
        Monday evening of TPAC?
  Rossen: Does it need to be 1 person?
  Bert: It's 15-20 minutes. It could be more. We can all go, it's
        just the talk is short.
  Bert: Do we have an interesting topic and someone to deliver?
  Rossen: There were proposals on the private list. One from
          astearns about the talk on the CSSWG and call for help. I
          proposed grid and volunteered gregwhitworth who can do a
          shortened version of the Sydney talk.
  Rossen: One is more process/PR and the other more technical.
  Rossen: I'm happy with either.
  Bert: I think grid would be interesting if gregwhitworth is
        available.
  gregwhitworth: Sure.
  gregwhitworth: I'll need to update it, but I can try to shrink it
                 down.
  Bert: I'll connect you with Gerome who is in charge of the talks.
  Rossen: Anything else on this?

  Bert: Nope. Reminder charter review ends soon and we need more AC
        reps and companies to review. If yours hasn't, please do so.
        We have 2 days.
  Rossen: Great reminder. Please update your AC rep and have them
          respond.

Synthesized baselines seems like a breaking change
==================================================

  fantasai: I'm having connectivity issues, but the summary is in
            the link.
  fantasai: The basic issue was that for writing modes...right now
            the behavior of what we do when there isn't a natural
            baseline is inconsistent. Implementations don't agree,
            specs don't agree. There were several options presented.
            I'd like a resolution.
  Rossen: One comment...I've edited your comment to say Edge matches
          Chrome so there's a bit of interop between Edge and Blink.
  fantasai: Okay

  fantasai: Just want comments. Does anyone need more explanation?
            What's helpful here?
  <Rossen> http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=4416
  Rossen: I think a good way to move forward, I'll paste the example
          and people can look.
  Rossen: I think it's concise and to the point.
  Rossen: Are people reviewing? Or are we waiting for someone to
          talk?
  Rossen: I think fantasai could elaborate on concerns and proposals.

  fantasai: Is jensimmons, rachelandrew, or leaverou on the call for
            an opinion?
  [they aren't]
  fantasai: We have a couple of options. 1 is make boxes without a
            natural baseline synthesize one. 2) If there's no
            natural we use a fallback. If you use a fallback the
            author could have gotten that from defining it on the
            item instead of synthesize.
  fantasai: If we synthesize we have to decide if we do it on margin
            box edge or another box edge.
  Rossen: Reading your comments and looking through this I agree we
          want consistency. If we synthesize it better be the same.
  fantasai: I agree.
  Rossen: If we make the...align with the inline model so based on
          the margin box...that is the more interesting topic we
          should decide on. I'm not sure margin makes the most sense
          for grid. Border may make more sense as it gives you visual.
  fantasai: I have no opinion on this.
  Florian: Sounds reasonable on the face of it.

  Rossen: What do people think? Other opinions?
  Rossen: Do we pick one of fantasai options?
  Rossen: I prefer A2 which is they're synthesized based on the
          border box edge.
  frremy: I agree.
  Rossen: So we have some votes for A2.
  <tantek> I have been trying to read and understand this issue.
  <tantek> A2 with border-box seems reasonable.
  Florian: Weak agreement.
  <Florian> (as in: I agree, but I haven't thought about it for very
            long)
  <SteveZ> I agree that visually border box makes more sense, but in
           inline the alignment is on margin edge so the result
           would differ inline and across grid areas

  Rossen: What I'll do because I want to move the conversation
          forward and it's holding Grid spec up I'll list the options.
  Rossen: I'm hoping we can get resolution on one.
  <Rossen> A. Make boxes without a natural baseline and boxes
              establishing an orthogonal flow synthesize a baseline.
  <Rossen> A.1 Base this synthesized baseline on the margin box edges
  <Rossen> A.2 Base this synthesized baseline on some other box edge
  <Rossen> B. Make boxes without a natural baseline and boxes
              establishing an orthogonal flow use start alignment
              instead of trying to synthesize a baseline.
  <Rossen> C. Something else.

  fantasai: bradk just joined. Do you have an opinion?
  bradk: I just joined.
  Rossen: We're talking about if we should synthesize baseline for
          grid or flex with orthogonal flow and ones with no inline
          content. If we do synthesize do we use margin box, border
          box or something else
  Rossen: I posted the options and we're trying to narrow down.
          Currently there's synergy around A2.
  <fantasai> bradk:
https://github.com/w3c/csswg-drafts/issues/373#issuecomment-242863486

  SteveZ: Two comments. 1) inlines align on margin box and so you
          get some interesting things from alignment inline vs row
          or flexbox. I'm not sure that's important. 2) if you use
          margin edge you can use big margins to adjust alignment
          and get centering with a bit of playing
  Rossen: That's a great point. I would argue the opposite. I
          wouldn't try and align grid and flex with inline in that
          respect since alignment and role distribution and sizing
          are all dependent on the sizing of the items and it
          doesn't matter for inline.
  Rossen: So for both complexity and interdependences I would argue
          the opposite.
  <tantek> steve makes a good point about potential utility of
           negative margins
  <fantasai> tantek: yes, it was mentioned in my writeup. Along with
             some problems with it
  <fantasai> tantek, One problem is that negative margins will cause
             overlapping with subsequent content -- this is less of
             a problem with inline layout because of the struts
  <tantek> fantasai, ok. I don't have strong feelings about it.
  <fantasai> tantek, Another consideration is that the
             'alignment-baseline' property can give control over the
             alignment point of synthesized baselines
  <fantasai> tantek, and a future property is on the radar for even
             more control

  bradk: Would you want to align with table cells? How they align?
  Rossen: I think they use border box or content box.
  Rossen: I think gregwhitworth and frremy were looking into table
          cells
  bradk: I don't have a strong opinion.
  Rossen: So bradk if you don't have strong opinions
  fantasai: table cells align content box
  Rossen: They're wierd.
  <tantek> fantasai - does A2 with border-box seem reasonable to you?
  <fantasai> tantek, yeah. Assuming the baseline controls, it's
             likely the best solution.
  <tantek> ok
  <fantasai> without those controls, it's less clear...

  dbaron: A bunch depends on what there are use cases for and what
          can happen in another way. There's a bunch that can be
          accomplished by using a non-baseline alignment. There's a
          bunch that can happen from making it a inline block inside
          a grid cell. Part of what's not clear to me is what are
          the use cases that you can't do in another way and what
          are people trying to do
  Rossen: There's already a bunch of alignment options to center.
          People use - margins in the inline is because they don't
          have other ways to center align. I'm with dbaron to allow
          all the other alignment options work itself and the
          baseline is a baseline.
  Rossen: The other comment on the table cell alignment model,
          that's weird because usually borders are on the table grid
          level and shared between table cells. That's why there it
          makes sense to align on content box
  fantasai: Table cells do content alignment instead of here we do
            self alignment. Conceptually it's do you move the
            contents or the box. So they will necessarily be
            different cases.
  fantasai: I'll throw in my hat for align on the border box. There
            are cases you might want items to align to each other.
            Border box is the visible part of the box and the margin
            doesn't provide that visible piece. Reason for margin is
            you can adjust the alignment point, but we have controls
            like alignment-baseline that let you determine that
            alignment point.
  fantasai: Those controls effect how the baseline is synthesized.
            Also SteveZ pointed out for inline we'd need more fine
            controls and that's something that we could apply here
            as well.
  <Rossen> +1 to everything fantasai said
  <gregwhitworth> sounds like it's border box then
  fantasai: So I'm leaning toward border box option because that's
            more in the spirit.
  fantasai: Also in flex and grid using a negative margin to adjust
            the alignment point can cause overlapping content.
  fantasai: Anyways, that's what I'm thinking.
  Rossen: I agree with fantasai.

  frremy: Are we sure we do content box on table rows?
  frremy: I'm not sure what's what we do.
  fantasai: We're sure
  <fantasai> *of course* they align on the content box; if they
             didn't the borders wouldn't align across the row!
  <fantasai> if you put inline-level content *inside* the table
             cell, then that will align on its margin box
  Rossen: Are you asking what implementors do now?
  frremy: Yeah.
  Rossen: Currently there is Edge and Chrome align on synthesize
          baseline based on margin box. Firefox seems to align on
          border box.
  Rossen: Or maybe margin box.
  Rossen: There's no interop at the moment. Given there's no perfect
          interop and we have a model that makes sense and is easy
          to explain and seems obvious we should try and resolve and
          clean up the spec and allow implementors to follow up.

  Rossen: To move forward, proposal is: resolve on option A2 with
          the modification that we're talking about the border box.
  Rossen: Objections to specifying that [reads option a2]

  RESOLVED: Accept option A2 with the modification that we're
            talking about the border box.

Add <number-optional-number> type
=================================

  Rossen: Who wants this one?
  Rossen: TabAtkins?
  TabAtkins: We skipped this last week, right?

  TabAtkins: Basic option is to make the grammar clearer on how to
             handle weird SVG behavior, particularly where there are
             optional commas. For single we're fine, but for
             arbitrary lists you can't quite mark it. You could use
             +# as a stacked combinator, but that's not technically
             possible. Proposal is to add it to the grammar and link
             to SVG but mark it as shouldn't be used and it's legacy
  Florian: Any drawback to that?
  TabAtkins: Not that I know of.
  dbaron: Draw back is another symbol for people to learn and read
          about.
  TabAtkins: Yeah. A combo of two symbols. Hopefully with the
             linking to a definition no one is using it.
  Bert: I'd prefer not to add a new symbol, but I'm not strongly
        against.
  TabAtkins: It's combining two existing combinators in a way that's
             technically not possible right now.
  <TabAtkins> <foo>+#

  Rossen: So any other opinions?
  * fantasai doesn't have a strong opinion on this
  myles: I weakly prefer that if we can do this with existing
         grammar something new doesn't need to happen.
  <TabAtkins> <foo> [ ,? <foo> ]*
  TabAtkins: I just put in how to write it without this.
  TabAtkins: It's that odd doubled grammar thing that we tried to do
             away with by introducing #. It looks pretty hefty.
  <fantasai> [ <foo>+ ]#
  * Bert prefers with the [] as fantasai did
  myles: Looks fine to me. I don't think we need something new.
  Florian: It parses right but implies a different tree?
  TabAtkins: No. Only difference is collapsing it so + and # are
             next to. It's only because we say combinators are only
             for non-terminals.
  fantasai: I think you mean we can't stack multipliers.
  TabAtkins: Yes.
  TabAtkins: Or rather we can't do it directly. We can do it with
             the indirection of a square bracket.
  fantasai: I don't care either way.
  <bradk> [ <foo>+ ]# seems clear enough to me
  <astearns> I think [ <foo>+ ]# is fine

  <frremy> should we vote, then? yay, nay, don't care?
  Rossen: There were at least a couple of people preferring not to
          have it and a couple of people who don't quite care but
          wouldn't mind adding it.
  Florian: And since it's legacy only thing maybe adding new isn't
           that important.
  TabAtkins: Then I'll probably still want to add a non-normative
             bit about the [] pattern thing. I'll want some
             indicator that this pattern has a particular meaning
             that's slightly different than what it seems to indicate.
  <astearns> +1 to clarifying note
  fantasai: I have no problem with a note. I might have comments on
            the wording, but a note is a good idea.
  <Florian> +1
  <zcorpan> [ 1+ ]#

  <TabAtkins> (The specific meaning is that [ <foo>+ ]# seems to
              mean "a comma-separated list of space-separated
              things", but in SVG it just means "a list that can be
              separated by spaces or commas".

  fantasai: Proposal is add a note explaining the syntax, but don't
            add anything.
  Rossen: Sounds fine. Can we resolve on this? TabAtkins do you have
          a problem with that?
  TabAtkins: Not enough to object.
  Rossen: Any objections?

  RESOLVED: Don't add any new syntax, just add a note explaining it.

  <Rossen> https://github.com/w3c/csswg-drafts/issues/332
  Rossen: We covered #3 as a part of #1
  fantasai: I don't think there's anything else there

Algorithm of `Element.offsetParent`
===================================

  <Rossen> https://github.com/w3c/csswg-drafts/issues/409
  Rossen: Anything new on this we need to talk about?
  Rossen: I think that was Florian?
  Rossen: Or maybe smfr.
  zcorpan: It was me.
  zcorpan: There were interop problems and it would be good to
           decide what we want the API to do. Most people prefer
           Gecko from the comments: matching containing block for
           abspos descendents. That's not what the spec says. If you
           have a non-none transform that has a containing block it
           doesn't affect .offsetParent
  dbaron: In some or all implementations?
  zcorpan: Some. It does affect in Gecko. Not in Blink or Webkit.
  frremy: It does in Edge. We're like Firefox.
  zcorpan: I suggest we align with Edge and Gecko.

  smfr: My comment is I agree it's good to standardize, but the
        guarantee for authors is you can walk up the chain, pop an .
        offsetLeft and compute. I think it's essential that you can
        compute a position.
  zcorpan: .offsetParent also picks up things like table cells which
           is a quirk in the API.
  dbaron: Presumably what smfr said will hold if .offsetTop and
          .offsetLeft are relative to the .offsetParent.
  zcorpan: They are in the spec.
  smfr: I don't think they take transforms into account.
  zcorpan: Spec says transforms are ignored for .offsetTop and
           .offsetLeft
  <bkardell> that is my recollection as well from some recent use

  smfr: Do any implementor have feedback on compat issues?
  Rossen: We haven't made changes since IE8. I would expect that
          those are used a lot.
  Rossen: So changing them will potentially have compat risks.
  smfr: Right. And I think Blink has changed since webkit fork. So
        I'd like feedback from blink if they saw compat issues.
  TabAtkins: I'm not sure. We'll have to investigate.
  smfr: Actually I'm not sure they've changed.
  Rossen: So TabAtkins can you verify if you've changed?
  TabAtkins: Yeah.
  <smfr> looks like blink added checks for tables and table cells
  Rossen: So I think there will be some compat risk for whomever
          changes. So we'll have to evaluate that and minimize the
          damage by spec whatever we need to spec.
  Rossen: At the same time if there are differences, especially
          between Blink and Webkit, that would be a good indicator
          people don't rely on this.
  <smfr> oh, no, they just moved code around

  Rossen: I don't believe we're ready to resolve.
  zcorpan: What do we need to resolve. Do we need to talk to a
           browser shipping something else? More opinions?
  Rossen: We'll have to have a clear spec as to what is expected, as
          to what the exact rules are for .offsetParent so everyone
          can compute the same. And then ID the compat issues.
  Rossen: There will have to be changes for someone. Last week I
          started writing a quick list of rules that we use for Edge.
          Once I'm done I'll add it to the issue and we can go from
          there. And it would be great if you can outline something
          similar from other impl. zcorpan posted a link to source
          code which not everyone can look at.

  smfr: Webkit would be willing to change behavior if we have a good
        spec soon. It's early in our release cycle.
  Rossen: So zcorpan do you have currently proposed text or a
          different proposal than the spec?
  zcorpan: Proposal is to change the spec to make .offsetParent
           return the ancestor that's the containing block of the
           abspos parent.
  Rossen: Did you say the nearest ancestor for abspos element or
          simply the containing block of the element and if it has
          to be abspos.
  <bkardell> just absolutely positioned, or relatively too?
  <zcorpan> "return the first ancestor which is a containing block
            of absolutely-positioned descendants"
  zcorpan: Doesn't matter what the element itself is. Nearest
           ancestor that's a container for an abspos element, even
           if there isn't one.
  Rossen: And there's the quirk with table cells?
  zcorpan: Yeah, that's still there.
  Rossen: And smfr you said you'd be willing to try this out?
  smfr: Yes.

  Rossen: Does anyone object? Chrome people?
  Rossen: TabAtkins?
  TabAtkins: I'm fine.
  zcorpan: I spoke to rune and mårten from Opera and they preferred
           Gecko. They're likely not aware if it breaks the web.
  Rossen: Let's move to a resolution and we'll find out from webkit
          impl experience and see what compat looks like. Sound
          okay? Objections?

  RESOLVED: Adopt the Gecko/Edge behavior and specify that
            .offsetParent is based on the nearest abspos containing
            block or table cell

Media Queries
=============

device-width media feature and privacy
--------------------------------------

  Rossen: I believe most remaining topics are Florian's. Order
          preference?
  Florian: First is quick.
  <Rossen> https://github.com/w3c/csswg-drafts/issues/426
  Florian: Maybe zcorpan can say more, but there's a change in OM
           View where various places that refer to the size of the
           screen are a problem. There's no great use cases, but it
           leaks private info. In order to allow browsers to hide
           that anywhere that you're supposed to give a screen
           measurement you can do the exact measurement or another
           measure.
  <zcorpan> the other thing is indeed the viewport
  Florian: In the MQ spec where we have ones that refer to screen
           size we propose we allow either the screen or the new
           area. It doesn't force a change, but it allows browsers
           to provide more privacy.
  <zcorpan> https://drafts.csswg.org/cssom-view/#web-exposed-screen-information
  Florian: They're deprecated, but we have to support them.
  TabAtkins: I strongly agree with this.

  Rossen: How does this align with screen object?
  Rossen: zcorpan?
  Rossen: The screen available width and height may return different
          values?
  zcorpan: Other way around. CSSOM View spec says now that
           screen-available-width or screen-width you can do what
           browsers do today or return size of the viewport.
  zcorpan: For not device-width leaks screen size.
  Florian: By using the same term browsers switch both or neither.
  Rossen: That's fine. For browsers in full screen it'll evaluate to
          the same. I don't have a disagreement.
  TabAtkins: We're not looking for the OM change, we're looking to
             make these things do the same thing.
  Rossen: So do we have a summarized proposal for resolution?
  Rossen: Any objections to the proposal?

  RESOLVED: Accept the proposal (Proposal: Make the device-width/etc
            MQs use the same concepts as CSSOM is using for
            returning device dimensions.)

Consider making device-pixel-ratio a standard alias
---------------------------------------------------

  Rossen: Anything in 2 minutes?
  <Rossen> https://github.com/w3c/csswg-drafts/issues/417
  Florian: We have resolution MQ that use to be under a prefix.
           Gecko has/will implement both resolution and
           -webkit-device-pixel-ratio, but they find it distasteful
           to have -webkit only, so they're considering
           device-pixel-ratio. This is just so that we have
           unprefixed as well as prefixed. I say don't because
           unprefixed is resolution.
  MaRakow: I agree with Florian. We haven't seen this in the wild
           and if we're trying to push authors we should move to
           resolution. Pressure is in one direction and fragmenting
           to two is detrimental.
  dbaron: I tend to think there's a lot of mind-share to
          device-pixel-ratio and so resolution doesn't make sense
          for what people want to use.
  <zcorpan> there's also window.devicePixelRatio,
            https://drafts.csswg.org/cssom-view/#dom-window-devicepixelratio
  <tantek> so basically, "resolution" lost the bike-shedding battle
           in the market
  hober: There's no disagreement from me that the name 'resolution'
         is bad
  Florian: It's out there so I don't think dropping resolution is an
           option.
  <bkardell> it seems like an alias is easier for authors

  Rossen: Do we believe we can resolve? We're top of the hour
  Rossen: One proposal is to drop -device-pixel-ratio.
  Florian: Reject proposal to add it.
  Rossen: Would people object to that? Especially people from Gecko?
  <tantek> flip the proposal around since the intent is to implement
           device-pixel-ratio
  <tantek> that's the question for which it should be asked if there
           are any objections

  dbaron: I'm pretty uncomfortable not simultaneously implementing
          the same thing unprefixed.
  Rossen: We have a bunch of those.

  Florian: Isn't that the same as doing -webkit gradient where we
           have old webkit syntax or the new syntax and they're not
           the same
  dbaron: From the names people can figure out what the new one is.
  Florian: Yeah, true.
  <tantek> the problem is that "resolution" is a crappy name, and
           has no easy discover-ability from -webkit-device-pixel-ratio

  smfr: Question on resolution. Does it change under page zoom, or
        is it capabilities of hardware?
  Florian: I don't remember, but it's the same as prefix.
  smfr: We've got this difference with window.devicePixelRatio. It
        seems to me that window.devicePixelRatio and the resolution
        MQ should be the same.
  dbaron: I think a bunch is not interoperable.

  myles: I think it's time.
  Rossen: We are at top of hour. I propose we leave this for next
          week and we can continue on github if people have opinions.
  Florian: smfr can you bring your question to github?
  smfr: Sure.

  Rossen: Remember to register for TPAC if you haven't. Talk to you
          next week.
Received on Thursday, 1 September 2016 00:39:35 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 1 September 2016 00:39:36 UTC