- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 18 Dec 2013 21:34:43 -0500
- To: www-style@w3.org
January F2F
-----------
- The group was reminded to add their information to the wiki.
- Glazou also stated he was working on getting the May details
together.
Compositing and Blending to CR
------------------------------
- RESOLVED: New LC for Compositing and Blending.
CSS Syntax Level 3 to LC
------------------------
- RESOLVED: Publish Syntax 3 as CR on Jan 7, pending review from
I18N WG
CSS Masking Issues
------------------
- RESOLVED: Shorten to mask-box from mask-box-image
- The proposed creation of bounding-box and its properties were
discussed with fragmentation and how it transforms getting
a lot of attention.
- Further discussion is to be held on the mailing list.
CSS Variables
-------------
- Glazou asked that the group consider moving Variables to CR and
giving further attention to the test suite.
interpolate() proposal
----------------------
- Leaverou's suggestion of creating interpolate() was discussed
with suggestions of either replacing or supplementing cross-
fade().
- Discussion will be continued on the mailing list.
CSS 3 Backgrounds
-----------------
- RESOLVED: background-position computed value is calc() per
dimension
- RESOLVED: Publish LC on Backgrounds 3
Fragmentation
-------------
- How backgrounds is handled was briefly discussed, though limited
by time.
- Most of the time was given to how size should be handled when
the box is a fixed ratio and height is dependent on width.
=====FULL MINUTES BELOW======
Present:
David Baron
Rik Cabanier
Dave Cramer
Bruno de Oliveira Abinader
Elika Etemad
Justin Erenkrantz
Simon Fraser
Sylvain Galineau
Daniel Glazman
Rebecca Hauck
Dael Jackson
Philippe Le Hégaret
Peter Linss
Simon Sapin
Dirk Schulze
Alan Stearns
Lea Verou
Steve Zilles
Regrets:
Mihai Balan
Florian Rivoal
Anton Prowse
Lief Arne Storset
ScribeNick: Dael
January F2F
-----------
glazou: Let's start.
glazou: Any extra items?
glazou: Before we start, I would like to make a reminder about the
January F2F
glazou: If you haven't added your data to the wiki, please do.
glazou: Also please start listing agenda items.
SimonSapin: About next F2F, we need to discuss in between January
and September.
glazou: I'm discussing to host in Seoul.
SimonSapin: Any ideas about dates?
glazou: Not yet.
glazou: I expect news in next few weeks.
Compositing and Blending to CR
------------------------------
<glazou> http://lists.w3.org/Archives/Public/www-style/2013Dec/0049.html
cabanier: Last week I asked about CR and got comments from the
group.
cabanier: Also have a comment from James Robinson on the list.
cabanier: I've address the issues and added them to the
disposition of comments section.
cabanier: Comments were about non-normative sections and I changed
them to normative.
cabanier: I thought that would take us back to LC, but after
reading process documentation this doesn't seem needed.
cabanier: So can we go to CR, or do we need another LC?
plh: I think we need to go back to LC.
plh: If we changed some sections to normative, you're changing
what's covered in spec.
cabanier: I didn't know if non-normative isn't covered.
plh: It's not.
cabanier: Then we need to put it back. I'd like shortest period
possible.
cabanier: That's 2 weeks. Is that okay?
plh: Isn't it 4?
cabanier: No, it's 2, I'll double check.
<cabanier> "Duration of the review: The announcement begins a
review period that should last at least three weeks but
may last longer if the technical report is complex or
has significant external dependencies."
cabanier: Announcement begins the review and it should be three
weeks.
glazou: Any objections or comments?
sylvaing: Three weeks from when?
plh: From publication.
sylvaing: Yes, be we control publication.
plh: We can go soon
sylvaing: We're looking to publish on the 28th?
glazou: Publish on 7th Jan, end on 28th.
cabanier: Yes, publish on 7th, end on 28th.
SimonSapin: So that ends in middle of our F2F?
glazou: That's fine. We can talk about it then.
cabanier: That's perfect.
glazou: Any objections?
fantasai: For what?
glazou: Compositing and blending.
RESOLVED: New LC for Compositing and Blending.
CSS Syntax Level 3 to LC
------------------------
<glazou> http://lists.w3.org/Archives/Public/www-style/2013Dec/0387.html
SimonSapin: LC has ended. I had a few comments, but issue was fixed
SimonSapin: No feedback from the working groups we pinged.
SimonSapin: Should we go to CR, or ping them again?
glazou: From a process standpoint we did what we were to do.
glazou: If there's no answer we can assume no comment.
<dbaron> I wouldn't expect comments from these groups anyway...
glazou: Only two comments that were fixed means little
controversy, so it should go to CR.
SimonSapin: Many people may be on holiday right now.
glazou: We can look for compromise. We can't publish CR before
early January anyway. Can resolve now and if get major
comment we revisit then.
glazou: You can ping non-responsive groups in the meantime.
SimonSapin: Sounds good.
glazou: Any objections to publishing CR of Level 3?
<plh> for publication on January 7, ping Chris or plh
RESOLVED: Publish CR of Syntax Level 3
SimonSapin: Wasn't there something about encoding in syntax,
fantasai?
fantasai: I don't think so
SimonSapin: Something from Richard?
fantasai: Richard wanted to review
fantasai: May get comments from international later; they're a bit
overbooked.
glazou: Can we ping him again?
fantasai: He said they couldn't do comments by the deadline, but
given how long we take to CR we can schedule now.
fantasai: I doubt there will be a large note.
SimonSapin: We can see what happens.
glazou: The 7th gives them three extra weeks to review
glazou: SimonSapin can you ping them?
glazou: So this is conditional approval pending international
comments.
RESOLVED: Publish Syntax 3 as CR on Jan 7, pending review from
I18N WG
plh: Bert is away, so I'm doing publish requests.
SimonSapin: Thank you
* plh got the end date of moratorium wrong. folks can publish on
Jan 2 it seems.
CSS Masking Issues
------------------
<glazou> http://lists.w3.org/Archives/Public/www-style/2013Dec/0281.html
<krit> http://dev.w3.org/fxtf/masking/issues-lc-2013.html
krit: fantasai sent comments and I added my comments to hers.
krit: I would like to go through some of the issues, especially 3
and 2 in that order.
krit: Issue 3 is renaming mask-box-image.
krit: Webkit is fine with this change and no comments from Mozilla.
krit: I'd like a resolution to rename to just mask-box.
glazou: Comments?
glazou: None?
dbaron: This is like border-image?
fantasai: Yes
dbaron: It feels weird, but I'm not going to object.
dbaron: It's weird to have mask-box that references an image.
krit: Long name still references images.
krit: mask-box is shorthand
<astearns> http://lists.w3.org/Archives/Public/www-style/2013Dec/0223.html
glazou: Is that okay for you dbaron?
dbaron: Yes.
RESOLVED: Shorten to mask-box from mask-box-image
<krit> http://dev.w3.org/fxtf/css-masking-1/
krit: Issue 2 has a lot of properties that are related.
krit: fantasai requested a new keyword for these related things,
krit: That makes it obvious these things belong together.
krit: I proposed mask-position, but we have a long hand called that.
krit: Other suggestions?
fantasai: I haven't thought about it too much, but what bugs me
about the current approach is we have mask-text and mask-
source.
fantasai: Even though it follows, it's unrelated, where as mask-
force-type is related.
fantasai: I want the to look like they're associated.
fantasai: I'm not super-clear on my thoughts.
krit: Do we keep with what we have or do we rename to something
like mask-element-type?
fantasai: It's not mask-element-type? I thought we carried that in
from SVG,
fantasai: So we can't really change that.
krit: It was SVG 2 spec.
fantasai: If mask-type isn't implemented I would change around to
mask-source-type to apply to SVG elements.
krit: It's implemented in webkit.
krit: Tantek might know...I think it's not...I think it can be
changed.
fantasai: If anyone has other thoughts?
fantasai: Maybe discuss on list?
krit: Yeah.
smfr: Imagine we have a syntax that makes a 9-piece image work as
any other image which means you could get read of this and
collapse the properties together.
krit: The idea behind mask-boxing was to have a parallel to border
image
smfr: We've moved beyond the parallel so it isn't worth maintaining.
smfr: If we can do this with syntax we could simplify this.
krit: That's one option.
krit: We could move box-masking to the second level so we have
more time to discuss.
krit: It's a bit difficult since box-masking has a bunch of images
with different sizes.
krit: Functionality is quite complex
krit: Use of box-masking...it would be good to do that with one
function.
fantasai: 9-piece images is useful in a lot of ways, there's a lot
you can do with it.
fantasai: One thing that might be difficult in a functional syntax
is you can outset and inset images and have them overflow.
smfr: That's true.
krit: What do you want to do now?
krit: You think we should not use box-masking?
smfr: I'm not hot on the names, but I don't want to hold up the
spec.
krit: Now is the right time to change them.
<leaverou> smfr++
fantasai: I guess box-mask would make more semantic sense but it
takes mask off the front of the name
krit: Box-masking is better?
sylvaing: We may want to us box for something else in the future.
krit: I'd like to...mask-box explains what it's doing.
krit: I don't think we should change it any further.
krit: I'm fine with switching property names.
rossen_: Did we do any kind of poll from the community on the
names?
rossen_: Give it a week to see if we can get better ideas?
sylvaing: We'd get an answer, but not a representative sample with
the holiday.
krit: We can go to next issue
<krit> http://dev.w3.org/fxtf/css-masking-1/#the-mask-origin
krit: This is reference to boxes, the mask value have the usual...
content-box, border-box to use for sizing.
krit: I added a new prop called bounding-box.
krit: It's basically a combination of border boxes to create a new
element
rossen_: That includes all the inside elements?
rossen_: So all the abspos items are included?
krit: yes.
fantasai: I have one concern about fragmentations,
fantasai: And how this is handled.
fantasai: Like if you paginate.
<krit> http://dev.w3.org/fxtf/css-masking-1/#propdef-mask-image
<krit> Fragmentation is specified for mask-image
rossen_: This shouldn't effect pagination because all boxes will
have independent flows.
rossen_: One giant box wouldn't effect fragmentation.
fantasai: Other values of the original will result in a box broken
across pages and reassembled,
fantasai: But in a bounding-box case you'd draw a box around all
fragments.
rossen_: This shouldn't be different then the discussion about
background images,
rossen_: And how you center on boxes fragmented across non-
homogeneous.
fantasai: And in that case we decide not to do this.
fantasai: This is different.
fantasai: Imagine a multi-column element with three boxes.
fantasai: In first it begins half way down, goes in 2nd, ends half
way into the 3rd
fantasai: If you have a background and stretch to full box, it'll
look like three fragments; It was split, drawn across,
and then put back.
fantasai: Bounding box says don't do that, draw a box that
contains all border boxes and then draw mask in that.
fantasai: What happens if you get a box same size and shape as
multi-column element and it stretches the entire box.
krit: I had some thoughts, this is like background image.
krit: If you don't want that, you use border box and have the
exact same background.
krit: As calculated it would be broken into different pieces for
each column.
fantasai: This switches if you include overflow content and
switches how fragmentation happens.
krit: no
rossen_: I think...the way fragments will change...the difference
between background is that it's calculated on the
combined boundary box of all fragments.
rossen_: In this case, the three boxes,
rossen_: The problem is your definition of bounding box it'll have
to create on final layout, not an approximation.
krit: If you have this content you can use border box and it'll
work.
krit: What I want to say is it'll mask overflowing content.
krit: It'll give you some fragments.
rossen_: Is it enough to say the end result in fragments when you
apply mask it's approximately same as in content box
where all content included in the overflow is masked.
krit: Yes.
rossen_: So then the problem fantasai pointed out shouldn't be a
problem.
krit: It makes it look odd if you pick bounding box and has
overflow.
krit: However, if you use border-box it wouldn't be a problem
krit: If you want to mask and have overflow.
rossen_: What about transforms?
krit: Doesn't effect bounding-box
rossen_: So it's handled pre-transform.
krit: Box would shift because you're transforming coordinates.
krit: You just change coordinate system.
rossen_: I don't buy it.
rossen_: If I have one box inside a box and outer box has bounding-
box
rossen_: Inner box overflows, no transform.
rossen_: Your bounding box will be the size of the containing box,
rossen_: So your mask will apply the on outside box.
rossen_: So I do a transform on the inner, what's your bounding
box?
krit: I was confirming that his definition is post- or pre- and it
is post transform. That's how I understand.
glazou: I'd like to point out the definition is detailed to how
you view the document.
<glazou> getBoundingClientRect()
krit: I'm not sure if it's a correct transformation.
krit: Then it's fine. It's spec'ed correctly
.
smfr: That's weird though, because transform is in drawing.
krit: The element is transformed.
smfr: We think the transforms of the content is transformed.
glazou: Is bounding pre or post?
krit: Post.
fantasai: Masking applies to element before transform, correct?
krit: Yes and no.
krit: It's for the element, not the matter itself.
fantasai: Just for the content. If the element is transformed then
the mask is with it.
glazou: We should wrap up.
krit: We should discuss further on the mailing list. Fantasai can
you answer questions on the mailing list?
smfr: I think it would be good to have an example in the spec.
glazou: Is that all the formatting issues?
krit: All for this call.
CSS Variables
-------------
glazou: I added this because Firefox is shipping so we need to
consider our next steps including the test suite.
glazou: Is any other browser planning to implement?
smfr: We have some in webkit, but I don't think anyone is working
on it.
glazou: I think old code is disabled in webkit.
sylvaing: doesn't chrome support it behind a runtime flag?
glazou: Anyway, even without 2 implementations we should set our
next steps.
glazou: Any tests we can gather, anything in test repository?
glazou: Who is willing to help on this?
* fantasai would like to point out the spec is still LCWD, maybe
it should move to CR?
glazou: Yes, fantasai.
glazou: Is it time to move to CR?
krit: I think there were comments from Cameron?
dbaron: I think they were more then editorial
dbaron: And I think heycam wrote some tests that can be contributed
glazou: This spec seems like it could move fast on the rec track.
interpolate() proposal
----------------------
<glazou> http://lists.w3.org/Archives/Public/www-style/2013Nov/0441.html
glazou: leaverou?
leaverou: For example if we had multi-elements and wanted to make
it different from overlap...
leaverou: It's been a while since I proposed this.
leaverou: I think it would help, why not expose it?
* fantasai would like to discuss css3-background briefly
* fantasai thinks we should take it to LC
krit: I think the original proposal was to rename cross-fade to
interpolate.
leaverou: And to enable it for any value, not just images.
leaverou: That's why the name change.
<astearns> Why not keep cross-fade() for images, and add a new
interpolation()?
leaverou: TabAtkins also agreed this would be useful.
krit: Wouldn't the current function work for everything?
leaverou: You can't calculate over colors, but you can interpolate.
leaverou: It also helps with variables.
leaverou: If you have colors, you can't do calculate or manual.
krit: Okay, I misunderstood.
leaverou: Any other interpolatable value this is good for.
smfr: In theory I support this.
smfr: Two questions; First, would computed return interpolate?
leaverou: Yes.
smfr: Other questions; if we have this function, people would use
it as an endpoint.
smfr: That would get complicated, because end up with nested
interpolate().
leaverou: We can do that for cross-fade.
smfr: In theory, yes.
leaverou: Cross-fade is supposed to work like images.
smfr: Cross-fade just supports pixel images in webkit.
leaverou: You mean?
leaverou: It's definitely in images 4.
smfr: It's not implemented.
leaverou: Eventually the bugs will be fixed.
smfr: Yes.
glazou: Should we take this to to the mailing list?
fantasai: Can we discuss css3 backgrounds?
glazou: After this.
glazou: Leaverou can you take this back to the mailing list?
leaverou: Yes. I'm a bit worried that it'll stall and browsers
will implement cross-fade() and it'll be too late to
change.
fantasai: I think you want to leave cross-fade and have more ways
to choose between.
leaverou: I'm not sure about cross-fade.
fantasai: I'm not saying interpolate is bad, but also have cross-
fade.
<astearns> +1 to adding interpolate() without replacing
cross-fade()
<sgalineau> astearns++
plinss: I agree. I think default in interpolate is cross-fade, but
there are other types of transition.
fantasai: Suppose you say you want to explicitly cross-fade an
interpolatable gradient, you can't do that with
interpolate.
leaverou: That makes sense.
glazou: Let's go back to the mailing list.
CSS 3 Backgrounds
-----------------
fantasai: Backgrounds has a few changes over years, we need
another LCWD.
fantasai: One of the remaining issues is the animation of
background position.
fantasai: I think TabAtkins gave a good proposal.
fantasai: Current way is two pairs, keyword and offset. This would
change it to horizontal axis offset and vertical axis
offset,
fantasai: So it would be offset from original position in respect
to dimension.
fantasai: Dimensions are important because in the future we may
have more then two.
fantasai: This should solve the problem with having all the
positions possible.
fantasai: If people are happy with that I'll put it in spec.
<SimonSapin> fantasai, did we end up fixing the background-
attachment: local stuff?
<fantasai> I don't remember! I'll look into it, thanks for the
reminder.
glazou: What do people think?
krit: I think fine.
glazou: Any objections?
glazou: Seems accepted.
RESOLVED: background-position computed value is calc() per
dimension
fantasai: So can we publish LC?
krit: Did we decide with background-origin be in the publishing?
krit: Box-height works off this.
fantasai: That's changed.
glazou: Any comments on LC?
RESOLVED: Publish LC on Backgrounds 3
<dbaron> I wouldn't mind seeing the text resulting from the
background-position changes...
Fragmentation
-------------
glazou: We only have 4 min left.
glazou: Can we discuss fragmentation?
glazou: Not sure.
fantasai: Depends on how much detail people want.
glazou: No time for detail.
<glazou> http://lists.w3.org/Archives/Public/www-style/2013Dec/0268.html
fantasai: We can go over the change to how backgrounds are handled
in fragmentation.
fantasai: We can get continuous behavior.
fantasai: Question is did people look at it?
Rossen_: If no one has looked deeply, no need to discuss.
Rossen_: We did get comments from astearns which helped.
fantasai: For sizing backgrounds; the case with problems is if
there's a fixed ratio and height is dependent on width.
fantasai: If width changed it created problems as you go from page
to page.
fantasai: We put in a rule that said you size once and don't
change from fragment to fragment.
fantasai: We used the size of largest box. The other options are
last or smallest.
fantasai: Is there reasons to go with something other then widest
box?
<fantasai> http://lists.w3.org/Archives/Public/www-style/2013Dec/0267.html
Rossen_: Current proposal is the widest box which is like saying
using bounding box.
fantasai: Sort of.
Rossen_: It had some initial acceptance on the mailing list.
astearns: Only thing I can think of is with a situation with
adding and removing it might be better to use first box
so you don't have the fragments change.
Rossen_: I think any approximation won't be perfect.
Rossen_: This is trying to optimize the average case.
Rossen_: Average case is when they are the same.
Rossen_: When fragments vary we want to have a good choice for
someone.
krit: Can an image be a fragment?
fantasai: Yes.
krit: If you're doing a fragmented image do we want the largest?
Rossen_: We're talking backgrounds.
Rossen_: With backgrounds it has multiple fragments and you have
to choose a start.
Rossen_: The worst case is with fragments and center and you need
special juju to make it work,
Rossen_: If you want a perfect experience.
Rossen_: That's what we're discussing.
krit: Sending examples would be good.
Rossen_: We can craft something.
fantasai: It's important to note the width isn't changing, it's
just the height we're fixing.
fantasai: If you have a square image and you repeat, it'll get
wider and narrower, but not taller and shorter.
plinss: Wouldn't you be messing with aspect ratio?
fantasai: Yes.
glazou: I guess we have to take this off call.
Rossen_: It's on the list, so please comment there.
fantasai: Link is up at the beginning of this piece of chat.
glazou: Thanks everyone. This is our last call in 2013.
glazou: Talk to you in January!
Received on Thursday, 19 December 2013 02:35:12 UTC