W3C home > Mailing lists > Public > www-style@w3.org > January 2014

[CSSWG] Minutes Telecon 2014-01-08

From: Dael Jackson <daelcss@gmail.com>
Date: Fri, 10 Jan 2014 19:26:17 -0500
Message-ID: <CADhPm3ubp4sKaD7XnMpLDb1oOs-AjibExxFyM6W0B0FY-AvCYA@mail.gmail.com>
To: www-style@w3.org
Seattle F2F and TTWF

  - Everyone was reminded to put their status on the wiki as well as
         any dietary restrictions.
  - People were also asked to add agenda items to the wiki.


  - Plh updated the group on the status of the charter and hopes to
         have feedback before or during the F2F.

CSS Fragmentation

  - The group discussed clarifying if fragments are separate boxes
         or parts of the same box.
  - This led to discussion of how other specs act and what wording
         they use to identify elements, fragments, and boxes.
  - Discussion on the naming and behavior issues will be discussed
         further on the mailing list.
  - Later in the call, fantasai asked about possibly releasing a new
         working draft. She'll go over some comments and request a
         resolution next week.

Shapes LC

  - Astearns brought the group up to date on the comments he's

CSS Syntax CR

  - SimonSapin has made a few non-normative changes to clarify.
  - He will contact the I18N WG again to make sure they've reviewed
         Syntax and don't have any comments.


  Glenn Adams
  Rossen Atanassov
  Tab Atkins
  David Baron
  Bert Bos
  Tantek Çelik
  Dave Cramer
  Justin Erenkrantz
  Elika Etemad
  Simon Fraser
  Sylvain Galineau
  Daniel Glazman
  Dael Jackson
  Philippe Le Hégaret
  Chris Lilley
  Anton Prowse
  Florian Rivoal
  Andrey Rybka
  Simon Sapin
  Dirk Schulze
  Alan Stearns
  Leif Arne Storset
  Lea Verou
  Steve Zilles

  Adenilson Cavalcanti
  Bruno de Oliveira Abinader
  Peter Linss
  Simon Pieters

  ScribeNick: Dael

Seattle F2F and TTWF

  glazou: Any extra items?
  glazou: Is sylvaing here?
  glazou: So sylvaing sent a message about updating wiki w/ flight
          and dietary needs if you have any.
  glazou: He also says we'll have own name and password for network.
  glazou: Please update wiki ASAP with your status.
  <ChrisL> http://wiki.csswg.org/planning/seattle-2014#participants

  astearns: I don't have anything to add. Sunday beforehand we have
  astearns: I encourage everyone to sign up.
  astearns: If you can't make it, send in tests you need written so
            we have tasks.

  glazou: We also need to fill in the wiki with agenda items.
  glazou: The F2F is coming soon, so we need proposals.
  glazou: plinss and I will review proposals ASAP, but he's in

  glazou: Anything else on the F2F?
  glazou: Is sylvaing there?
  glazou: sylvaing, hello!
  glazou: We were about to close Seattle F2F. Anything to add
          besides what you said in your e-mail?

  sylvaing: No. One new piece is a meet up Wednesday night with
            local community groups.
  sylvaing: If there's any comments on that, let us know.
  glazou: Okay. We may be leaving Wednesday night.
  sylvaing: There's not an easy time. We can check if Monday works.
  glazou: Okay. Let's move on.
  * plh apologizes in advance for leaving the f2f early


  glazou: We need an update on the charter extension.
  plh: I was contacted about that recently.
  plh: It's going to review inside W3C and we'll hopefully have
       feedback by F2F.
  plh: If not feedback, we can continue with discussion within the
  plh: Hopefully we should be able to send for final review the week
       after F2F or during it.
  plh: I do know that since it's a draft it hasn't done anything,
       but I do expect some feedback. I think it's as good as we can

  glazou: There's an argument for the extension. We're expecting
          progress on the super group front.
  glazou: That will allow us to make a different charter in 6 months.
  plh: Right now the end of the charter is Feb 2015.
  plh: So 12 months.
  plh: I guess that's fine.
  plh: That makes sense.
  <ChrisL> That is fine, we can always recharter before it expires.

  glazou: That will let us have time with web consortium to discuss
          the super group
  plh: That's where we are.
  glazou: Questions, comments?

CSS Fragmentation

  <glazou> https://lists.w3.org/Archives/Member/w3c-css-wg/2014JanMar/0009.html
  glazou: We have request to discuss from krit.

  krit: I created an example with border radius.
  krit: Fragmentation means that I had multi-column with an element
        across the columns.
  krit: The question is how do we define the different fragments?
  krit: The spec isn't clear if it's one box split into different
        parts or if the border is drawn between columns
  krit: I think it's essential for many parts to define this clearly.
  krit: Do we create different boxes upon fragmentation?

  rossen: Yes.
  rossen: I've been reading your comments and we can consider that
          every fragment is a box and has its own model.
  rossen: The way the border is controlled on break is done by using
          the border box decoration property.
  rossen: That gives you the ability to have or don't have padding
          on break.
  rossen: So, to further elaborate as to if there is one box after
          fragmentation, I think that's not correct
  rossen: Correct is that this is collection of boxes. Fragment flow
          is the collection, not multiple fragments.

  krit: To be clear, I'd like a resolution to document how it works.
  rossen: What type of resolution? One to have us edit the spec is
  krit: I just want resolution that each fragment creates its own box
  rossen: Yes.
  * fantasai is confused.

  fantasai: The entire point of introducing the term 'fragment' was
            to distinguish it from box.
  fantasai: In CSS2.1, both the abstract layout object was called
            a box, and the pieces of it were called a box. We
            decided to call the pieces "fragments" to distinguish
            them from the abstract layout object "box".
  krit: That's fine as long as the spec says that each fragment has
        its own piece.

  dbaron: There's a bunch of existing specs that assume one behavior
          or the other. Mostly they assume each fragment is its own
  dbaron: I'm fine either way, but the resolution needs to say it's
          not changing existing specs and they might disagree.
  rossen: I'm with you.
  rossen: I think that it being closer to CSS 2.1 for inline boxes
          and the fact they are boxes is that right way to go.
  rossen: So should we have resolution.
  fantasai: I think that's dependent on us for fragmentation.
  krit: I think it's every spec.

  Rossen: We can see what spec has references and see if there are
  Rossen: I can't think of anything but multi column, box, and page
          that talk about this.
  Rossen: For those specs I think they're only talking boxes.
  SimonSapin: We also have box generation where they don't have size
              or position.

  fantasai: What do we call it is the problem. The full name is box
  fantasai: The CSS2.1 spec confuses elements and boxes as well as
            fragments and boxes. The abstract layout object "box"
            is sometimes called an "element", sometimes called a
            "box". And box fragments are also called "boxes".
  fantasai: So the content is a box, it gets split, and the it's
            both called box.
  fantasai: So we need to call them both box, but be able to
            distinguish between them.
  rossen: This is why we used fragments to distinguish. Is that the
          confusing part?

  krit: Is fragment how it differs? When a fragment has its own
        padding it isn't defined.
  fantasai: Maybe call it box fragment and box element and they can
            go by all those names?
  <fantasai> We can call them both boxes, or we can call them
             fragments / elements
  SimonSapin: I think it is defined by the box-decoration-break
  rossen: That's what I was saying a few minutes ago.

  krit: It's not clear which box you mean
  rossen: We mean fragment box, but we can be clear.
  fantasai: In fragmentation spec we use fragment when we mean a box
            fragment and box when we mean the abstract layout object box.

  glazou: What is the action for the near term?
  fantasai: We need a set of terms to agree to first. I propose
box-element and box-fragment
  dbaron: I don't like box-element.
  <antonp> Me neither.
  <glazou> Let's rename this at CR anyway.

  fantasai: The problem is we have a lot of specs that use box and/or
            element interchangeably. If we want to be compatible with
            those specs as dbaron wants, we need a term that can be
            shortened to either.
  dbaron: I think specs that use the term "element" to refer to
          something other than an element in the DOM are wrong and
          should be fixed.
  <astearns> +1 to dbaron - should not propagate the problem of
             conflating boxes with elements.

  rossen: Can we have element-box and fragment-box instead?
  krit: I like element-box
  ???: I'm fine with box-fragment.
  <leaverou> Not every fragmented box is an element, it could be a
  <ChrisL> I like fragment-box. Anything with 'element' in there
           implies it's in the DOM as a node.
  <leaverou> agree with ChrisL

  rossen: We can easily clarify in box decoration.
  krit: That's what I said.
  fantasai: Box is the generated abstract thing, and fragment is the
            piece of it and it's consistent on that.

  rossen I think what krit was saying is he's confused about
         fragment boxes
  fantasai: Where we were going now, fragments are the fragmented
            pieces of the box.
  rossen: That wasn't my intention. The way we implement is the
  rossen: There could have been miscommunication, but I've always
          thought of them as boxes.
  * sgalineau thought fragments were box fragments i.e. elements
              generates boxes which can then be fragmented.
  <fantasai> sgalineau, that's exactly right.
  <SimonSapin> sgalineau, that's box-decoration-break.
  <leaverou> sgalineau: Isn't that what box-decoration-break is
  * sgalineau leaverou, simonsapin: well, that sounds like fragment
              decoration :)

  krit: There's a difference in implementation. Webkit is one box.
  krit: IE and Firefox do different boxes.
  rossen: That's because we actually implemented fragments.
  fantasai: Firefox has layout objects called frames which are linked
            into a chain to represent a box. Each individual frame
            is a box fragment.
  krit: So in this case you're saying the fragment is right?

  <sgalineau> fantasai: So they're box fragments. But the
              terminology does not answer whether
              border/padding/margins get duplicated on fragments or

  glazou: We need to move one. Can we continue on the mailing list?
  rossen: Yes.
  glazou: I think that's better.
  glazou: We see the problem and we should have margins etc. on the
          fragment, but how to say it in the spec is undefined.

Shapes LC

  <glazou> https://lists.w3.org/Archives/Member/w3c-css-wg/2014JanMar/0014.html
  <astearns> http://dev.w3.org/csswg/css-shapes/issues-lc-20131203.html
  <ChrisL> Pointer to disposition of comments?
  <astearns> http://dev.w3.org/csswg/css-shapes/#20131203

  astearns: We're at the end of the comment period.
  astearns: I've gone through all of them and created a disposition.
  astearns: I got comments from digipub and posted them to www-style.
  astearns: There was nothing formal from SVG, but I got feedback
            from Tavmjong and krit.
  astearns: There were some explanations and clarifications.

  ??: SVG was also Tavmjong and he said we didn't have shape from
  astearns: He said that before LC so I didn't take it as a LC
  ChrisL: Did he agree?
  astearns: I gave him my rational, but I don't remember what he
            said in reply.

  astearns: There's some substantial changes. I added serialization
            and I changed outside from auto-none and I assume that
            we will need a second LC.
  astearns: I want to wait until serialization of background is
  astearns: Background position has changed and I had to adapt.
  astearns: I wanted to make sure that they're serializing in the
            same way.

  ChrisL: I want to make sure Tavmjong's comment is addressed.
  ChrisL: Inkscape did an in good faith implementation of something
          we did and then we backed away from it.
  ChrisL: They need to be able to put text in shapes and they're
          trying to do it with what CSS is doing.
  ChrisL: They need to have something they can use.
  ChrisL: Even though the issue was raised before LC, I'd encourage
          you to ensure he's okay with this.
  astearns: I'll get back to him on that issue.

  astearns: My position from last time is, just because shape inside
            isn't in level 1 doesn't mean we can't go ahead with
            implementation if it's going to be a level 2 feature.
  astearns: If it's a level 2 feature, they can do it. We also have
            it in webkit and blink and it's just postponed on the
            implementation side.

  glazou: I have a question on issue 6
  glazou: Our response asked whether this was OK with i18n.
  astearns: We didn't get an answer.
  astearns: We should get a positive response, but we do need it.
  ChrisL: One useful way forward is to e-mail them and say we need
          to know if you have comments or if you need more time.
  astearns: I will do that today.

  astearns: That's all I had. I just wanted to update the group.

CSS Syntax CR

  <SimonSapin> http://lists.w3.org/Archives/Public/www-style/2014Jan/0060.html
  <glazou> http://lists.w3.org/Archives/Public/www-style/2014Jan/0060.html

  SimonSapin: I did not receive any comments since we discussed.
  SimonSapin: I happen to have found something online that I tried
              to address with mostly editorial clarification.
  SimonSapin: There's no normative changes for implementors.
  SimonSapin: This is without comments from I18N WG.
  SimonSapin: So I don't know if I should wait for them or what's
              the next step.

  glazou: The LC period ended three weeks ago so we're beyond the
limit for comments.
  fantasai: Internationalization did tell me they might be late.
  SimonSapin: They didn't tell me.

  glazou: It's becoming urgent,
  fantasai: I would ping Richard Ishida and ask him if he has
            comments or needs more time.
  SimonSapin: I did include internationalization in the e-mail
              yesterday. Should I ask Richard specifically?
  fantasai: I would do that and give him time to respond. Their
           cycles are slower.
  fantasai: You should get response this week.
  fantasai: I'm happy to say we can resolve for CR as long as
            they're happy, but I'd like them to say they're okay.
  SimonSapin: Okay.
  SimonSapin: I'm happy to reach out.
  <Bert> (Richard is on vacation this week.)

  glazou: I'm in principal okay with that. One point, setting a
          deadline and never ever meeting it is pointless.
  glazou: Four weeks beyond the deadline is a lot.
  glazou: I'm not saying anyone in particular is guilty, but we have
           a process. We can extend it when people are going to take
           more time.
  glazou: And we can be firmer on the limits, or there's no point in
          a review period.
  <ChrisL> they should ask for an extension. And it's asking: we can
           say no.

  fantasai: He did say he's busy and would be taking several weeks
  fantasai: Also, this isn't urgent to put in CR. No one is waiting
            for it.
  glazou: I agree. Remember, I said in principal.
  SimonSapin: He told you, but he should have told the WG.
  fantasai: He should have.

  glazou: SimonSapin, when you contact them, I want you to be firm
          with them on time.
  glazou: I want to be sure that SimonSapin is okay with this plan
          to ask for comments and get an extension.
  glazou: If you're not ok we'll decide now.
  SimonSapin: I'm fine with waiting.
  glazou: Please ping Richard ASAP.

  glazou: What I see is only editorial changes, so it's easy to move
          to CR if the WG agrees.
  glazou: Shall we defer to next week?

  SimonSapin: Well, we already resolved.
  glazou: We're waiting for comments.
  fantasai: We have that if internationalization agrees we can resolve.
  <fantasai> http://lists.w3.org/Archives/Public/www-style/2013Dec/0403.html

  glazou: Be we don't have a resolution on these comments.
  SimonSapin: So we'll talk next week.
  glazou: That is better.
  glazou: If Richard answers no comments then we're fine and we can
          move on.

  SimonSapin: What is the next step for CR?
  glazou: Bert will issue transition request and we'll have a call
          with a director.
  ChrisL: Did you see the link I posted with the specs for CR?
  [Link from before meeting:

  SimonSapin: My question was more what do I need to do?
  ChrisL: As long as your disposition of comments is in order, you
          don't need anything else.
  glazou: So you're all set.


  fantasai: I wanted to, before we untangle box fragments which
            would require significant changes, I was wondering about
            publishing an updated WD.
  fantasai: if people think that's a good idea.

  astearns: You asked me to review and I posted stuff on the 6th of December.
  fantasai: I'm happy to go through those.
  fantasai: I'll try this week and ask for a WD next week.
  fantasai: I'm also holding up boxes and borders because I wanted
            to publish both together.

  astearns: On backgrounds and borders I want serialization defined
            before we publish.
  fantasai: Is it in OM? It's not in backgrounds and borders level 3.

  astearns: You and TabAtkins were talking and said you need to make
            sure serialization is correct.
  fantasai: It's somewhat defined but may be confusing.
  glazou: Any other items?

  * leaverou side comment: Generated content on issues prevents
             people from searching in their browser for "Issue" to
             find all issues in a document.
  <ChrisL> +1 to the generated content should be actual content
  <SimonSapin> leaverou +1
  <SimonSapin> leaverou, Bikeshed���s issue index helps, though
  * TabAtkins leaverou That's why I added the Issues Index. ^_^
  <leaverou> SimonSapin: ah, good point, I forgot about that
  * TabAtkins But also, I did consider having Bikeshed generate the
              words directly.

  glazou: I guess this is a shorter call

9-Part Sliced Images

  krit: I wanted to ask about sliced-image() function. If we want
        live images for CSS image,
  krit: Where we have border images and if we can have something
        like that for CSS images.
  krit: I can link the proposal.
  <krit> http://lists.w3.org/Archives/Public/www-style/2014Jan/0000.html
  krit: The intention of the report is that we remove the box
        properties that do for masking the same as border image.
  krit: If we use border image to avoid another property.
  krit: I want to ask the group if it makes sense to have a sliced
        image and if I should move forward.

  fantasai: A sliced image is fine, but anything within the image
            would be tricky.
  ChrisL: You'd have to do an outset.
  fantasai: I'm not convinced. Maybe 9-slice images would be useful
            for other things, but not for border and masking.
  fantasai: Because of those parameters and being able to tie it to
            the border width.

  smfr: This would move the complicated slicing numbers into image
         which would simplify border image.
  fantasai: I'm not sure how you mean.
  smfr: If this is like masking and border image, I don't think
        that's tied to the 9-piece-ness of the image.
  smfr: Are they tied to slice width?
  fantasai: It's tied to how we define the outside of the box.
  fantasai: You'd have one big image that you stretch.
  smfr: So the outsets are independent of the 9-sliced-ness of the
  smfr: I think this would be useful.

  fantasai: What else would you use it for?
  smfr: The buttons. Some people change button with hover.
  fantasai: Wouldn't you use border image for that?
  smfr: I think masking is a concrete use-case.

  krit: For border image I don't think it's a problem, though this
        may not make it easier, it's another way to do it.
  fantasai: One reason we split border image is people wanted to take
small pieces out.
  fantasai: This made it easier to change one piece.
  smfr: That's fine.
  fantasai: That doesn't apply to masking, but you wouldn't want to
change on hover.

  tantek: I think the background use case is simpler.
  tantek: That way you don't have to use border height to alter.
          That's not a big advantage, but simpler to achieve the end

  fantasai: You'd still need the same properties.
  tantek: It's less work slightly on the metrics pieces, which is
          the harder piece to get right.

  glazou: So, krit, anything else on this?
  krit: My intention was to have mask box.
  krit: I'd like to emphasize that even with proposals I'd still
        like to have mask box.
  fantasai: I think it makes sense.

  krit: So smfr, should we proceed with this image property to
        replace mask box?
  smfr: I think it would be useful to solicit use-cases to see if it
        would be useful.

  krit: That's independent of mask image.
  krit: So do we want mask box or proceed with replacing it with
        mask image?
  smfr: I don't know if I can make that call now.
  krit: I'm fine with waiting, but how long?
  smfr: If we do this, it would be images 4, right?
  fantasai: We have a F2F coming up. This could be on the agenda to
            wrap this up.
  smfr: That's reasonable.
  krit: Absolutely.

  glazou: Anything else?

June F2F

  SteveZ: How about June dates?
  glazou: I was away for last 10 days and couldn't ping Samsung main
  glazou: I'll do that now and report ASAP.
  <TabAtkins> Huge +1 for Korea meeting.

  SteveZ: You're aware that AC meeting is June 8-10?
  glazou: Yes. Plan is to have it in Seoul, not Samsung HQ because
          we'd have network issues.
  glazou: I'll report as soon as I can.

  glazou: I guess that's all for today
  glazou: Talk to you next week! Bye!
Received on Saturday, 11 January 2014 00:26:45 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:38 UTC