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

[CSSWG] Minutes Telecon 2016-07-20 [css-color] [css-align] [css-grid] [css-values]

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 20 Jul 2016 20:17:12 -0400
Message-ID: <CADhPm3sdRMoZB+TkUiPoQg8f_tfzuZqHuXVTLvYPmLJcmtA9xA@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.

Predefined spaces

  - RESOLVED: Add AbobeRGB and ProPhotoRGB as predefined spaces.
              Allow either the table of numbers or an ICC v.4
              profile with relative colorimetric intent
  - RESOLVED: Add a single CMYK profile, with relative colorimetric
              intent, mainly to use as a fallback

Support for CSS namespaces

  - TabAtkins explained the work being done on web components which
      will solve for many of the problems authors are facing around
      - The group agreed that this approach did seem like it would
          help and more experimentation in this direction would lead
          to more progress.
  - The group also actioned TabAtkins to create a wiki to gather the
      history of work and experimentation and allow authors to
      comment and contribute to further progress.

Testcase for text-align: right + list-style: outside

  - RESOLVED: Outside bullets are outside the box.


  - RESOLVED: Accept the change (implied min takes on the constraint
              defined on the track).
  - Everyone has a week to review the proposal for block-axis
      baseline: https://github.com/w3c/csswg-drafts/issues/197
  - Next week the group will resolve on block-axis and then vote to
      publish Grid.

Values & Units

  - RESOLVED: Start a level 4 draft of Values & Units, move calc()
              serialization to it, and then publish the remainder of
              Values & Units 3 as CR.


Agenda: https://lists.w3.org/Archives/Public/www-style/2016Jul/0049.html

  Rachel Andrew
  Tab Atkins
  Bert Bos
  Tantek Çelik (IRC Only)
  Dave Cramer
  Alex Critchfield
  Elika Etemad
  Simon Fraser
  Dael Jackson
  Brian Kardell
  Brad Kemper
  Ian Kilpatrick
  Chris Lilley
  Myles Maxfield
  Michael Miller
  Edward O'Connor
  Anton Prowse
  Liam Quin
  François Remy
  Florian Rivoal
  Geoffrey Sneddon
  Alan Stearns
  Lea Verou
  Greg Whitworth
  Steve Zilles

  Rossen Atanassov
  David Baron
  Daniel Glazman
  Jen Simmons

Scribe: dael

  astearns: Let's get started. Does anyone have anything to add to
            the agenda?
  <TabAtkins> We can drop the comma-redux topic - I've begun
              gathering compat data, but haven't analyzed it yet.
              I'll be ready next week.
  <ChrisL> yeah, agreed on the comma topic
  fantasai: If we have a few minutes, Values & Units. We're still
            hung up on the calc() serialization but I'd like to
            publish a new CR so I propose make that undefined.
  astearns: Okay. We'll do that instead of the comma discussion.
  astearns: Anything else?

Predefined spaces [css-color]

  <ChrisL> https://github.com/w3c/csswg-drafts/issues/292
  ChrisL: At the San Francisco meeting a couple of people suggested
          we should have a larger set of predefined spaces. The
          thought there I think was we should add a bunch more.
          Recently dino said start with a small set. Apple only
          needs one, P3. Maybe AdobeRGB and ProPhoto.
  ChrisL: I said they should be added. We can do an ICC profile or
          do the table we have. Table is simpler but less control.
  ChrisL: It's also helpful to have a predefined CMYK space as a
  ChrisL: I could go either way on that. I can see it being helpful
          or slowing up. I'd like opinions. Especially from digital
          publishing or print-PDF publishers
  ChrisL: I'd like to know what other people thought.
  <myles> ChrisL: is there a specific proposal here, or are we just
          discussing which color spaces should be present

  Florian: You said should we define the color spaces with ICC
           profile or table. Do we have to say in the spec?
  ChrisL: Yes. An ICC profile needs a rendering intent. Relative
          color image is testable and perceptive isn't testable.
          Also, if we provide ICC profile do we require support of
          ICC? If so which version? There's a bunch to put forward.
          P3 and r2020 were done with tables and people have that. I
          was thinking that would help get implementation going

  SteveZ: Is there a difference that's noticeable between the two
          methods since they're fixed somewhere? I understand
          control eventually, but if we're restricting to a fixed
          set is there difference?
  ChrisL: If you use version 4 of ICC you apply chromatic adaptation
          transform to the primaries and then do a tag for the
          chromatic adaptation. So the numbers would be different,
          but visually similar. For relative color intent it will be
          the same for in gamut.
  ChrisL: If I have access an implementation that does ICC I could
          test but I don't know one.
  Florian: What happens for out of gamut colors?
  ChrisL: You have to define it. At the stage you can go to linear
          RGB you get linear. I think we should say you clip to a
          neutral gray point. It shouldn't do per component clipping.

  Florian: Can't we say should use ICC may do table and they're
           close. One is better and if you're willing to do it go
  ChrisL: We could. More complex to test but I wouldn't mind. Does
          it mean implementors have to ship both or they can choose?
  Florian: I mean choose. If I understand they give similar results,
           but they're better with the profile. If they're not will
           to do profile they get similar results but a bit better.
  Florian: Do we need the profile in the spec?
  ChrisL: Yes. We will need it in the spec.

  ChrisL: Additionally for AdobeRGB we need Adobe's permission for
          the trademark. We could name it something similar, but I'd
          rather get explicit permission

  smfr: For webkit we'd prefer an ICC profile solution. We want to
        offload the code. We don't want separate code in the browser
        that's different than the color mapping for images.
  ChrisL: Would you apply same logic to rec2020 and P3 tables?
  smfr: I think we'd want color profile.
  ChrisL: I can work on adding those profiles. It would be great to
          have input from Adobe if we can use the name.
  SteveZ: I'll ask.

  Florian: For the CMYK fallback discussion. I think that it would
           be nice if you're doing content that's meant for printing
           or on screen viewing. You can add a RGB fallback, but
           then you have to manually calculate and that's a pain. So
           if you can fallback to a known profile it gets you close.
  ChrisL: I suggest I spec that out and if it's not implemented we
          can always drop it.
  Florian: Sure.
  Florian: I don't think we want a whole bunch of cmyk profiles.
           This would be mostly a fallback.

  astearns: It sounds like we have a way forward. Do you want to
            handle it in github or do you want a resolution?
  * fantasai is in favor of more explicit resolutions, not less
  Florian: If we agree resolutions are good.
  <fantasai> If we have consensus, let's record it.
  ChrisL: Okay, yes.
  <ChrisL> Proposed resolution: add AbobeRGB and ProPhotoRGB as
           predefined spaces. Allow either the table of numbers or
           an ICC v.4 profile with relative colorimetric intent
  <ChrisL> Proposed resolution: Add a single CMYK profile, with
           relative colorimetric intent, mainly to use as a fallback
  astearns: Any objections to the first part of the resolution?

  RESOLVED: Add AbobeRGB and ProPhotoRGB as predefined spaces. Allow
            either the table of numbers or an ICC v.4 profile with
            relative colorimetric intent

  astearns: Objections to the CMYK portion?

  RESOLVED: Add a single CMYK profile, with relative colorimetric
            intent, mainly to use as a fallback

  astearns: Anything else on color spaces?
  ChrisL: That's it beside the commas.
  astearns: And TabAtkins is still collecting data there.

Support for CSS namespaces [css-scoping]

  <astearns> https://github.com/w3c/csswg-drafts/issues/270
  ChrisL: This is the 'what to do with shadowDOM' thing. How do you
          style, do selectors work, etc. I think closing and saying
          we won't fix it is doing the community a disservice. I'm
          hearing a lot of pain where people want to be able to do
          modularize-able solutions. I see huge long naming
  ChrisL: It's not 'do we have namespaces', it's what are we working
          toward to have local variable type styling for
          theme-ability. Just saying we won't do anything for a few
          years isn't appropriate.
  TabAtkins: Today the answer is web components. There are some
             holes and we'd like it something like easier to do
             declaratively, but we'd like it to mature to see where
             we need to go. That's our focus. Everything that people
             suggest won't do what they want. You want the solution
             to work in both directions that's something web
             components allow. Their solutions don't think both
             directions. And browsers aren't doing scoped styles so
             people won't implement the new things.
  ChrisL: What does web components allow? Can you theme and style?
          I'm not familiar enough.
  <bkardell> TabAtkins: it could be declarative today, right? all
             you need is a web component that just does that.
  TabAtkins: If you put things in a shadow tree they're style-able
             in the tree. The styles inside can't go out and the
             styles outside can't go in. So it's a full
             self-contained piece of HTML that won't be messed up by
             styling on the rest of the page.

  leaverou: How are they themed?
  leaverou: I've refrained from using components because they're not
  TabAtkins: We have some solution now. If you use variables you can
             pass in styling one piece at a time. Not the most
             convenient. We have the @apply rule that was generally
             accepted that lets you shift entire style blocks across
             the boundary.
  TabAtkins: From inside the tree you can detect what's going on
             from the outside like if a class is on an ancestor so
             you can adjust accordingly. So you can ship with
             multiple themes that do something depending on a class
  <iank> Polymer has a writeup here of the mixin/custom-prop

  bkardell: I wanted to add that one of the good things about this
            is that we did experiment with several things. Chrome
            and Polymer had experiments to allow you to explicitly
            cross boundaries. We had a number of discussions based
            on what people thought they wanted, but when we gave it
            it wasn't really what they wanted.
  bkardell: Going forward we should expose basic things, allow
            experimentation, and progress. This is new ground. The
            only way we can know this is the right thing is to be
            allowed to use it.
  TabAtkins: He's referring to the deep selector. It led to unending
             problems of people changing things they didn't mean to.
             So we dialed back to explicit sharing. It's all the
             flexibility without a footgun.
  leaverou: This sounds good but I'm skeptical that a component
            exposes its variable so to change it you have to change
            your CSS. Assuming there's no native slider, you want to
            use a slider and then another slider you'll have to look
            up the documentation. Native components do accept some
            styling. It would be nice if author components did the
            same thing.
  TabAtkins: That's good feedback. We should keep that in mind as we
             move toward more declarative.
  <bkardell> but if we expose the right bits, then maybe people like
             leaverou can experiment with ways to do that in wicg :)

  leaverou: I'm not sure this is just shadowDOM. I think it may also
            be nesting. That's another thing authors ask me about.
  leaverou: Authors ask me a lot about nesting and scoping in every
            conference for the last few months. I don't know what to
            tell them.
  leaverou: So nesting is another big thing. This is what the naming
            conventions are trying to address.
  astearns: So there's several issues. Scoping, nesting, a more
            declarative approach to components. I'm not sure a
            single github thread will be that helpful. It might be
            good to have a single place with the history of this
            conversation. So look we have this deep selector and it
            didn't work like we wanted.
  astearns: I'm thinking a wiki page with all the history where we
            can take this github and point it there to say we've
            worked on these things, we're trying these things. So
            we're not shutting down conversation but it's not a
            single thread.
  astearns: I want a place where we can engage the community on
            these issues and some place with the history of what we
            tried and what we're looking to do.
  <bkardell> this really does sound to me like a great thing to
             bring up in wicg before csswg itself burns time on
             it... that is inclusive of devs and hopefully then we
             can bring back the good ideas.
  ChrisL: Sounds great. So who should write it and who has the
          material to begin it?
  TabAtkins: I can start writing that. I have the history in my head.
  fantasai: A blog post would be nice, but the commenting on our
            blog is too broken.
  astearns: And bkardell mentioned on IRC that this may be good for
            the incubation group.
  <bkardell> also repos and wikis and all available on wicg
  ChrisL: In terms of what I wanted from putting this on the agenda,
          I've achieved it.

  ACTION TabAtkins to start collecting namespaces history and future
         plans on a wiki so we can show the community and allow
  <trackbot> Created ACTION-783

  <rachelandrew> I'd be very happy to look over or edit copy for
                 this sort of outreach to authors, I'm used to
                 writing for that audience.

Testcase for text-align: right + list-style: outside

  <astearns> https://lists.w3.org/Archives/Public/public-css-testsuite/2016Jul/0002.html
  <astearns> http://jsbin.com/ciganovici/edit?html,css,output
  fantasai: We have an incompatibility among implementations. We
            need to pick a behavior.
  fantasai: The intention was to leave this undefined in CSS2.1 but
            the text isn't that unclear.
  fantasai: The text says the bullet is outside the box which only
            can be interpreted one way. But dbaron said we meant to
            leave it undefined due to incompatibility issues in 2.1
            discussions. So we just need to pick one.
  fantasai: And edit accordingly
  fantasai: I don't know what people would expect. I think having
            right or center aligned bullets is super weird and rare.

  gsnedders: This came up because Google hit this with a web compat
  gsnedders: It was on something like a Chrome webdev page that was
             broken in Firefox.
  astearns: And in the report was there a preference?
  gsnedders: I don't think so. Just a desire for interop.
  gregwhitworth: Webkit matches chrome?
  gsnedders: Yeah.
  gregwhitworth: So the shortest course of action for me is to ask
                 FF to match everyone else.
  <fantasai> What does Edge do?
  astearns: Sounds good to me.
  gsnedders: Firefox places the bullets to the center and right so
             it hides under the black box in the test case.
  gregwhitworth: If you change the color you can actually see it
                 which makes me think they're aligning the whole
  gsnedders: It's weirder than that.
  astearns: I suggest that we do what everyone else does and have
            Firefox change.
  fantasai: Sounds like we file a bug on Firefox for this one?
  gsnedders: There's a 15 year old bug on this.
  fantasai: As far as I can tell the spec is clear
  gsnedders: We just re-added the test.
  fantasai: So it sounds like outside bullets are outside the box.

  RESOLVED: Outside bullets are outside the box.

  <gsnedders> fantasai:
https://bugzilla.mozilla.org/show_bug.cgi?id=25291 is the FF bug,
  <gsnedders> 16 year old bug, rather than 15. my bad. :)


Implied Minimum Size of Grid Items

  <astearns> https://github.com/w3c/csswg-drafts/issues/283
  fantasai: We have an implied minimum size on flex and grid items.
            Usually it's the content size but sometimes it's
            smaller. If you spec 100 px we'll do that instead of
            imply a min.
  fantasai: One thing pointed out was with track sizing we have
            sizing on the track not the item. So it seems that the
            implied min should account for that.
  fantasai: I changed the spec to if you put a grid item inside a
            100px track and in the grid item there's a 200px image
            it doesn't stretch the item. The implied min is still on
            flexible tracks.
  astearns: Does anyone have an opinion on if that's the right way?
  astearns: Given the lack of opinions, I"m include to go with
fantasai 's decision.
  fantasai: Okay.
  <rachelandrew> that makes sense to me
  <fantasai> good :)
  <astearns> thanks, rachelandrew

  RESOLVED: Accept the change (implied min takes on the constraint
            defined on the track).

Block-axis baselines

  <astearns> https://github.com/w3c/csswg-drafts/issues/197
  fantasai: Mats pointed out each box has a baseline in order to
            baseline align it to other boxes. We define block-axis
            baselines and those should also be honored for baseline
            alignment. One of the things going on in Flexbox is
            we're only doing it if the axis matches the main axis.
            We're not synthesizing an axis for orthogonal flows.
  fantasai: So if you have a mix of flex items and 2 are horizontal
            and 2 vertical you can align the horizontal to each
            other. For the vertical you can synthesize but that's
            weird so Flexbox says you just start-align that stuff.
            We wanted to preserve that behavior. So to get that to
            work correctly we introduced natural and synthesized
            baseline. If you baseline align you do it with natural.
  fantasai: Synthesized are for putting content on a line of text.
  fantasai: So we made a bunch of edits to the specs to bring this
            in line. I think it makes sense, but I'm not 100% sure
            it's correct. We'll have to do some cleanup in alignment
            for tables legacy behavior. This is the direction we're
            going in and if people want to think about this we'd
            appreciate some feedback.
  <fremy> fantasai: I am ok to review the changes if you send a mail
          to the list with them so I don't have to look for them ;-)
  <fantasai> fremy:

  astearns: One questions from your explanation. You said things are
            start align with no natural baseline. If it's last
            baseline it should be end align.
  fantasai: Yes. That's specified.
  astearns: That makes sense to me. Other opinions?

  astearns: fremy volunteered to review. Should we give him a week
            to review?
  fremy: Yep.
  fantasai: Makes sense.


  fantasai: So once this issue is closed we'd like to go to CR
  <fantasai> https://drafts.csswg.org/css-grid/issues-wd-20160519

  astearns: So I propose we allow a week for review on baseline and
            next week we resolve on that and do CR next week.
            Objections to that timeline?
  astearns: Let's go with that.

Values & Units

  <fantasai> https://drafts.csswg.org/css-values-3/issues-cr-2015
  fantasai: Every issue tracked there^ is closed except there have
            been concerns on the text for calc() serialization. We
            have a lot of changes and we should push to CR. I'd like
            to defer calc() serialization to level 4 and we can sort
            it out there on a longer time scale. Also allowing us to
            republish this draft.
  fantasai: We've been holding off on forking level 3 to 4 because
            we want to do the fork when we publish the CR to
            minimize changes. So I'm hoping we can do that and put
            the calc() serialization and add the units that were
            resolved on for level 4.

  astearns: I'm not sure happy in leaving it undefined, but I'm
            happy with moving this along and adding the things
            resolved on. As long as calc() serialization and all the
            discussion stands in the level 4 draft I'm okay with
            taking it out of level 3.
  astearns: other opinions?
  <bkardell> seems good
  <bkardell> +1
  astearns: In publishing a new CR of Values & Units 3 are you also
            committing to making level 4?
  fantasai: Yep. I want to prepare the draft, fork off of level 3,
            and then publish.
  astearns: So start a level 4 draft, move calc() serialization to
            it, and then publish the remainder of Values & Units 3
            as CR
  astearns: Objections?

  RESOLVED: Start a level 4 draft of Values & Units, move calc()
            serialization to it, and then publish the remainder of
            Values & Units 3 as CR.

  <ChrisL> is that an updated cr?
  <fantasai> yes
  <ChrisL> is there a list of changes compared to the previous cr

  astearns: Any other topics?
  fantasai: I vaguely recall agenda+ something. Let me see what.
  astearns: ChrisL had a question.
  ChrisL: Questions on Values & Units.
  ChrisL: On the level 3 CR; is it updated CR and is there a change
          log? I'm thinking of the transition request.
  fantasai: It's an updated CR. THere's a list of changes and DoC
            and I'm going to review those. I'll collect them and
            send them to you.
  ChrisL: Sounds good.

  <bkardell> was issue 266 discussed earlier?
  <bkardell> it was on the agenda I think?
  <bkardell> gotcha
  astearns: bkardell, we decided to defer the comma discussion until
            next week.
  <bkardell> thanks astearns

  astearns: fantasai did you find something?
  fantasai: I found an inconsistency on baseline alignment. If you
            need more alignment than you can do with baselines.
            Flexbox says flex-start align, alignment says
            start-align. I think we need self start. When you have
            varying amounts of content they'll look almost start
            aligned but the baseline won't be perfect. The
            flex-start won't get you that. I think that's an error
            in flexbox and it needs to depend on the writing mode.
  fantasai: I think that's an error and I'd like to fix, but it's to
            flexbox so it needs a resolution.
  astearns: Sounds like the next step is to come up with a proposal
            we can review.
  <fantasai> https://github.com/w3c/csswg-drafts/issues/332
  astearns: Ah, okay.
  [silence while people look]
  astearns: Why don't we add this to next week's agenda with the
            other baseline topic to allow time to review.
  fantasai: Sounds good.
  astearns: Alright, so we'll end a bit early. Thanks everybody.
Received on Thursday, 21 July 2016 00:18:12 UTC

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