headers
Giovanni Campagna | 1 Jul 2009 15:19
Picon
Gravatar

Comments on css3-multicol

The following are comments to the yesterday (30/06) css3-multicol Last Call WD.

1) The title is still "CSS3 module: Multi-column layout"

Hadn't the WG decided to adopt consistent naming and in particular to
avoid saying CSS3?

If yes, it should be called "CSS Multi-column Layout Module" or "CSS
Multi-column Layout Module Level 3" (although I guess that Level 3 is
only for features that did exist in level 2)

2) About column-rule-color:
Why UAs are required only to support CSS2 colors?
If the goal is to avoid the burden of hsl / rgba / SVG colors,
shouldn't that be delegated to a reduced profile?

3) About column breaks

    3.a) At the beginning of section 5, replace desrciption with description

    3.b) Is it possible to avoid a column break while still allow a page break?
Is the intended effect like:

----------------------------------
| a bcd efg hij |                |
| lmn opq rst u |                |

/ page break, but content remains in the same column /

| rst uvw xyz ab|                |
(Continue reading)

Permalink | Reply | 5 comments |
headers
Håkon Wium Lie | 1 Jul 2009 15:58
Picon
Favicon

Re: Comments on css3-multicol

Also sprach Giovanni Campagna:

 > The following are comments to the yesterday (30/06) css3-multicol Last Call WD.

Thanks for your comments. I should have announced the draft to the
list, but I'm in a tight space bandwidth-wise at the moment and didn't
know that the last call draft had been published. 

The draft is here:

  http://www.w3.org/TR/2009/WD-css3-multicol-20090630/

The Last Call period ends on 1 October 2009.

Cheers,

-h&kon
              Håkon Wium Lie                          CTO °þe®ª
howcome <at> opera.com                  http://people.opera.com/howcome
Permalink | Reply | 0 comments |
headers
Bert Bos | 1 Jul 2009 19:32
Picon
Favicon

[css3-multicol] last call for comments on CSS Multi-column module

As some people already discovered, the CSS WG published a new draft of 
the multi-column module yesterday:

    http://www.w3.org/TR/2009/WD-css3-multicol-20090630/

This is a "last call," i.e., we are inviting comments for hopefully the 
last time before Candidate Recommendation. So, please, review the draft 
and tell us if we've missed any problems...

As usual, the preferred place for comments is this mailing list, 
<www-style <at> w3.org>. Please, prefix the subject of your message with

    [css3-multicol]

as I did on this message.

The previous draft was from 2007. The column-break properties from that 
draft have been removed, in favor of a unified definition of column and 
page breaks in the Paged Media module. The other properties are 
unchanged, except that their definitions have been completed and made 
more precise.

Bert
--

-- 
  Bert Bos                                ( W 3 C ) http://www.w3.org/
  http://www.w3.org/people/bos                               W3C/ERCIM
  bert <at> w3.org                             2004 Rt des Lucioles / BP 93
  +33 (0)4 92 38 76 92            06902 Sophia Antipolis Cedex, France
(Continue reading)

Permalink | Reply | 0 comments |
headers
Bert Bos | 1 Jul 2009 19:37
Picon
Favicon

[css3-multicol] Dangling example of column-break

I just noticed that there is still an example (example VI) in the 
non-normative section 1 that we forgot to delete, when we removed 
the 'column-break-*' properties from the draft.

Bert
--

-- 
  Bert Bos                                ( W 3 C ) http://www.w3.org/
  http://www.w3.org/people/bos                               W3C/ERCIM
  bert <at> w3.org                             2004 Rt des Lucioles / BP 93
  +33 (0)4 92 38 76 92            06902 Sophia Antipolis Cedex, France
Permalink | Reply | 1 comment |
headers
L. David Baron | 2 Jul 2009 01:48
Gravatar

[css3-transitions] animation of color values should mention premultiplication

http://dev.w3.org/csswg/css3-transitions/#animation-of-property-types-
currently says:
  # color: interpolated via red, green, blue and alpha components
  # (treating each as a number, see below). 

This bullet point should probably mention that the red, green, and
blue values should NOT be premultiplied with the alpha.  (I think
that's the correct behavior, anyway.)

-David

--

-- 
L. David Baron                                 http://dbaron.org/
Mozilla Corporation                       http://www.mozilla.com/
Permalink | Reply | 1 comment |
headers
Dirk Pranke | 2 Jul 2009 08:28
Picon
Favicon

question on width calculation for floats and tables nested inside a div

Hi all,

In the course of investigating a bug in WebKit, I've run across some
ambiguity on how to render tables sized at width:100% inside a div
that also has a float in it.

That sentence is a bit hard to parse, so this is best illustrated by
looking at the example:
https://bugs.webkit.org/attachment.cgi?id=32157

The relevant part of the CSS spec is section 9.5, paragraph 3:

"The border box of a table, a block-level replaced element, or an
element in the normal flow that establishes a new block formatting
context (such as an element with 'overflow' other than 'visible') must
not overlap any floats in the same block formatting context as the
element itself. If necessary, implementations should clear the said
element by placing it below any preceding floats, but may place it
adjacent to such floats if there is sufficient space. They may even
make the border box of said element narrower than defined by section
10.3.3. CSS2 does not define when a UA may put said element next to
the float or by how much said element may become narrower."

but how are we defining "sufficient space" The block formatting
context or the current containing block?

In my interpretation, option #1 is probably what everyone should be
doing (but no one does). Anyone want to give reasons as to why options
#2 or #3 make more sense?
(Continue reading)

Permalink | Reply | 3 comments |
headers
David Hyatt | 2 Jul 2009 18:42
Picon
Favicon

Re: question on width calculation for floats and tables nested inside a div

On Jul 2, 2009, at 1:28 AM, Dirk Pranke wrote:

> Hi all,
>
> In the course of investigating a bug in WebKit, I've run across some
> ambiguity on how to render tables sized at width:100% inside a div
> that also has a float in it.
>
> That sentence is a bit hard to parse, so this is best illustrated by
> looking at the example:
> https://bugs.webkit.org/attachment.cgi?id=32157
>
> The relevant part of the CSS spec is section 9.5, paragraph 3:
>
> "The border box of a table, a block-level replaced element, or an
> element in the normal flow that establishes a new block formatting
> context (such as an element with 'overflow' other than 'visible') must
> not overlap any floats in the same block formatting context as the
> element itself. If necessary, implementations should clear the said
> element by placing it below any preceding floats, but may place it
> adjacent to such floats if there is sufficient space. They may even
> make the border box of said element narrower than defined by section
> 10.3.3. CSS2 does not define when a UA may put said element next to
> the float or by how much said element may become narrower."
>
> but how are we defining "sufficient space" The block formatting
> context or the current containing block?
>
> In my interpretation, option #1 is probably what everyone should be
> doing (but no one does). Anyone want to give reasons as to why options
(Continue reading)

Permalink | Reply | 0 comments |
headers
L. David Baron | 2 Jul 2009 19:09
Gravatar

Re: question on width calculation for floats and tables nested inside a div

On Thursday 2009-07-02 06:28 +0000, Dirk Pranke wrote:
> That sentence is a bit hard to parse, so this is best illustrated by
> looking at the example:
> https://bugs.webkit.org/attachment.cgi?id=32157

> In my interpretation, option #1 is probably what everyone should be
> doing (but no one does). Anyone want to give reasons as to why options
> #2 or #3 make more sense?

I think option #3 is the correct behavior.

After a quick glance at the relevant Gecko code, I don't see why
it's doing #2 rather than #3.  It wouldn't surprise me if it was
because we ran into compatibility problems somewhere, but it also
wouldn't surprise me if it was an accident.

The reason option #1 (and, in general, making width calculation
depend on the available space next to floats) is bad is that it
tends to produce layouts that vary in extremely unstable ways under
resizing.  For example, a series of floats that, without that
behavior, would wrap into multiple "lines":

     +-----+ +-----+ +-----+ +-----+
     |     | |     | |     | |     |
     +-----+ +-----+ +-----+ +-----+
     +-----+ +-----+ +-----+
     |     | |     | |     |
     +-----+ +-----+ +-----+

might, with width calculations that depend on the available space
(Continue reading)

Permalink | Reply | 0 comments |
headers
fantasai | 2 Jul 2009 20:32

[CSSWG] Minutes and Resolutions 2009-07-01

Summary:

   - Multicol has been published
   - Flexbox and Image Values to be published as FPWD
   - RESOLVED: accept that overflow: visible does not allow
               replaced content to overflow
               css3-background and css3-page to be updated

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

Present:
   David Baron
   Bert Bos
   Arron Eicholz
   Elika Etemad
   Sylvain Galineau
   Daniel Glazman?
   Alex Mogilevsky
   Peter Linss

<RRSAgent> logging to http://www.w3.org/2009/07/01-CSS-irc

Agenda
------

   Bert: Multicol has already been published
   <dbaron> Regrets: Øyvind Stenhaug, Anne van Kesteren, Dave Singer,
                     Tona Henderson, Håkon Wium Lie, Steve Zilles,
                     César Acebal, Molly Holzschlag
   <arronei> I'm here on IRC and will be on the call in 5 minutes or so
(Continue reading)

Permalink | Reply | 5 comments |
headers
David Hyatt | 2 Jul 2009 21:08
Picon
Favicon

Re: [CSSWG] Minutes and Resolutions 2009-07-01

On Jul 2, 2009, at 1:32 PM, fantasai wrote:

>  RESOLVED: accept that overflow: visible does not allow replaced  
> content
>            to overflow
>

Just so I understand, you're saying that images should be clipped to  
border-radius even when overflow is visible?  I need to make changes  
to WebKit if so.

dave
(hyatt <at> apple.com)
Permalink | Reply | 3 comments |

Gmane