W3C home > Mailing lists > Public > www-style@w3.org > February 2011

[CSSWG] Minutes and Resolutions 2011-02-17

From: fantasai <fantasai.lists@inkedblade.net>
Date: Thu, 17 Feb 2011 15:50:09 -0800
Message-ID: <4D5DB431.2050106@inkedblade.net>
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 GMT

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