+dev-tech-layout So one thing that I probably should have mentioned yesterday is that one big set of code where we currently want physical coordinates rather than logical coordinates inside of reflow relates to Invalidation, but that set of code should all be going away with https://bugzilla.mozilla.org/show_bug.cgi?id=539356 . So following the conversion approach Elika suggested right now (before those calls go away) might make would have a good bit more complication than once the invalidation code goes away.
That said, if we follow Elika's approach, which as I understand it involves converting the reflow API to logical names (e.g., fully converting nsHTMLReflowState and nsHTMLReflowMetrics, and adding logical alternative setters/getters to nsIFrame), I'm still a little worried about what's going to happen to the frame classes that are still going to want to do everything in terms of physical coordinates. At a first glance these might be nsImageFrame, nsObjectFrame, nsHTMLCanvasFrame, nsVideoFrame, nsImageBoxFrame, nsImageControlFrame, nsProgressFrame (I think), nsGfxCheckboxControlFrame (and probably nsGfxRadioControlFrame too), the interfaces to SVG (nsSVGOuterSVGFrame and nsSVGForeignObjectFrame), and possibly (?) all of MathML. I think we may need to think a little more about where the logical/physical boundaries should be -- both in terms of algorithms and in terms of frame classes. -David -- 𝄞 L. David Baron http://dbaron.org/ 𝄂 𝄢 Mozilla http://www.mozilla.org/ 𝄂 _______________________________________________ dev-tech-layout mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-layout
