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

[CSSWG] Minutes Telecon 2016-03-23 [cssom] [css-values] [css-selectors] [css-2015] [css-exclusions] [mediaqueries]

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 23 Mar 2016 19:35:53 -0400
Message-ID: <CADhPm3vwz_FQqoNhp-HwMPcC35keH6_h_d=26o-jgm4jpzSNHQ@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.

CSSOM Selectors section review reminder

  - The Selectors section of CSSOM will be on next week's agenda and
      everyone should review it in advance.

calc() simplification for serializing specified values

  - Tentatively the group decided combine identical units and
      resolve all numeric and multiplication and division by numbers.
  - On next week's call this will be resolved formally after
      implementors have had time to speak to the appropriate

Rewrote grammar in terms of the Value Definition Syntax

  - Everyone accepted the rewrite and TabAtkins will add a note
      warning that if this is inconsistent with previous grammar,
      please send an issue because it's probably wrong

ch unit definition

  - RESOLVED: Accept this change:

Define <length-percentage> etc. productions

  - RESOLVED: Accept change for issue #5 of Values and Unit 3

Using the Snapshot to track pre-CR "shipping is okay" features

  - RESOLVED: Add edits to 2015 snapshot and then republish.
  - RESOLVED: Start an ED for 2016 snapshot.

Shortening minimum/maximum to min/max

  - RESOLVED: shorten minimum/maximum to min/max in exclusions values

Media Queries issues

  - RESOLVED: Remove the on-demand value from hover.
  - RESOLVED: Move light-level to the next level of Media Queries


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

  Tab Atkins
  David Baron
  Bert Bos
  Dave Cramer
  Alex Critchfield
  Elika Etemad
  Simon Fraser
  Tony Graham
  Dael Jackson
  Brad Kemper
  Ian Kilpatrick
  Myles Maxfield
  Thierry Michel
  Edward O'Connor
  Anton Prowse
  Matt Rakow
  Florian Rivoal
  Andrey Rybka
  Alan Stearns
  Ian Vollick
  Greg Whitworth
  Steve Zilles

  Rossen Atanassov
  Tantek Çelik
  Daniel Glazman
  Peter Linss
  Michael Miller

Scribe: dael

CSSOM Selectors section review reminder

  astearns: We should get started. Does anyone have additional items
            to add today?
  astearns: This is a reminder that we have an action on everyone to
            review the CSSOM Selectors section. It will be on the
            agenda next week. Please look and come with opinions or
            give feedback on the list.

calc() simplification for serializing specified values

  TabAtkins: In short, every browsers disagrees about how/when to
             simplify calc() expressions. We need to define it so we
             have a stable serialization and representation. So we
             need to figure out what to do. Everyone agrees on
             computed and used values that are calc(). Resolve
             everything as much as you can and you get a dimension a
             percent and a number
  TabAtkins: Specified values is the annoying part. Writing to a
             style sheet and reading from the OM, what simplifies?
             1px + 2px is 3px? If you have incompatible does it
             simplify? Edge does not, chrome aggressively
             simplifies, FF is in the middle.
  fantasai: I wanted to point out this is for the specified style.
            Computed is separate.
  TabAtkins: Computed is easy and consistent.
  dbaron: I thought Firefox was simplifying numbers and not other
          things. We needed to do that to do division by 0 testing.
  TabAtkins: I think that's what y'all do.
  TabAtkins: Y'all combine numbers and not anything else.
  <gregwhitworth> do you mind sharing the test so we don't have to
                  recreate it if you have it handy

  astearns: You said compatible measures could be collapsed, but I'm
            not sure that's always the case. Pixels and inches are
            different when printed.
  TabAtkins: No. Size may be different by they have a fixed ratio
             defined by spec.
  TabAtkins: We pinned that down about two years ago.
  Florian: I think it's even older.

  TabAtkins: So, what precisely if anything should be combined. We
             can say nothing, numeric sub expressions, also
             identicals, also compatibles. There's also a side
             question of multiplication and division can be resolved.
  TabAtkins: I'm happy with any answer. I don't think there's a big
             implementation burden for anyone, but we have to agree
             because we're all different.
  gregwhitworth: I don't have a strong passion, but have you gotten
                 any feedback from authors on this?
  TabAtkins: No, I haven't obtained any author feedback
  * fantasai suspects they'd want it more expanded than collapsed,
             since that's what specified styles are for

  dbaron: I'm not crazy about merging different units because in
          specified style we preserve units.
  <fantasai> +1 to dbaron
  TabAtkins: I have a slight preference for combining identical
             units because when we represent in the OM, we can't
             differentiate 10px + 10px from 20px. We'd like to
             resolve multiplication and division so that we don't
             have to represent those. We'd like a sum of united
             values to be consistent with OM work
  <SteveZ> how is 10px+10px different from 10px+1in?
  dbaron: I think we had tentative agreement to extend calc() for
          multiplication and division with units.
  TabAtkins: We had tentative plans, but that's a niche calc() use.
             We'd like the majority to be simple.
  dbaron: So you'd have two different OM representations.
  TabAtkins: Possible, or another list of complicated things and a
             list that's simple values.
  dbaron: That feels funny to me especially to design the initial OM
          to assume we won't do that.
  * fantasai is basically in agreement with all of dbaron's concerns
  TabAtkins: I know that dealing arbitrary united that need to be
             kept in some form will be complex. I don't want to
             design to be purposefully complex. I know whatever we
             do will have something on the edge. I want the majority
             as simple as possible to work with.
  astearns: Another possibility is to have a way of converting a
            calc() to a simpler expression in the OM so you wouldn't
            have to simplify what you're getting back.
  TabAtkins: That doesn't change my argument. The representation as
             a JS should be as simple as possible when we get it.
             Even when we get the complex, we want to drop it so
             it's simple. Even if under the hood you started with
             something more complex.

  dbaron: I'm okay with the conclusion, i.e.,the idea that you
          simplify identical units and simplify
  TabAtkins: We'd be fine with doing the same. Pulling back on our
             simplification so in and px are distinct. Safari
             matches us, IE is more different. What are your
  smfr: I'm fine with this for webkit.
  gregwhitworth: I'll want to talk to the devs to see how bad it
                 would be to change, but on the surface no strong
                 opinions against change.
  TabAtkins: I don't think it'll be hard, but I'm happy to let you
             chat and make sure.
  gregwhitworth: I'll let you know in the week.
  TabAtkins: Tentatively we combine identical units and resolve all
             numeric and multiplication and division by numbers.
  * fantasai thinks collecting feedback from authors is pretty
             important here

Rewrote grammar in terms of the Value Definition Syntax

  <astearns> https://lists.w3.org/Archives/Public/www-style/2016Mar/0254.html
  <astearns> https://lists.w3.org/Archives/Public/www-style/2016Mar/0267.html
  TabAtkins: We only had a few instances in the appendix for CSS.
             Selectors was one of the last and I wrote it in terms
             of syntax tokens. I had one small edit from Simon. As
             best as I can tell the grammar is now correct.
             Otherwise, this is a review request to make sure I
             didn't mess anything up.
  TabAtkins: Unless there's comments I don't have anything further.
  fantasai: We need a big warning that if this is inconsistent with
            previous grammar, please send an issue because it's
            probably wrong.
  TabAtkins: Happy to do that.
  <dbaron> yes, fantasai's suggestion of a warning is good

ch unit definition

  <astearns> https://hg.csswg.org/drafts/diff/398d30b81c76/css-values/Overview.bs
  astearns: There was a change. ^
  astearns: We just need a resolution on if the change is good.
  <dbaron> did you check https://wiki.csswg.org/spec/property-dependencies ?
  fantasai: There were two change sets. We're comparing the first
            sentence, in red, to the text in green. The second
            sentence in red wasn't there before.
  fantasai: We said the fallback is .5em and we changed that to
            account for when text orientation is upright and you're
            vertical the height should be 1em.
  Florian: I'm in favor.

  dbaron: Did you check property dependencies wiki?
  Florian: I believe FF already does this.
  fantasai: To the extent we have units that depend on font
            information, those units will depend on features that
            effect font, such as text-orientation. That's regardless
            of the change.
  dbaron: I think that's true, but we need to edit the wiki. I guess
          I should do that now.
  dbaron: I think this is the...it should be a fourth line in the
          type-based dependencies.
  Florian: I don't know if FF falls back to 1em in upright, but it
           uses the vertical metric in upright when available. In
           terms of dependency it seems about the same.
  dbaron: I think it's okay, it does need to be considered.
  fantasai: I was going by text orientation already effects font.
  fantasai: Regardless of this change, if we have a problem, we
            already had it.
  <dbaron> wiki updated
  astearns: So dbaron will update dependencies wiki. Any other
            comments? Objections?

  RESOLVED: Accept this change:

  Florian: Koji didn't like it, but wasn't willing to block, for the

Define <length-percentage> etc. productions

  fantasai: I was looking for the resolution where we decided to
            merge these into a single type, so we do need a
            resolution. There's one concern where we discussed
            adding keywords to calc() and if we're doing that, the
            point was to create a value type that was everything in
            calc() and we can't do that with a bunch of keywords.
  fantasai: That makes me question if it's necessary to have this
  TabAtkins: It's not always valuable. I think we...we eliminated
             the cases where a separate <length> wasn't combine-able.
  <fantasai> <length> | <percentage>
  fantasai: If you have <length> or <percentage> in the grammar it
            should always combine.
  TabAtkins: I think that's now true. One of the motivating examples
             was something we fixed. I think it makes our grammars
             more readable.
  fantasai: We can't extend this to include keywords which at some
            point will be combinable.
  TabAtkins: I'm willing to take on that burden when we hit it. We
             can say it takes values from this property plus <length>
             and <percentage>.
  fantasai: I'm fine if this is a syntactic shorthand it's fine.
  TabAtkins: So far there's no semantic difference. In theory would
             could create something that's a percentage and number
             and not combinable, but that's not recommended in our
             rules for percentages.

  <gregwhitworth> what keywords are we referring to?
  <gregwhitworth> or are they hypothetical?
  astearns: [read gregwhitworth question]
  fantasai: There's been requests to allow calc() to combine with
            auto and things like that and it's reasonable that we
            will at some point allow that.
  <gregwhitworth> oh, ok
  <gregwhitworth> interesting
  fantasai: That will allow us to have computed values and let us
            animate from 0 to auto which people want.
  <dbaron> (similar for min-content, max-content, etc.)
  fantasai: Right now it's <length> and <percentage> and combo there
            of, but I don't expect that restriction to hold in the
            future. To simplify grammar I don't mind. To have a pre-
            combined <length-percentage> I don't mind.
  <fantasai> <length-percentage> = <length> | <percentage>
  fantasai: I should be length and percentage 100% is = length.
  TabAtkins: If you say <length> and <percentage> separate you need
             prose so they use the same 0 base. <length-percentage>
             assumes that, but says they'll be defined so combinable.
  fantasai: I want it just to be a syntactic shortcut. We should
            just have it just as defined as grammatical. It needs to
            be defined for <length> or <percentage> or
  TabAtkins: If we ever defined something where they're not
             reliable, we shouldn't do that. It's a distinction
             without a difference. Your situation is identical to
             mine. Only if we really mess up will they become
  <dbaron> (worth minuting that fantasai and TabAtkins both agree we
           should never have percentage and length in a property and
           have them not compatible)

  TabAtkins: Back to the topic. Are there objections to making a
  astearns: fantasai you're fine?
  fantasai: As long as it's a short way of writing things, yes.
  TabAtkins: That's how defined in the spec.
  astearns: Yes, I agree with dbaron. We should never have
            percentage and length in a property and have them not
  <fantasai> ACTION: fantasai clarify the thing dbaron wrote above
             in the spec
  <trackbot> Created ACTION-761

  RESOLVED: Accept change for issue #5 of Values and Unit 3

  TabAtkins: We made that mistake for position where they're not
  fantasai: Technically they are.
  TabAtkins: They can't be a single unit until layout time. You
             can't say here's two amounts in px...
  astearns: This isn't the issue we're discussing.

Using the Snapshot to track pre-CR "shipping is okay" features

  <astearns> https://lists.w3.org/Archives/Public/www-style/2016Mar/0303.html
  TabAtkins: We should.
  astearns: I agree.
  gregwhitworth: How come we aren't adding this to 2016.
  <SteveZ> +1
  fantasai: It's a bunch of definitions added in 2015. It's fixing
            2015 doc.
  TabAtkins: Why don't we publish this under 2016 because it's 2016?
  fantasai: I see this as a correction to the previous snapshot.
            These were taken in 2015 and not documented. For 2016 we
            might add additional things. I want to distinguish. If I
            made a typo in 2015 I'd fix it. This is equivalent.
  <dauwhe> EPUB 3.1 will likely be referencing the 2015 snapshot
  TabAtkins: I understand the theory. Practically it's 2016 so we
             should publish 2016. If you want to correct 2015, go
             ahead. But let's publish 2016 which is 2015+changes.
  fantasai: We haven't added anything new.
  TabAtkins: We have. This thing. It is the year 2016. There are
             changes. Let's make it part of 2016. Let's not tie
             ourselves into semantic knots.
  astearns: I disagree it's a semantic knot. These should have been
            in 2015 so let's fix. WE should also pub 2016.
  TabAtkins: Fine. But let's publish 2016. As soon as we're aware we
             should touch the snapshot we should do a new year.
  fantasai: There's nothing to add to the 2015.
  <SteveZ> i agree that we should be publishing a 2016 and updating
           2015 for the reasons Tab is expositing.

  TabAtkins: I'd like to publish to put a new date on it. If people
             get used to year, they should be looking at the current
             year. If it's the past year it feels obsolete.
  fantasai: It's Q1 of 2016.
  TabAtkins: I will publish 2016 for you. We can get it done and
             update as needed. It's just there to help people. And
             it helps people know it's up to date.
  astearns: But if we publish in both we have a doc that looks up to
            date, but no different.
  TabAtkins: But it is up to date. It's the current date. There's no
             confusion about "it's 2016, but why am I looking at
             2015". It's the problem with dated URLs. They see
             something old in the URL and don't know why they're

  astearns: [reads dauwhe comment "EPUB 3.1 will likely be
            referencing the 2015 snapshot"]
  astearns: You don't care if it's 2015 or 2016, TabAtkins, but I
            think we should put them in both and I don't care if we
            have 2016 just yet.
  TabAtkins: So our desires are congruent. fantasai seems to
             actively not want 2016. Unless that's an objection,
             let's publish both.
  dauwhe: I'd like to see a change section in 2016 saying no changes.
  fantasai: That's going to be confusing. 2016 will have a lot of
            changes, but we'll publish one saying no changes and
            then we'll make changes. That won't have the same impact
            as the same.
  TabAtkins: I don't think public impact is important. It's useful
             to say what's stable.
  fantasai: Most of our drafts are at least a year old. I don't see
            this as a problem.

  gregwhitworth: I wanted to bring up why I brought this up. I
                 brought it up, and I'm cool with it in 2015, is
                 because it felt like we were pulling teeth for 2015
                 and we keep 2016 as a wiki and at the end of the
                 year we shout from the rooftops what we did in 2016
                 and that'll be the snapshot. Basically have it as a
                 wiki and at the end of the year we'll link to it.
  TabAtkins: Thumbs up.
  <TabAtkins> I agree with Steve too
  SteveZ: I wanted to say I think every snapshot should have a
          "what's new in 20xx" section. If you do that you don't
          have to put anything in it right now, that's consistent
          with wiki. Then anyone can look and see what's new. That's
          consistent with what we've done with drafts.
  fantasai: It's inconsistent with new levels of a draft. We don't
            do a level 4 until we have something to put in.
  TabAtkins: We do that because drafts aren't dated. They represent
             functionality. Snapshot is the state at this time. The
             2015 is what the state is in 2015. There's semantic
             value in the name. How much are you arguing that you
             object to the 2016 snapshot publishing?
  fantasai: I have a strong preference that we don't.

  astearns: I'd suggest that we put these changes in the 2015
            snapshot and start a 2016 wiki and we publish it at the
            end of the year using the wiki as a guide.
  Florian: Why not a ED?
  fantasai: I'm happy with just an ED
  TabAtkins: An ED is the same as a wiki for the editors.
  fantasai: And easier.
  astearns: I agree.
  <Bert> +1
  astearns: So, proposal: we put the edits in 2015 snapshot and
            start an ED for 2016 snapshot. Objections?
  fantasai: Sounds good to me. Can we also resolve to republishing
            2015 after the edits.

  RESOLVED: Add edits to 2015 snapshot and then republish.
  RESOLVED: Start an ED for 2016 snapshot.

Shortening minimum/maximum to min/max

  astearns: Rossen said it was okay but they shipped minimum/maximum.
            I'm okay
  <fantasai> It's easier to type also
  TabAtkins: I'm okay [missed]
  astearns: We use them in property names, but also in values.
  TabAtkins: Also in property values with min-content.
  astearns: So does anyone object to this change?

  RESOLVED: shorten minimum/maximum to min/max in exclusions values

MQ issues

Transition to CR

  <astearns> https://lists.w3.org/Archives/Public/www-style/2016Feb/0047.html
  Florian: I'll start with the last point...We're doing this to head
           to CR and put the less stable things into level 5. THe
           point is to solve these issues or decide they should be
           pushed to level 5.
  Florian: Is there a problem with this approach?
  fantasai: I'm in favor. Our goal should be to have CR ready over
            the summer.
  Florian: Yes.
  Florian: I don't have a lot of free time right now. If I did we
           could have LC worthy by F2F.
  <dbaron> I'm happy with that too, as long as the grammar changes
           (allowing and/or more and parens more) are in 4 :-)

hover: on-demand

  <astearns> https://lists.w3.org/Archives/Public/www-style/2016Feb/0041.html
  Florian: Hover lets you check if the primary pointing device can
  Florian: There is hover: none which says you can't. There's a
           value that says you can.
  Florian: There's on-demand which says you can hover, but it takes
           some effort. So if you're on a phone and have to long-
  Florian: There's multiple questions. If we do keep this, should it
           be in the boolean? so on-demand and none are grouped.
  Florian: Other question is do we need on-demand and we don't hover
           if impossible or difficult? I think gregwhitworth and I
           say not needed. TabAtkins disagrees. TabAtkins, can you
           explain the other side?
  TabAtkins: It was low value, but there are cases where a hover
             interface is possible, but not as convenient and it's
             still reasonable to target those with hover at times.
             If you'd rather just do hover or not, it's not a huge

  <dbaron> could the feature be split into two features?

  gregwhitworth: Do you guys have use cases for these MQ in general?
  gregwhitworth: Where the demand is coming from? Are you seeing a
                 lot of requests?
  TabAtkins: Hover is easy. People do sophisticated attempts at
             device detections to know if people can hover. That's
             spread everywhere.
  Florian: And it's much better to have hover MQ then doing a query
           for device size.
  gregwhitworth: Cool, thanks.
  fantasai: I think this and pointer accuracy are sure critical for
            distinguishing between mobile and not. Like you have
            tablets with large screen the same size as a laptop.
  TabAtkins: Physically you can't distinguish anymore.

  smfr: I'd prefer not to have on-demand hover because in iOS it's
        pretty special and magic. I'd prefer not to have it because
        I don't think it'll express what we're doing correctly.
  Florian: So remove the on-demand and clarify none means impossible
           or inconvenient.
  <smfr> sounds good
  TabAtkins: And hover is when it's an easy and natural part of the
  Florian: I think that was the original, yes.

  astearns: [reads dbaron IRC "could the feature be split into two
  dbaron: I think the later discussion makes that irrelevant.
  astearns: Objections to removing on-demand value?

  RESOLVED: Remove the on-demand value from hover.

light-level and a11y

  <astearns> https://lists.w3.org/Archives/Public/www-style/2016Feb/0046.html
  Florian: You can detect if it's too bright or too dim to see
           anything by your screen and light level.
  Florian: It has dim, normal, and washed. There's also a note
           saying types of adjustments to cope with washed are
           similar to the type done for a11y reasons. People with
           low vision like increasing contrasts and font sizes.
  Florian: For example people with dyslexia like large font and
           reduced contrast. So it says that the UA may allow the
           user to trigger this manually.
  Florian: A couple of people have said they want this remark
           removed. Probably because we should have a dedicated MQ
           for that so people shouldn't abuse this one. My take is
           we should have dedicated MQ, but I think it's a good
           opportunity when we have a feature that serves both
           purposes because when we make dedicated a11y features
           they're not used.
  Florian: It doesn't prevent us from having the dedicated one for
           people that do a good job on a11y.

  smfr: This always comes up...I think it's the responsibility of
        the OS to deal with different light conditions. I don't
        think we should have light-level MQ.
  Florian: The feature entirely?
  smfr: Yes.
  Florian: So how do you do your GPS inverting screen at night?
  smfr: We have a feature in iOS that detects and adjusts. We also
        have a11y features that do things. If the OS has that
        functionality and the page does, they can interact poorly.
        It's better if it's just the OS.
  Florian: I don't think any OS does screen inversion.

  fantasai: I think this feature needs more discussion and therefore
            should be deferred to the next level.
  <gregwhitworth> I agree with fantasai here.
  astearns: I agree. Is that okay Florian?
  Florian: I'm a bit surprised at the push-back because it's been
           there a while, but if there is a big discussion okay, I
  astearns: I'm a bit surprised too. It would have been good to have
            this on the mailing list. But let's resolve to push this
            to the next level.
  Florian: Yeah.
  TabAtkins: I'm fine.

  RESOLVED: Move light-level to the next level of Media Queries

  astearns: Thanks everyone.
Received on Wednesday, 23 March 2016 23:36:51 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:37 UTC