Done: https://bugs.webkit.org/show_bug.cgi?id=61096
On Wed, May 18, 2011 at 9:36 AM, Simon Fraser simon.fra...@apple.comwrote:
The best way to move forward would be to file a bug requesting that the
prefixes be removed.
Simon
On May 18, 2011, at 9:31 AM, Brady Duga wrote:
Though, in this case, the spec is at CR and has been since 2009. Is there
an additional process to removing the vendor prefixes for WebKit? So, are
they still there because no one bothered to remove them, or because the
consensus is they should remain for some reason?
--Brady
On Wed, May 18, 2011 at 7:36 AM, Simon Fraser simon.fra...@apple.comwrote:
On May 18, 2011, at 6:36 AM, Sabri Aurrelia wrote:
Why does webkit not provide support for native CSS3 attributes in its
parsing engine where those attributes clearly coincide with most other
browsers' attributes -and- the Candidate Recommendations set forth by W3?
Let me put it this way: What is the purpose of every browser having
their own nearly-identically named attributes that take the same arguments,
which are also the same as the attributes set forth in the Candidate
Recommendation?
What makes -webkit-column-gap and -moz-column-gap and column-gap
different from each other aside from the name, and if that's true, why is
there even a name difference?
Is it a waiting game? Or is it possible to take the initiative and
adopt early the attributes recommended? Is there too much risk involved in
early adoption even where there's already nearly complete consensus among
vendors?
Vendor prefixes remain on new properties until the draft spec that
describes them reaches Candidate Recommendation status.
A Google search for CSS3 vendor prefix will turn up lots of discussion
on the www-style mailing list about this.
Simon
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev