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

[CSSWG] Minutes Lisbon F2F 2016-09-20 Part III: CSS Scroll Snap, Media Queries, Grid [css-scroll-snap] [mediaquereis] [css-grid]

From: Dael Jackson <daelcss@gmail.com>
Date: Tue, 15 Nov 2016 21:27:42 -0500
Message-ID: <CADhPm3sKj7kCosayQB52cVHqfXp4rPzMjb_C+76yg6qfBF81cA@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.

CSS Scroll Snap

  - RESOLVED: Defer the event model to the next level

Media Queries

  - RESOLVED: Do not add a less-than-srgb Media Query
  - RESOLVED: The new value (the the script media query) will be
              punted to the next level.
  - RESOLVED: Publish that (Media Queries 4) as a working draft


  - RESOLVED: block-axis baselines are not supported (confirmed!)
  - RESOLVED: percentage gaps and percentage tracks use same
              resolution method
  - RESOLVED: Percentages in intrinsically sized grids tracks and
              gaps will either get back computed or not.
  - RESOLVED: Grid to CR


Agenda: https://wiki.csswg.org/planning/tpac-2016#agenda

Scribe: frremy

CSS Scroll Snap

Scroll padding

  fantasai: We have one open issue, which is scroll padding.
  [Florian and fantasai are deciding who to present]
  Rossen: Matt wanted to be able to join for this issue
  <fantasai> https://github.com/w3c/csswg-drafts/issues/156
  Rossen: Let's change the order of topics.

Event Model

  fantasai: Another issue is the event model.
  fantasai: The proposal is to defer this to the next level.
  Rossen: Any objection?
  TabAtkins: I would rather have scroll snap as soon as possible.
  Rossen: Since there are no objection, let's call this resolved.

  RESOLVED: Defer the event model to the next level

  Florian: If you try to snap to something beyond scrolling reach,
           what happens?
  fantasai: The snap position is changed so that it becomes in range.
  Florian: My understanding is that is says precisely how you snap
  Florian: but now whether you should do it.
  Florian: Another part seems to indicate you don't
  Florian: because the "corridor" is not defined.
  fantasai: Since you *shift* them inside range, they are.
  Florian: ok, this didn't used to be written this way when I filed
           the issue.
  Florian: I am convinced by the explanation now.
  Florian: I'll review again and will return if I find anything
           else, but its ok for now.

Media Queries

  Florian: 4 issues

Issue #3 - add a value specifically for the "less than sRGB" case?

  <Florian> https://drafts.csswg.org/mediaqueries/#issue-d9e3b586
  Florian: Issue 3 needs to be discussed.
  Rossen: The color one?
  Florian: Yes.
  Florian: Should we have a "shitty" color one, when you support
           colors, but poorly.
  dbaron: We already have grayscale btw.
  Chris: What would you do in that case?
  dbaron: There is one for srgb.
  ChrisL: Still not sure what the author could do with it.
  Florian: I am not arguing in favor, just trying to make sure we
  ChrisL: We want to go up, not down.
  LeaVerou: Devices with small gamuts typically display colors as
            less saturated.
  LeaVerou: So you might want to adapt.
  dbaron: There are more than just "non-srgb" and "close-to-srgb"
  LeaVerou: How about a percentage of coverage?
  Florian: Any measure won't be expressive enough.
  LeaVerou: It's not perfect but looks sufficient.
  Florian: How about one point "less srgb but still better than

  fantasai: We should have a note.
  fantasai: explaining what matches what
  <fantasai> explaining what it means to match not sRGB
  <fantasai> which is implied by the spec, but not clear to readers

  dean: The issue is also browsers that just do not support the
        media query
  dean: if you try to detect "not-srgb".
  Florian: It is a general issue.
  dean: But now makes it worse.
  Rossen: Proposed resolution is then to resolve as won't fix.
  Rossen: No objection?

  RESOLVED: Do not add a less-than-srgb Media Query

Script Media Query

  Florian: Other issue: script mq
  Florian: How about engines that run scripts, but only until some
           point (like printed).
  Florian: If the MQ doesn't tell you that it is supported, the MQ
           isn't very useful to depend on.
  Florian: Maybe a value would be great.
  Florian: But defining the threshold is tricky
  Florian: but if we define a threshold might force user agents to
          lie about it
  Florian: so we should probably keep it fuzzy.
  Florian: We discussed but we didn't resolve on that last time
  tantek: Any pointer to the old discussion?
  Florian: Nope, sorry
  < > https://drafts.csswg.org/mediaqueries/#scripting
  Florian: but this summary is about as good as it got
  <Florian> https://drafts.csswg.org/mediaqueries/#issue-51d591c9

  Rossen: Your preference?
  Florian: Not changing the spec, keep fuzzy.
  Rossen: fantasai, since it is your issue, what is your call?
  fantasai: I am fine with a fuzzy boundary, but I want at least one
            certainty value people can trust.
  Florian: A "onload" threshold could be an issue if there is a
  Florian: So I don't think it would help anyone.
  Rossen: But would it solve the issue?
  fantasai: I don't know, you guys know.
  fantasai: But authors want at least some way of knowing that.
  fantasai: if we define a baseline, at least authors can depend on
            that baseline.
  fantasai: Otherwise, people will rely on undocumented heuristics
            and we won't get interop.
  fantasai: I know almost no JS, but if I write a script, I want to
            know if it will be guaranteed to run, interoperably.

  tantek: Please capture this in github.
  tankek: Second question, did anyone prototype this?
  Florian: Not any implementation
  Florian: that I know of.
  tantek: Then lets assume none.
  tantek: Then let's mark as at-risk.
  Florian: Fine by me.
  <tantek> https://drafts.csswg.org/mediaqueries/#scripting
  <tantek> the summary artificially constrains what the feature
  tantek: (pasting what he just read)
  tantek: That description constrains the use case.
  tantek: It could be used to do more things.
  tantek: So it's misleading.
  Florian: I am fine doing this editorial change.
  <bkardell> Is it actually useful to detect the opera mini case?
             Because it is an arbitrary cutoff
  <gsnedders> bkardell, Yes. And it's horribly awkward. See all
              usage of :root.no-js etc.

  dbaron: If you want to figure it out, you need use cases where css
          needs to be different based on javascript running
  dbaron: why not just have the script do something.
  dbaron: Like removing classes that will trigger the behavior
  dbaron: assume it won't run
  dbaron: then cancel the effect.
  <dino> 100% agree with dbaron
  TabAtkins: It's cheaper on MQ.
  TabAtkins: So performance might be better.

  tantek: What is this nojs class nonsense, you can just flip the
          stylesheet to enabled.
  LeaVerou: Reality is, all big websites use a nojs class that they
            remove via JS. They do not toggle stylesheets, because
            this is easier for maintenance.
  TabAtkins: Friendlier to bundling.
  <dbaron> that said, I think the main use case is really just "is
           script enabled"?

  * jcraig wonders if you couldn't use a custom -scripts-loaded
           media feature

  Florian: Can we just agree on a "something will run, at least"?
  dino: Let's set the print baseline.
  dino: When the rendering finalizes, scripts stop running.
  tantek: ok, then lets call that value "onload"

  gsnedders: Has Opera said if they're going to implement this
             middle value? has anyone?
  simonp: Opera Mini is still using Presto and we're not going to
          implement any new features there.
  gsnedders: So is it theoretical only?
  LeaVerou: Google crawler does run some scripts.
  eliott: Google crawlers won't report that.
  eliott: We just act like if we were really loading the page, right?
  Florian: Then we can make the entire MQ as at-risk
  tantek: Let's punt the new value to the next level.
  Rossen: Would you oppose that?
  Florian: I don't oppose either way.
  tantek: Lack of prototype is a strong signal to punt it.
  Rossen: Any objection?

  RESOLVED: The new value will be punted to the next level

  ?: what to do with intermediate value?
  dbaron: I think it should probably match what people do with nojs
          classes, which means those implementations should return

  Rossen: What about the entire MQ?
  Florian: We should keep, as at-risk.
  Florian: Print is a valid use case.
  Rossen: Proposal is to mark it as risk, then. Objections?

  RESOLVED: Keep the script-detecting mq, but mark as at-risk in
            current level

  Florian: We now need to make a disposition of comments
  Florian: but we went through all the known open issues.

  Rossen: Okay, anything else on the topic?
  Florian: no, I'll ask for CR when we are done with these
  (various +1)
  tantek: Ask for a review after you made those changes, please
  Florian: OK

  RESOLVED: publish that as a working draft


  Rossen: There was a grid issue to be discussed?
  <fantasai> https://drafts.csswg.org/css-grid/issues-wd-20160519

Baselines (Issue 14)

  fantasai: First one is the baseline issue.
  fantasai: We decided to not to have block-axis baselines
  fantasai: but original poster isn't very happy.
  fantasai: proposal is: given lack of review, we should drop the
            feature for now, but maybe consider for later addition.
  fantasai: For a while, it is not expected you can make it work
  Rossen: Anyone objecting to keep the current resolution not to
          work on block baselines?

  jet: I am just wanting to check that it is what we are going to
  fantasai: I can also make it undefined.
  fantasai: The point is not to make it prevent the spec to go to CR
  jet: Wait wait wait.
  jet: Let's see if we match first.
  fantasai: Can I get a response today?
  jet: I hope so.
  <jet> fantasai: bug 1151204 btw

  tantek: Would it be possible we match others?
  Rossen: Not us, we don't have vertical baselines at all
  dbaron: Why would an author want that?
  dbaron: They can make the whole grid vertical.
  fantasai: Mixed mode.
  dbaron: Seems like the case you describe should be described in
          the other way, and you don't have the problem.
  fantasai: Yeah, it's just a convenience in that case.

  <fantasai> Discussion was about block-axis baseline alignment, for
             example by having a column of 5 author bios which are
             horizontal-tb grids with vertically-written author
             names in the first column of each bio item
  <fantasai> and then you want to align along the block axis the
             vertical bio names within the column of the parent grid
  <fantasai> dbaron was saying that you could just make the items
             vertical and make the rest of the content inside them
  <fantasai> and that would solve the problem
  <fantasai> and agreed that we should not have block-axis baselines
             as a feature
  <dbaron> but my point was that if you have a grid item where the
           thing you want to align is vertical, then structurally
           that grid item is vertical, with some horizontal stuff
           inside -- and then you don't need block-axis baselines

  Rossen: Just a reminder, we want to keep an existing resolution.
  Rossen: How about we resolve again, and you reopen if you need?
  jet: Looks fine to me.
  Rossen: Anyone else want to object?

  RESOLVED: block-axis baselines are not supported (confirmed!)

  Rossen: next issue?

Percentage margins and intrinsic sizes
  Scribe: gregwhitworth

  fantasai: The only other issue is % gaps.
  fantasai: We resolved to treat them as empty tracks.
  fantasai: mats disagrees as he thinks they should back resolve the
  fantasai: I think that Ilgalia has implemented intrinsic percent
            to auto and back computing other ones.
  Rossen: Wait, they're not symmetric.
  fantasai: No, I don't think so.
  fantasai: This deals with how to deal with % in CSS in general.
  fantasai: Let's say you have a float and a block inside that with
            %s and it will overflow.
  fantasai: We can't change that because of back compat.
  <fantasai> https://github.com/w3c/csswg-drafts/issues/347
  dbaron: We do back tracking for margin/paddings when inside of a
          shrink wrapped container.

  fantasai: If we go with the order of importance then we show go
            with what Gecko does.
  fantasai: That's what author's want.
  fantasai: Where we don't have a back compat issue do we want to
            fix them or fallback to auto.
  Rossen: We've discussed this in the past.
  Rossen: Our experience in the area is that this is very fragile
          especially when %s go over 100
  Rossen: so trying to backcompute the margins becomes really crazy.
  Florian: What does it mean if it is over 100%
  dbaron: I think the answer there is to only deal with it in in
          maxcontent widths and not mincontent widths
  dbaron: that way you'll be ok.
  Rossen: At the very least min and max are supposed to be treated

  fantasai: I think I have a bunch of related questions, the key one
            here is gaps.
  fantasai: We figured it'd be nice if the gaps are handled similar
            to tracks, and that's what Mats has been arguing for
  fantasai: that's one option.
  fantasai: The other option is to make them compute the same and
            fallback to auto.
  fantasai: Make them compute the same but have them both back
            compute the %s.
  Rossen: Our opinion is #2.
  Rossen: Behave consistently and fallback to auto
  Rossen: Consistency over inconsistency
  Rossen: and implementation simplicity over complex % back tracking.
  Florian: As in it's hard for browsers to get them right?
  Rossen: Yes, especially when you nest them.
  dbaron: I'm not sure what nesting them has to do with it.
  dbaron: You go level by level resolving the % against that of the
          intrinsic width.

  fantasai: I don't have an opinion on this.
  fantasai: It would be good to hear from the Blink folks.
  ojan: Hi.
  dbaron: It would help if someone explained the issue.
  dbaron: [draws a diagram on the board]
            <img src="100x100.png" style="margin-left: 20%">
  dbaron: We make the intrinsic size 125px
  dbaron: and the whole thing fits.
  dbaron: Gecko does this for margins and padding in this case, and
          other impls don't.
  dbaron: What we're talking about is doing this sort of thing for
          grid stuff.
  dbaron: So the alternative here, is if you ignore the % you make
          the intrinsic width 100px
  dbaron: you end up with a margin that is 25px and it overflows by
  dbaron: If you ignore the percentage, you make the div 100px, and
          the margin is 20px, and it overflows.
  Florian: Which doesn't sound like what an author would want.

  fantasai: I think there are actually two things happening here
  fantasai: One of them is: if you have a child box of an
            intrinsically sized element for grid we would have a
            track that is in a shrink wrapped grid container.
  fantasai: We can say that % depends on an indefinite size and
            treat it as auto and we won't have the overflow problem.
  dbaron: I don't think that's quite true.
  dbaron: One of the things this gets you, if you have the image
          inside of the grid track and says 20% and the image is
          100px and the track needs to be 20% of the parent then
          this will cause overflow.
  dbaron: Tables do this, nothing overflows.
  TabAtkins: Let's keep that in tables.
  dbaron: You might have overflow but it depends on the sizing the
          of the tracks.
  dbaron: If you end up with a 300px grid and then you say, this
          piece is 20%.
  Florian: That's not what fantasai is saying, it's ignore.
  dbaron: For everything or just intrinsic sized items.
  fantasai: For everything.
  dbaron: That's ok too.
  fantasai: I don't want overflow.

  Rossen: I want to timebox this discussion.
  Rossen: There are two things we need to decide, do we want
          consistency with gaps and tracks (in regards to resolving
  dbaron: So treating them as a 0 even though you asked for a %
          there will be nothing there.
  ojan: That seems fine to me.
  Rossen: What does?
  ojan: If you put an % sized gap on an intrinsic sized track that
        seems fine to 0 them out.

  fantasai: So Mats Palmgren said we should back compute on gaps,
            not tracks because it's more complex.
  fantasai: So we end up with 3 options.
  Rossen: So in other words, two of them would be consistent and one
          of them would not.
  Rossen: Would any one object to keeping them consistent?
  Rossen: Let's call it resolved.

  RESOLVED: percentage gaps and percentage tracks use same
            resolution method

  Rossen: Now on to the other part, if they're consistent are we
          back computing %s or not?
  Rossen: Does anyone object to not back computing %s on tracks?
  dbaron: I would like to hear actual author feedback.
  Rossen: Are there any objections?
  jensimmons: I don't know what you're discussing?
  gsnedders: I think asking for author point of view makes a bit of
             sense, but, I think back track has to be there or it
             does not make sense.
  dbaron: What are the use cases for intrinsically sized grids.
  dbaron: I feel like it's mainly used for top down not bottom up.
  jensimmons: It's pretty big deal honestly.
  jensimmons: People will expect the math to add up.
  <rego> a simple example of a percentage gap and how it actually
         works in both FF and Blink/WK implementations:
  <rego> tracks work exactly the same right now, so using: grid:
         100px 10% 100px / 200px 10% 200px; behaves consistently

  fantasai: Let's say you have a grid, it's floated, it's
            intrinsically sized.
  astearns: What if we wait to get more author feedback rather than
            just getting feedback from the author in the room?
  ojan: I would like to figure out if we can do what Gecko does.
  dbaron: The way table column width assignment is very similar to
  ojan: There are two things we can do offline: 1 get author
        feedback and 2 get desire to implement this from UAs.
  fantasai: We will keep the resolution and then spec out both and
            fix this in three months in Seattle.
  fantasai: Mark it undefined so we can go to CR
  <gsnedders> I'll also note after what was minuted for what I said,
              Rossen asked if I'd object, and I said "yes" (somewhat

  RESOLVED: Percentages in intrinsically sized grids tracks and gaps
            will either get back computed or not.


  fantasai: We would like a transition to CR.

  RESOLVED: Grid to CR

  <ChrisL> (I was just asking fantasai about DoC etc and wide review)
Received on Wednesday, 16 November 2016 02:28:46 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:52:53 UTC