The current way of highlighting elements in the page is a bit quirky. CP gets a reference to the element, computes its bounding box, and overlays an empty div with a red border of the same dimension on top of it. This has a couple of issues:
One cannot interact with the box without masking the original element (and vice versa). This is why clicking on the probe's icon toggles the mouseover on the red boxes.
If the element moves, the box does not follow it. One would need to manually refresh the display of the boxes to put it in its new location (and currently the probe does not provide a way to do that).
What if the underlying element is red?
The red highlight isn't always in the foreground.
Yet, highlighting the elements themselves (changing their border attribute, for example) is no better: if a CP property refers to the border, highlighting the element might change the truth value of the property (even worse if it is the application itself that refers to that attribute). Plus, one has to record the element's state before modifying it, and restore it when it becomes "un-highlighted", etc.
Originally reported by: Sylvain Hallé (Bitbucket: sylvainhalle, GitHub: sylvainhalle)
The current way of highlighting elements in the page is a bit quirky. CP gets a reference to the element, computes its bounding box, and overlays an empty div with a red border of the same dimension on top of it. This has a couple of issues:
One cannot interact with the box without masking the original element (and vice versa). This is why clicking on the probe's icon toggles the mouseover on the red boxes.
If the element moves, the box does not follow it. One would need to manually refresh the display of the boxes to put it in its new location (and currently the probe does not provide a way to do that).
What if the underlying element is red?
The red highlight isn't always in the foreground.
Yet, highlighting the elements themselves (changing their
border
attribute, for example) is no better: if a CP property refers to the border, highlighting the element might change the truth value of the property (even worse if it is the application itself that refers to that attribute). Plus, one has to record the element's state before modifying it, and restore it when it becomes "un-highlighted", etc.Can we do better?