W3C home > Mailing lists > Public > www-style@w3.org > July 2017

[CSSWG] Minutes Telecon 2017-07-26 [css-align] [css22] [css-sizing] [css-counter-styles]

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 26 Jul 2017 20:49:04 -0400
Message-ID: <CADhPm3sLwz1T2_ErWL_DA_rYDraTehOLxvMoMzwkVWTd9psFvQ@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.

Spec Rec next steps

  - fantasai pulled a list of open Align issues to ensure they're
  - Bert reported that he's done enough work on CSS 2 so that a
      discussion on how to manage it going forward can be added to
      the F2F agenda.

CSS Alignment

  - RESOLVED: Option #1 from the issue
              "Reduce the size of the alignment container by the
              size of the float's margin box, then center the block
              in the remaining space (this is the behavior of HTML's
              align attribute)"
  - Issue #1611 (https://github.com/w3c/csswg-drafts/issues/1611)
      "Should last-baseline's fallback alignment be safe or unsafe?"
      is deferred to the F2F.
  - RESOLVED: Such alignments that overflow will not participate in
              last baseline alignment (Issue #1556:

Intrinsic Size of Images with Intrinsic Aspect Ratio and No Size

  - fantasai requested review on the text changes added to the spec
      to address this issue (https://github.com/w3c/csswg-drafts/issues/1609)
  - She also mentioned that Issue #951
      is on the F2F agenda for discussion so people can think about
      it in advance.
      - AmeliaBR noted that many of these cases have been addressed
          in SVG so referring to that spec should be useful in this

CSSFontFaceRule does not seem Web compatible

  - This topic will be added to the F2F agenda so all interested
      parties are available.

Exclude 'none' from <counter-style-name>

  - RESOLVED: Accept the edits proposed in

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

  Rachel Andrew
  Rossen Atanassov
  Amelia Bellamy-Royds
  Bert Bos
  Tantek Çelik
  Dave Cramer
  Alex Critchfield
  Elika Etemad
  Tony Graham
  Dael Jackson
  Tomoya Kimura
  Thierry Michel
  Anton Prowse
  Jen Simmons

  Tab Atkins
  David Baron
  Daniel Glazman
  Chris Lilley
  Peter Linss
  Melanie Richards
  Alan Stearns
  Lea Verou
  Greg Whitworth

Scribe: dael

Spec Rec next steps

  Rossen: Let's get going.
  Rossen: As usual, I wanted to ask if there is anyone who wants to
          bring extra topics besides the one tantek added
  Rossen: tantek that one topic you added, it's agenda for F2F which
          is why it didn't show. I was only querying for call.

  fantasai: Gerard wanted me to ask about impl report for writing
            modes and FF and Edge
  Rossen: I don't being on Edge we have the numbers. Safari answered
          over email and it looks like they're working on results as
  Rossen: In the ideal world we'll have a report for F2F next week.
  Rossen: Anything else to add fantasai?
  fantasai: I don't think so.

  Rossen: Going through the current inventory it seems we have
          publication requests for counters 3 scroll snap, font 4
          was published, box alignment is now past dbaron comments.
  fantasai: We published the WD for alignment last week. There's
            still open items.
  Rossen: What do we have outstanding for this? Are these what we
          have today?
  fantasai: Some yes, I think a few are marked for F2F. I can
            collect a list of open items.
  Rossen: Okay.
  <dbaron> (from TAG meeting) we're still going back-and-forth on
           some of the css-align issues
  <Rossen> dbaron, thanks for the update
  <fantasai> Open issues on css-align:
and https://github.com/w3c/csswg-drafts/issues?utf8=%E2%9C%93&q=is%3Aissue%20label%3Acss-align-3%20label%3A%22Agenda%2B%22
  <fantasai> There might be a few more, those are the ones we triaged

  Rossen: Did we close on UI tests for UI 4?
  fantasai: I think florian fixed a bunch, I have to re-review.

  Rossen: Is bert on?
  Bert: I'm here.
  Rossen: How are we doing with converging of CSS 2 folders, modules
  Bert: I merged css-2 and css-2-testing into 1. I removed the empty
        repo. There is not only 2 of them. I've been busy trying to
        make all the links work and cleaning up. Some of that is
        checked in. Then I started removing text that's in other
  Bert: The action item is done, but I'm still working on adding
        other things like the references to new modules.
  Rossen: Should we be able to put this on F2F agenda for next steps?
  Bert: Yes, I think we should do that. I won't have all the things
        I want done, but it'll be enough to talk about.
  Rossen: Thank you.

CSS Alignment

  Rossen: We have a number of Align topics.

Which behavior for block's "justify-self: center"?
  Github: https://github.com/w3c/csswg-drafts/issues/1612

  Rossen: Summary is you have a float and you are positioning a BFC
          next to it and this block has a justify-self: center which
          means without a float it'll be centered, but since the
          float is taking space away the justification need to
          either a) take the float into account or b) don't
  Rossen: In the case that the bfc has sufficient space to
          distribute around it the question is which proposal makes
          more sense? Place the float and then center or center
          ignoring the float and shift the float if necessary.
  Rossen: As an implementor I prefer option 1. I see more people on
          the issue for option 1. I'd like to hear alternatives or
          opposing opinions if there are any from the WG.

  Rossen: If no one has any we can resolve on option #1: the block
          would be positioned next to the float and centered in that
          remaining space.
  Rossen: [Reads from the github] "Reduce the size of the alignment
          container by the size of the float's margin box, then
          center the block in the remaining space (this is the
          behavior of HTML's align attribute)"
  Rossen: That's the proposal.
  Rossen: If there are no objections we can resolve.
  <fantasai> testcase

  Rossen: fantasai when you discussed with TabAtkins the current
          proposed is for BFC with fixed width or width which is
  fantasai: Either one. As long as width is smaller than remaining
  Rossen: I was asking because if the width is auto and supposed to
          extend out to fill available space css2.1 behavior is
          already what you described here.
  Rossen: The justification even though there would be centering you
          wouldn't be able to tell. So I guess this is mostly
          observable when BFC has fixed size smaller than available
          space and has justification.
  fantasai: Looks like centering with margins for auto has same
            behavior as centering with center tag.
  Rossen: For BFC next to floats?
  fantasai: Yeah. Which I wasn't expecting. I was expecting [missed]
  Rossen: This is the test case you pasted in IRC?
  fantasai: Yeah.
  Rossen: This is just another confirmation of existing behavior
          consistent with what you're trying to define.

  Rossen: I'm going to call for objections on the current proposed
          behavior. Current proposed is "Reduce the size of the
          alignment container by the size of the float's margin box,
          then center the block in the remaining space (this is the
          behavior of HTML's align attribute)"
  Rossen: Is there anyone objecting this this?

  RESOLVED: Option #1 from the issue "Reduce the size of the
            alignment container by the size of the float's margin
            box, then center the block in the remaining space (this
            is the behavior of HTML's align attribute)"

Should last-baseline's fallback alignment be safe or unsafe?
  github: https://github.com/w3c/csswg-drafts/issues/1611

  Rossen: We discussed last week, but didn't resolve as far as I
  Rossen: We wanted to gather any additional thoughts on Github.
          There were no updates. Do we feel like we have enough to
          resolve or do we leave to F2F?
  Rossen: Last week we couldn't get to a solution going back and
          forth a few times.
  Rossen: We didn't resolve due to time constraints. But we also had
          this back and forth about if this makes the most sense and
          the most consistent with other alignments and their
          default behavior in overconstraint scenarios.
  fantasai: Seems we didn't have consensus because good arguments in
            both directions.
  fantasai: Probably what we need is actual use case scenarios to
            come up with a reason for one being better.
  Rossen: As I mentioned, I can be persuaded either way. I favor
          consistency and in this case there was some inconsistency
          with the way fallback occurs for safe and unsafe because
          discrepancy between baseline-align and align end.
  fantasai: There's 2 kinds of align. safe and unsafe. We could be
            consistent with either one.
  Rossen: Right.
  fantasai: I'm okay deferring to F2F.
  fantasai: I'm hoping at F2F people will h ave something concrete
            for one or the other.
  Rossen: I don't mind

Compatible alignments aren't always compatible
  github: https://github.com/w3c/csswg-drafts/issues/1556

  Rossen: Can you summarize fantasai ?
  fantasai: We opened this and resolved on some. The cases where you
            have a stretch item and a last baseline aligned. If you
            have content alignment you can align stretch items. As
            long as the stretching takes effect. If the stretching
            is constrained we resolved that since there's an
            explicit need to align to top or bottom that's fine.
            We're covered.
  fantasai: If you have 2 end aligned things that normally are last
            baseline content alignment, but if one is overflowing
            and safe alignment it would end up start aligned. So
            what do we do for that thing?
  fantasai: Does everything shift down and do unsafe, do we bail
            where if you overflow we don't do baseline? We need to
            figure out and I don't have a clear proposal.
  fantasai: You have 2 items, self align to the end. They have
            content baseline alignment. One of them happens to be
            bigger than the box, but has safe alignment so it'll
            overflow the bottom. What do we do?

  fremy: I don't know if we need to baseline align. It seems like an
         error. I'd be fine saying we don't baseline align and just
         give up.
  Rossen: You favor where baseline align is ignored?
  fremy: Yes.

  Rossen: fantasai do you have a strong opinion?
  fantasai: Options are we perform last baseline alignment and treat
            all as overflow. Alternative is to say the overflow
            thing can't be last baseline.
  Rossen: And I think that second is what fremy was pointing out.
  Rossen: From impl PoV I would also favor the second. It would be
          good to hear from more people.

  Rossen: If there are no other opinions we can try and resolve or
          postpone to F2F with a whiteboard and more people.
  Rossen: Preference?
  fantasai: I'm okay resolving to bail on baseline alignment and if
            this happens that item can't participate.
  Rossen: Fine to me. Prop: Such alignments that overflow will not
          participate in last baseline alignment. Obj?

  RESOLVED: Such alignments that overflow will not participate in
            last baseline alignment

Intrinsic Size of Images with Intrinsic Aspect Ratio and No Size
  github: https://github.com/w3c/csswg-drafts/issues/1609

  fantasai: We won't resolve here, but I wanted attention. I checked
            in some rules for this that are in the sizing spec and
            we'd appreciate review. There's another case in issue
            951. There's no hints in 2.1 for this case and there's
            discussion there on how to handle it.
  fantasai: So there's two things with these. We'd like review of
            the new text and we should resolve 951, but that's on
            the F2F agenda.

  AmeliaBR: I haven't looked into the various issues with as much
            detail as I'd like, but it looks like the specific issue
            of what to do when width is
            undefined...that's....basically there are a lot of
            things with SVG not defined in any spec but we're
            getting a de facto standard from browsers impl so you'd
            want some tests to see what's already done.
  AmeliaBR: I or someone else could do that before the meeting in a
            couple weeks. Sorry I didn't prepare before.
  Rossen: Good point. In terms of SVG and ways we compute intrinsic
          size and all the variations...about a year ago we were
          revving our version of SVG sizing and at that time we did
          document what everyone is doing. I believe we have introp
          in most of the cases. The result of the work I believe was
          spec or tried to spec in the integration spec.
  Rossen: If it didn't make it it should be there. Regardless it's a
          valid point and we should solidify and explain how that
          works. Definitely a big +1 from me.
  <AmeliaBR> https://www.w3.org/TR/SVG2/coords.html#SizingSVGInCSS
  AmeliaBR: The text is in SVG 2^
  AmeliaBR: That's written in very SVG specific. For CSS you'd want
            to generalize, but it's written with CSS terminology. It
            can probably be reused. It doesn't cover min-width and
            max-width which becomes and issue with flexbox and grid
  fantasai: This is defining what intrinsic dimensions the SVG has.
            The SVG can return any combo of these as far as I'm
  fantasai: I think the one combo they don't have is width and
            height but no aspect ratio because you infer that.
  Rossen: Width and height with both % aren't.
  fantasai: SVG says we don't have an aspect ratio in %
  Rossen: Width and height are computable.
  fantasai: Spec says if width or height are auto or % CSS is told
            there is no width or height. CSS algorithm takes that to
            calc a box. CSS then tells the SVG here's your size.
            Then SVG uses information to draw inside the rectangle.
            This spec is about how to size that rectangle.
  fantasai: When you're auto sized if the SVG has a width and height
            that's easy. If it has one or the other...it's missing
            some info...we need answers. If it has aspect ratio but
            not width or height browsers tend to use size of
            containing block to calc width and use aspect ratio for
  fantasai: That gives you a fulls sized SVG image taking up width
            of containing block.

  fantasai: So that's great and I think standardizing on that where
            we can is great. There's one case with cyclic
            dependency. You can't use containing block size if that
            size depends on you.
  fantasai: We need an answer for that size. I think there isn't
            consistency in this respect. I think using 300px for the
            width is possible but not ideal. 951 is to find a better
            solution. Current proposal is same as what we do for
            orthogonal flows. We have a formula to find a size.
  fantasai: The rest of the cases are a little constrained. If you
            don't have any intrinsic size or aspect ratio, that's
            the iframe case and we use 330 x 150.
  fantasai: We took the 2.1 rules and tried to write them into
            Sizing. That one underdefined case is on the F2F agenda.
  Rossen: That's 951?
  fantasai: 951 is the open. Other we believe is consistent with
            2.1, but it all requires a bunch of testing and I
            haven't done that.
  fantasai: We're looking for review of CSS 3 Sizing to make sure
            it's correct and thoughts on 951.

  Rossen: I'm going to go back to your opening statement that this
          is more of an awareness call. I would side on taking this
          to the F2F and solving on a white board.
  Rossen: Resolving now won't get us too far.
  fantasai: If AmeliaBR would review that section we'd appreciate it.
  AmeliaBR: I'll try.

  Rossen: Will you be at F2F?
  AmeliaBR: No.
  Rossen: Let us know if you can call in and we'll try and

CSSFontFaceRule does not seem Web compatible
  github: https://github.com/w3c/csswg-drafts/issues/825

  Rossen: This was added by ChrisL.
  <myles> https://www.w3.org/TR/2011/WD-cssom-20110712/#cssfontfacerule
  myles: This is about what happens in CSSOM if you pull out a rule
         that represents a FontFaceRule. There's an old spec that
         says this only has one rule that is a style declaration.
  <myles> https://drafts.csswg.org/css-fonts-4/#cssfontfacerule0
  myles: This was updated to ^ which gets rid of the one style
         attribute and replaces with a bunch of strings.
  myles: Before you would get your rule in JS and say
         .style.getPropertyValue and in the new rule you say .family
         to get the string.
  myles: Every browser implements the old approach. There have been
         proposals of what to do. 1) revert, 2) have both 3) make a
         .style but have it be a new custom object with only some
         stuff and not all the generality of the style declaration.
  myles: This came up because I started making edits and I don't
         know what to do.
  myles: My opinion is since browsers are standardized that's what
         should go in spec. I imagine there are other thoughts.
  <tantek> +1
  Rossen: Most people engaged in this aren't on the call today.
          ChrisL, dbaron, and TabAtkins are all not on the call.
  myles: We can push. I'll give the speech again next week.
  Rossen: I'm sympathetic with your proposed opinion to standardize
          on one behavior. But I'd also like to hear from others
          that were in this conversation.
  myles: That's fine.

  <TabAtkins> The specced thing is definitely *better*, no question.
              And it's what I designed the FontFace object after,
              not knowing the spec didn't match reality. But we need
              someone to actually make the change and show it's

Exclude 'none' from <counter-style-name>
  github: https://github.com/w3c/csswg-drafts/issues/1295

  Rossen: Who is on the call from this convo? SimonSapin?
  fantasai: This was filed a while ago about dealing with none
            value. This was with SimonSapin & Xidorn about excluding
            none from <counter-style-name> Edits are checked in,
            it's on the agenda to check they're okay because it's a
            change to CR spec.
  fantasai: Otherwise we should resolve to accept edits and
            republish counter styles.
  <fantasai> well, I guess there are two more issues on counter
  <fantasai> to resolve before republishing
  <fantasai> DoC:
  <AmeliaBR> Weren't there other changes about disallowed names?
             Decimal and circle, or something like that? Have they
             already been approved or deferred?

  <Rossen> https://github.com/servo/servo/commit/04aaef8b3d0bc12ad5d2d5c9ecf003c016928a30
  Rossen: I'm trying to find the edits. Is this the edit ^?
  <fantasai> Looks like the changes are here:
  Rossen: For this issue, #12 in DoC....
  Rossen: Excluding none from <counter-styles-name> will this reset
          the CR? I missed the consequence of accepting the edit
  fantasai: It's a substantive change to a CR spec so we need WG
            approval for the change.
  Rossen: Did anyone get to review? Does anyone have an opinion?
  * tantek tries to review quickly
  <tantek> interesting
  <tantek> in a good way
  <fremy> (I just gave this a read, I think this is reasonable
          change; sounds ok)

  Rossen: So we can resolve on the committed change and reset the CR
          of CSS counters.
  <fantasai> https://drafts.csswg.org/css-counter-styles/issues-cr-20150611#issue-7
  fantasai: There's 2 more issues on counter styles before we
            republish. 2 more substantive. 1 is included in the
            change set which is computing undeclared to decimals.
            Last one is involving i18n and a11y so we'll have to
            liaise with those groups.

  Rossen: tantek you seems to be reviewing. Interesting in a good
          way from you. fremy seems to support.
  Rossen: Should we resolve or is anyone else looking?
  * tantek reviews conversation
  <tantek> seems sensible, improves consistency
  <tantek> per https://github.com/w3c/csswg-drafts/pull/1326
  <tantek> and I've never looked at this issue before AFAIK. so
           consider it an outside opinion

  <Rossen> https://wiki.csswg.org/planning/paris-2017#proposed-agenda-topics
  Rossen: While everyone reviews, I want to remind people to add
          topics to the F2F agenda ^
  Rossen: Please add agenda items.

  Rossen: tantek supports it. Thanks for reviewing.
  Rossen: Other opinions before I CFC?
  Rossen: Objections to accepting the edits for
https://github.com/w3c/csswg-drafts/issues/1295 ?

  RESOLVED: Accept the edits proposed in

  Rossen: That's the top of the agenda.
  Rossen: Any other quick topics? Or should we reclaim 5 min?

  Rossen: I wish you all safe travels. For those of you already
          there we'll see you next week.
Received on Thursday, 27 July 2017 00:49:59 UTC

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