Bug 61096 – [CSS3 multi-col] Remove -webkit prefix from column properties

• Status: RESOLVED
• Resolution: CONFIGURATION CHANGED
• Component: CSS

[Brady Duga]

534+, SVN rev 86783

Since CSS3 Multi-col is now at CR (and has been for some time), it might be a good idea to provide unprefixed versions of the column properties. Specifically:


-webkit-column-break-after => break-after
-webkit-column-break-before => break-before
-webkit-column-break-inside => break-inside
-webkit-column-count => column-count
-webkit-column-gap => column-gap
-webkit-column-rule => column-rule
-webkit-column-rule-color => column-rule-color
-webkit-column-rule-style => column-rule-style
-webkit-column-rule-width => column-rule-width
-webkit-column-span => column-span
-webkit-column-width => column-width
-webkit-columns => columns

Note the 'break' properties shouldn't have 'column' in their names. I don't know enough about the details of the -webkit-prefixed properties to know if they adequately conform to the current spec, so it is entirely possible this request is premature.

[Eric Seidel (no email)]

I assume there is a test suite with with to test our conformance?

[Brady Duga]

I thought one had been started, but now I am not seeing it. A test suite is part of the CR exit criteria (to REC), so I wouldn't necessarily expect one at the moment. Since CSS guidance is prefixes can be dropped at CR, it's not clear that passing a test suite is a required step. Of course, it could be a required step in the *WebKit* process to drop prefixes, in which case this request may be premature.

[Ojan Vafai]

In this specific case, I believe that WebKit's multicolumn implementation has many bugs (e.g. https://bugs.webkit.org/buglist.cgi?quicksearch=multi-column). I'd be hesitant to remove the prefix before we were a little more confident that we're matching the spec, which is where a test suite would help.

[Brady Duga]

I will let someone with more knowledge here speak up, though looking at that list, one of them is this bug, one of them is a master tracking bug for paged media, and at least 3 of them claim to be fixed in their comments, though they are marked as "new".

[Brady Duga]

Just to follow up on the previous question about tests, it looks like a test suite is currently under development. See http://lists.w3.org/Archives/Public/www-style/2011May/0512.html

[Brady Duga]

I spent a little time today looking at the syntax for the various -webkit-column- properties compared to the current CR of the multi-column spec. It appears that they are largely consistent, with a few minor problems, detailed here:

1. -webkit-column-width allows 0 and negative values, which are forbidden in the spec.

2. -webkit-column-count allows 0, which is forbidden in the spec

3. -webkit-column-break-before/after have had the -column- dropped, though that isn't really a problem if we are renaming

4. -webkit-break-before/after are missing the values |page|, |column|, |avoid-page| and |avoid-column|. However, it appear these properties are ignored now anyway (they don't seem to do anything about column breaks) so that may not be a concern.

5. -webkit-column-break-inside is missing |avoid-page| and |avoid-column|. Same lack on concern applies here as in #4.

6. -webkit-column-span accepts the values |all| and 1, but the current spec says |all| and |none|. I think |none| and 1 are meant to be the same. Once again, hard to notice since it doesn't appear that spanning more then 1 column is supported (1, |none| and |all| behave the same way).

It seems not unreasonable to proceed with adding non -webkit- prefixed versions of the various properties as it is more likely to help with their adoption and will make use of webkit for non-browsers purposes easier (eg, ePub 3 where the column properties have no prefix). Two objections have been raised so far, that there are bugs in the current implementation and there are no tests to validate our conformance to the spec. As far as I know, neither of those reasons speaks against changing the property names, at least not from a CSS conformance perspective. The purpose of the embargo on unprefixed property names is to allow the CSS WG a free hand in renaming and redefining behavior. Since the current implementation seems close with regards to the specs syntax, I am not sure there is a reason to maintain the prefix. If we required that all properties carry a UA prefix until all bugs/most were resolved, the Web would be a painful place. That said, I may not be aware of a formal (or informal) process for removing the prefix in the WebKit community, so there may be reasons to maintain it.

Are there any further thoughts on whether this is a good idea or not?

[Theresa O'Connor]

The CSS WG has recently tightened the conditions under which UAs should drop prefixes. See http://www.w3.org/TR/css-2010/#testing for the current policy.

Given this, I think it's premature for us to drop prefixes.

[Brady Duga]

Good point - I didn't realize those changes had been made. Guess this will have to wait for the test suite.

[Brent Fulgham]

It looks like we have made this change in a separate bug.