On Mon, Jul 12, 2010 at 22:28, David Hyatt wrote:
> On Jul 12, 2010, at 12:09 PM, Maciej Stachowiak wrote:
>
>>
>> The reason for these is historical. Originally, we didn't use a separate
>> vendor prefix for WebKit, just -khtml. Later we changed to -apple.
>
> That's not quite right. Originally
Good day,
While going through WebCore for some CSS research I'm currently doing,
I came across a piece of code[1] which translates all "-khtml-" and
"-apple-" vendor-prefixes to "-webkit-". This effectively means
"-apple-transform" and "-khtml-transform" can both be used instead of
"-webkit-transf
On Jul 12, 2010, at 12:09 PM, Maciej Stachowiak wrote:
>
> The reason for these is historical. Originally, we didn't use a separate
> vendor prefix for WebKit, just -khtml. Later we changed to -apple.
That's not quite right. Originally we just had -khtml- for CSS extensions, and
then we used
On Jul 12, 2010, at 10:44 AM, Peter Beverloo wrote:
> Right now WebKit has by far the most prefixed elements[1], a
> significant part of which have not been standardized/drafted yet.
> Keeping the translation for all properties active practically triples
> the amount of supported vendor-specific
Excuse me, I forgot to note the new bug + patch in my previous mail,
although it was listed in the references.
https://bugs.webkit.org/show_bug.cgi?id=42093
Regards,
Peter Beverloo
http://peter.sh/
On Mon, Jul 12, 2010 at 17:26, Eric Seidel wrote:
> Please post a patch:
> http://webkit.org/codi
Right now WebKit has by far the most prefixed elements[1], a
significant part of which have not been standardized/drafted yet.
Keeping the translation for all properties active practically triples
the amount of supported vendor-specific CSS extensions, which cannot
be desirable.
I'm not opposed to
The reason for these is historical. Originally, we didn't use a separate vendor
prefix for WebKit, just -khtml. Later we changed to -apple. Eventually we
realized WebKit would not be an Apple-specific project forever, so we switched
to -webkit. The main risk to removing the old prefixes is that
On Mon, Jul 12, 2010 at 9:20 AM, Peter Beverloo wrote:
> I decided to take this issue to the mailing lists before posting a
> patch for such reasons. The Apple documentation which is referred
> to[1] in that bug has been updated to use WebKit's own vendor prefix,
> so I suspect the impact of remo
On Mon, Jul 12, 2010 at 18:00, Ryosuke Niwa wrote:
>
> While converting all -khtml- properties to -webkit- may not be appropriate
> because there could be incompatible implementation of certain property, there
> are properties starting with -khtml- that are supposed to be supported by
> WebKit.
While converting all -khtml- properties to -webkit- may not be appropriate
because there could be incompatible implementation of certain property,
there are properties starting with -khtml- that are supposed to be supported
by WebKit. See bugs such as https://bugs.webkit.org/show_bug.cgi?id=11825.
Please post a patch:
http://webkit.org/coding/contributing.html
On Mon, Jul 12, 2010 at 8:25 AM, Eric Seidel wrote:
> Sounds like an easy patch to post. I'm in favor of removing this
> support. Reducing the number of non-standard CSS properties we
> support seems like a good thing.
>
> -eric
>
Sounds like an easy patch to post. I'm in favor of removing this
support. Reducing the number of non-standard CSS properties we
support seems like a good thing.
-eric
On Mon, Jul 12, 2010 at 1:53 AM, Peter Beverloo wrote:
> Good day,
>
> While going through WebCore for some CSS research I'm cu
Good day,
While going through WebCore for some CSS research I'm currently doing,
I came across a piece of code[1] which translates all "-khtml-" and
"-apple-" vendor-prefixes to "-webkit-". This effectively means
"-apple-transform" and "-khtml-transform" can both be used instead of
"-webkit-transf
13 matches
Mail list logo
