Henri Sivonen wrote:
I'm not sure what kind of forward-looking precautions should be taken.
If it's easy to take, it should. It significantly reduces complexity and developer brain-print if people don't have to remember to check whether your code needs fixing every time they make changes to frame construction.
The alternative is, of course, that this code needs to be revised if such a substantial change is made to the engine.
Or even if some aspect of frame construction changes such that frames are or are not created in various cases (something we do for SVG already, and might want to do for XUL, and do in some cases for tables but want to stop, etc).
Is there a stable API that exposes the same data as getComputedStyle but without converting the style system data to strings?
No. What would the interface actually output? The actual values stored in the style data are an internal implementation detail and are NOT stable, so any stable API would need to convert from those to something else.
The reason why I am looking at nsIFrame is to avoid the overhead of going via string representations of data that exists as numbers and enumerations.
How significant is this overhead in your case, compared to the other things going on?
For the purpose of what I am interested in for this feature, an element is rendered if its non-whitespace text content was visible (assuming different color and background)
So something with "opacity:0" is not "rendered", right? And a node that has no non-whitespace textnode descendants (eg a table of images) is not "rendered" either?
Your definition of "rendered" does, more or less, have having an nsIFrame as a prerequisite (SVG aside). Having an nsIFrame doesn't guarantee "rendered", of course, as per the above examples.
So "rendered" only needs to fit reasonably well with an intuitive understanding of what is visible on the page (if scrolled). This is used for a heuristic, so it is pragmatic to let the data that is exposed by the available interfaces to dictate the details.
OK. -Boris _______________________________________________ dev-tech-layout mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-layout
