[webkit-dev] Removing support for the -khtml- (and -apple-?) vendor prefixes

2010-07-12 Thread Peter Beverloo
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-transform. I am unaware of the rationales behind the apple
vendor-prefix, but I'd like to propose removing support for the
KHTML-prefix.

My main argument for this is that WebKit and KHTML are, in my opinion,
two separate engines by two separate vendors. The port occurred eight
years ago, and code in both projects has changed significantly ever
since. When Microsoft announced support for -webkit-text-size-adjust
in IE Mobile it was argued that browsers should not implement
properties with prefixes belonging to other vendors, which seems to
be exactly what WebKit is doing with the KHTML prefix.

I understand the history of supporting -khtml-, and have heard from
the KHTML project that they implement the -webkit- prefix as well.
However, considering that WebKit has grown significantly in the past
few years and that all code changes basically made KHTML and WebKit
two individual rendering engines, with individual CSS support, I
believe it would be appropriate for support to be dropped.

Regards,
Peter Beverloo
http://peter.sh/

[1] http://trac.webkit.org/browser/trunk/WebCore/css/CSSParser.cpp#L5583
[2] 
http://blogs.msdn.com/b/iemobile/archive/2010/05/10/javascript-and-css-changes-in-ie-mobile-for-windows-phone-7.aspx
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


[webkit-dev] Remove me from your mailing list..

2010-07-12 Thread Johnson, Christopher
Please remove me from your mailing list.

 

Thanks.

 

V/R,

 

Christopher Johnson | SAIC

Electronic Technician 1 | Defense Solutions Group

Office: 843-218-3064 | Fax 843-218-7727

Cell: 843-532-4285 | NIPR: christopher.john...@saic.com

 

Science Applications International Corporation

1545 Truxton Ave.

Charleston, SC 29405

www.saic.com http://www.saic.com/ 

 



smime.p7s
Description: S/MIME cryptographic signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Remove me from your mailing list..

2010-07-12 Thread Jeremy Orlow
Seriously?  It's the first result: http://www.lmgtfy.com/?q=webkit-dev

Clearly you overly value your own time if you couldn't even do a quick
search on how to properly unsubscribe and instead spammed an entire mailing
list.

J

On Mon, Jul 12, 2010 at 11:23 AM, Johnson, Christopher 
christopher.john...@saic.com wrote:

  *Please remove me from your mailing list.*

 * *

 *Thanks…*

 * *

 *V/R,*

 * *

 *Christopher Johnson* | *SAIC*

 Electronic Technician 1 | Defense Solutions Group

 Office: 843-218-3064 | Fax 843-218-7727

 Cell: 843-532-4285 | *NIPR:* *christopher.john...@saic.com*



 *Science Applications International Corporation*

 1545 Truxton Ave.

 Charleston, SC 29405

 *www.saic.com***



 ___
 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


[webkit-dev] Exposing FileReader to a worker

2010-07-12 Thread David Sanders
Hi all,

I'm trying to expose the FileReader class to workers but am having a bit of
trouble doing so.  Initially I've tried to simply add FileReaderConstructor
to WorkerContext.idl but still could not create a file reader from a worker.

Afterwards, I read through the source and saw that the
XMLHttpRequestConstructor is defined by returning the result from
getDOMConstructor() in JSWorkerContext.  I tried the same for FileReader but
am getting the following when trying to compile:

error: no matching function for call to ‘getDOMConstructor(JSC::ExecState*,
const WebCore::JSWorkerContext* const)’

Regards,
David
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Exposing FileReader to a worker

2010-07-12 Thread David Sanders
Sorry I forgot to ask whether anyone knew what was required to add a class
to a worker context.  ;)

David
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Removing support for the -khtml- (and -apple-?) vendor prefixes

2010-07-12 Thread Eric Seidel
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 pe...@lvp-media.com wrote:
 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-transform. I am unaware of the rationales behind the apple
 vendor-prefix, but I'd like to propose removing support for the
 KHTML-prefix.

 My main argument for this is that WebKit and KHTML are, in my opinion,
 two separate engines by two separate vendors. The port occurred eight
 years ago, and code in both projects has changed significantly ever
 since. When Microsoft announced support for -webkit-text-size-adjust
 in IE Mobile it was argued that browsers should not implement
 properties with prefixes belonging to other vendors, which seems to
 be exactly what WebKit is doing with the KHTML prefix.

 I understand the history of supporting -khtml-, and have heard from
 the KHTML project that they implement the -webkit- prefix as well.
 However, considering that WebKit has grown significantly in the past
 few years and that all code changes basically made KHTML and WebKit
 two individual rendering engines, with individual CSS support, I
 believe it would be appropriate for support to be dropped.

 Regards,
 Peter Beverloo
 http://peter.sh/

 [1] http://trac.webkit.org/browser/trunk/WebCore/css/CSSParser.cpp#L5583
 [2] 
 http://blogs.msdn.com/b/iemobile/archive/2010/05/10/javascript-and-css-changes-in-ie-mobile-for-windows-phone-7.aspx
 ___
 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] Removing support for the -khtml- (and -apple-?) vendor prefixes

2010-07-12 Thread Eric Seidel
Please post a patch:
http://webkit.org/coding/contributing.html

On Mon, Jul 12, 2010 at 8:25 AM, Eric Seidel e...@webkit.org 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

 On Mon, Jul 12, 2010 at 1:53 AM, Peter Beverloo pe...@lvp-media.com wrote:
 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-transform. I am unaware of the rationales behind the apple
 vendor-prefix, but I'd like to propose removing support for the
 KHTML-prefix.

 My main argument for this is that WebKit and KHTML are, in my opinion,
 two separate engines by two separate vendors. The port occurred eight
 years ago, and code in both projects has changed significantly ever
 since. When Microsoft announced support for -webkit-text-size-adjust
 in IE Mobile it was argued that browsers should not implement
 properties with prefixes belonging to other vendors, which seems to
 be exactly what WebKit is doing with the KHTML prefix.

 I understand the history of supporting -khtml-, and have heard from
 the KHTML project that they implement the -webkit- prefix as well.
 However, considering that WebKit has grown significantly in the past
 few years and that all code changes basically made KHTML and WebKit
 two individual rendering engines, with individual CSS support, I
 believe it would be appropriate for support to be dropped.

 Regards,
 Peter Beverloo
 http://peter.sh/

 [1] http://trac.webkit.org/browser/trunk/WebCore/css/CSSParser.cpp#L5583
 [2] 
 http://blogs.msdn.com/b/iemobile/archive/2010/05/10/javascript-and-css-changes-in-ie-mobile-for-windows-phone-7.aspx
 ___
 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] Removing support for the -khtml- (and -apple-?) vendor prefixes

2010-07-12 Thread Peter Beverloo
On Mon, Jul 12, 2010 at 18:00, Ryosuke Niwa rn...@webkit.org 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.  See bugs such as https://bugs.webkit.org/show_bug.cgi?id=11825.  Not 
 supporting these will be a burden for some Web developers as they need to add 
 both -khtml- and -webkit- to specify one property.
 Best,
 Ryosuke Niwa

 On Mon, Jul 12, 2010 at 1:53 AM, Peter Beverloo pe...@lvp-media.com wrote:

 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-transform. I am unaware of the rationales behind the apple
 vendor-prefix, but I'd like to propose removing support for the
 KHTML-prefix.

 My main argument for this is that WebKit and KHTML are, in my opinion,
 two separate engines by two separate vendors. The port occurred eight
 years ago, and code in both projects has changed significantly ever
 since. When Microsoft announced support for -webkit-text-size-adjust
 in IE Mobile it was argued that browsers should not implement
 properties with prefixes belonging to other vendors, which seems to
 be exactly what WebKit is doing with the KHTML prefix.

 I understand the history of supporting -khtml-, and have heard from
 the KHTML project that they implement the -webkit- prefix as well.
 However, considering that WebKit has grown significantly in the past
 few years and that all code changes basically made KHTML and WebKit
 two individual rendering engines, with individual CSS support, I
 believe it would be appropriate for support to be dropped.

 Regards,
 Peter Beverloo
 http://peter.sh/

 [1] http://trac.webkit.org/browser/trunk/WebCore/css/CSSParser.cpp#L5583
 [2] 
 http://blogs.msdn.com/b/iemobile/archive/2010/05/10/javascript-and-css-changes-in-ie-mobile-for-windows-phone-7.aspx
 ___
 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


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 removing -khtml- will be rather small.
After all, that regression happened about four years ago.

I will upload a patch within a few hours.

Regards,
Peter Beverloo
http://peter.sh/

[1] 
http://developer.apple.com/mac/library/documentation/AppleApplications/Conceptual/SafariJSProgTopics/Tasks/DragAndDrop.html
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Removing support for the -khtml- (and -apple-?) vendor prefixes

2010-07-12 Thread Ryosuke Niwa
On Mon, Jul 12, 2010 at 9:20 AM, Peter Beverloo pe...@lvp-media.com 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 removing -khtml- will be rather small.
 After all, that regression happened about four years ago.


You'll hope.  There was a incident about a year ago where MediaWiki had a
work-around for a very old KHTML bug and we had to add a special work around
for MediaWiki for the compatibility. (See
https://bugs.webkit.org/show_bug.cgi?id=28350).  Later, we found that there
are various websites that uses 3 years old or older copies of MediaWiki.
 I'm very afraid that the change you  proposed will cause many problems like
that.

But don't take me wrong, I like your idea.  I'm just saying we have to be
extra careful.

Best,
Ryosuke
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Removing support for the -khtml- (and -apple-?) vendor prefixes

2010-07-12 Thread Maciej Stachowiak

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 some older 
WebKit-specific content authored against them will break. I'm not sure the code 
cleanup benefits outweigh the risk of breaking content.

If we want to phase out support for these older prefixes, what I'd propose as a 
first step is supporting the legacy prefixes for old properties but not for any 
new ones.

Regards,
Maciej

On Jul 12, 2010, at 1:53 AM, Peter Beverloo wrote:

 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-transform. I am unaware of the rationales behind the apple
 vendor-prefix, but I'd like to propose removing support for the
 KHTML-prefix.
 
 My main argument for this is that WebKit and KHTML are, in my opinion,
 two separate engines by two separate vendors. The port occurred eight
 years ago, and code in both projects has changed significantly ever
 since. When Microsoft announced support for -webkit-text-size-adjust
 in IE Mobile it was argued that browsers should not implement
 properties with prefixes belonging to other vendors, which seems to
 be exactly what WebKit is doing with the KHTML prefix.
 
 I understand the history of supporting -khtml-, and have heard from
 the KHTML project that they implement the -webkit- prefix as well.
 However, considering that WebKit has grown significantly in the past
 few years and that all code changes basically made KHTML and WebKit
 two individual rendering engines, with individual CSS support, I
 believe it would be appropriate for support to be dropped.
 
 Regards,
 Peter Beverloo
 http://peter.sh/
 
 [1] http://trac.webkit.org/browser/trunk/WebCore/css/CSSParser.cpp#L5583
 [2] 
 http://blogs.msdn.com/b/iemobile/archive/2010/05/10/javascript-and-css-changes-in-ie-mobile-for-windows-phone-7.aspx
 ___
 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] Removing support for the -khtml- (and -apple-?) vendor prefixes

2010-07-12 Thread Peter Beverloo
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 idea of limiting the supported properties for
these prefixes to a certain subset, but my preference would be to only
support behavioral properties as -webkit-binding,
-webkit-font-smoothing, -webkit-highlight and
-webkit-user-(drag|modify|select). In the same piece of code,
prefixed versions of border-radixes and opacity are still supported as
well. Although I think the latter of which could be removed as well,
considering Safari 1.1 got released in 2003.

Regards,
Peter Beverloo
http://peter.sh/

[1] http://peter.sh/examples/?/css/vendor-prefix.html
[2] https://bugs.webkit.org/show_bug.cgi?id=42093

On Mon, Jul 12, 2010 at 19:09, Maciej Stachowiak m...@apple.com 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. 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 some 
 older WebKit-specific content authored against them will break. I'm not sure 
 the code cleanup benefits outweigh the risk of breaking content.

 If we want to phase out support for these older prefixes, what I'd propose as 
 a first step is supporting the legacy prefixes for old properties but not for 
 any new ones.

 Regards,
 Maciej

 On Jul 12, 2010, at 1:53 AM, Peter Beverloo wrote:

 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-transform. I am unaware of the rationales behind the apple
 vendor-prefix, but I'd like to propose removing support for the
 KHTML-prefix.

 My main argument for this is that WebKit and KHTML are, in my opinion,
 two separate engines by two separate vendors. The port occurred eight
 years ago, and code in both projects has changed significantly ever
 since. When Microsoft announced support for -webkit-text-size-adjust
 in IE Mobile it was argued that browsers should not implement
 properties with prefixes belonging to other vendors, which seems to
 be exactly what WebKit is doing with the KHTML prefix.

 I understand the history of supporting -khtml-, and have heard from
 the KHTML project that they implement the -webkit- prefix as well.
 However, considering that WebKit has grown significantly in the past
 few years and that all code changes basically made KHTML and WebKit
 two individual rendering engines, with individual CSS support, I
 believe it would be appropriate for support to be dropped.

 Regards,
 Peter Beverloo
 http://peter.sh/

 [1] http://trac.webkit.org/browser/trunk/WebCore/css/CSSParser.cpp#L5583
 [2] 
 http://blogs.msdn.com/b/iemobile/archive/2010/05/10/javascript-and-css-changes-in-ie-mobile-for-windows-phone-7.aspx
 ___
 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] Removing support for the -khtml- (and -apple-?) vendor prefixes

2010-07-12 Thread Peter Beverloo
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 e...@webkit.org wrote:
 Please post a patch:
 http://webkit.org/coding/contributing.html

 On Mon, Jul 12, 2010 at 8:25 AM, Eric Seidel e...@webkit.org 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

 On Mon, Jul 12, 2010 at 1:53 AM, Peter Beverloo pe...@lvp-media.com wrote:
 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-transform. I am unaware of the rationales behind the apple
 vendor-prefix, but I'd like to propose removing support for the
 KHTML-prefix.

 My main argument for this is that WebKit and KHTML are, in my opinion,
 two separate engines by two separate vendors. The port occurred eight
 years ago, and code in both projects has changed significantly ever
 since. When Microsoft announced support for -webkit-text-size-adjust
 in IE Mobile it was argued that browsers should not implement
 properties with prefixes belonging to other vendors, which seems to
 be exactly what WebKit is doing with the KHTML prefix.

 I understand the history of supporting -khtml-, and have heard from
 the KHTML project that they implement the -webkit- prefix as well.
 However, considering that WebKit has grown significantly in the past
 few years and that all code changes basically made KHTML and WebKit
 two individual rendering engines, with individual CSS support, I
 believe it would be appropriate for support to be dropped.

 Regards,
 Peter Beverloo
 http://peter.sh/

 [1] http://trac.webkit.org/browser/trunk/WebCore/css/CSSParser.cpp#L5583
 [2] 
 http://blogs.msdn.com/b/iemobile/archive/2010/05/10/javascript-and-css-changes-in-ie-mobile-for-windows-phone-7.aspx
 ___
 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] Bugzilla Question - Master Bug vs Component?

2010-07-12 Thread Beth Dakin

On Jul 10, 2010, at 1:17 AM, Alex Milowski wrote:

 I would think we'd close it when we've actually completely implemented
 MathML.  

If this is what you want the bug to represent, then it does make sense to keep 
all feature-implementation bugs related to this master bug, but none of the bug 
bugs…if that makes any sense.The bug bugs should be in the MathML component, 
but they shouldn't block the feature-complete bug.

 Just
 enabling it seems like something we could do now but our implementation is
 quite impoverished with respect to MathML 3.0.

I think we should consider enabling MathML. Just because we don't have MathML 
3.0 implemented yet doesn't mean we need to keep it off; there was a time when 
we didn't have any CSS 3 implemented, but that didn't mean our CSS 
implementation had to be turned off! I have been playing around with a 
MathML-enabled build, and I feel like we do a pretty good job getting a lot of 
MathML on the web right, and I haven't experienced any crashes in the MathML 
code either. And if we turn it on, more people will test it, and that is just 
plain helpful. Just my opinion!

-Beth
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Bugzilla Question - Master Bug vs Component?

2010-07-12 Thread Sausset François
Le 12 juil. 2010 à 21:01, Beth Dakin a écrit :

 
 On Jul 10, 2010, at 1:17 AM, Alex Milowski wrote:
 
 I would think we'd close it when we've actually completely implemented
 MathML.  
 
 If this is what you want the bug to represent, then it does make sense to 
 keep all feature-implementation bugs related to this master bug, but none of 
 the bug bugs…if that makes any sense.The bug bugs should be in the MathML 
 component, but they shouldn't block the feature-complete bug.
 
 Just
 enabling it seems like something we could do now but our implementation is
 quite impoverished with respect to MathML 3.0.
 
 I think we should consider enabling MathML. Just because we don't have MathML 
 3.0 implemented yet doesn't mean we need to keep it off; there was a time 
 when we didn't have any CSS 3 implemented, but that didn't mean our CSS 
 implementation had to be turned off! I have been playing around with a 
 MathML-enabled build, and I feel like we do a pretty good job getting a lot 
 of MathML on the web right, and I haven't experienced any crashes in the 
 MathML code either. And if we turn it on, more people will test it, and that 
 is just plain helpful. Just my opinion!
 

Opinion that I share!
But I think that Alex was not meaning to wait until a full support of MathML 3.

François Sausset

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Removing support for the -khtml- (and -apple-?) vendor prefixes

2010-07-12 Thread Maciej Stachowiak

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 CSS extensions, which cannot
 be desirable.
 
 I'm not opposed to the idea of limiting the supported properties for
 these prefixes to a certain subset, but my preference would be to only
 support behavioral properties as -webkit-binding,
 -webkit-font-smoothing, -webkit-highlight and
 -webkit-user-(drag|modify|select). In the same piece of code,
 prefixed versions of border-radixes and opacity are still supported as
 well. Although I think the latter of which could be removed as well,
 considering Safari 1.1 got released in 2003.

WebKit really uses vendor-prefixed properties for a few different purposes:

1) Properties that are only intended to be used internal to the engine, to 
implement particular effects.
2) Properties that are future CSS standards but not yet mature enough to remove 
the prefix.
3) Experimental properties that may be proposed as standards in the future.
4) Proprietary properties that we don't intend to standardize, but which can be 
used by content.
5) Properties that were once prefixed for one of the above reasons, and we keep 
the prefixed version in addition to the unprefixed one.

One beneficial exercise would be to classify prefixed properties into the above 
buckets. For categories (3) and (4), we should consider whether the properties 
in question can actually be proposed as standards, and therefore move to 
category (2). For category (5), we should assess the compatibility impact of 
removing the prefixed version.

Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Bugzilla Question - Master Bug vs Component?

2010-07-12 Thread Maciej Stachowiak

On Jul 12, 2010, at 11:01 AM, Beth Dakin wrote:

 
 On Jul 10, 2010, at 1:17 AM, Alex Milowski wrote:
 
 I would think we'd close it when we've actually completely implemented
 MathML.  
 
 If this is what you want the bug to represent, then it does make sense to 
 keep all feature-implementation bugs related to this master bug, but none of 
 the bug bugs…if that makes any sense.The bug bugs should be in the MathML 
 component, but they shouldn't block the feature-complete bug.
 
 Just
 enabling it seems like something we could do now but our implementation is
 quite impoverished with respect to MathML 3.0.
 
 I think we should consider enabling MathML. Just because we don't have MathML 
 3.0 implemented yet doesn't mean we need to keep it off; there was a time 
 when we didn't have any CSS 3 implemented, but that didn't mean our CSS 
 implementation had to be turned off! I have been playing around with a 
 MathML-enabled build, and I feel like we do a pretty good job getting a lot 
 of MathML on the web right, and I haven't experienced any crashes in the 
 MathML code either. And if we turn it on, more people will test it, and that 
 is just plain helpful. Just my opinion!

I think it's fine to enable MathML soon, as long as we make sure of the 
following:

1) Using a MathML-enabled build shouldn't cause stability problems or 
functional or performance regressions when browsing ordinary non-MathML content.
2) We should try to do some fuzz testing to verify that MathML doesn't create 
security risks.

#2 can happen after we enable MathML, but should probably happen before anyone 
ships it.

Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Removing support for the -khtml- (and -apple-?) vendor prefixes

2010-07-12 Thread David Hyatt
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 -apple- for features that we were Apple-specific, i.e., that we 
knew nobody else would care about.  Those features include Dashboard regions 
and Safari RSS line clamping).  Eventually we just decided to merge both into a 
common prefix, but we wanted to keep the old property names working for 
compatibility.   It was convenient to just map both to -webkit- rather than 
actually checking the specific property names and only supporting either 
-khtml- or -apple-.

My recommendation would be as follows:
(1) Drop support for -khtml- completely.
(2) Continue to support -apple- for -apple-dashboard-region and 
-apple-line-clamp only.

dave
(hy...@apple.com)

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


[webkit-dev] Removing support for the -khtml- (and -apple-?) vendor prefixes

2010-07-12 Thread Peter Beverloo
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-transform. I am unaware of the rationales behind the apple
vendor-prefix, but I'd like to propose removing support for the
KHTML-prefix.

My main argument for this is that WebKit and KHTML are, in my opinion,
two separate engines by two separate vendors. The port occurred eight
years ago, and code in both projects has changed significantly ever
since. When Microsoft announced support for -webkit-text-size-adjust
in IE Mobile it was argued that browsers should not implement
properties with prefixes belonging to other vendors, which seems to
be exactly what WebKit is doing with the KHTML prefix.

I understand the history of supporting -khtml-, and I've heard from
the KHTML project that they implement the -webkit- prefix as well.
However, considering that WebKit has grown significantly in the past
few years and that all code changes basically made KHTML and WebKit
two individual rendering engines with individual CSS support, I
believe it would be appropriate for support to be dropped.

Regards,
Peter Beverloo
http://peter.sh/

[1] http://trac.webkit.org/browser/trunk/WebCore/css/CSSParser.cpp#L5583
[2] 
http://blogs.msdn.com/b/iemobile/archive/2010/05/10/javascript-and-css-changes-in-ie-mobile-for-windows-phone-7.aspx
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] HTML5 MathML3 entities

2010-07-12 Thread Mike Marchywka
















 From: aba...@webkit.org
 Date: Sun, 11 Jul 2010 16:33:57 -0700
 To: m...@apple.com
 CC: webkit-dev@lists.webkit.org
 Subject: Re: [webkit-dev] HTML5  MathML3 entities

 On Sat, Jul 10, 2010 at 6:28 PM, Maciej Stachowiak  wrote:
 On Jul 10, 2010, at 11:10 AM, Sausset François wrote:
 I just saw that when looking at the code by myself.
 What do you exactly mean by a prefix tree?

 The data structure commonly called a Trie is a prefix tree:
 http://en.wikipedia.org/wiki/Trie

Never missing a chance to reveal my ignorance, I didn't know these had a name.
However, I am using a prefix tree to store URL's in our browser cache.
I did keep vaciliating over redundant hashes and linked lists as well as 
explicit
copies of complete keys (uh, I don't want to explain now ). As pointed
out, this helps eliminated redundnant prefixes ( http:// may come uip a lot ).
Also of course memory coherence options proliferate if you start thinking
about things like this. 


 This data structure not only lets you tell if a particular key is present, 
 but it also lets you check if a string you have could possibly be the prefix 
 of any valid key.

 I think it is challenging, though, to make a trie structure that can be a 
 compile-time constant, and building one dynamically will cost runtime memory 
 per-process (whereas constant data would be in the data segment and shared).

 Another possibility is to make an array of all the entity names in sorted 
 order. Then lookup can use a binary search, and on a failed lookup, looking 
 to either side of the last key checked should determine whether it is a 
 valid prefix.

 I expect binary search would be slower than Trie lookup, though I don't know 
 by how much.

 Binary search will certainly be easier to implement. Let's start with
 that and experiment with prefix trees as a possible performance
 optimization. I'll give it a try now.

When I did this, I wrote the code in java but made heavy use of conditioanl 
compilation
to get it to work on j2me or j2se. This proved to be invaluable since lots of 
subtle low
probability errors can occur and debugging in target setting ( a phone) would 
have taken forever.
Certainly with java simple things can be surprisingly slow ( like recreating a 
key from pieces if
you need to do it a lot) but with things that translate to native code this may 
be
easier to optimize. 

Also, I'm not sure about the wiki speed analysis. If you do simple string 
compares on highly
redundant keys, you spend a lot of time comparing http://www.; to 
http:///www.; etc/
Fail fast equality compares as well as memory compaction could offer many 
benefits.  
Its too early for me to think about Orders and logs LOL. 


 Adam
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
  
_
The New Busy think 9 to 5 is a cute idea. Combine multiple calendars with 
Hotmail. 
http://www.windowslive.com/campaign/thenewbusy?tile=multicalendarocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_5
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Bugzilla Question - Master Bug vs Component?

2010-07-12 Thread Alex Milowski
On Mon, Jul 12, 2010 at 7:49 PM, Maciej Stachowiak m...@apple.com wrote:

 I think it's fine to enable MathML soon, as long as we make sure of the 
 following:

 1) Using a MathML-enabled build shouldn't cause stability problems or 
 functional or performance regressions when browsing ordinary non-MathML 
 content.

Some of tis is testable by passing all our test cases, right?  Or did you have
something else in mind?

Do we have anything that measures performance for regressions?

I suspect that the performance on MathML with complicated row structures
isn't going to be good at the moment.  There are two many multiple
rendering passes for operator and content stretching and that can probably
be optimized.  On the other hand, it seems to do quite well on reasonable
MathML.

 2) We should try to do some fuzz testing to verify that MathML doesn't create 
 security risks.

 #2 can happen after we enable MathML, but should probably happen before 
 anyone ships it.

What is involved in (2) ?

I'm happy to try to beat on the code to make sure it works well
enough for people to feel comfortable turning it on.

-- 
--Alex Milowski
The excellence of grammar as a guide is proportional to the paucity of the
inflexions, i.e. to the degree of analysis effected by the language
considered.

Bertrand Russell in a footnote of Principles of Mathematics
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] Bugzilla Question - Master Bug vs Component?

2010-07-12 Thread Maciej Stachowiak

On Jul 12, 2010, at 4:06 PM, Alex Milowski wrote:

 On Mon, Jul 12, 2010 at 7:49 PM, Maciej Stachowiak m...@apple.com wrote:
 
 I think it's fine to enable MathML soon, as long as we make sure of the 
 following:
 
 1) Using a MathML-enabled build shouldn't cause stability problems or 
 functional or performance regressions when browsing ordinary non-MathML 
 content.
 
 Some of tis is testable by passing all our test cases, right?  Or did you have
 something else in mind?

That plus browsing around some, or using the Safari stress test feature, wuld 
be enough to show basic stability.

 
 Do we have anything that measures performance for regressions?

The Safari team has some internal tests we could run, once you have a patch 
ready.

 
 I suspect that the performance on MathML with complicated row structures
 isn't going to be good at the moment.  There are two many multiple
 rendering passes for operator and content stretching and that can probably
 be optimized.  On the other hand, it seems to do quite well on reasonable
 MathML.

At this point, what I'm concerned about is that turning MathML on doesn't 
regress performance of other things (such as page load speed of normal HTML 
pages, or memory use when not using MathML). I would not expect it to, but 
there's always the possibility of unexpected interactions.

Optimizing MathML rendering itself is something that can be done after it gets 
turned on/

 
 2) We should try to do some fuzz testing to verify that MathML doesn't 
 create security risks.
 
 #2 can happen after we enable MathML, but should probably happen before 
 anyone ships it.
 
 What is involved in (2) ?
 
 I'm happy to try to beat on the code to make sure it works well
 enough for people to feel comfortable turning it on.

I'm not an expert on making fuzzers, so maybe some of the security people here 
can chime in or perhaps even help out.

Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev