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