[webkit-dev] Adding ENABLE_CONTACTS to WebCore

Hi webkit-dev! I wanted to let you know that I plan to add Contacts API support to WebKit. This API is a new feature that is published by W3C. The Device APIs Working Group of W3C has just released a Last Call Working Draft of its Contacts API: http://www.w3.org/TR/2011/WD-contacts-api-2011

[webkit-dev] Adding CSS3 font feature propreties

Hi webkit-dev, I'm thinking about adding CSS3 font feature properties[1] support to WebKit. It allows page authors to control over advanced typographic features. Firefox has an experimental implementation and an article[2] shows how these properties work. I really would like to add this feature

Re: [webkit-dev] Implementing new WebSocket protocol

FWIW it has settled down. The spec is in last call and isn't changing, rather we're just arguing over wording, references in the spec, clarifying text based on implementation experiences and ambiguities implementers have found, etc. On Thu, Jun 23, 2011 at 6:29 PM, Charles Pritchard wrote: > *

Re: [webkit-dev] Implementing new WebSocket protocol

That said, you're all lucky that the rest of us developers have no idea when the current round of specification flux will settle down. Security vulnerabilities will always trump the specs. Thanks for keeping on top of things. -Charles On 6/23/2011 5:16 PM, Ian Fette (イアンフェッティ) wrote: That sai

Re: [webkit-dev] Some questions about adobe air version webkit

Hi Arno, I'd like to be included in any discussion as well! -Brent On Jun 16, 2011, at 9:53 PM, Arno Gourdol wrote: > Hi Wang, > > We'll contact you off list and help you get sorted. If anyone else is > interested in the discussion on this mailing list, let us know. > > – Arno > > > > >

Re: [webkit-dev] Implementing new WebSocket protocol

That said, I don't think the intent should be to support any old versions for any protracted amount of time. -00 has security vulnerabilities brought up by people on webkit-dev@ so from the Chrome side, we intend not to support -00 at all once we have -09 support available. All the makers of server

Re: [webkit-dev] Adding Persistent Position

On Jun 23, 2011, at 2:43 PM, Ryosuke Niwa wrote: > I think we need a PersistentPosition that auto-corrects itself and survives > DOM mutations without being orphaned; similar to how Range is automatically > updated. I’m not sure that auto-correction has a simple unambiguous meaning. There are

[webkit-dev] Adding Persistent Position

Hi, I think we need a PersistentPosition that auto-corrects itself and survives DOM mutations without being orphaned; similar to how Range is automatically updated. Why? 1. ReplaceSelectionCommand and DeleteSelectionCommand have wrapper for removeNode, deleteTextFromNode, etc... to update

Re: [webkit-dev] Inconsistency in logging approach

On 23.06.2011 22:16, Darin Adler wrote: > But I’m surprised that GTK and EFL chose to leave logging on in releases. > > -- Darin > They warn user with messaage sth like: "WEBKIT_DEBUG is not empty, but this is a release build. Notice that many log messages will only appear in a debug build.

Re: [webkit-dev] API documentation in cpp files

W dniu 22.06.2011 18:27, Darin Adler pisze: For WebKit API header files, files intended to be used by the clients of WebKit outside the project, I think your proposal makes sense. For an example of a header file in WebKit that is done in this way, you could look at JavaScriptCore/API/JSObjectR

Re: [webkit-dev] Inconsistency in logging approach

On Jun 23, 2011, at 1:12 PM, Łukasz Ślachciak wrote: > Personally, I like approach of putting logging related code into #if > !LOG_DISABLED macro instead of #ifndef NDEBUG. As I remember it, my original design for LOG was: 1) Control with LOG_DISABLED, not NDEBUG. 2) Turn off for relea

[webkit-dev] Inconsistency in logging approach

Hello All, I would like to know what do you think about Logging in Release build. Should WebKit allow it? Currently it is not possible because some features (like IconDatabase) use #ifndef NDEBUG for marking LOG macro related code. From the other hand in WebKit2 all logging is based on the #if

Re: [webkit-dev] Switching away from integers for layout

We spent a lot of time thinking about this and I should have mentioned our thoughts in the original email. My apologies. We're not opposed to fixed-point, but given that the line box tree and SVG both already use floating point, we felt like it made the most sense to validate in our prototype that

Re: [webkit-dev] Switching away from integers for layout

On Jun 23, 2011, at 11:46 AM, Levi Weintraub wrote: > We’ve been getting an increasing number of complaints lately about the > zooming support in webkit and how hard it is to correctly support zooming in > complex web applications. > > To address this we plan to convert the rendering tree to f

Re: [webkit-dev] Switching away from integers for layout

I know you made some consideration of "fixed point" vs. "float point" in your investigation. I suspect that decision is orthogonal to work of plumbing more precise types through the engine... but I am still curious to know if there was a decision if fixed point or float point might be the eventual

Re: [webkit-dev] Switching away from integers for layout

On Thu, Jun 23, 2011 at 11:46 AM, Levi Weintraub wrote: > To address this we plan to convert the rendering tree to float to allow for > better zooming and scaling support. Furthermore this could be expanded to > support sub-pixel layout and positioning which in turn would allow higher > precision

[webkit-dev] Switching away from integers for layout

We’ve been getting an increasing number of complaints lately about the zooming support in webkit and how hard it is to correctly support zooming in complex web applications. To address this we plan to convert the rendering tree to float to allow for better zooming and scaling support. Furthermore

Re: [webkit-dev] Implementing new WebSocket protocol

On 2011-06-23 17:15, Simon Fraser wrote: I'm surprised that the protocol has no facility for versioning. Is that really he case? Should it be considered for future versions of the spec? It does.

Re: [webkit-dev] Implementing new WebSocket protocol

I'm surprised that the protocol has no facility for versioning. Is that really he case? Should it be considered for future versions of the spec? Simon On Jun 23, 2011, at 6:07 AM, Yuta Kitamura wrote: > There seems to be no strong objection to adding a runtime flag, and I think > it will take

Re: [webkit-dev] Implementing new WebSocket protocol

There seems to be no strong objection to adding a runtime flag, and I think it will take some time and need multiple patches to get the implementation in good shape. Therefore, I'd like to start to implement behind a runtime flag. It allows each port to control the time to switch protocols, too (of