[webkit-dev] Moving WebCore/accessibility code into WebCore/platform/

Maciej Stachowiak mjs at apple.com
Tue May 21 12:05:08 PDT 2013

On May 21, 2013, at 7:34 AM, Mario Sanchez Prada <mario.prada at samsung.com> wrote:

> Hi all,
> Following the discussion in the contributors meeting about layering violations I was thinking about moving all the accessibility stuff inside WebCore/accessibility into a new WebCore/platform/accessibility directory.
> My reasoning behind this could be summarized as this:
> * Accessibility code is actually already platform dependant, as every port supporting this exposes the
> accessibility hierarchy in slightly different ways (ATK flattens more the hierarchy than Mac, for instance).
> * Besides the AccessibilityObject wrappers and partial platform-specific implementation files (e.g. AccessibilityObjectMac.mm) present in places like WebCore/accessibility/[atk|mac], there are other bits in WebCore/accessibility that are platform specific as well (e.g. AccessibilityRenderObject). These bits are guarded with "#if PLATFORM" macros, which would still be necessary to meet the different requirements of each port.
> * The number of ports adding support for accessibility is increasing, some of them sharing code already (e.g. EFL and GTK port, both use ATK), so I believe that would be a nice move to make.
> Of course, we could always add an exception to the style checker, but I feel like relocating things would be a better approach in this case, thinking of the long term.
> What do you think?

I think the main problem with this change is that the current WebCore/accessibility code has lots of knowledge of the DOM and render tree. Making WebCore/platform depend on these Web-specific concepts is a layering violation - imagine how it would work if it was a top-level directory Platform that was a peer of WebCore, and built before it without access to its headers. That is logically how it should operate.

If the accessibility code could be redesigned to have a good abstraction between the parts that are tightly tied to Web-specific classes and concepts, and the part that is platform-specific, then the second part could be moved to WebCore/platform. A refactoring like that could be a good improvement, but is likely hard to do.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20130521/8e853188/attachment.html>

More information about the webkit-dev mailing list