layout problem in specified URL

[Gregory]

there's a layout problem in Luminous Landscape — Anti Shake (http://luminous-landscape.com/forum/index.php?showtopic=2376&hl=).

it can be reproduced in WebKit 13302 but is not apparent in WebKit 14802 (June 10).

will OW stay with 13302 or will it adopt the latest build of WebKit once other bugs are found/fixed, and features successfully implemented?

regards,
Gregory

[Handycam]

Hmm. I can confirm this. FWIW, neither their HTML nor their CSS will validate.

[Len Case]

will OW stay with 13302 or will it adopt the latest build of WebKit once other bugs are found/fixed, and features successfully implemented?

We picked 13302 as the last stable point before a fairly major destabilizing change in WebKit (moving away from using standard Cocoa views for form elements).

The plan is to stay on 13302 for the 5.5 release. As we find issues in 13302 that have been fixed on the head and are still compatible, we have and will try to fold those changes back into our version.

We will evaluate moving forward to a newer version for releases after 5.5 but some of our customizations will have to be rewritten to move away from the Cocoa controls (e.g. Zoomed Text Editing and Add Search Shortcut).

[Gregory]

As we find issues in 13302 that have been fixed on the head and are still compatible, we have and will try to fold those changes back into our version.
does that imply that if we find problems in 13302 that have been solved in later releases that we should tell you about them as I did in this thread?


but some of our customizations will have to be rewritten to move away from the Cocoa controls
confused: isn't Apple 'softly' advocating developers to use Cocoa for the sake of 'easier' universal builds?
.
.
.

[Len Case]

does that imply that if we find problems in 13302 that have been solved in later releases that we should tell you about them as I did in this thread?
Yes, indeed--thank you.
Even better would be if you can figure out which Nightly first fixed the problem (so we can narrow down our search for the actual change that fixed it).

but some of our customizations will have to be rewritten to move away from the Cocoa controls
confused: isn't Apple 'softly' advocating developers to use Cocoa for the sake of 'easier' universal builds?
The issue is that WebKit no longer uses cocoa to draw internal form elements on a webpage. This is because Cocoa controls (buttons, text fields, etc.) were never designed to be used inside a web page and don't correctly handle floating divs, etc. also they don't handle all the drawing methods that CSS can specify (like border colors, etc.). This is good for standards compliance but bad for our customizations since we have to redo them to work with the new implementation.

That said, WebKit is a Cocoa framework so using WebKit *is* using Cocoa.