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

[CSSWG] Minutes Telecon 2016-12-14 [css-variables] [css-syntax] [mediaqueries]

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 14 Dec 2016 23:04:15 +0300
Message-ID: <CADhPm3va500GFLM+HaLj9tRWcWyoxc0jzfnPNGaTWYkVY7uY1g@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.


  - It is still undecided if there will be a meeting next week.
  - A location is being sought for to host a summer F2F in Europe.
      There's also a doodle for members to add availability

Relative URL resolution in var() references

  - RESOLVED: No change in current custom properties for issue #757.
              Need to solve this issue with future work.

'>>' and '>>>' should be a token

  - RESOLVED: We drop the implicit requirement that selectors
              parsing remains LR1 and as a consequence we remove
              specialized selectors from the syntax and replace

Consider making device-pixel-ratio a standard alias

  - RESOLVED: Do not add device-pixel-ratio unprefixed.
  - It was left undecided if -webkit-device-pixel-ratio should be
      defined in the Media Queries spec. Several people had no wish
      to define it since it's an alias to the resolution media
      query, but there was concern that that's compatibility hostile
      since currently you need -webkit-device-pixel-ratio to be
      web compatible.


Agenda: https://lists.w3.org/Archives/Public/www-style/2016Dec/0053.html

  Rachel Andrew
  Rossen Atanassov
  Tab Atkins
  Bert Bos
  Tantek Çelik
  Alex Critchfield
  Simon Fraser
  Daniel Glazman
  Tony Graham
  Brad Kemper
  Dael Jackson
  Chris Lilley
  Peter Linss
  Myles Maxfield
  Michael Miller
  Rachel Nabors
  Simon Pieters
  Anton Prowse
  Liam Quin
  Matt Rakow
  Melanie Richards
  Florian Rivoal
  Jen Simmons
  Geoffrey Sneddon
  Alan Stearns
  Majid Valipour
  Lea Verou
  Steve Zilles

  David Baron
  David Cramer
  Elika Etemad
  Vladimir Levantovsky


  astearns: Let's start. I've heard a couple people are not
            available next week
  astearns: Is there anyone that could come and wants a meeting next
  * Bert won't be here next week
  Florian: I could come.
  gsnedders: I'm the same.
  astearns: Other opinions?
  jensimmons: I can make it
  glazou: I'm unlikely be be available.
  astearns: Alright. We will see I think. It sounds there will be a
            bunch of people out. We definitely won't have the 28th.
            If we don't have a call next week there will prob be
            enough for a Jan 4.
  gsnedders: Assuming people are around.
  astearns: mmm....true. People will have had time to recover, I

  [discussion on webex problems]

  astearns: Other scheduling topic was if we can have a meeting in
            the summer.
  astearns: fantasai put up a doodle.
  <astearns> doodle for summer meeting http://doodle.com/poll/n7dg3i2hmuvzagws
  astearns: I expect there will be enough business that it would be
            useful. I don't know if anyone could host. Europe makes
            sense for location.
  astearns: If anyone has a European location please get a hold of
            Rossen or me. Please put your availability in the doodle
            so we can see if there's a time that would work.
  <Bert> (I'd be happy to host. Meeting rooms enough. Hotels may be
         expensive in that period...)
  jensimmons: I live in NYC but I'm sure I could get Mozilla in
              Paris or London.
  Florian: Paris is beautiful.
  gsnedders: New London is small. I'm not sure there's space there.
  Rossen: Also W3C hosting in Sophia something we can explore.
  Bert: Yes, the rooms here are all available. The advantage is
        you're on the cost. You have to book a hotel early, it's
        high season. I'm happy to host.
  Rossen: Sounds great. We'd be happy to be hosted.
  <gsnedders> I could potentially help to arrange something around
              Scotland, but don't have hte funding to pay.

  astearns: Let's plan on if and when and where we'll have a meeting
            in the summer when we meet in Seattle.

  glazou: One thing about Sophia in the summer if you mean July and
          August it's extremely painful to drive there. It's a
          gigantic traffic jam. If you remember last time we were
          there in summer it took us an hour to get to dinner.
  glazou: So end of June is waaayyy better there.
  Rossen: That's really good input
  Florian: jensimmons if you can check on Mozilla availability it
           could be useful. And then we weigh in Seattle.

Relative URL resolution in var() references

  <astearns> https://github.com/w3c/csswg-drafts/issues/757
  TabAtkins: I wasn't around last week.
  TabAtkins: I'm not sure...is frremy on?
  frremy: I am
  TabAtkins: mmkay. Can you summarize why you think my solution
             won't work?
  frremy: I think there are 2 reasons. First you need to spec the
          URL in a property that only contains the URL which will be
          a pain. Even if you could do something like background
          you'd have to create your own syntax and that will change
          over time.
  frremy: Second is if you look at the way yours works it resolves
          at computation time and I don't think we want to replace
          with computed because we resolve before the computed time.
          It assumes if you have time it brings them at computation
  frremy: I think that's why if it makes sense.
  TabAtkins: That we can't do complex properties in level 1 of
             Houdini is true of everything. That's a limitation of
             living in level 1. We'll aim to relax that in the
             future as we get more of a handle on it. Houdini should
             reproduce everything CSS does eventually. It's not a
             URL specific problem.
  TabAtkins: Computation is more interesting. Your example of a
             custom property of 1em being used in a font size...I
             think that's invalid because you introduced another
             chain. URLs just resolve on the sheet they're in. It's
             not the same deal. Dependencies aren't ever cyclical.
             Which style sheet it's in matters.
  TabAtkins: That's what people are asking for.
  frremy: I don't think the solution is a fix. It seems like it
          would be a custom thing for only URLs. I checked in Edge
          and Chrome and they don't support custom URLs. I don't see
          why we wouldn't fix it the right way.
  frremy: It seems like we need to fix it so let's fix it.

  TabAtkins: Your solution of look for things like URLs and keeping
             the information around doesn't work. There are several
             functions that use URLs and they carry them around as
             just strings. That means you have to track every string
             as well.
  frremy: No, if you think about strings I don't want to resolve
          that. It's based on the token that's URL or image. A
          string is a string. If you want to define a URL or image
          this is where you resolve.
  TabAtkins: Or any future functions.
  frremy: Yep. You resolve the image or url, not the string. Keeping
          source for string doesn't make sense.

  leaverou: If we're adding new URL function would it help to accept
            a second argument as the base that would accept a custom
  TabAtkins: I think that's straight up a useful feature.
  <ChrisL> yes, we need better control of the base to resolve against
  TabAtkins: It doesn't directly address the issue. If you have an
             untyped custom prop with a URL it doesn't know it's a
             URL unless we go with pretend typing.
  Florian: If you specify the origin as CSS origin it doesn't solve
           the problem?
  TabAtkins: Right.

  leaverou: You could have a custom prop with its own origin and set
            it as it's own origin. It's hacky.
  Rossen: It's a good thing to keep the relative things relative.
          You would have to deal with the case where you spec the
  leaverou: Is frremy implementable?
  ChrisL: It doesn't sound it. We'd need a URL function that would
          allow the base so that people can control that. We need to
          support relative and absolute URLs. Duck-typing strings is
          a terrible idea.
  TabAtkins: Everything works as you expect if it's typed using
             Houdini. It's untyped that are causing problems because
             we know they're URLs.

  astearns: Sounds like we should try to solve frremy problem in the
            future but keep the current terrible string URLs in
            variables as they are now.
  TabAtkins: That's the solution if we do nothing. Which I'm fine
  frremy: I think it's a mistake but if this is what we want to do
          it's an option.
  astearns: Will you object to doing nothing?
  frremy: I can't object to doing nothing :D
  Rossen: I wouldn't say this is objecting to doing nothing. All
          frremy is asking is to keep pursuing a better solution. If
          we solve it now or kick it down the road and keep at it,
          that's tbd by the group. By ducking our head in the sand
          it doesn't mean the problem is gone.
  Rossen: I'm not hearing consensus around this is the only way
          we'll solve it. I'm hearing what frremy says kinda makes
          sense but maybe not the right time.
  astearns: And I thought that's what I was expressing. We need to
            solve it but won't do so with the L0 custom properties.
  leaverou: Perhaps this is another reason to prioritize the
            declarative API

  Rossen: frremy are you okay with this for now?
  frremy: Current behavior isn't working at all. If you think it's
          not working and we document it's not working it's fine.
          It's just not what I think authors want. If we doc it it's
  Rossen: We document it this way...
  frremy: I'm not saying we should put it in a spec. I'm fine
          keeping as is.
  astearns: As specified the strings should resolve at computation
            time and relative URLs will resolve at that point to the
            style sheet they're resolved. If that doesn't work in
            Chrome or Edge that's a bug.
  astearns: The spec says at computation time the URLs will resolve.
            Am I wrong?
  leaverou: I agree with astearns.
  frremy: I don't think it's specified in the spec.
  TabAtkins: It is. Once you substitute it into a property that
             knows it's a URL it's resolved.
  leaverou: Right now it doesn't work in Chrome.
  frremy: Same in Edge.
  astearns: That they don't work is a bug. That they prob won't
            resolve to the expected URL is something we'll fix in
            the future
  TabAtkins: And we have a solution spec in simple cases. We expect
             to address most or all needs as we expand what a typed
             custom property can express
  astearns: Let's close on this.

  RESOLVED: No change in current custom properties for issue #757.
            Need to solve this issue with future work.

'>>' and '>>>' should be a token

  <astearns> https://github.com/w3c/csswg-drafts/issues/712
  TabAtkins: For grammar reasons to keep the selector grammar being
             a single token look ahead earlier CSS added in special
             tokens just for selectors.
  TabAtkins: By making them special tokens in the CSS we needed
             special selectors with one look ahead. We introduced >>
             and >>> combinators.
  TabAtkins: And these are under the same issues. If we want
             selectors as one token of look ahead we need to make >>
             and >>> a single token in syntax
  TabAtkins: Question is, is LR1 in selector syntax important to
             maintain. If it is I can modify for specialized tokens.
             If not I'll avoid doing so and we can try and remove
             special syntax. This would make selectors LR3. It would
             simplify things because we won't have selectors only
  TabAtkins: Other benefit as dbaron pointed out, specialized tokens
             mess with grammar. Having these extra tokens can have
             similar problems to the unicode issue. Do impl still
             think maintaining selectors as one look ahead is
  <TabAtkins> unicode issue = "u+a { color: blue; }" was invalid,
              because the selector part parsed as a unicode-range
              token, while "u + a { color: blue; }" was valid. This
              is confusing.

  glazou: First, personally, I think either solution is fine. I want
          to give a user specific tale. I read the issue in detail
          on github. Most people never noticed you can add a comment
          between : and class selector. Most are unaware that if you
          have two combinators you can have a comment in between.
          From a user prospective these kind of controls are really
          complete. You can't divide into pieces.
  glazou: The attribute selectors between the name and the value the
          |= can't divide into two pieces. Whatever is best for
          implementors would be fine for me.
  TabAtkins: I agree. The details of where you can put comments it
             are just random and arbitrary. This is just a what is
             easiest for implementor issue. I agree.

  TabAtkins: If people need to consult and come back later I'm fine
             with that. We need a decision at some paint.
  Rossen: On our end I don't believe it will be a big deal. Did you
          guys have a solution or experiment in Chrome?
  TabAtkins: Ours is fine. We have it a separate tokens. You can do
             >>> with comment in between. It's if it should be
  Rossen: I don't believe the complexity will be there. I think
          we'll be fine.

  glazou: I just thought about a case. a>b>c and you remove the b.
  glazou: Suddenly the whole thing is something else. Is it
          something we want? I'm not against it but we should
          consider. Removing the b changes the behavior.
  TabAtkins: That's a weird thing to do. Hopefully it's a typo and
             you notice.
  glazou: All types of weird things happen in style sheets.
  Rossen: I think the case from glazou is the editing scenario and
          you're typing and you could get weird behavior with a typo.
  TabAtkins: In editing if you leave white space in the place of the
             b it's not valid. It's only if you remove all which
             space it because valid.
  <liam> [ this comes up if you comment out the b too, e.g. for
         testing ]
  Rossen: Sure. Let's not debate. It's reasonable to expect you may
          run into it. Let's just put it on the record.

  <leaverou> Question: Does this affect the Houdini Parsing API as
             well? If so, having it as a series of child combinators
             decreases usability for developers.
  astearns: leaverou had IRC question. [reads]
  TabAtkins: It does not effect Houdini. We're not exposing weird
             selector tokens. They're all exposed as just a string.
  leaverou: Houdini doesn't parse selectors?
  TabAtkins: As far as Houdini APIs are concerned you won't see a
  leaverou: This is just internals?
  TabAtkins: Yeah.
  TabAtkins: From Houdini side we removed those weird tokens.

  TabAtkins: Chrome is okay with separated tokens. Sounds like MS is
             okay. Do we want to resolve, see if Mozilla has an
  astearns: dbaron commented in the thread, but I don't think I see
            an opinion there.
  <glazou> https://github.com/w3c/csswg-drafts/issues/712#issuecomment-264568190
  TabAtkins: He said adding more tokens was bad with the unicode
             range issue I mentioned. Well, potentially problematic.
  TabAtkins: He also pointed out in this exact case it wouldn't make
             selectors not LR1, but if I go to where I want and
             throw away the old tokens it would make selectors LR3
             or at least 2.
  astearns: Two options. Resolve today and see if anyone complains.
            Or we wait for more input.
  astearns: I'd be happy resolving today.
  TabAtkins: They're easy changes to make.

  glazou: If it helps we could also reverse the question. Do we want
          to allow comments between the > signs in these
          combinators. If the answer is no it gives a direction
  Florian: I think we don't care. We care about consequences of
           impl, but don't care about the comments.
  TabAtkins: Yeah. Comments is already weird.

  Rossen: I'm in favor of progress. Resolve and move on. The problem
          will clearly come back.
  TabAtkins: Proposed resolution: We drop the implicit requirement
             that selectors parsing becomes LR1 and as a consequence
             we remove specialized selectors from the syntax and
             replace accordingly
  astearns: Objections?
  Florian: Do you mean becomes?
  Florian: I'm only asking about resolution phrasing.
  Florian: Just replace becomes with remains for the resolution.
  glazou: Yes. I agree with the proposal

  RESOLVED: We drop the implicit requirement that selectors parsing
            remains LR1 and as a consequence we remove specialized
            selectors from the syntax and replace accordingly.

  <TabAtkins> (We still maintain the implicit requirement that
              Selectors syntax, like CSS parsing in general, should
              be a small finite amount of lookahead, of course. Just
              drop the strict requirement that it be LR(1),

Consider making device-pixel-ratio a standard alias

  <astearns> https://github.com/w3c/csswg-drafts/issues/417
  Florian: Three parts. We have a MQ called resolution. It used to
           be -webkit-device-pixel-ratio. webkit name is common
           enough that non-webkit implementors are implementing.
           Compact spec documents this.
  <zcorpan> https://compat.spec.whatwg.org/
  Florian: Q1: Are we happy that this is only in compact spec or,
           given that it's implemented by all browsers should we
           inline into MQ spec?
  Florian: I think we can resolve on that first.
  TabAtkins: I'm for pulling into the full spec. We put it in a
             compat appendix and document in a core spec.
  <MaRakow> seems fine
  Florian: That would be my favorite thing to do.
  Rossen: Moving to a different spec means we'll pursue [missed]
  Florian: I'm not talking about device adaptation. The MQ spec.
           There's a compat spec that lists things that need to be
  Rossen: What I'm saying is you won't take the prefix and put it in
          the MQ and say implement as the
          -webkit-device-pixel-ratio. But also un-prefixing it.
  Florian: That's Q2.
  Rossen: The resolution on Q1 weighs on Q2. If it's only about
          quirking and keeping up with that I'd prefer to keep it
          just in that spec. If we're evolving it would be good to
  <zcorpan> quirks spec and compat spec are different specs :-)

  Florian: This is a feature we have under a different name.
  astearns: We have it under a different name and the
            -webkit-device-pixel-ratio so it's compat not quirk.
  Rossen: We called compat quirks
  Florian: It's not the same thing.
  zcorpan: Quirks is things browsers have in their quirks. This is
           in all rendering modes so not a quirk.

  Rossen: Let's talk in compat. So adopt this and keep it moving
          forward or leave as is?
  Florian: Given this is an alternative name for an existing
           behavior that everyone has to impl we should put it in
           the spec.
  MaRakow: Do we have precedent? I think we should keep as if it's
           it's the same.
  Florian: People who do compat remove it from there if it goes
  MaRakow: Then I'm happy both ways.
  Rossen: If we're not doing anything except put it in or spec
          what's the point? If we're planning on changing then let's
          move. That's why the decision of where to put it weighs on
  Florian: So part 2. Even if we don't resolve on doing anything
           other then adding it, if you impl MQ it's not sufficient
           to just use resolution. You must also do
           -webkit-device-pixel-ratio. So they belong in the same

  smfr: They're not the same. There's difference in zoom.
  Florian: They are. There's a difference between safari and
           everybody else. Everybody else treats them the same, but
           safari and everyone else doesn't do the same. Within each
           browser the names are consistent.
  smfr: I think authors using -webkit-device-pixel-ratio are IDing
        the iOS behavior. Since there's not software zoom on iOS
        it's the same as resolution but on mac desktop it's not the
  Florian: The standard name behavior on safari is the same. You
           treat both standard and non-standard the same. Which is a
           spec violation of resolution. If we should match safari
           is a relevant conversation, but there is no browser that
           treats the names differently. The two names do the same.
  MaRakow: When we implemented -webkit-device-pixel-ratio it didn't
           make a huge interop difference there. But there were
           cases with a ratio of 2 there was a difference. There may
           be benefit of specing it with a note to rec preferring 2.
           We didn't see issue with it being an alias of resolution.

  Florian: We've touched on all the points including the extra one
           if people should match safari.
  smfr: Webkit will impl resolution MQ as specified and if we do
        that there's little pressure to unprefix. We're okay with
        the difference on software zoom. I think
        -webkit-device-pixel-ratio should be historical.
  <MaRakow> +1 to smfr

  Florian: Mozilla while implementing -webkit-device-pixel-ratio
           felt uncomfortable when the standard name wasn't the same
           thing. So they wanted to add device-pixel-ratio. I don't
           think that helps anyone.
  MaRakow: I agree. It's a historical property.
  Rossen: And keep it in the compat spec. Agreed.
  Florian: So we seem to have easy agreement to not add unprefixed
           device-pixel-ratio to any spec.
  Florian: It's not in any browser.
  Rossen: Not in compat spec?
  Florian: Unprefixed is no where.
  Rossen: Oh, sorry.
  astearns: So who in Mozilla wanted to add the unprefixed?
  Florian: Someone with a github name I can't parse.
  MaRakow: dbaron mentioned it last time we talked. I think he felt
           uncomfortable adding prefixed without an unprefixed. I
           think he said it was unpleasant but didn't disagree.
  astearns: Objections to resolving not to add device-pixel-ratio

  RESOLVED: Do not add device-pixel-ratio unprefixed

  Florian: The remaining questions are tied. Do we want to
           acknowledge the existence of the prefixed version. If we
           want to pretend it doesn't exist we're fine. If we want
           to inline we have to agree on what it does. Do we want to
           leave it to the compat spec or is a CSS thing everyone
           has to impl?
  Rossen: We would prefer to leave it in the compat spec.
  Florian: That seems compat hostile.
  Rossen: I don't believe compat under-specifies.
  Florian: It doesn't say what it does.
  <zcorpan> Florian you can file an issue on the compat spec
  myles: Then why not change the compat spec?
  Florian: We don't maintain it.
  myles: That makes sense.

  Florian: Maybe my test is wrong, but from my testing...in all
           browsers neither resolution not
           -webkit-device-pixel-ratio are affected by pinch zoom. In
           all except safari both are affected by page. In safari
           neither are affected by page zooming. So browsers agree
           both names mean the same thing.
  astearns: Would it make sense to file an issue on the compat spec
            to say -webkit-device-pixel-ratio is an alias of
  Florian: That's what they say.
  astearns: So resolution is defined in our spec. If it just says
            they're aliases no matter what spec it's in doesn't much

  Florian: I thought I heard smfr say is they're willing to fix
           their implementation of resolution to match the spec, but
           not -webkit-device-pixel-ratio and therefore they'll be
           similar but not same.
  smfr: We don't have a final decision, but that's my preference.
  Florian: Not my preferred solution, but...
  astearns: We're at top of hour and I'm not hearing consensus.
  Florian: Here's a proposed way forward. With this resolution I can
           close the issue. Currently the spec is clear these names
           do the same and safari is buggy. If safari wishes to
           change it can. Or it can file a bug on the spec. They're
           defined as an alias. If they wish that to change they can
           also file a bug.
  Florian: It seems safari hasn't made up their mind so we can't
           discuss it effectively for not.
  astearns: I think that's a good summary. We'll see for next week.
            I'll see if there's enough agenda items and if people
            will be around.
Received on Wednesday, 14 December 2016 20:05:21 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 14 December 2016 20:05:22 UTC