- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Thu, 17 Feb 2011 15:50:09 -0800
- To: "www-style@w3.org" <www-style@w3.org>
Summary:
- Koji Ishii taking editorship of CSS Line Grid module
- Reviewed status of CSS2.1 test results and issues list
- Whether root element is a block formatting context root
deferred to CSS2.1 errata (currently undefined), to allow
time for investigation implications.
http://wiki.csswg.org/spec/css2.1#issue-209
- RESOLVED: remove gamma-correction note from CSS2.1
http://wiki.csswg.org/spec/css2.1#issue-221
- RESOLVED: Make containing block formed by relatively-positioned
inline that is split across lines undefined.
http://wiki.csswg.org/spec/css2.1#issue-215
- RESOLVED: Drop vertical-align from list of properties required
to apply to ::first-line.
http://wiki.csswg.org/spec/css2.1#issue-216
- Tentatively resolved: Remove 3 lines from multicol pseudo-algorithm
that relaxes column-gap when column-count requires too
many columns. Pending Hĺkon's review.
- Discussed interaction of HTML and Selectors spec wrt :active.
====== Full minutes below ======
Present:
César Acebal
Tab Atkins
David Baron
Bert Bos
Arron Eicholz
Elika J. Etemad
Simon Fraser
Sylvain Galineau
Daniel Glazman
Koji Ishii
John Jansen
Chris Lilley
Peter Linss
Steve Zilles
<RRSAgent> logging to http://www.w3.org/2011/02/16-css-irc
Administrative
--------------
glazou: Extra agenda item sent to the list from Koji.
glazou: Asking to resurrect CSS Line Grid, with him assuming editorship.
glazou: Any objection to this?
[no objections]
glazou: Welcome, Koji.
<glazou> http://idpf.org/epub/30/spec/epub30-contentdocs.html#sec-css-profile
glazou: Next topic. Epub wants us to review the CSS-related section of
their doc and send comments.
glazou: What's the deadline?
fantasai: I'm pretty sure we'll have some reasonably amount of time to
discuss it...
<fantasai> I don't see any mention of a deadline for comments.
<fantasai> Probably one month is good, so that they have time to address
them and can make it in before their next draft (which I'm
guessing will be more than one month out).
glazou: The CSS section is mostly a profile, right?
fantasai: Yes, so we want to make sure they're profiling correctly.
<ChrisL> its also a profile of CSS 2.1, while EPUB2 was CSS2 iirc
fantasai: jdaggett had some concerns about how they were profiling CSS3
Fonts. I tried to get them addressed before publishing, but
still needs review.
fantasai: There are several features listed not in CR yet, so we need to
recommend on how to deal with that.
ACTION on everyone: Review the CSS-related section of the epub document.
CSS 2.1
-------
glazou: Peter, you got a message from web2pdf.
plinss: They're fixing a bunch of bugs in our blocked tests.
<glazou> WebToPDF.NET
plinss: They'll have a public beta release that fixes several of our blockers.
<glazou> http://test.csswg.org/harness/results?s=CSS21_HTML&t=0&f[]=1&f[]=1
plinss: We're on 15 blocked tests now.
plinss: I know they have fixes on two of them, and regressions on two more
that they'll go back and fix.
glazou: Any other 2.1 comments?
johnjan: Looks like Elika's done a bunch of updates to the current issues
list.
fantasai: I just copied over the LC comments from the page I was stashing
them on.
fantasai: There's a bunch of issues over clearance and margins that need
a closer look at.
<fantasai> http://wiki.csswg.org/spec/css2.1#issue-207 probably requres
some investigation by WG members; it involves clearance
<fantasai> also http://wiki.csswg.org/spec/css2.1#issue-211 is margin
collapsing
<fantasai> http://wiki.csswg.org/spec/css2.1#issue-209
fantasai: Issue 209 should be easy to resolve.
dbaron: The issue with the root element is that we never say what precisely
establishes the root BFC, whether it's the root element or something
above it.
dbaron: The only place I've found that matters is if the root contains
floats that extend below its normal content, and if the root has
a border or a background image vertically positioned anywhere other
than "top".
dbaron: Gecko treats it as the root establishes a new BFC. Opera and Webkit
don't.
fantasai: My inclination is to treat it as a BFC, since its margins don't
collapse. It would make things more consistent.
alexmog: In IE we have a pagination problem, since if the root is a BFC
then it won't break across pages.
alexmog: ...
fantasai: Why would the root take the size of the page?
alexmog: The root's layout box (whatever gets the scrollbar) gets set to
the size of the first page.
alexmog: I may not be able to describe the problems properly, and they may
be impl-specific.
<dbaron> https://bug590491.bugzilla.mozilla.org/attachment.cgi?id=469029
<fantasai>
http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cstyle%3E%0A%20%20html%20{%20border%3A%20solid%20blue%3B%20}%0A%20%20.float%20{%20float%3A%20left%3B%20height%3A%2016in%3B%20border%3A%20solid%20orange%3B%20}%0A%3C%2Fstyle%3E%0A%0A%3Cdiv%20class%3D%22float%22%3E%3C%2Fdiv%3E
dbaron: What matters in the test is the position of the orange stripe
<dbaron> in first test, what matters is position of orange stripe
fantasai: In my test, if the blue box is large enough to hold the yellow,
it's a BFC.
alexmog: It's not a BFC in IE9 or IE8. It was in IE7.
fantasai: I suspect this isn't a web compat issue, since we have differeing
implementations.
fantasai: So I suggest to make it a BFC, because authors would get confused
otherwise when root backgrounds don't contain their floats.
alexmog: Can I check with Paged Media issues and get back to you on that?
fantasai: Yup.
alexmog: Another issue. When pages change width, usually you take the
width of the page where the BFC starts, and it stays that width.
This is how we treat tables and such.
alexmog: But if the root is a BFC it has to act differently, so it can get
larger if the page gets larger.
Bert: Related, we have 'overflow' which can't apply to <body>.
glazou: So do we need more time to decide on exactly how to handle this?
dbaron: I'm okay with changing Moz, though we do need to define where the
root BFC comes from.
glazou: Is that okay with everyone?
<dbaron> I don't really understand alexmog's paged media issue, though.
alexmog: Is it okay to say that the root is not a BFC in paged media?
<dbaron> I don't see any reference to block formatting contexts in the
CSS 2.1 paged media chapter or in css3-page.
alexmog: It's not written anywhere, but it's something that people will
have to solve as they implement Paged Media.
dbaron: is it related to BFCs specifically, or just to certian types of
things that establish BFCs?
alexmog: It's certainly easier to say that everything that establishes
a BFC has that behavior.
fantasai: You say IE has special behavior for tables and such across pages
to make their widths stay the same across pages that have different
widths.
fantasai: You also do that for overflow:hidden?
alexmog: Yes, overflow:hidden elements also have this behavior.
fantasai: It might make more sense for overflow:hidden elements to act
like normal elements.
alexmog: So I don't strongly object to the root being a BFC, it would
just make its pagination rules somewhat special.
fantasai: Yeah, the pagination rules aren't clear in the first place.
We wrote something about changing page widths into paged media,
though it's maybe not quite the same.
alexmog: It's unlikely we'll make changes to IE9 in this regard, btw.
fantasai: of course :)
glazou: So what do we do?
TabAtkins_: It sounds like nobody has great disagreements, we just need
to have some careful consideration of the issues and decide
what to specify.
johnjan: Is this really something we want to change right now?
glazou: FF4 and IE9 are shipping with different behavior, so no matter
what's decided there will be differeing impls.
<ChrisL> erratum for CSS 2.1 then?
dbaron: I'm okay with waiting six months and putting this into the next
revision of 2.1, but I'm not okay with waiting for CSS3.
RESOLVED: Discuss issue, resolve in CSS 2.1 errata.
Topic: Gamma section in CSS 2.1 spec
ChrisL: There was a discussion a few years ago from Chris Murphy, as a
result of which we removed the section on gamma from CSS3 Color.
ChrisL: It was confusing and outdated.
ChrisL: It was recently pointed out to me that the same section is still
there in CSS 2.1 as an informative note.
ChrisL: It has no conformance weight, but it's still confusing and
outdated and has negative value. So we should delete it from
CSS 2.1 as well.
RESOLVED: Remove the gamma note from 2.1.
Filed as http://wiki.csswg.org/spec/css2.1#issue-221
<ChrisL> the comment from Chris Murphy about being ignored at W3C
<ChrisL> http://lists.freedesktop.org/archives/openicc/2011q1/002969.html
<arronei> http://wiki.csswg.org/spec/css2.1#issue-215
<arronei> http://wiki.csswg.org/spec/css2.1#issue-216
arronei: There are two issues on the issues list that are super simple,
215 or 216. We discussed at the testing f2f, and I think we all
agreed to kill them.
arronei: I'm not hearing any objections to leaving 215 undefined.
arronei: dbaron, you said FF is the only one that passes 216, and everyone
else goes the other way. Do you object to dropping it?
dbaron: I'm fine with that. It can fall into a MAY.
RESOLVED: Resolve issue 215 as undefined, and accept proposal for issue 216.
Multicol algorithm
------------------
glazou: howcome's not on the call, but he quoted two of his messages.
alexmog: Which way to go is a matter of philosophy
* glazou loves when philosophy come to CSS :-D
alexmog: There are a few ways to treat a situation when there's no usable
layout that satisfies the constraints.
* fantasai votes for adding more comments to the pseudo-algorithm =)
alexmog: One way is to honor everything that is exactly defined, and just
overflow if necessary.
alexmog: Another is to keep content visible, so users on a phone don't get
a pretty layout, but it's usable.
alexmog: I think that nowhere in CSS do we alter the way we interpret
properties based on whether an overflow is about to happen.
alexmog: If we really care about the end-user and want to show them
content, when the design intent totally fails, the best thing for
the user is to just drop to a single column as soon as possible
when the multicol properties can't be satisfied.
alexmog: So once we shrink down to 0 col width, the next step should be
to drop straight to 1 column.
alexmog: I think these are the only two situations (honor exactly, or
drop to 1 col quickly), and not to try and gradually relax
properties, hovering around unusable states.
Bert: I like the principle, but what's the practical effect of 0-width
columns?
alexmog: I think the page becomes unusable before 0px-wide columns.
alexmog: If the column is too small, the overflow just intrudes into
the column-gap.
alexmog: If there's a single 0-width column, you'll see the overflow
content. With multiple columns you won't.
szilles: I thought we discussed overflow columns just going to the right.
Does that help in this case?
alexmog: Different situation - that's where column width is specified,
but not count. This case is where column-count is specified,
but not width.
szilles: So really, if you want to service multiple screens, setting a
fixed number of columns is a bad idea.
alexmog: Without using media queries, yeah. Setting column-width is
a better approach in general.
TabAtkins_: I think we should just honor things exactly. It can produce
an unusable situation, but that's easy to fix right with
media queries.
szilles: And what happens if I set both -width and -count?
alexmog: Current spec ignores -count in that case.
alexmog: I don't think that this extreme case is a good enough reason
to add column-min-width.
<fantasai> I thought the -count became the maximum column count?
alexmog: So we have two in favor of treating things exactly as specified.
bradk: Me too.
szilles: i could live with it.
glazou: What's the option preferred by howcome?
alexmog: I'd prefer to ask him directly, but I think he was okay with
either option, and just wanted consensus.
szilles: "Treating things exactly" is how the spec is now, right?
alexmog: No, the current spec somewhat relaxes count in some situations.
It would remove 3 lines from the pseudo-algorithm.
fantasai: column-count sets a maximum number of columns when used with
column-width, so if you set both values you effectively get
a minimum width anyway.
<fantasai> You get your column count combined with a minimum width for
the columns when you set both.
alexmog: So I think we should ask howcome if he agrees with the consensus
here.
ACTION howcome to read the minutes from today and confirm if he agrees
or not with the Multicol algo consensus.
<trackbot> Created ACTION-297
<fantasai> So if there is not room for all the columns given your
column-width, the algorithm drops columns until -width is honored
<fantasai> Could even recommend that authors set -width when setting -count,
so that the columns don't get too narrow.
:active disagreement between CSS and HTML
-----------------------------------------
<fantasai> http://lists.w3.org/Archives/Public/www-style/2011Feb/0426.html
<fantasai> http://lists.w3.org/Archives/Member/w3c-css-wg/2011JanMar/0176.html
Bert: I think the trouble is the definition of the word "activate".
Bert: We thought we needed some indirection at the time of speccing, so we
just used the word "activate" and let the source language define that.
Bert: But HTML already uses the word "activate" for something else.
Bert: So this is just a wording problem. They have to invent a new word
for this or something, as the word "activate" is already taken in
that spec.
ChrisL: So it seems that HTML can just say "For CSS purpose, 'activate'
means XXX"
Bert: Right. Another option is for HTML to use a different word for what
they currently call "activate", and then use "activate" in the CSS
sense.
* fantasai has the opinion that Bert should forward his message to www-style
TabAtkins: I pinged Hixie this morning to ask him to change the wording.
ACTION TabAtkins to report back to the group on the progress of this issue.
<trackbot> Created ACTION-298
Meeting closed.
Received on Thursday, 17 February 2011 23:50:43 UTC