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

[CSSWG] Minutes Sydney F2F 2016-02-01 Part II: Tables, Colors, Transforms [css-tables-3] [css-color] [css-transform]

From: Dael Jackson <daelcss@gmail.com>
Date: Sun, 13 Mar 2016 08:37:47 -0400
Message-ID: <CADhPm3vDD_PoAn_NiknYVseKQAtHRMjU8ELTy-bTK7_K5+Xg1w@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.
=========================================


Tables
------

  - RESOLVED: Add gregwhitworth and franremy as editors of CSS
              Tables and copy into CSSWG ED repo
  - There was a desire to have headers and footers repeated; the
      only disagreement was if it should be a 'should' or a 'must'
      level.
  - RESOLVED: 'contain' applies to table cells

Colors
------

  - RGB color section outside of 0-1 is being addressed in a spec
      written by Chris and therefore doesn't need to be explained in
      the CSS3 Colors.
  - There was a desire to create a new way to specify colors and
      color profile and work will start to come up with language on
      a proposed approach. Once written the proposal will go into
      Colors 4.
      - SteveZ will also get feedback from Adobe on how they expect
          wide gamut colors to be handled.

Transforms
----------

  - smfr gave a status update for the spec stating he's still looking
    for implementor feedback on preserve-3d and some assistance from
    someone who knows matrix math.
  - RESOLVED: Republish Transforms

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

Agenda: https://wiki.csswg.org/planning/sydney-2016

Scribe: fantasai

Tables
======

Introduction & ED
-----------------

  [gregwhitworth walks to the podium, about to dive into the most
      dangerous jungles of CSS: specifying Table Layout]
  gregwhitworth: Hi!
  gregwhitworth: We're going to talk about Tables!
  gregwhitworth: One Spec to Rule Them All.
  * gregwhitworth shows a photo of a wooden table, then of the One
                  Ring
  gregwhitworth: I want to take all of these specs that define
                 "something" about tables, and marry them all
                 together.
  gregwhitworth: Break this cycle of fixing bugs to fix some sites
                 that break other sites...

  gregwhitworth: We do not want to add new features to Tables.
  gregwhitworth: We don't care. We're not adding anything new.
  gregwhitworth: Goal is Interop Interop Interop Interop
  gregwhitworth: Also, to explain Reality.
  [image of several copies of the word "interop" superposed but not
      aligned.]

  gregwhitworth: franremy did a great job in the opening, to tell
                 people that This Is Not Our Fault.
  gregwhitworth: So many things just don't make sense about how
                 tables work.
  gregwhitworth: But last year we were fixing tons of tables bugs.
  [video meme of "That doesn't make sense"]
  gregwhitworth: Developer reached out to us about a bug and said
                 "this doesn't make sense"
  gregwhitworth: Tried to bring it to the working group, and working
                 group said... Ummm not defined.
  gregwhitworth: Goal is to find all sections that are undefined.
  [image of browser logos]
  gregwhitworth: Also, find all interop issues.
  gregwhitworth: The spec says "this should happen" and it doesn't.
  gregwhitworth: Find all interop issues, and decide on something,
                 that is something someone is shipping. Unless
                 there's a really strong argument to not do that.
  gregwhitworth: Goal is to by 2017, have our developers be able to
                 kick out 50% of those bugs.
  gregwhitworth: Point to spec language saying "We're doing it right."
  gregwhitworth: Allow other browser vendors to rev their table
                 layout to match the spec.
  gregwhitworth: That's the goal of the spec.
  <zcorpan> gregwhitworth++
  <fantasai> gregwhitworth++
  * bradk wonders how we can have interoperable tables without
          accounting for row spans and col spans, which already
          exist in HTML.
  <tantek> "one table spec to rule them all"

  gregwhitworth: On purpose, this is a ton of red.
  gregwhitworth: A myriad of stuff from previous attempts at a spec.
  gregwhitworth: From dbaron, Bert, Microsoft, CSS2.1
  <gregwhitworth> http://gregwhitworth.github.io/css-table-3/
  gregwhitworth: All I'm looking for there is a current CSS3 Table
                 spec in the repo.
  gregwhitworth: This is a huge goal for us at Microsoft. Was asking
                 for ED.
  fantasai: YES.
  fantasai: It can't be the table spec to rule them all if
            it doesn't include those.
  gregwhitworth: Still a bit work to do before discussing specific
                 issues.
  gregwhitworth: Just don't want to rathole on random discussions.
  gregwhitworth: Here's a list of bugs we're tracking.
  gregwhitworth: Browser vendors can look at them; our bug database
                 isn't public, so copied them out here.
  gregwhitworth: Goal is to resolve 50% of them in 2016.

  dbaron: One thing I was going to say is that I would be very happy
          to see this in the WG repository.
  dbaron: Even if you're not comfortable going to FPWD yet, should
          be ED asap.
  <SimonSapin> +1 for in wg repo
  <tantek> +1 for put new draft in wg repo
  dbaron: My intuition is that the least interop parts of tables
          have to do with height calculations.
  dbaron: I think width is substantially more interoperable than
          height.
  dbaron: Wasn't able to skim issues list when you went by,
  dbaron: But if you're short of height issues, ask me for some.
  gregwhitworth: We ran into lots of issues.
  gregwhitworth: e.g. resolving px vs percentages in height
                 completely different than width.
  gregwhitworth: There's gonna be a ton of issues.
  dbaron: Height distribution in IE6 was saner, and a lot more
          similar to width distribution.
  dbaron: Don't say that very often :)

  RESOLVED: Add gregwhitworth and franremy as editors of CSS Tables
            and copy into CSSWG ED repo

  <dauwhe> wonderful!
  <tantek> amazing

  zcorpan: I wanted to discuss something else...
  zcorpan: I really like that there's this spec, and I'm happy to
           contribute to it.
  zcorpan: It also covers mapping from HTML to CSS, and that's
           something that's already in the HTML spec.
  zcorpan: I haven't checked it's the same.
  gregwhitworth: IIRC there are holes.
  gregwhitworth: We've only done this for 3-4 weeks.
  gregwhitworth: I think okay with later on ripping stuff out, I
                 just truly would like to keep everything in one
                 place or now.
  zcorpan: Should fix HTML once we know the right behavior.

  zcorpan: Do you care about quirks mode here? Because I have some
           quirks documented.
  gregwhitworth: Not right now. Want to get standards mode
                 interoperable first.
  gregwhitworth: I think that's a V2 state.
  Florian: When Quirks mode are different from standards mode, yes.
  Florian: But I think if everyone is different, it might be worth
           checking out the quirks mode and aligning to that if it's
           more sane, instead of aligning to one of the standards
           behaviors.
  gregwhitworth: That makes sense, but also have to consider that
                 since most pages are standards, that might break
                 things more since nobody does it.

  astearns: You talked about interop without calling anyone evil or
            naively characterizing their business model,
  astearns: so thank you.

Table Header/Footer Repetition
------------------------------

  <tantek> https://lists.w3.org/Archives/Public/www-style/2016Jan/0135.html
  Florian: CSS2.1 is undefined about this.
  Florian: When you fragment across fragmentainers, do you repeat
           headers/footers or not?
  Florian: Browsers disagree.
  <dbaron> which browsers do what?
  Florian: Think we should do that. And possibly have a switch for it.
  Florian: Everyone who uses tables for print wants this.
  Florian: If you're using tables for layout, wouldn't have
           tables/footers anyway, so not a problem there.
  Florian: I would like to go away from undefined and make it a MUST.
  Florian: I'm okay if people say "only if we can turn it off", but
           not necessary.

  dbaron: Which browsers do what?
  Florian: Firefox and Edge repeat the headers and footers repeat
           across pages. Not on columns for some reason.
  Florian: Webkit/Blink don't.
  Florian: Printing implementations all do it.
  dbaron: In Firefox's case, the "not on columns" bit is because the
          code to do this does not support dynamic changes.
  Florian: Would you consider it a bug to fix eventually?
  dbaron: Do you consider heat death of the universe eventually?
  Florian: Yes.
  dbaron: Not going to a priority.
  Florian: That's fine.

  gregwhitworth: I think this is a good idea of what to file against
                 the spec.
  gregwhitworth: For the column case, what are use case of splitting
                 tables for multiple columns?
  gregwhitworth: What makes the most sense?
  gregwhitworth: Say this is what we agree on, what's the use cases,
                 etc.
  gregwhitworth: Use case may be so rare that not worth it.
  Florian: Use case is pretty simple.
  Florian: Think of a scientific document. LaTex 2-columns, includes
           data table.
  Florian: Table is broken across pages or column as necessary.
  gregwhitworth: What happens if you have very small viewport?
  Florian: I think we agree we need to have error-handling code for
           not enough room.
  Florian: I would suggest drop footer if not enough room, if still
           not enough drop header.
  Florian: I can take it back to the list if you want.
  gregwhitworth: I think we should spec printing, discuss for other
                 thing.
  Florian: I'm not sure I want to distinguish here.
  Florian: Don't want to distinguish between print/non-print UAs.
  <dbaron> We actually don't split tables at all when they're inside
           of multicols when printing.
  <dbaron> (from https://bugzilla.mozilla.org/show_bug.cgi?id=678447 )

  fantasai: I think the spec should recommend repeating. If we can't
            say MUST due to implementations not being able to
            implement soon, then that's fine, we call it "SHOULD"
            and not "MUST".
  gregwhitworth: Prefer to going with MUSTs than SHOULDs in the spec.
  * franremy agrees with gregwhitworth here. SHOULDs are a pain.

  <zcorpan> gregwhitworth re forms in tables, it's not rendered in
            webkit/chrome if the form is foster-parented. so seems
            like something that can be fixed in webkit/chrome rather
            than spec, unless you found sites being broken in gecko.
            http://software.hixie.ch/utilities/js/live-dom-viewer/saved/3850

Applying 'contain' property to tables
-------------------------------------

  Florian: There was a side-discussion wrt applying 'contain' to
           internal table elements.
  Florian: Not sure I a see a good reason for not applying to table
           cells. For table rows, I care less.
  Florian: But I think it makes perfect sense to apply to table cells.
  Florian: I wanted to get a sense of consensus of implementers,
           when you implement 'contain' can you also apply to table
           cells?
  dbaron: Table cells aren't the only type I'm worried about. E.g.
          what does it mean for 'display: inline'?
  dbaron: I think 'contain' needs to be doing blockification.
  dbaron: Most display types don't work with 'contain'
  ojan: I thought it forces a block?
  leviw: It's not in the spec.
  leviw: I agree it doesn't make sense in the inline flow case.
  leviw: I think it should just say...
  dbaron: I see this in the spec
  dbaron: It's well-hidden.
  dbaron: "Layout containment forces a formatting context ....."
  [several people peer at dbaron's screen]
  dbaron: It's not actually defined. "The element MUST be, no
          definition of making it"
  ojan: I'm sure that was the intention, need to give feedback to
        TabAtkins.

  franremy: Table cells are very similar to block.
  franremy: No reason to believe we can't use 'contain' on a table
            cell.
  Florian: ...

  RESOLVED: 'contain' applies to table cells

  Rossen: Okay, lunch is scheduled for ~1pm

Colors
======

RGB color selection values outside of 0-1
-----------------------------------------

  <dino> https://lists.w3.org/Archives/Public/www-style/2016Jan/0301.html
  dino: Had a conversation in Sapporo,
  dino: Sent a follow-up mail.
  dino: First suggestion is, CSS3 Color spec already says RGB color
        section that it allows values outside of 0-1.
  dino: If you're on a device that supports that gamut, you should
        show the colors, otherwise clip.
  dino: Nobody has implemented that yet.

  dino: There's a few things to discuss.
  dino: Doesn't say what those colors mean.
  dino: sRGB doesn't say what to do.
  dino: There's a spec from Microsoft scRGB, which specifies what to
        do outside of 0-1.
  dino: Maybe we should update the spec to explicitly link to that.
  <astearns> https://en.wikipedia.org/wiki/ScRGB
  dino: Also, we're not so sure what tools would allow devs to
        specify this.

  dino: Maybe a question for Adobe, what would you do in Photoshop
        to pick a color on your fancy monitor that's outside sRGB,
  dino: And have that convert to e.g. -10%.
  SteveZ: I'm not quite sure that I'm prepared to answer that
          question directly.
  SteveZ: But my memory is Photoshop uses its own color space most
          of the time.
  SteveZ: It's an Adobe color space.
  dino: Say you have an image with a very bright red, outside sRGB,
  dino: Tagged with color profile,
  dino: And now you want to have your web page background match.
  dino: You only have the ability at the moment to specify that
        using the background: rgb() syntax.
  dino: How is a dev going to figure out what values to put in rgb()
        syntax?
  SteveZ: I can ask the ICC guys.
  dino: This would be useful feedback.
  ACTION SteveZ: ask ICC guys how authors can choose colors outside
         sRGB
  dino: We're trying to specify how to read the value and spec on
        screen, but doesn't help anyone if they can't actually
        figure out what numbers to use.

  Florian: Chris is working on spec to be able to specify colors in
           different color spaces.
  Florian: Once we have that, do we need this hack around rgb()?
  Florian: Couldn't we just use the proper color syntax with that?
  Florian: Or do we need this fix?
  dino: Answer might be yes, don't need to do this.
  dino: But then we should go back to clamp the values outside 0-1.

  smfr: So, I think we're trying to solicit feedback on Adobe on
        what the authoring story is.
  smfr: How can you author things to work correctly in the deep
        color world?
  smfr: And want to make sure what Chris is writing works with that
        too.
  smfr: Let's say you have a very deep red, and want to match color
        in CSS,
  smfr: If they both end up on a regular display,
  smfr: Need to make sure the colors still match.
  Florian: Chris is dealing with that.

New way to specify colors and color profile
-------------------------------------------

  dino: 2nd thing we sort of agreed on;
  dino: a new way to specify colors, along with color profile.
  dino: I figured a function named color() makes a lot of sense...
  dino: How do you specify which color profile ?
  dino: We had an @color-profile, but I was going to suggest some
        keywords for common profiles
  Florian: I believe what we discussed last time was a function
           which starts with the name of the color space and an
           arbitrary set of parameters, not even necessarily numbers,
  Florian: some predefined, e.g. sRGB.
  Florian: And others name and link to ICC color profile.
  Florian: Not necessarily numbers, because might want to use spot
           colors, e.g. Pantone.
  Florian: I'm not sure it's happened so far.
  <bradk> PMS = Pantone Matching System
  <bradk> Pantone Matching System is trademarked or something

  dino: We might write up a proposal.
  dino: I suggested that possibly an alternative to this is that we
        come up with another function that is defined to be colors
        space bt2020.
  dino: Much bigger than sRGB. many monitors, HDTV, are aiming at
        that.
  dino: Hardware sometimes say it supports, but doesn't really.
  dino: Might say rgb2020...
  Florian: This isn't a quick solution, because the problem isn't
           the syntax, it's color conversion.
  Florian: Switching color spaces, syntax is trivial once you have
           the conversion math.
  Florian: But need to have basic model in place.
  zcorpan: Whatever we come up with, should be consistent with what
           we do in HTML for <canvas>.

  zcorpan: Some idea floating around, about being able to point to
           an actual image and use the image's profile,
  zcorpan: That seems could be useful.
  dino: The basic reason you'd want to do that is authors don't know
        how to specify a profile, but do have plenty of images.
  zcorpan: So can pick a point on the image, and this is the color I
           want to match.
  Florian: I think that's something we can do in the syntax we were
           discussing. Could point to an ICC profile, but could also
           point to an image and work within that image.

  dino: How do authors detect whether they're in a system that
        supports deeper colors?
  dino: Could use an MQ.
  dino: Does the output device have enough range to support all the
        colors in this color?
  dino: Not necessarily useful thing to ask.
  dino: Could ask, is this the kind of like we have today, or
        better, or super-awesome?
  fantasai: color: normal | good | awesome ? :)
  dino: or if I support a color in this syntax, will it be clamped?

  <zcorpan> @supports (color: color('bt2020', ...)) { ... } ?
  fantasai: @supports is for do you support the feature in the
            browser.
  fantasai: Media Queries is about querying the capabilities of the
            output device.

  Florian: For qualitative MQ...
  Florian: The difference between regular and fancy I can see, but
           in terms of actual authoring usage, what do you
           differently in terms of styling if you have a more-
           awesomer screen?
  smfr: You might want to support different image assets.
  Florian: Even though you don't know how much "better" it is?
  smfr: We'd specify better as ?? and even better as bt2020
  smfr: ... which roughly equates to 10-bit color and 12-bit color.
  Florian: Bit depth of a color is not directly linked to the gamut
           of it, but broader color spaces tend to be associated
           with higher bits, because otherwise don't have enough
           precision.
  dino: Awesome vs awesomer... most devices in the consumer market
        say that they're awesomer, but they're only actually awesome.
  Florian: Most of them barely reach normal.
  Florian: Most screens don't cover sRGB color space, never mind
           broader one.

  zcorpan: I wanted to discuss a bit about feature discussion.
  zcorpan: If the syntax we come up with this is a color function,
  zcorpan: And we allow profile,
  zcorpan: And we say color profiles that are not supported are
           invalid,
  zcorpan: then @supports is the right solution.
  Florian: Old-fashioned @supports wouldn't work here.
  Florian: The behavior we expect from a browser isn't to drop the
           declarations if not support the profile, but to convert
           the colors.
  Florian: You support all colors, you just might not display them
           equally nightly
  smfr: @supports is explicitly about asking about what features the
        engine supports. Swapping monitors doesn't change the
        results of @supports.
  smfr: This is a question for media queries.

  Florian: Goal of discussion?
  dino: Think there's reasonable consensus. Might make direct
        suggestions rather than waiting for stuff to happen.
  Florian: That's the only sane want to do this.

  smfr: Would like to get an action on authoring tool vendors to
        give us feedback.
  SteveZ: I have no idea what the feedback will do, but certainly
          willing to take the action to try.
  ACTION: SteveZ ask authoring tool people how authors can specify
          colors outside sRGB
  trackbot Created ACTION-747
  dino: Feedback on how authoring tool vendors expect ppl to work
        with wide gamut colors. how do they choose colors?
  astearns: How can they choose colors in a way that's compatible
            with how the tool emits colors.
  smfr: It's not just choosing colors in the UI, it's managing deep
        color assets through the whole content management chain.

  smfr: Final comment to make...
  smfr: I would love to see Firefox and Chrome start treating CSS
        colors as sRGB on wide gamut displays
  smfr: Specifically on new images,
  smfr: not getting color matched.
  smfr: Colors get too bright, gives you a headache.
  smfr: Would like to see other UAs do color matching, hopefully
        that will also encourage them to give feedback

  Rossen: Is this going into Color 4?
  Florian: I think that was the plan.
  Rossen: That takes us to the end of the morning agenda.

Transforms
----------

  smfr: Didn't have time to get all issues together.
  smfr: No change to status since last time we discussed.
  smfr: I'm waiting mainly on feedback from implementers, especially
        with regards to preserve-3d behavior.
  smfr: Spec was revised 18 months ago with new description of
        preserve-3d behavior and 3D context behavior.
  smfr: Got some feedback from roc; he liked the description but
        some issues with regard to intersection.
  smfr: Still have very poor interoperability among implementations
        with regard to preserve-3d behavior. Particularly want
        feedback.
  smfr: Fairly hard problems with getting a solid description of
        this,
  smfr: Particularly with transform-style: flat,
  smfr: and creating a stacking context.

  smfr: Other side of it is, being wary of the compat risk of
        changing behavior.
  smfr: So if we do change the spec, would UAs be willing to change
        behavior?
  smfr: Compat risks are possibly high for WebKit, though may be
        willing to change behavior for non-prefixed (vs. prefixed).
  smfr: So might get a behavior split there.
  smfr: That's the basic status.

  smfr: I also have a call for help with someone who knows more
        matrix math,
  smfr: To help define things like backface-visibility.
  smfr: If anyone has people who know transform math better, would
        be helpful.
  smfr: Need also help editing.

  dbaron: I'm also very concerned about preserve-3d, especially
          interoperability for 3d in general.
  dbaron: One of my concerns has been that we hit an interop issue,
          and it's hard to look at the spec and determine who's
          right according to the spec- according to what's there.
  dbaron: Which is worrying.
  dbaron: It's been awhile since I looked at any of these.
  dbaron: I think we're interested in trying to improve interop,
  dbaron: Hard to commit to doing that at a particular time.
  dbaron: Probably for the next 2-3 months we do not want to make
          substantive changes,
  dbaron: Because we made an architectural change, and we need to
          fix all the regressions first.
  dbaron: I think after that, would like to prioritize,
  dbaron: Don't have any particular concrete suggestions.

  fantasai: Is the most recent WD is from 2013?
  smfr: That's out of date. I think krit has requested public WD...
  fantasai: Do we want to republish?

  RESOLVED: Republish Transforms

  Vollick: We haven't implemented also because of an overhaul, will
           have to get back to you.
  smfr: Edge?
  Rossen: Not a current priority for us.
  Rossen: Implementation we did a few months ago...
  Rossen: Implementing most interoperable version, which is older
          version.
  Rossen: I can get you an update.

  [lunch]
Received on Sunday, 13 March 2016 12:38:44 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:37 UTC