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

[CSSWG] Minutes Telecon 2016-12-07 [css-grid] [css-variables] [css-writing-modes-3]

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 7 Dec 2016 23:24:25 +0300
Message-ID: <CADhPm3vnB3dXEN-Mz295Lq8nR3HJz9jNhHNdEWa-Vw1zsRe=zw@mail.gmail.com>
To: www-style@w3.org
=========================================
  These are the official CSSWG minutes.
  Unless you're correcting the minutes,
 Please respond by starting a new thread
   with an appropriate subject line.
=========================================


F2F updates and call schedule for 2016 holiday season
-----------------------------------------------------

  - The F2F meeting in Japan is confirmed for 17-21 April.
  - The telecon on 28 December is canceled. 21 December and 4
      January are currently planned to occur, but members should
      keep an eye on the private list.

Future work of FXTF specs
-------------------------

  - The specs that were a part of the FXTF are now the sole
      responsibility of the CSSWG.
  - Rossen will investigate the best way to move the specs in the
      CSSWG drafts & github repo making sure to preserve spec
      history and issues.

Stretching image grid items in both dimensions
----------------------------------------------

  - There were two options for how to address when an image is
      stretch in one direction and has a value like center in the
      other direction.
      1) It always preserves aspect ratio
      2) Ignore/break aspect ratio
  - There was no clear consensus between the two options.
  - A few people felt that the problem is created by putting sizing
      in an alignment property and there should be thought on
      avoiding that.
  - The interested parties will talk over github and maybe get on a
      call to keep thinking through the implications of these issues.

Relative URL resolution in var() references
-------------------------------------------

  - There were two views on this issue:
      - This is an edge case and an exception shouldn't be made as
          it's harder to teach exceptions
      - This problem makes URL in variables close to useless and
          therefore needs fixing
  - Several vendors weren't giving options and TabAtkins, who had
      strong options, wasn't on the call, so discussion will
      continue on github and a resolution will be sought on next
      week's call.

Propose to replace "'text-orientation: upright' to cause strong LTR"
    with author notes how to do it
--------------------------------------------------------------------

  - RESOLVED: Add a note along the lines of koji's example telling
              authors how to work around the lack of correct
              implementation.
  - The section will remain as a MUST with a plan to argue it's an
      edge case and shouldn't block a move to PR.

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

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

Present:
  Rachel Andrew (IRC only)
  Rossen Atanassov
  David Baron
  Bert Bos
  Dave Cramer
  Alex Critchfield
  Simon Fraser
  Daniel Glazman
  Tony Graham
  Dael Jackson
  Brian Kardell
  Brad Kemper
  Chris Lilley
  Peter Linss
  Michael Miller
  Rachel Nabors
  Anton Prowse
  Matt Rakow
  François Remy
  Florian Rivoal
  Jen Simmons
  Geoffrey Sneddon
  Alan Stearns
  Lea Verou
  Greg Whitworth
  Steve Zilles

Regrets:
  Tantek Çelik

F2F updates and call schedule for 2016 holiday season
-----------------------------------------------------

  Rossen: Let's get going.
  Rossen: First do we have any additional items?

  Rossen: Quick update and a call for people on the holidays.
  Rossen: Seattle is confirmed to be in Seattle. We (MS) will be
          hosting in our West Lake office.
  Rossen: We've reserved another room in a building that's in
          walking distance for one day of Houdini. For those of you
          attending both and booking a hotel or room in that area-
          it will work for both.
  <ChrisL> I will likely not be able to attend due to a one-time
           conflict.

  Rossen: I've also have confirmation from Hiroshi-san that the
          proposed Aprils dates are secured. We'll be at a
          university.
  <astearns> Keio
  Rossen: It's in Keio University in Tokyo. Dates are 17-21 Apr.
  Rossen: That is it about upcoming F2F.

  Rossen: Other part was I wanted to get an idea of if we should
          have phone calls when since holiday and vacation times are
          coming up.
  Rossen: How many meetings will we be able to complete by the end
          of the year? I'm assuming next week is good.
  <Bert> is available on 16th, but not on 22, nor on 6
  Florian: I agree next week is good. One after prob. After that
           it's over.
  glazou: Yep.
  <dbaron> I'll be away next week but could likely make following
           meetings
  <dauwhe> -1 for the rest of the year for me :)
  Rossen: Can anyone make the meeting between the 25th and 1st?
  <ChrisL> 28th seems unlikely
  glazou: We usually cancel that.

  Rossen: How about the week before?
  glazou: I will not
  <gregwhitworth> I won't
  Florian: I would
  <astearns> I can
  Rossen: Okay, I see some I will not and some how can. Sounds like
          21st is tentative for now. I'll send an e-mail to the
          private list before the call and we'll go for that. 28th
          is out for sure.
  <Bert> is available on 14th, but not on 21, nor on 4 (sorry
         off-by-two :-) )

  Florian: First week of January?
  Rossen: Great question.
  Rossen: Do we usually have that one?
  Rossen: Jan 4th. Is that one we can make?
  <dauwhe> I'll be around Jan 4
  <Florian> I'm neutral on Jan 4
  astearns: Given we cancel after the F2F we may as well have the
            4th.
  Rossen: Good point. Week after the first is the F2F.
  Rossen: For now we'll keep Jan 4. Keep an eye on the private list.
          If we don't get enough people we'll cancel on the fly.

Future work of FXTF specs
-------------------------

  Rossen: We did have...during TPAC we had an SVG WG meeting meant
          to recharter the SVG WG.
  Rossen: We scoped everything down to a subset of current SVG 2 as
          the proposed charter.
  Rossen: There were a number of specs between SVG and CSS as FXTF
          and they're now out of scope for SVG.
  Florian: Intentional or just an unfortunate side effect?
  ChrisL: It was.
  Rossen: Yes. I see it as both intentional and a side effect.
  Rossen: It was intentional as the WG was having enough trouble
          landing SVG and it was unfortunate because they were
          having trouble focusing.
  Rossen: All the specs in FXTF being worked on were being done by
          the WG with the exception of web animations. Web
          animations is also mostly Houdini & CSS.
  Rossen: Reason I'm forcing the discussion is we have to take
          ownership and designate editors. That's the level setting
          of the discussion.

  ChrisL: When we have a TF the work has to be in the scope for both
          WG. When one WG moves it out of scope I don't believe we
          have to do anything special. We move on and select new
          editors as we have for other reasons on a spec.
  <leaverou> +1 to ChrisL
  Rossen: That's a great point. We need spec editors keeping track
          of what's happening in the WG.
  Rossen: For example what happened to bring this up is there were
          issues in FXTF repo that were open for weeks and no one
          noticed.
  Rossen: The specs worked on by FXTF are very important and we
          shouldn't lose track of those. We can bring them under CSS
          Drafts and continue work there with appointing editors.
  <ChrisL> +1 to moving to csswg-drafts repo, if the issues also
           migrate
  ChrisL: I agree to moving them to CSS repo if the issues move
          with. I don't know if they do.
  Rossen: Who is a github ninja and can answer that?
  plinss: I don't know of any mechanism to move the issues. They
          wouldn't automatically. There may be a process.
  fantasai: Do we have to move them or can we leave them where they
            are?
  Rossen: No one is paying attention.
  ChrisL: We can close and re-open manually.
  <smfr> https://github-issue-mover.appspot.com
  <gsnedders> yeah, there's no way to do it automatically except
              through the public API recreating all of them
  Rossen: Okay. What if we agree to attempt to move them under CSS
          WG drafts for overall visibility and that would be it.
  ChrisL: sgtm
  Rossen: Objections?

  Florian: It looks like a fair amount of busy work to move things
           around. It's a problem no one is looking. I'm watching
           both but I'm not paying attention to these specs. For me
           moving would change nothing. It's not just me, but others
           may be in my situation.
  Rossen: It sounds like there's an issue mover smfr put in IRC.
          Assuming we can move the specs and the issues it makes
          sense to have all the work for one WG in one place unless
          there's a good reason for it. The good reason was FXTF but
          that reason no longer exists.
  <Florian> if the move is low overhead, then no objection

  ACTION Rossen figure out how to move the FXTF spec while
         preserving issues
  <trackbot> Created ACTION-805

  plinss: Should we be careful to preserve history?
  Rossen: Yes, let me look into it.
  fantasai: I think history is very important. If you're concerned
            about not having attention it's a matter of set your
            filters. I'd rather we didn't disrupt the history. For
            issue tracking we've only been using github for a short
            period.
  Florian: You can merge and preserve history.
  <gsnedders> You just use git read-tree in general
  Rossen: Without spending too much more time, we agreed let's look
          into what it means to move everything carefully to keep
          history and issues.
  Rossen: More important was we need to take full ownership of these
          specs.

Stretching image grid items in both dimensions
----------------------------------------------

  fantasai: I think there's a bit more to think about in general,
            but one issue is if you have stretch in one direction
            and center in another what is the size in the center
            direction and does it account for aspect ratio. I
            thought yes, Mats thought it was use original size in
            direction not stretched.
  fantasai: I think that will be confusing because that's not how
            images every work. Any auto sizing that happens accounts
            for change in the other side. Only exception is flexbox
            where it would trigger a loop to get it 100% correct.
            Everywhere else we maintain aspect ratio if you do any
            auto sizing. That should stay true. We shouldn't
            preserve real size against aspect ratio.
  Florian: Makes sense.
  fantasai: Other opinions?
  <astearns> +1 for fantasai's position
  <gsnedders> +1

  fantasai: We need a resolution. Proposal is if an image is stretch
            or normal in one axis it preserves aspect ratio in other
            dimension unless explicitly overwritten.
  fantasai: If it's stretch in both we break the aspect ratio. If
            it's stretch in one dimension and center or something
            like it in the other, that's the issue.
  Rossen: How does that effect the sizing for things such as flex or
          grid algorithm that depend on item size?
  fantasai: I don't remember.
  Rossen: If we only have one item and it is flex and it's an image
          with stretch on the main and something else on the crop.
          Would crop overflow?
  fantasai: The image would take...let's say you sent a bunch of
            prop and it flexes, in the cross axis if you spec center
            it takes the size that would result from aspect ratio.
  Rossen: Right. I wanted to make sure this is the part we're not
          losing.
  Rossen: Assuming that this is the case for the intrinsic sizing I
          don't have a problem.

  <jensimmons> https://github.com/w3c/csswg-drafts/issues/523#issuecomment-264106069
  jensimmons: When I look at how Manuel described this issue I'm
              confused. It sounds like the opposite of what he said
              you're saying. Is the way he summarized accurate?
  fantasai: Hang on.
  fantasai: [checking]
  fantasai: If we set stretch in both axis we break aspect ratio. If
            it's stretch or normal in on axis and something like
            center in the other that axis gets resized to match
            stretch in the aspect ratio.
  fantasai: So if you stretch 2x the center would also be doubled.
            This is all for auto sizing. For auto sizing we preserve
            aspect ratio in pretty much all but stretch stretch.
  jensimmons: And Mats is saying if you do stretch in one dimension
              it breaks aspect ratio. I think I'm leaning toward
              what he's saying.
  Rossen: I think you're agreeing to preserve aspect ratio when not
          stretched.
  jensimmons: No, opposite.
  Rossen: Do you like option 1 or 2?
  jensimmons: 2.
  Rossen: Which is ignore the ratio.
  fantasai: This is a case where you have an image that's 50x50. You
            put it into 100x100 cell. You stretch one axis. It'll be
            100 in one axis and stay 50 in the other.
  jensimmons: I think that's okay. If you start to do stretch and it
              get squashed you realize you should do stretch,
              stretch. If the cell changes ratio the image would
              too. If it starts normal, normal I want it to only
              stretch where I change normal to stretch.
  Rossen: And that's the overflow I was pointing out and according
          to fantasai that shouldn't overflow.
  fantasai: The flex will overflow. If you flex one it'll overflow.
  Rossen: That's my assumption and it makes more sense to me...
  fantasai: Especially if you have an auto size grid. I don't see an
            image where you'd want to not preserve aspect ratio.
  jensimmons: Why not normal?
  fantasai: hang on, dbaron is on the queue.

  dbaron: I'm confused with 100x100 grid cell since I understand
          image size can influence grid cell size.
  fantasai: Yes
  dbaron: If an image is stretch in one dimension and you're
          proposing to maintain the aspect ratio does the images new
          size in the other dimension influence the grid size?
  fantasai: That's a good question. Prior to a resolution 2 months
            ago, stretch was the initial default. We're putting
            sizing behavior in an alignment property.
  fantasai: Normal should be equivalent to one or the other value.
            Whichever can vary depending on element type, but we're
            creating a system where we're sizing in an alignment
            property and that's a problem. I'm unhappy with how
            that's turned out so far.
  Rossen: In the previous layout systems alignment didn't influence
          sizing.
  fantasai: Right.
  Rossen: And I don't see why this should be a percent to change
          flex or grid would would imply that option 2 would be from
          a layout pov more predictable.

  fantasai: I think there's more to think about here in terms of
            trying to resolve. I'm against having multiple values of
            alignment property effect sizing. We already have
            stretch vs others. We shouldn't do more. We tried to do
            that and it's creating a mess.
  fantasai: I think this whole things needs cleanup and I don't 100%
            know what that is.
  Rossen: It doesn't sound like we can or want to resolve on this.
  Rossen: Should we decide to work on this in a smaller group over
          github or get on a phone if needed and go from there?
  fantasai: I'm happy to do that. This week is finals, so I can't do
            a lot for the next week.
  Rossen: You take care of your finals and we'll figure out grid in
          the meantime.
  <jensimmons> I’m happy to get on a call about this all
  <rachelandrew> I'd be happy to get on a call once I'm back (so
                 next week)

Relative URL resolution in var() references
-------------------------------------------

  fremy: The issue is...basic premise of variables if you can define
         them. I think there's an issue preventing this. If you have
         a URL defining a var and it's not considered a URL until
         replaced in a property. If you're using a relative
         stylesheet it's not going to work. It breaks relative URLs
         if you use them in variables.
  fremy: I think it's user hostile. I proposed to remember the
         origin of the URL token so you can resolve the URL later.
  leaverou: I think it's a bit confusing to teach that it's defined
            at time of use except this one case. Exceptions make it
            hard to teach.
  fremy: I'm not sure it's hard to teach. It isn't because it
         doesn't have a meaning. The issue is you can't use relative
         URLs if you want to use CSS variables. It's a big
         limitation.
  leaverou: So themes are hot linked? I think most authors download
            them and use them alongside their CSS.
  fremy: Probably not the same folder...every team has their own
         folder. If you download you have to fix them. You can't use
         relative URLs. I think that defeats the purpose of URLs. I
         think we could make it not work until you define types with
         customer property but I think that's worse because it'll
         not work if you don't define the property.
  fremy: afaict you can't define things like background and you'd
         have to define background somewhere else.
  leaverou: We should clarify this is quite an edge case. In most
            cases people have a CSS folder. I think TabAtkins got
            the right idea where URL tokens shouldn't be defined and
            if they need to be we can use a declarative syntax.
            Perhaps we could have a switch in the @ rule about how
            URLs resolve so people could do either
  leaverou: I think for now it's more important to be consistent
            with CSS variables.
  <astearns> +1 to making things work consistently for now, and
             getting this case to work with typed variables in the
             future
  fremy: If it's just me maybe we shouldn't. Do other people think
         this could be an issue?
  leaverou: We could straw poll.

  Rossen: TabAtkins isn't on and he had a strong opinion. I'm not
          hearing anything from Mozilla or Webkit. I want to hear
          more from other implement with their thoughts.
  dbaron: I think it's easier to be consistent then try and add a
          new mechanism. It's hard for me to say importance. I'm
          somewhat swayed by the argument there will be other ways
          to solve it.
  leaverou: From what I've heard from Google the fremy proposal is
            harder because you have to keep the origin of the URL
            token along with it.
  <dbaron> for us, it's actually a bit harder than that
  Rossen: Hard may not be the same for everyone else. That's why I
          want to hear more from Mozilla and Webkit.
  smfr: Webkit switched to use Blink's CSS parser so we're much
        closer on that.

  ChrisL: It's arguable by design that these are untyped by design.
          Though it's awkward for users it's consistent and we're
          not building into a corner. I like TabAtkins declarative
          syntax as well.
  leaverou: I think idea with most Houdini API is we'll have
            declarative ways eventually
  ChrisL: Yes, but I'm hoping for a concrete proposal instead of
          hoping for future
  leaverou: Me too.
  * fantasai isn't following variables too closely, but leaverou's
             argument makes sense to me

  Rossen: If I can summarize, TabAtkins has proposed an opinion on
          github. Sounds like Webkit has a similar implementation to
          Blink so if the decision was taken to align for Blink it
          should workfor Webkit.
  smfr: We implemented variables separately from Blink
        implementation.
  smfr: Webkit shares the CSS parser, but it has its own variable
        implementation.
  Rossen: Okay, I take it partly back. It should work in terms of
          parsing if we align to blink.
  <smfr> hyatt agrees with tab
  Rossen: Also, dbaron said he's mostly persuaded by TabAtkins
          proposal on github but not strongly opinion.
  <dbaron> not sure where I said that...?
  Rossen: Not much consensus with fremy on the other side.
  Rossen: We can give this another week and with more impl can give
          feedback on what the outcome should be rather then force a
          resolution?
  Rossen: What do you think? We can try and force consensus.
  ChrisL: If we can get resolution it would be good because we're
          missing some testing in that area
  leaverou: I think we can wait a week. It's important TabAtkins
            weighs in.
  fremy: Yeah, okay.
  Rossen: This is now on the radar of everyone that should be
          interested. We'll discuss it in a week. Before them people
          can go on github and bring other data points.

Propose to replace "'text-orientation: upright' to cause strong LTR"
    with author notes how to do it
--------------------------------------------------------------------

  <dauwhe> https://github.com/w3c/csswg-drafts/issues/755
  Rossen: This was from koji with comments from Florian.
  koji: This is something we discussed in TPAC. I have new
        information pieces. First, there is a way for authors to
        make it happen using bidi and direction properties.
  koji: It's in the last comment, but this is whether to make it
        automatic.
  koji: Other thing is I think I said no browsers have implemented.
        Gecko has partial implementation.
  Rossen: Did you check Edge?
  koji: The test fails. I'm not sure...
  Rossen: We're unprefixing upright
  koji: This is text orientation
  Rossen: Perhaps I misspoke. Sorry.

  koji: I'm okay to leave as-is since Chris says it can be
        exceptions. By understanding it's doable by authors it might
        be better to use notes saying author can do it.
  Florian: On the work around, if a browser implemented according to
           spec and an author also applied to work around it would
           be okay. Implement and work around don't conflict.
           Correct?
  koji: The complex...I need to think.
  koji: It's not easy to answer from the top of my head. Text is
        only one line but it's quick complex. Descendants could have
        different bidi and in those cases it's complicated.

  fantasai: We try to avoid having authors touch the unicode bidi.
            It's mentioned the authors shouldn't normally do this.
  koji: I put we could recommend bdo instead of properties.
  fantasai: It's not correct to do that. If you have your markup you
            don't want to change that based on stying. Cases to do
            this are very stylistic. You want something to look like
            a book spine.
  fantasai: You might decide later you want it horizontal or you
            have fallback code where you can do transforms if you
            don't support writing modes. You can't do that if you're
            setting bidi codes in the page.
  fantasai: The bidi stuff is a content thing. It doesn't belong in
            the style layer and needs to be separate.
  koji: But requires ltr is stying.
  fantasai: Vertical upright requires the typeset to ltr because
            when they're upright they'll be left to right in the
            typesetting POV. Doesn't mean it's rtl text in general.
            If you change the writing mode so it's sideways it needs
            to honor it's intended directionality.
  fantasai: We don't want authors using direction in bidi, but in
            the markup is worse.
  <dauwhe> Note that I emailed this issue to the EPUB WG on Monday,
           and didn't get any feedback.

  Florian: I don't think fixing the markup is good, but we have to
           choose between few bad options. This is a relatively rare
           case. Holding the spec up on a rare case might not be
           great and asking browsers to fix this rare case isn't
           great. If we can go to rec and not and exception I think
           that would be fine.
  Florian: If we drop to a should and restore to must that might
           work. That's why I asked if the work around works if a
           browser impl. If that's the case we can say this is a
           should and if the browsers don't impl here's a work
           around.
  fantasai: That seems like a better way forward
  fantasai: The work around is not compat without an impl that
            supports text orientation upright.
  Florian: But you can use @supports
  fantasai: Yeah. That should go in the example.

  Rossen: I agree this is a corner case and hanging the spec on this
          isn't a great idea. From the options listed, what do we
          feel we can resolve on?
  Rossen: 1) we can mark as at-risk 2) mark as should 3) and a
          non-normative example of the work around. or a combo of
          those
  Florian: I was suggesting a combo. I think we should introduce a
           note. The choice is drop to a should or keep as a must
           and argue during the call we should still go to rec.
  Rossen: Koji?
  koji: I'm okay with any.
  Florian: I think it goes to what will be easier. If the "it's a
           must but we don't care" is easy let's do that. if it's
           problematic we should drop to a should.
  Rossen: Can you summarize a proposed resolution?
  Florian: Add a note along the lines of koji's example telling
           authors how to work around the lack of correct impl.
  Rossen: I don't think we need a resolution on a note.
  Florian: It's in CR.
  Rossen: Correct. Sorry. Objections?

  RESOLVED: Add a note along the lines of koji's example telling
            authors how to work around the lack of correct impl.

  Florian: Either we don't need a second resolution and leave it as
           a must, or if we're worried we can drop to a should and
           restore to must at next level.
  Rossen: Doesn't sound like we need to resolve on this now. We can
          make the must as a should during CR.
  koji: I'm okay with it.
  <glazou> +1
  Rossen: Can we live with this one resolution for the note and
          react later if needed?
  koji: I'm fine.
  Florian: Think so.
  Rossen: Let's call this closed and bring this back if needed
          during PR transition. We'll talk next week.
Received on Wednesday, 7 December 2016 20:25:33 UTC

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