W3C home > Mailing lists > Public > www-style@w3.org > September 2013

[CSSWG] Minutes Telecon 2013-09-25

From: Dael Jackson <daelcss@gmail.com>
Date: Thu, 26 Sep 2013 19:44:37 -0400
Message-ID: <CADhPm3uVXhTC0Or_OfcS8rbo5oxK1gD41wWn2RM4cdooXBSD9A@mail.gmail.com>
To: www-style@w3.org
Summary:

  - RESOLVED: Publish CSS Compositing and Blending Level 1 as LC
  - Everyone will review GPCM and Page Floats for next week's telecon
  - RESOLVED: TabAtkins to put overflow: clip to new ED
  - RESOLVED: Use doubles instead of float for matrix items
  - Remaining issues for DOMMatrix, DOMPoint and DOMPointLiteral were
     deferred until next week
  -The group discussed the need for and use of device-cmyk(). No conclusion
     was reached by the end of time, so the discussion will be continued on
     the mailing list.

===== Full Minutes =====

Present:
  Tab Atkins
  David Baron
  Bert Bos
  Tantek Çelik (via IRC)
  Dave Cramer
  Justin Erenkrantz
  Sylvain Galineau
  Daniel Glazman
  Rebecca Hauck
  Koji Ishii
  Dael Jackson
  Dean Jackson
  Chris Lilley
  Peter Linss
  Edward O'Connor
  Christopher Palmer
  Anton Prowse
  Matt Rakow
  Florian Rivoal
  Simon Sapin
  Dirk Schulze
  Alan Stearns

Regrets:
  Simon Fraser
  Brian Kardell
  Brad Kemper
  Leif Arne Storset

Agenda: http://lists.w3.org/Archives/Public/www-style/2013Sep/0655.html'
Scribe: dael

  glazou: First thing, Dael starts scribing today
  <stearns> woohoo!
  glazou: Thank you dael, don't hesitate to stop us.
  glazou: If dael needs names corrected, don't hesitate to do that.
  TabAtkins: If you need to scribe someone you don't know, just put three
             question marks.
  glazou: If you don't know a term, ask a speaker to clarify.

  glazou: Second, I won't make it to shenzhen, plinss will chair.

  glazou: Any additions to the agenda?

  glazou: ChrisL are you there?
  ChrisL: Yes.
  glazou: First item is for you. [un-minuted conversation]

Compositing and Blending Level 1
--------------------------------------------

  sylvaing: We agreed today is when we move to Last Call, sorry I only sent
            the reminder yesterday. We can move it to next week if needed.
  sylvaing: David provided some feedback, but I haven't heard from anyone
            else.

  ChrisL: There had been some other issues about compositing, but they
          might just need to take it to level 2 sooner.
  sylvaing: That seems reasonable.
  ChrisL: I might have some comments, but I'll e-mail them in, I don't want
          to delay the Last Call.
  sylvaing: Sure

  florian: I like what the spec does, but I don't feel confident to provide
           meaningful feedback

  glazou: Any objections?
  glazou: No objections, let's agree to publish

  RESOLVED: Publish CSS Compositing and Blending Level 1 as LC


Publish GCPM
------------------

  <glazou>
https://lists.w3.org/Archives/Member/w3c-css-wg/2013JulSep/0284.html
  howcome: This was from the F2F. We had decided to split this into pieces.
           This is the GCPM that we split and page flow.

  howcome: The page flow was considered complex enough to warrant its own
           specification
  howcome: I think this split is warranted. There are two new URLs that I
           sent in an e-mail [see glazou's link above]
  howcome: I haven't changed anything in functionality, it's the splitting
           that we agreed to do.
  howcome: There will be changes, but getting WD is important so it doesn't
           hang.

  ChrisL: The action you had to split and you've done it.

  glazou: You sent your e-mail not too long ago; I had just enough time to
          review it. I agree to publish the GCPM WD, and wait another week
          to review floats.
  howcome: We can give both one week for review.
  glazou: That's fine. Other opinions?

  howcome: That's perfect. I have an issue because I have changes I'd like
           to make, but I've held back on them to avoid rounds of editing
  howcome: I'd rather get them out once there's a WD
  ChrisL: Sounds good

  SimonSapin: I sent some comments on mailing list, but nothing blocking
              publication

  glazou: Everyone agrees?
  glazou: We'll make a decision next week
  ACTION: All, review GCPM and Page Floats

Overflow: Clip
------------------

  <glazou> http://lists.w3.org/Archives/Public/www-style/2013Sep/0515.html

  * tantek thinks overflow:clip is a good idea per
           http://lists.w3.org/Archives/Public/www-style/2013Sep/0515.html

  TabAtkins: The title is of the message wrong because I had posted to
             coworkers.

  TabAtkins: One of the things we've been trying to do is find ways to
             denote boundaries.
  TabAtkins: So we can do as much independently as possible.
  TabAtkins: This is my proposal for overflow: clip so none of the children
             of the clipped elements can paint outside.
  TabAtkins: More importantly, it's so children can't paint outside the
             clipped element.
  TabAtkins: It would be a containing block for position:fixed and
             position:absolute
  TabAtkins: It lets us more aggressively work outside compositing.
  TabAtkins: There's a few other bits that let us not worry;
  TabAtkins: It completely shuts down scrolling.
  TabAtkins: We think this would end up helping with optimization.
  TabAtkins: Authors can opt-in and layout is independent of the outside
             document.

  TabAtkins: Should I keep pursuing this?
  <tantek> yes

  krit: You just want to clip inside the box so if you have fliters or
        drop shadow this can go with that.
  TabAtkins: So the element's own filters can extend past.

  glazou: So the main effect is on scrolling?
  TabAtkins: Correct. We can be agressive about clipping what's on screen.

  <tantek> Basically this is like overflow:hidden but a ban on any kind of
           scrolling, programmatic or otherwise.

  florian: We might have to do some work for detecting but the scrolling
           change seems necessary.
  TabAtkins: Even the absolute positioning part is important because
             authors can use it so we prefer a guaranteed fast pass.
  TabAtkins: We don't like having mysterious connections fall down.
  TabAtkins: This is how we make it explicit that they can't do things
which
             will increase speed.
  krit: This only works when you know the size?
  TabAtkins: In so far as...it still does.
  TabAtkins: You have to be fixed height to a certain extent. Even if
you're
             auto-height, being able to aggressively clip is still
             worthwhile.
  TabAtkins: This gives you a benefit in unconstrained cases.
  <tantek> Agreed - even auto-height is very useful to clip without
           scrolling.

  florian: I agree with you from my Opera experience.
  florian: I agree with the problem and I think this would help. I hesitate
           with this feature targeting "do this thing as usual but faster."
  florian: For most users, the new value is the same as 'hidden' - that
           bothers me because it boils down to "do what you were doing
           before, but faster"

  <Bert> q+ to say it sounds strange to have a feature that only serves
         implementers and doesn't bring new functionality for designers.

  Rossen: I would second with florian.
  Rossen: I also work on scrolling and to me this looks weird.
  Rossen: The first thing people will do is the start adding an overflow
          clip,
  Rossen: And everyone will try and use it,
  Rossen: And this really concerns me in general. Adding features to help
          performance is great;
  Rossen: This is adding a feature that has almost no user benefit to
          existing behavior so some implementers might take advantage of it..
  Rossen: I think this is a little bit of a stretch.
  TabAtkins: If you were to add overflow: clip it would still work, but it
             break your page.
  TabAtkins: It would makes things faster, though.

  TabAtkins: I don't think this is specific to Blink.
  TabAtkins: Painting is expensive and being able to do less is a win for
             everyone.
  TabAtkins: There's nothing specific to our architecture.

  Bert: Rossen said my pieces.

  krit: The performance improvement is in layout, not render?
  TabAtkins: This isn't related to layout. There's no chance this will
paint
             outside. It's about painting, not layout.
  krit: This wouldn't have a huge impact on performance.
  florian: Some things are layout, some are painting, some are in-between.
  florian: You're not in layout. You're not painting but preparing.
  florian: I see the concerns expressed and agree.
  Rossen: To add to florian you're preparing layout while the painting is
          waiting and that may not be true for architecture.
  TabAtkins: This is about being able to aggressively prune invalidation
             cycles.
  TabAtkins: And things that are on the page won't be painted over and this
             lets you be aggressive.

  glazou: I think we're having two discussions.
  glazou: We haven't agreed to have this somewhere in the spec.
  glazou: I think that having the full technical discussion isn't worth our
          time if we don't have it in the spec

  florian: Could you change this to be similar to overflow: hidden so that
           it's used in conjunction?
  TabAtkins: The clipping and not scrolling are closely related so that
             could be done.
  TabAtkins: Overflow: hidden isn't strong enough in either way.
  florian: I'd prefer something that's orthogonal to overflow: hidden
rather
          than this which sort of replaces it
  florian: Or better put, "complementary to overflow:hidden"
  florian: If you find a way to do what you propose to combine with
           overflow: hidden, it's a better addition.

  <tantek> I disagree - that seems better from a programmer / feature
          independence perspective, but another property is more complex
for
          the author.
  <tantek> the better/simpler solution is to just add a value to "overflow"
  <tantek> that is, I disagree with what Florian was minuted as saying.

  antonp: I think one of the issues is that the authors will want to use
          this.
  antonp: It becomes hard to educate how to make the decision. It would be
          better if it wasn't orthogonal.
  antonp: We need to be careful about how you teach web authors to use this
          so I agree with florian.

  glazou: I'm not sure the solution by florian is right. It's a nice model
          conceptually,
  glazou: From a web author it's more complex.
  TabAtkins: Well, antonp is right there are still use cases for
             overflow: hidden
  TabAtkins: For most cases it's what you'd want.
  <tantek> what glazou said
  glazou: A lot of websites that are using hidden are using a work around
  <tantek> It's small enough functionality that it's not worth
denormalizing
           into separate property
  TabAtkins: You're either overpainting in the expectation that there might
             be a scroll or your first scroll will be ugly.
  dbaron: I think you can probably optimize overflow:hidden on the
         assumption that there won't be scrolling and then deal with the
         iffy performance on the first scroll if it happens.

  glazou: I don't wish to spend the hour on this.
  TabAtkins: Let's continue on the e-mails

  glazou: Working group, do you agree to add this to spec and which one?
  florian: I'm not strongly objecting, but I'd like TabAtkins to have a new
           way to address the issues.
  * sgalineau is not super comfy with using CSS to give low-level
              performance hints but happy to hear more.

  glazou: To which spec do we add it?
  TabAtkins: We have an overflow spec.
  TabAtkins: The other option is display. Or it is independent and placed
             later.
  ChrisL: I'd rather not display.
  Rossen: I'd prefer the last and we'll decide later.

  <glazou> TabAtkins, ok for new ED of new document?
  TabAtkins: I'm back
  glazou: Are you okay for new ED for new document?
  TabAtkins: Yes.
  glazou: Any objections?

  RESOLVED: TabAtkins to put overflow: clip to new ED

DOMMatrix, DOMPoint and DOMPointLiteral
-----------------------------------------------------------

  <glazou>
https://lists.w3.org/Archives/Member/w3c-css-wg/2013JulSep/0280.html
  <krit1> http://www.w3.org/TR/2013/WD-matrix-20130919/#attributes

  krit1: We had a discussion about the attributes we use.
  krit1: There was discussion we should use float again.
  krit1: I restarted the discussion and it seemed no one objected to having
         doubles.

  TabAtkins: We're fine with doubles.
  glazou: And you're looking for agreement?
  krit1: I'd like a resolution.

  glazou: Thoughts? No opinion?
  glazou: No objections?

  RESOLVED: Use doubles instead of float for matrix items

  <krit1> http://dev.w3.org/fxtf/matrix/#the-dompointliteral-dictionary
  krit1: Next is to discuss some parts with zcorpan.
  krit1: Is he on the call?
  [Silence indicates no]

  krit1: What I'd like to discuss is I've edited DOMpoint to the
         specification of DOMMatrix.
  krit1: What I'd like to add is general geometric specifications.
  krit1: I'd like to join this with SVG WG to have geometric in one
         specification.

  glazou: I support that.
  glazou: Other opinions?
  glazou: None apparently

  krit1: I'd also like to have zcorpan here. So maybe next week.
  glazou: That's why I didn't call it resolved. We'll wait for him.
  glazou: Let's defer to next week.

  krit1: I'd like to move the other items to next week
  glazou: Fine.

getBoxQuads
-----------------

  dbaron: I'm not prepared to discuss
  glazou: Okay, let's go to the last item.

device-cmyk()
------------------

  <glazou>
https://lists.w3.org/Archives/Member/w3c-css-wg/2013JulSep/0281.html

  TabAtkins: Discussion is good on mailing list, all parties aren't here.
  TabAtkins: I'm confused so I want to spend the day working it out.

  ChrisL: What's going on is that for many years now
  ChrisL: I've been trying to get normal industry standards on the web.
  ChrisL: Originally it was in a print spec then it moved to a SVG spec,
  ChrisL: Then it got moved to SVG 2,
  ChrisL: Then people said why just for SVG, why not HTML too?
  ChrisL: At Paris F2F we agreed it would be part of CSS Color.
  ChrisL: That's great, but Rik started commenting on mailing list.
  ChrisL: His point was clear, no color management on the web.
  ChrisL: I'm not happy with it, we can have color management in other
         places, but not HTML.
  krit1: I don't think that's his position.
  ChrisL: I'm pleased it's not.
  krit1: I think he's just concerned that it's extremely complex to
         implement.
  krit1: I think that's his concern.
  ChrisL: You don't deal with that by saying tough luck.
  ChrisL: People should be able to do that.

  dino: Please explain what you mean by color management?

  SimonSapin: I think part of the confusion is that we have two different
              issues. One is color management. The other is device-cmyk().
  ChrisL: I get the difference but people are confusing them.
  ChrisL: We need device-cmyk(). If you want to measure your printer we'll
          want 10% cyan etc. You don't want color management near that.
  ChrisL: That's useful.
  ChrisL: It used to be everything was done that way, not RGB. That's the
          old way which we've been away from.
   ChrisL: I don't want to go back to the 1980s
  <dbaron> I'm not sure that "testing a printer" is an important use case
we
           need to address.

  ChrisL: Adobe would have been the last company I would have thought to
          object.
  ChrisL: They do solid color work. I'm astonished. I hope it's not the
          corporate position.

  dino: What did ChrisL mean by color management? Is that specific colors
        in a color space, or entire doc, or images with, color profile
        attached, etc?
  ChrisL: What I mean is you say what color you want, measure it, and get
          the same color on output.
  ChrisL: On the web it's good for responding to tagged images so they can
          be displayed correctly.
  ChrisL: And also so you can mesh things up and not restricted to RGB box.
  ChrisL: That's what I meant.
  ChrisL: It also means we have places with clipping if you use RGB. If you
          instead use unbounded you don't have that issue.
  ChrisL: There are benefits to that.
  ChrisL: It's also more perception of space. There's lots of reasons.
  ChrisL: It's to capture for display and share it with others.

  dino: What you're saying is people use a picture and want to preserve
        colors as close as possible.
  ChrisL: Yes.
  dino: One of the reasons we don't do this is performance. Performance is
        more important then accurate color management
  dino: For web it comes down to you plug in same color as you get on the
        page.
  ChrisL: I wouldn't call that color management.

  ChrisL: I'm not trying to force people, I'm trying to make an option.

  florian: A bit closer to the spec we're trying to discuss.
  florian: Yes, device-cmyk() is useful, but not main thing people want.
  florian: What they want is real color management.
  florian: Therefore, giving them this tempts them to do something.
  ChrisL: That's what I wanted to say, thank you.
  ChrisL: That's why Hakon put this in the spec.

  florian: The second thing is that the way I read this it won't do what
           people want.
  TabAtkins: It always converts to RGB, but if browser knows it can use it.
             This is for people who want their colors explicitly not to be
             managed.
  ??? If the author doesn't compose overlay we should leave it up to
      the browser.

  glazou: We're past the hour.
  glazou: We'll continue this on the mailing list.

Meeting Closed
Received on Friday, 27 September 2013 13:48:48 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 September 2013 13:48:49 UTC