W3C home > Mailing lists > Public > www-style@w3.org > October 2009

[CSSWG] Minutes and Resolutions 2009-10-14

From: fantasai <fantasai.lists@inkedblade.net>
Date: Wed, 14 Oct 2009 11:58:55 -0700
Message-ID: <4AD61F6F.4060907@inkedblade.net>
To: www-style@w3.org
Summary:

   - Call for agenda items for TPAC: add to wiki at
       http://wiki.csswg.org/planning/tpac-2009

   - Reviewed status of css3-multicol LC comments, specifically
       - name needs to be changed to match convention
       - discussion of this module's relation to css3-color vs css2.1
         and the testing implications thereof
       - discussion of where column rules are drawn; whether they are
         drawn for empty columns or empty parts of columns, etc.

   - Discussed text-overflow: shrink proposal. A note will be added
     to css3-text editor's draft; it will be addressed by the next
     active css3-text editor.

====== Full minutes below =======

Present:
   César Acebal
   Tab Atkins
   David Baron (late)
   Bert Bos
   Arron Eicholz
   Elika J. Etemad (late)
   Sylvain Galineau
   Daniel Glazman
   Brad Kemper
   Håkon Wium Lie
   Chris Lilley
   Peter Linss
   Steve Zilles

<RRSAgent> logging to http://www.w3.org/2009/10/14-CSS-irc
<glazou> hmmm http://lists.w3.org/Archives/Member/w3c-css-wg/ does not work for me...
<anne2> I can't call in today it seems
<anne2> I worked a few days on the CSSOM, but not a lot to report just yet:
         http://dev.w3.org/csswg/cssom/
<glazou> ok

Scribe: Tab Atkins

Agenda
------

   glazou: Extra action items?  Bert, did you send a message?
   Bert: Sent 2 items.  Background&Borders are scheduled for LC tomorrow.
         Also, what is happening with Multicol?  Are we discussing comments?
         Do we need Hakon for that?
   glazou: Yes, need Hakon.  I think we still have on the agenda a note about
           floats in multicol.  So we're probably not ready yet.
   glazou: But we may rely on Hakon to know precisely.
   Bert: Was just wondering if we have an overview of received comments besides
         the float thing.
   glazou: suggest rely on Hakon to summarize for us.
   glazou: No extra action items.

TPAC
----

   glazou: First item on agenda is items for TPAC meeting.
   <glazou> http://wiki.csswg.org/planning/tpac-2009
   glazou: Need proposals as soon as possible so we can schedule things.
   glazou: Request from dsinger to have someone from CSSWG to attend HTMLWG
           Accessiblitity meeting on Sunday before TPAC.
   <ChrisL> I will be at that workshop
   <Bert> Stanford
   glazou: Located in Stanford, not the hotel.
   glazou: Asked Dave to reply on information for that.
   glazou: I'll be able to attend in the morning, but probably not in the afternoon.
   glazou: There's a registration for that, but no fee.
   <Bert> (I'm arriving too late on Sunday, unfortunately.)
   glazou: When we know precisely when it is, we should decide who will attend.
   glazou: Please enter suggestions for TPAC for the FtF meeting.
   glazou: Only one line on the wiki page for the moment.

CSS3 Multi-Col
--------------

   glazou: Back to Bert's question, about multicol draft.
   glazou: Where do we stand on comments?
   Hakon: We stand at a good point.  LC ended on Oct 1st.
   Hakon: We had comments from 3 or 4 people.
   Hakon: From Alex and Sylvain in the WG, and from Giovanni outside the WG.
   Hakon: Don't think there are any hard issues to deal with, but would like
          to resolve them today if I can have like 15 minutes.
   Hakon: For example, the name of the draft.  The current name is -----.
          Should we update the name of the draft?
   <ChrisL> I'd like some time during today's telcon to discuss, among other
   <ChrisL> things, the name of the document. Today it's called
   <ChrisL>     CSS3 module: Multi-column layout
   <ChrisL> should we call it
   <ChrisL>     CSS Multi-column Layout Module Level 3
   <ChrisL> instead? (that's a long name)
   glazoue: Hakon proposed to rename from "CSS3 module: Multi-column layout"
            to " CSS Multi-column Layout Module Level 3".
   Bert: We appear to be moving toward the latter pattern.
   glazou: I think the new name really describes the intent of the module.
   Hakon: The problem with level 3 is that there is no level 1 or 2 with
          multicol layout.  So calling it "level 3" is a little misleading.
   glazou: I have no opinion.  I think it's a minor issue.  What do other
           people think?
   Bert: That's what we usually call it in speech.
   <ChrisL> +1 for new name
   glazou: No objections?
   glazou: Any non-editorial changes?

   Hakon: Yes, I need 5 more minutes.
   Hakon: Other feedback - one commenter said that we lacked requirements for
          colors in the gap.
   <howcome> Giovanni is asking for a "color profile" of multicol with
             relaxed requiements
   <howcome> I think a profile is too much work
   glazou: Why is he asking for that?
   <howcome> there are relaxed requirements in the multicol draft
   <howcome> it refers to css3 colors, but says that implementors only have to
             support css2
   glazou: I think this will be extremely confusing for web authors.
   <howcome> I don't want to require support for css3 colors in order to support
             multicol layout
   ChrisL: Surely it's a conformance class; it shouldn't require a whole
           new profile.
   <ChrisL> surely that is a conformance clause, not a whole new profile
   szilles: Why does the draft refer to css3 colors if people don't want
            to support it?
   Hakon: We have to refer to *something* for the color property in the
          column gap.
   szilles: Is CSS2 not enough?
   Hakon: It's enough for me.
   <howcome> column-rule-color needs a reference
   szilles: So is it just an issue of which to refer to?
   <anne2> (don't most browsers support css3-color nowadays?)
   <sylvaing> why wouldn't CSS3 color be OK there ?
   Hakon: Yes.
   glazou: When CSS3 colors becomes a rec, will that automatically update the
           multicol draft up to css3 colors?
   <howcome> This property sets the color of the column rule. The <color>
             values are defined in [CSS3COLOR].
   <howcome> Conforming user agents are only required to support the subset
             of color values defined in [CSS21].
   Sylvain: Yeah, we don't want to do special-casing of color models for
            particular properties.
   glazou: I suppose that they'll expand the value-space of colors supported
           by CSS3 colors.
   szilles: Won't that be put into the snapshot of what needs to be implemented?
   szilles: This is a general problem for specs.  For conformance and testing
            you have to pick one for everyone to do.
   glazou: But CSS3 colors isn't a rec for the moment.
   szilles: So the only thing that multicol *can* call for is 2.1.
   szilles: So that hits the issue of how we are updating specs in a modular
            fashion.
   szilles: If we were doing the specs in lockstep, this wouldn't be a problem.
   szilles: so my suggestion is that, in a snapshot, say "the following specs
            that refer to XXX color spec now refer to YYY color spec".
   Hakon: I think the current text is okay.  Do you want me to change it?
   ChrisL: Yeah, why not just say that the color values are defined in CSS2.1
           and that's it?
   ChrisL: If someone supports css3 colors now, surely they'll support those
           colors *everywhere*?
   Sylvain: Sure, but what if there's a fix for something?  You don't want to
            support something that's been proven to be wrong.
   <sylvaing> Tab, that was Hakon I think :)
   glazou: A possiblity: we say that your module depends on css2.1 color,
           and leave up for implements to use css3 color.
   szilles: And sometime in th future, we can update via a snapshot to css3
            color officially.
   Hakon: So what do we say in multicol?  Define it as css2.1 and say it will
          automatically upgrade to css3 when it becomes a rec?
   <ChrisL> Just say it uses a <color>
   glazou: No, just say nothing.  Otherwise it requires testing.  We'll just
           update the spec when css3 colors moves up to rec.
   szilles: Or a new snapshot.
   * anne2 thinks it would be nice to have a latest version/level link for
           each profile
   Sylvain: Aren't we doing a lot of work?  Updating a spec that's a rec is hard.
   szilles: If you want a Rec you need conformance, and you need something clear.
            You can't make "automatic" clear.
<Zakim> +David_Baron
   szilles: Important part of conformance is that the part that *is* in the
            language is done in an interop way.
   Hakon: Agreed, but don't think we should leave it open.  We should make it
          clear that you could do rgba or not.
   ?: If you say CSS2.1, it would be clear.
   ChrisL: But you are.  Just say <color>, and then when CSS3 color comes up
           it will allow it.
   Hakon: No, you have to refer to <color> from a specific spec.
   glazou: I don't think implementors will use different color specs in their
           implementation.
   Hakon: Exactly, so I don't want to leave it undecided.
   <Bert> Thinking about: "At the time of publication, <color> was defined by
          [CSS21]."
   szilles: So this isn't an issue with multicol, it's an issue about how to
            resolve linked specs.  It may require an FtF.
   Sylvain:  Someething about CSS2 being a subset of css3 color.
   Steve: Since css3 is a clear superset of css2.1, I think we can take the
          dependency.
   szilles: I understand, but I'd rather solve the general problem and then
            apply that, so we're not left with someething we don't like.
<Zakim> +fantasai
   plinss: Can't we just say "the current <color> defined by CSS"?
   glazou: No, because then we'll have to change tests, testing on 2.1 first
           and then 3 later when color updates.
   szilles: People can't ever decide which things they implement, because the
            rules change.
   plinss: If color level 3 is a rec, and multicol is a rec, nobody's going to
           implement multicol with color level 2.
   <anne2> szilles, fwiw, we're usually pretty clear on what we want to implement :)
   Hakon: We could avoid referring to anything, and just say that it takes the
          same values that are taken by the 'color' property.
   glazou: Steve, would that work for you?
   <anne2> szilles, though it seems that often specifications change halfway :/
   glazou: That would probably require writing tests, not for CSS2.1, but for
           CSS3 colors.  If we start writing tests for 2.1 and css3 colors move
           along the rec track, we'll miss tests.
   <Bert> "the same as 'color'" is a testable statement :-) Even if you don't
          know what the range of values is....
   Hakon: I'm not worried about people **something** things here.
   Hakon: I'm not too worried about people screwing up implmntations here.
   plinss: I accept that this is a geneeral problem with any inter-module
           dependency, and it merits further discussion.
   Sylvain: I agree, and let's do what peter suggested and just write tests
            for css3 colors.
   ChrisL: Actually, don't we already have a good css3 color test suite and
           pretty much done?
   szilles: I'm still unhappy with what I'm hearing, because I don't think it
            makes a clear statement of what's expected of a conforming
            implementation, and whether a conforming impl is allowed to exceed
            the spec.
   glazou: What would you say?
   szilles: I'd have the spec say that it should implement css2.1 color, and
            I'm fine with being silent on further.
   szilles: We have to ask ourselves if we're happy with impls going beyond
            the spec.
   szilles: I want to adopt a criteria to test for.  I think we all agree on
            practical issues, I just want it clear what needs to be tested
            at this moment.
   glazou: Other opinions?
   fantasai: As far as testing goes, we do have a n/a category in our test
             implementation reports.
   <ChrisL> yup, we could make css3 color support an optional feature, and use
            'not applicable' as needed
   fantasai: If we included the tests for multicol, we'd have two tests -
             one which uses css2.1 color and one with css3 color.  An impl
             that only supports css2.1 color would write "n/a" for the css3 test
   glazou: Yeah, that's what I suggest.  Point at 2.1 for now, and update in
           the future.
   szilles: So if I had two implementations, one which implements 2.1 and one
            does 3, which is conforming?
   glazou: I disagree with "not interoprable". The spec says to do 2.1 until
           we move it with a snapshot.
   szilles: I think we really just need to decide how modularization works.
            This is only one example.
   szilles: I'm less concerned about the way it comes, as long as it's clear
            what conformance means.  That's what a lot of people care about.
   glazou: Agree, and I think that if we don't establish clear guidelines for
           the tests, we'll have remarks from the w3c staff.
   * myakura wonders if we can stay with CSS2 for now and have a PER once the
           color module is done.
   glazou: My suggestion is to write css2.1 in the prose, but prepare tests
           with css3 colors so we're ready.  That way we're clear, but can
           move forward in the future.
   glazou: Let's reserve some time at TPAC to discuss modularization.
   szilles: I'm happy with that.
   TabAtkins: Sounds good.
   glazou: Objections? --no objections--

   Hakon: One more item.  Sylvain's commeent.
   Hakon: It's regarding the rule between columns.  How far down/up should we go?
   Hakon: say you have 2 columns with images at the bottom, but there's not
          space, so they're moved to the next column.
   Hakon: The spec kind of says  there will be a rule where there is content.
   Hakon: So is there content when something is moved?
   Hakon: The issue is if there is "content" based on layout, or based on where
          content is put?
   Daniel: I looked at newspapers, and it seems that when there is a column
           rule, it spans the size of the box, not the size of the content.
   Hakon: Yes, and also there *could* have been content there.
   Hakon: But I think that visually it makes sense to not have a rule there.
   Hakon: I think it often goes too low because of the line-height.  I think
          it should only go as low as the lowest baseline.
   szilles: Dos that mean if i have 3 columns with 2 rules between them, they
            can be at different heights.
   Hakon: yes.
   szilles: That sounds weird to me.
   Hakon: If we don't have that rule, we'll have a lot of lines with whitespace
          next to them.
   Hakon: Let's say you introduce a column break.  Should you continue to put
          the rule there?
   Daniel: I perfectly see your point, but how is the author going to control
           that?
   Daniel: And that could lead to bad visual designs.
   Hakon: No, we would *say* that we only show the rule when you have actual
          content.
   fantasai: I think if you have a rule it should be the entire height of
             the column block.
   fantasai: Either you have a rule or not.
   TabAtkins: I provisionally agree.
   Hakon: That's the simplest.  I've been using these rules for a while, and
          I find that the rules are too long.
   ?: When you split content into columns, you care much about the final result.
      I don't think authors will want to have the rules be shorter.
   * TabAtkins can't understand enough of Hakon's most recent statement to
               scribe.
   glazou: I just looked at the latest issue of Canard Enchainé and there's
           whitespace in front of the columnn rule.
   * sylvaing is not sure the Canard is the best reference. Everyone there is
              crazy. By design :)
   szilles: I'm not sure quite what you're saying without examples.
   glazou: I strongly disagree with your original proposal that implements
           *should not* render rules in front of whitespace.
   <Bert> I agree with Håkon: rules no longer than the actual content. But:
          all rules must be the same length.
   glazou: If you are going to vary this, it needs to be in control of the author.
   * TabAtkins didn't understand Hakon again.  ;_;
<Zakim> +dsinger
   glazou: That's all for multicol?
   <Bert> Hakon: I will provide examples.

<dsinger> please come to the media accessibility workshop!
<glazou> dsinger: yes i already said that to the wg

text-overflow: shrink
---------------------

   TabAtkins: next on the list is text-overflow: shrink.
   glazou: Ok, continued discussion.  I wasn't there, so it's probably up to
           you to continue.
   <glazou> dsinger: got my email about it?
   TabAtkins: I wanted the ability to make a line of text always stretch/shrink
              to its box..
   fantasai: So are you looking for text-overflow: shrink?  Or something with
             justification?
   TabAtkins: Don't really care.  Can adjust size, spacing, etc.
   fantasai: Sounds like justification.  We can put a note into CSS3 text, but
             I don't think that it'll be implemented in the near future.
   Bert: Why not?  It seems necessary.  I want to both stretch/shrink text, but
         also align the last line.
   fantasai: I'm not talking about the last-line property, I'm talking about
             an option for shrinking/growing text in the text-justify
   fantasai: This shouldn't be part of text-last-align, but rather part of
             text-justify.
   Bert: That makes things complicated, because every line could be a different
         size.
   fantasai: Yeah, that's what you'd get.
   TabAtkins whoever was talking, I didn't get that.
   <fantasai> I'm saying it should be text-justify: resize-font
   TabAtkins: I don't think that's at all a desirable effect when you just want
              to align the last line.
   <fantasai> If you want to align the last line, use text-align: last.  We're
              talking about shrinking text.
   TabAtkins: Would that apply with a single line?
   <bradk> You should be able to fit a text via resizing or condensing, without
           changing the text-align
   fantasai: Yes.  If there's just one line it's the last line.
   TabAtkins: Nah, text-align isn't meaningful when the text is purposely filling
              the whole line.
   fantasai: If you define a min/max size, then it may not fill the whole space
             and the alignment will matter.
   * TabAtkins didn't understand whoever was just talking.
   <fantasai> http://dev.w3.org/csswg/css3-text/#justification
   <fantasai> Pick a keyword, I'll add a note to text-justify. But I'm not
              actively editing css3-text
   Bert: A topic for the FtF?
   fantasai: No, I don't think it's a high priority, because Text isn't a
             high-priority topic. Nobody's editing it. Unless you're taking it
             over, Bert?
   Bert: If that's what it takes, why not?
   <bradk> My comment was that text-overflow is the place for that, because you
           might want text to be centered until it got too wide, and then you
           resize or condense it.
   Daniel: So what's the way forward?
   <fantasai> TabAtkins will come up with a keyword for text-justify, I will add
              it as a note to css3-text, and the next editor of css3-text can
              take care of it; it may or may not make it into the next official
              working draft

glazou: That's it, and please add tpac suggestions to the wiki page.
<fantasai> http://wiki.csswg.org/planning/tpac-2009
Meeting closed.
Received on Wednesday, 14 October 2009 18:59:32 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:21 GMT