Open Web Competition Platform is a repo for documenting and tracking issues related to browser and web competition. Its aim is to facilitate coordination between browser vendors, operating systems, developers, and industry to help document outstanding competition issues with an eye towards resolving them more quickly.
MIT License
5
stars
1
forks
source link
Alternate browser engines on iOS must be able to bring their own rendering architecture #11
To correctly render CSS and manipulate the Javascript DOM, your browser app needs to integrate closely with UIKit and customize the way it handles many low-level user interface events. Use view classes in BrowserEngineKit to handle scrolling, drag interactions, and the context menu in your browser app.
It's not entirely clear, but this seems to imply that existing browser rendering engines must be re-architected to fit the UIKit rendering model. Chromium has a large and sophisticated rendering architecture which is designed to be platform-agnostic, rather than rely on operating-system-specific details such as the OS compositing architecture. As such, complex behaviour like scrolling is implemented nearly identically across all non-iOS Chrome platforms including Windows, MacOS, Android, Linux and ChromeOS. Using an operating-system provided scrolling / compositing architecture is infeasible for Chromium both because of the huge engineering expense and also because it would result in a worse product in some ways.
For example, the CSS specifications define a very complex set of stacking rules that determine how elements layer on top of each other. Chrome and Firefox have worked hard to implement this faithfully, while WebKit still has bugs which are probably due to limitations in Apple's UIKit system. For this test page, Chrome and Firefox render it correctly on MacOS as follows:
But Safari incorrectly clips the green box to be contained by the black scrolling rectangle:
It should be possible to implement a 100% CSS-spec-compliant rendering engine on iOS in the EU.
Outcome
Apple's Browser Engine Kit documentation should be clarified to indicate that use of UIKit components like BEScrollView are optional, or can be easily integrated into an existing browser rendering architecture. It's not yet clear if iOS contains all the functionality necessary for alternate browser engines to use their own rendering architecture without loss of full fidelity in functionality like text selection, accessibility, scrolling and dragging. But to the extent such functionality is found to be missing, iOS should provide the necessary lower-level hooks to enable it.
Description
Apple's Browser Engine Kit documentation says:
It's not entirely clear, but this seems to imply that existing browser rendering engines must be re-architected to fit the UIKit rendering model. Chromium has a large and sophisticated rendering architecture which is designed to be platform-agnostic, rather than rely on operating-system-specific details such as the OS compositing architecture. As such, complex behaviour like scrolling is implemented nearly identically across all non-iOS Chrome platforms including Windows, MacOS, Android, Linux and ChromeOS. Using an operating-system provided scrolling / compositing architecture is infeasible for Chromium both because of the huge engineering expense and also because it would result in a worse product in some ways.
For example, the CSS specifications define a very complex set of stacking rules that determine how elements layer on top of each other. Chrome and Firefox have worked hard to implement this faithfully, while WebKit still has bugs which are probably due to limitations in Apple's UIKit system. For this test page, Chrome and Firefox render it correctly on MacOS as follows:
But Safari incorrectly clips the green box to be contained by the black scrolling rectangle:
It should be possible to implement a 100% CSS-spec-compliant rendering engine on iOS in the EU.
Outcome
Apple's Browser Engine Kit documentation should be clarified to indicate that use of UIKit components like
BEScrollVieware optional, or can be easily integrated into an existing browser rendering architecture. It's not yet clear if iOS contains all the functionality necessary for alternate browser engines to use their own rendering architecture without loss of full fidelity in functionality like text selection, accessibility, scrolling and dragging. But to the extent such functionality is found to be missing, iOS should provide the necessary lower-level hooks to enable it.