[webkit-dev] Why vendor-specific attributes in CSS3 parsing engine?
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? --M.Pemrich Matthew A. Pemrich ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Why vendor-specific attributes in CSS3 parsing engine?
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
Re: [webkit-dev] Why vendor-specific attributes in CSS3 parsing engine?
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
Re: [webkit-dev] Why vendor-specific attributes in CSS3 parsing engine?
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.com wrote: 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
Re: [webkit-dev] Why vendor-specific attributes in CSS3 parsing engine?
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
