On May 21, 2013, at 7:34 AM, Mario Sanchez Prada <[email protected]> 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. Regards, Maciej
_______________________________________________ webkit-dev mailing list [email protected] https://lists.webkit.org/mailman/listinfo/webkit-dev
