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

[CSSWG] Minutes Telecon 2017-04-05 [css-images-3] [css-grid] [css-multicol] [cssom-view] [css-overflow] [css-fonts-3] [css-ui-3] [css-transforms] [css-cascade]

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 5 Apr 2017 19:13:10 -0400
Message-ID: <CADhPm3sQtnLMtkJJWg_32-y7pnRFRbKvPCrjt3+Ygmb5tW-MxA@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.
=========================================


Telecon for Transforms & fill-stroke
------------------------------------

  - The inaugural call between the CSSWG and those interested in SVG
      will be 6 April at 9pm UTC.

 REC Steps
 ---------

   - Fonts 3: Myles was actioned to make the changes to the test
       font requested by ChrisL and Rossen.
   - Cascade: The edits to drop scoped styles were made.
   - Values & Units: smfr was actioned to review the <position>
       edits.
   - RESOLVED: Update motion draft on TR

2017 Paris f2f dates - can we decide exactly?
---------------------------------------------

  - RESOLVED: Meeting Houdini Aug 1, CSS Aug 2-4 in Paris

Move underimplemented features to Images 4
------------------------------------------

  - RESOLVED: Move everything with no impl to next level and mark
              everything with 1 impl as at risk.

Grammar of grid-row-start and friends is ugly and harms value space
    for line names
-------------------------------------------------------------------

  - Everyone agreed that limiting the name space was bad and should
      be avoided in the future. Unfortunately, it is too late to fix
      this issue.
  - RESOLVED: No change on issue 1137
(https://github.com/w3c/csswg-drafts/issues/1137)

Definition of `column-span` should say what happens without an
    ancestor multicol
---------------------------------------------------------------------

  - RESOLVED: Have column-span elements create a bfc even if not in
              a multi-col container.
  - Florian will clarify the spec in the form of a note.

New feature - scroll-boundary-behavior (an extension of
    -ms-scroll-chaining)
--------------------------------------------------------

  - RESOLVED: Create a WICG repo for this new feature and work there
              for now.

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

Agenda: https://lists.w3.org/Archives/Public/www-style/2017Apr/0014.html

Present:
  Rossen Atanassov
  Tab Atkins
  David Baron
  Tantek Çelik
  Dave Cramer
  Benjamin De Cock
  Elika Etemad
  Simon Fraser
  Daniel Glazman
  Tony Graham
  Dael Jackson
  Brad Kemper
  Peter Linss
  Thierry Michel
  Michael Miller
  Simon Pieters
  Anton Prowse
  Melanie Richards
  Florian Rivoal
  Geoffrey Sneddon
  Alan Stearns
  Lea Verou
  Greg Whitworth
  Steve Zilles

Regrets:
  Rachel Andrew

Scribe: dael

Telecon for Transforms & fill-stroke
------------------------------------

  astearns: Let's start. Any extra items?
  fantasai: Yes.
  fantasai: There was a suggestion to have a separate SVG call for
            transforms & fill-stroke. I sent an email about that
            yesterday.
  fantasai: Current proposed time slot is tomorrow during SVG time
            slot. That depends on who is interested in making it.
            I'd be interested to take a quick IRC survey.
  dbaron: What time is that in clock time?
  fantasai: Let me grab the link
  <fantasai> https://www.timeanddate.com/worldclock/fixedtime.html?month=04&day=06&year=2017&hour=21&min=00&sec=0&p1=0
  fantasai: 9pm UTC, 5pm East US, 11pm Paris, 7am Sydney, 6am Tokyo

  astearns: So could people interested in meeting at that time
            tomorrow put in IRC if they can make it?
  fantasai: Topic for tomorrow is transforms.
  fantasai: I want to know if you care about transforms,
            fill-stroke, or both. And then I want to know if you can
            make it.
  <dbaron> I'm somewhat interested in transforms, but can't make
           that time tomorrow
  fantasai: If you're interested in one of those, please type T, F,
            or Both in IRC.
  <Rossen> T
  <dbaron> T
  <TabAtkins> Both
  <ChrisL> both
  <gregwhitworth> T
  <smfr> Both
  <fantasai> T if you're interested in Transforms, F, if you're
             interested in Fill-Stroke, Y if you can make it N if
             you can't make it tomorrow
  astearns: Please now type if you can make it tomorrow.
  <Rossen> interested<T> Sure();
  <bradk> Interested, but can't make it
  <ChrisL> Both Y
  <TabAtkins> Y
  <smfr> Y
  <dbaron> N
  <tantek> cannot make it to the telcon
  <tantek> N
  <gregwhitworth> N

  astearns: I expect some of these issues should be on the F2F
            agenda.
  astearns: So we'll also have F2F discussion and we can meet after
            the F2F.

  fantasai: dbaron and gregwhitworth would a different week work?
  dbaron: For me a different week would work...but let me think
          between now and f2f.
  fantasai: smfr is out next week.
  <gregwhitworth> I'm just pretty booked at the moment, I can make
                  tomorrow work if necessary.
  dbaron: For time tomorrow I'm on plane to Asia and will be there
          through the F2F.
  Rossen: Can we keep it tomorrow? Go with the time. A number of
          people can join. If we have pending decisions for FF and
          there's no rep we can make those resolutions pending
          review. But it would be good to get on the phone and make
          progress.
  <gregwhitworth> that sounds fine
  <fantasai> birtles, Can you make it tomorrow?
  Rossen: dbaron is that okay with you? And whoever else can't make
          it?
  dbaron: That's okay.
  fantasai: I'll take minutes.
  Rossen: Thanks for organizing fantasai.
  astearns: This will be the inaugural and we'll continue these to
            get transforms done.

REC steps
---------

  astearns: That's was the item for transforms. There's a bit on
            fonts 3 and Rossen was to investigate a font issue in
            Edge?
  Rossen: I did look yesterday. The font that was prepared wasn't
          prepared in a way that works with dwrite.
  Rossen: I did send a message to those on the original email.
  Rossen: Summary was if you're asking for zero horizontal progress
          we'll make 0.
  ChrisL: Well, the CSS font has it's own duplicate set of metrics.
          Some browsers will respect that and some won't.
  Rossen: It depends on if you're calling back on dwrite or not.
  Rossen: But I believe what's in the email was actionable.
  ChrisL: Yes. I can patch the font to do that. myles could do it
          better.
  Rossen: Okay.
  smfr: I think myles is out this week.
  ACTION myles to respond to the dwrite issue and ChrisL's asks for
         font edits.
  <trackbot> Created ACTION-838

  astearns: Cascade. There's an item to drop scoped styles. Did that
            edit get made fantasai?
  fantasai: I think TabAtkins and I did that two weeks ago, yes.

  astearns: V&U
  astearns: It has <position> edits.
  <astearns> https://lists.w3.org/Archives/Public/www-style/2017Mar/0054.html
  fantasai: They're done. We're waiting on review by somebody.
  astearns: Is there a person you'd like to action to review?
  fantasai: I have no idea. Does anyone care? Maybe smfr since he
            has to integrate into transforms?
  smfr: I missed that.
  fantasai: We made edits to <position> for transform-origin.
  smfr: Sure, I can do that.
  ACTION smfr look at <position> edits
  <trackbot> Created ACTION-839

  fantasai: Are there plans to update motion draft on CR?
  <tantek> +1 fantasai update it please
  astearns: Good question.
  TabAtkins: Yeah, sure. It wasn't on my immediate to do list, but
             it should be done.
  ACTION TabAtkins update motion draft
  <trackbot> Created ACTION-840

  fantasai: We'll need to update backgrounds & borders once the
            <position> edits are published and that will need a
            resolution.
  astearns: Right. There was another item on backgrounds & borders
            about fixing test. That was on tmichel.
  tmichel: I haven't made progress. I have to investigate how to
           change those tests.
  astearns: That's fair.

  astearns: Last thing is changes to tests for UI. They were
            reviewed and Florian was going to update the tests.
  Florian: I'm waiting for a review from fantasai on an update I did.
  astearns: So, fantasai, will you have time soon to look?
  fantasai: Probably not, but I can try.
  Florian: Should be quick since I think I did everything you asked
           for.
  fantasai: I think there was one that was a long thing.

  Florian: Is gsnedders on?
  gsnedders: Yes.
  Florian: I think there's one PR that has been migrated, but one
           hasn't. What's the status there?
  gsnedders: There's three left on the old repo that have comments
             which are hard to move over. So yeah, I should be able
             to do that soon.
  Florian: Yeah, one PR is in the new, one will go soon.
  gsnedders: Yes, there's 3 still on the old platform total.

  astearns: And fantasai mentions we need a resolution to publish
            motion. This is just an update, it's not in CR?
  fantasai: Correct. This is merging in round display and other
            changes.
  ChrisL: It's an auto publish?
  fantasai: The old one was on the old system but yes.
  astearns: Objections to updating Motion draft?

  RESOLVED: Update motion draft on TR

2017 Paris f2f dates - can we decide exactly?
---------------------------------------------

  <astearns> https://github.com/w3c/csswg-drafts/issues/1165
  astearns: I thought dates were exact, Aug 1-4 where one is a
            Houdini.
  tantek: Which one?
  astearns: We usually do Houdini first. Aug 1 houdini, 2-4 is CSS.
  tantek: Can we get a resolution on the record?
  * fantasai couldn't find it either
  astearns: I think we were waiting on confirmation from Mozilla
            they can host.
  tantek: We can confirm we have the space.
  Rossen: We don't tend to have formal resolutions on F2F days.
  fantasai: We do usually.
  Rossen: I don't recall, but sure.
  gsnedders: There were two lines in the minutes on the F2F.
  astearns: Yeah, the discussion was longer than the minutes.
  <fantasai> It appears there was no minute-taker for that discussion
  astearns: Obj to resolving to meeting Aug 1-4 in Paris?
  <fantasai> rossen, resolution on dates =
https://lists.w3.org/Archives/Public/www-style/2017Mar/0021.html

  RESOLVED: Meeting Houdini Aug 1, CSS Aug 2-4 in Paris

  tantek: astearns can you make the page?
  astearns: I will set up a page stub for you to fill in details.
            I'll copy what I can.
  tantek: dbaron myself and Jet will work on that.

Move underimplemented features to Images 4
------------------------------------------

  <astearns> https://github.com/w3c/csswg-drafts/issues/1148
  leaverou: I was looking at the last CR. There are many features
            that have wide impl, but there are some that are none
            or 1.
  leaverou: First is image(). Unless someone plans to implement I
            would suggest deferring.
  TabAtkins: I agree.

  leaverou: Another feature without impl is image-resolution. Is
            anyone planning on impl?
  TabAtkins: I thought we had an impl of that. I could be wrong.
  <leaverou> http://dabblet.com/gist/33ac15e3d6372b2d97b17061783eb40f
  leaverou: Since we don't have tests I had to make a quick one.
            This is what I used ^
  <smfr> webkit does not have image-resolution
  <dbaron> Gecko does not have image-resolution
  leaverou: It just tests parsing so if the browser doesn't
            recognize I assume it's not impl.
  TabAtkins: Ah, I was thinking image-rendering.
  Florian: image-resolution has partial implementation in
           Viviostyle. I'm not sure we fully comply.
  TabAtkins: That's still compatible with going to level 4.
  leaverou: Do we agree with deferring? Yeah.

  leaverou: Image-orientation is only Gecko.
  leaverou: Any plans to impl?
  <tantek> there's web author demand for image-orientation
  <tantek> especially in the IndieWeb community
  TabAtkins: I could have sworn safari had something.
  smfr: On iOS we respect it and on mac we don't and this is
        terrible. We need to pick one. If we had this the author
        could force, but we don't have an impl yet.

  TabAtkins: We also have an issue that we want to kill everything
             except from image and initial because the rest aren't
             really CSS appropriate.
  <zcorpan> https://bugs.chromium.org/p/chromium/issues/detail?id=158753
  fantasai: The other values were added for printer impl. That's why
            it's in a spec.
  ChrisL: If you only have those two values it's a true/false with
          lengths.
  TabAtkins: Nothing wrong with a property only having two
             reasonable values.
  ChrisL: It does mean if you want 270deg rotate you have to edit
          the image.
  TabAtkins: Or you use a transform.
  Florian: Or a writing mode
  <zcorpan> writing-mode doesn't affect images?
  <fantasai> writing-mode doesn't affect images
  ChrisL: Yeah, okay.
  astearns: Given there's only on impl and there's question on
            values it seems it could move.
  leaverou: I agree.

  <leaverou> http://dabblet.com/gist/d2c5b3d1beba1dd514f505ab8e3ad219
  leaverou: There's gradient interpolation. I did a test ^
  leaverou: None of the UAs seem to support. I heard Edge 15 might
            have, but I don't have one here to test.
  <MaRakow> yes, edge supports gradient interpolation for some time
            now

  fantasai: Back to image-orientation I'd prefer to keep it in. It's
            referenced from other specs. If it keeps us from PR we
            can drop at that point.
  TabAtkins: Mark as at risk
  <ChrisL> mark it as at-risk, then

  TabAtkins: And MaRakow says Edge does support [gradient
             interpolation].
  leaverou: We have 1.
  Florian: It's a good feature, but depends on how fast people will
           get to it.
  fantasai: I think we need to clean up what's clearly not going to
            get impl. We can mark the others as at-risk.
  leaverou: It's been there over 5 years though.

  TabAtkins: Let's punt the things with 0, things with 1 get an
             at-risk.
  <tantek> +1 tabatkins. drop 0 impls feats. at risk 1 impl feats.
  leaverou: I think we can get a resolution. The rest have 2
            depending on if you consider blink and webkit different.
  TabAtkins: In this case I think those are pre-fork..
  astearns: So they're at risk.
  <fantasai> either way, using just those two as implementations is
             questionable, because they share architecture and code

  astearns: Move everything with no impl to next level and mark
            everything with 1 impl as at risk.
  <glazou> +1 to what astearns said
  leaverou: Yes, and can we then resolve on an updated CR?
  Florian: You need a DoC.
  ChrisL: Could we only resolve once the supporting documents are
          done?
  fantasai: Yes, I agree with that.
  astearns: Objections to the resolution on edits?
  astearns: proposal: Move everything with no impl to next level and
            mark everything with 1 impl as at risk.
  tantek: Can we ask for that to be in a changes section?
  TabAtkins: Of course.
  fantasai: Changes and DoC haven't been compiled.

  RESOLVED: Move everything with no impl to next level and mark
            everything with 1 impl as at risk.

  astearns: We'll make the edits and then update the draft once it's
            all in place.
  astearns: Anything more on images 3?
  leaverou: Nope.

Grammar of grid-row-start and friends is ugly and harms value space
    for line names
-------------------------------------------------------------------

  <astearns> https://github.com/w3c/csswg-drafts/issues/1137
  glazou: I made that comment because I found the issue when I
          started impl the properties. I understand this is too
          late, but I wanted to highlight it. We narrowed the value
          space for no reason.
  glazou: It's something we should not do again and it's unfortunate
          that I couldn't see it before.
  TabAtkins: I agree in general that having custom idents live in an
             overlapping value space with specified idents is often
             clumsy. I thought it was reasonable at the time, it's
             probably too bad we cut out values. I agree in the
             future we should minimize situations where this happens.
  glazou: It's not minimizing. I really think we should get rid of
          this kind of issue. If we keep this kind of thing we're
          only thinking about engines. Editors will have to provide
          UI mechanism to disable for these values. It's bad design.
          We're responsible for the whole system. We should not do
          it again.
  TabAtkins: Yeah, sure.
  <fremy> +1
  TabAtkins: I won't say we'll never do it again because we may have
             to deal with it for compat, but I want to avoid it.
  astearns: And we're talking about combining keywords and custom
            idents.
  glazou: Yeah.
  astearns: I'll put it on our list of css mistakes page.

  astearns: Just to be clear, you're okay closing no change glazou?
  glazou: Yeah.
  astearns: Since this is on CR we need a resolution. Objections?

  RESOLVED: No change on issue 1137

Definition of `column-span` should say what happens without an
    ancestor multicol
---------------------------------------------------------------

  <astearns> https://github.com/w3c/csswg-drafts/issues/1074
  Florian: If I remember we reached where if column-span should do
           anything not in the multi-col. Both sides were hanging in
           terms of author friendliness.
  Florian: One set of people said if you're not in multi-col you
           don't expect it to do anything so it shouldn't. The other
           side is that the content of the multi-col is usually
           styled the same as other block layout and if you do
           remove the multi-col you're likely to forget to remove it
           and you'd want the rest of the style to stay.
  Florian: So are we looking for predictable and consistent model or
           one that does things the way you want if you forget to
           remove something.
  Rossen: To confirm you're calling predictable and consistent where
          when you have remaining values in a layout system that no
          longer matches, that's what you mean?
  Florian: If you're not in a multi-col, multi-col properties don't
           apply.
  Rossen: I'm in favor of that one.
  <bdc> FWIW as an author, the typical thing I'd do is to use
        multicol for wide viewports and just kill it in a media
        query for mobile/etc.
  <bdc> would be very unexpected/annoying to revert multiple props

  TabAtkins: We took as a general principle that a one col or one
             row grid should act the same as a flexbox, basically.
             Similarly a single column multi-col is basically
             identical to a flow-root container so having the
             differences minimize would be good. So having this
             property that has the sole effect of making a child a
             block container is fine with me.
  Florian: You disagree with Rossen?
  TabAtkins: Yes. Let's make col-span continue being a block
             container.
  Florian: Interesting thing is you're both arguing against what
           your browsers are doing.
  Florian: Edge does what TabAtkins wants and Chrome does what
           Rossen wants.
  astearns: Chrome is the odd one out?

  <Rossen> https://jsfiddle.net/Ld86cuwk/
  <Florian> https://github.com/w3c/csswg-drafts/issues/1074#issuecomment-289172502
  Florian: Safari and Edge create a bfc.
  Rossen: Is that the right link?
  Florian: Yeah.

  fantasai: I'd like to point out the irc comment from bdc [reads]
  Rossen: What we're currently doing seems like a bug, even though
          it matches what you're saying. That's an easy bug to fix.
  astearns: But if you fix it and it breaks the author
            expectations...
  Rossen: Can we rename this property to please make me a bfc?
          Because this will go into css tricks as the main way to
          make a bfc.
  <dbaron> We did add display:flow-root!
  Florian: You can use flow-root for that.
  astearns: This behavior has worked this way in several browsers
            for years and that hasn't happened.
  Florian: And I think the MQ argument strengthens the argument.
           Switching multi-col on or off is a very reasonable use
           case. Having a single thing to switch is much more author
           friendly.
  Florian: I was neutral but am starting to join TabAtkins and
           fantasai.
  <bradk> So to make a flow root, { column-count:1; } on parent and
          { column-span: all } on child.

  astearns: Another thing to note is we have a browser with a
            different behavior that is willing the change.
  Florian: I think currently the spec isn't very explicit. But it
           does correspond to making a bfc if you read it carefully.
  Rossen: I don't formally object, but I'm not going to agree.
  astearns: Would anyone else object to having column-span elements
            create a bfc even if not in a multi-col container?

  RESOLVED: Have column-span elements create a bfc even if not in a
            multi-col container.

  Florian: The spec needs to be clear that this is intentional, so
           I'll add a note.

New feature - scroll-boundary-behavior (an extension of
    -ms-scroll-chaining)
--------------------------------------------------------

  <astearns> https://github.com/w3c/csswg-drafts/issues/769
  fantasai: This was requested by someone...
  TabAtkins: Majid, he's one of our implementors.
  fantasai: And someone from Facebook.
  TabAtkins: Microsoft has a feature already where you can dictate
             what happens when you're scrolling inside a scroller
             and you hit the end. Do you capture or do you move the
             rest of the scroll action upwards in the page.
  <tantek> what about the scroll-bounce?
  TabAtkins: They have an explicit control. It's ms prefix. We'd
             like to standardize this idea, we like it. THere's a
             lot of discussion of what to capture and how to do so.
             That's cool. Basic ask is does the WG feel this is
             worth doing a spec? Should we do this in WICG?
  fantasai: I think it's already in WICG. Question is do we add it
            to a draft and which?
  fantasai: There's a lot of question so we're in a place where we
            want to be able to have individual issues on each
            question.
  TabAtkins: Yeah. Do we believe this is mature enough to bring into
             the group or leave in WICG and make sure it has a repo
             there.

  Rossen: I didn't read the whole WICG topic, but I remember there
          being breakouts on this. I would be in favor of moving it
          in, especially if there's interest from others.
  Rossen: Maybe Overflow? Something along those lines.
  fantasai: Makes sense to me.
  TabAtkins: Or we can support it getting a WICG repo. Then when we
             do get agreement there we can pull into overflow.
  fantasai: Open discussion on syntax has not stopped us from
            putting things into a draft before. If there wasn't
            feature clarity I would say more discussion, but this
            seems as well defined as a lot of stuff in drafts
            already.
  astearns: I'm interested to experiment with WICG process. I'd be
            interested to have an official repo and go through that
            process.

  astearns: So why don't we try the official WICG incubation process
            and move it in once it's in a good state?
  Florian: One problem is define a good state
  TabAtkins: There's success criteria in WICG. They've worked for
             webapps. If there are issues we will be in there and we
             can provide feedback on how to improve for csswg. It
             seems valuable to experiment and this seems like a good
             thing to do it with.
  Rossen: There has been quite a bit of discussion on this and on
          our side the people most involved on initial
          implementation have had discussion with Majid. Most
          technical discussion is closed. If we're only talking
          syntax I think we're ready to move.
  Rossen: Although, as I said, if others want to continue in WICG
          and you believe you have strong technical additions or
          objections to what is done so far I'm fine continuing
          there.

  ChrisL: I'm hearing 3 or so viewpoints. I heard astearns say he
          wants to experiment with WICG. I hear Rossen say it's
          mature enough and let's move now. I hear TabAtkins say
          that there is a process to move and we haven't made that.
          Is that correct?
  TabAtkins: I'm in astearns' camp.
  astearns: I think that is true, though, that there is a process
            that says you set up a repo and work there until it's
            ready for standards. If this is mature enough it can
            skip repo, maybe that's feedback for WICG when working
            with us.
  Florian: The point where a spec is ready to graduate if we work
           together cannot be dictated from one side. They can say
           we're only comfortable working until as late as something
           and we can say we won't work until a point. But we need
           to agree on a certain point in between.
  TabAtkins: We don't have to send signals, we're the ones that lead
             the WICG CSS forums.
  Florian: It's overlapping with us, but it's not us.
  TabAtkins: I don't want to get into a WICG discussion with one
             minute left.

  astearns: I'd like to continue experimenting with WICG, get a
            repo, and see if that was a useless step so we can
            figure out what to do in the future given this
            experiment.
  astearns: Are there objections to creating a WICG repo for this
            near feature and working there for now.
  <ChrisL> no objection
  <leaverou> no objection
  <dbaron> needs to leave for another meeting, and is fine with
           experimenting with this in WICG for a bit
  Florian: I'm not super enthusiastic about the whole thing, but if
           we're going to experiment this is a good thing to do it
           on.

  RESOLVED: Create a WICG repo for this new feature and work there
            for now.

  Rossen: We're less that 2 weeks from F2F and there's nothing on
          the agenda. Please add topics.
  astearns: Yes, please do. Thanks everyone for calling in.

  <fantasai> astearns, so do we close the issue in our repo and ask
             ppl to re-open when they're ready to move over or what?
  <astearns> fantasai: I think we leave the issue open, and add a
             link to the WICG repo
  <astearns> once everything in that issue is addressed, or added to
             WICG issues, we can close it
  <fantasai> doesn't like having untagged issues in the repo, they
             tend to get lost
  <fantasai> can we assign it to a module at least?
  <astearns> it's tagged with overflow and cssom-view now
  <fantasai> ok
Received on Wednesday, 5 April 2017 23:14:17 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 5 April 2017 23:14:18 UTC