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

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=61096





--- Comment #6 from Brady Duga <duga+wk-bugzilla at google.com>  2011-06-08 15:32:53 PST ---
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?

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.