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

[CSSWG] Minutes Telecon 2013-12-18

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 18 Dec 2013 21:34:43 -0500
Message-ID: <CADhPm3v+f341PLGxRkB91V3u_4b1-aM3X3WoAsx-C0WsHBzEnQ@mail.gmail.com>
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

This archive was generated by hypermail 2.3.1 : Thursday, 19 December 2013 02:35:13 UTC