On 03/13/2012 09:55 AM, L. David Baron wrote:
+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.
MathML should be logical, actually. But for frame classes that are
going to operate in physical coordinates, they should continue to
do so for their calculations--they just need to be able to send
the reflow information back up in the coordinate system their parent
uses.
This can be thought of as an instance of orthogonal flows: just assume
that systems in physical coordinates are horizontal LTR. If it helps,
we can have dual name mappings, so physical systems can use continue
to use physical names--we just need to be careful to not use those
names in logical layout systems since they'll be wrong.
~fantasai
_______________________________________________
dev-tech-layout mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-layout
