- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Wed, 14 Oct 2009 11:58:55 -0700
- 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 UTC