Changes between Initial Version and Version 1 of Ticket #8587, comment 8
- Timestamp:
- Mar 31, 2014, 8:06:10 AM (10 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Ticket #8587, comment 8
initial v1 7 7 I guess that we don't use `position:fixed` for historical reasons. Now perhaps we could do that, because it would simplify the code a lot and perhaps made it faster. 8 8 9 Perhaps, because `position:fixed` is known for causing problems. And because I wasn't able to reproduce the issue. I attached [[attachment:8587 .html]] with CKEditor nested in 60 positioned divs. The only delay I see is on leaving maximize and it's caused by too heavy styling of the divs (border-radius and box-shadow) which affects entire page performance (e.g. scrolling in editor). This delay does not happen on [[attachment:8587_2.html]] which has lighter styling. Of course, the delay would be lower if browser wouldn't have to rerender all those divs when leaving maximize, but in most cases it will have to do that anyway, because maximize needs to override `<html>` styles in order to get rid of scroll.9 Perhaps, because `position:fixed` is known for causing problems. And because I wasn't able to reproduce the issue. I attached [[attachment:8587_heavy.html]] with CKEditor nested in 60 positioned divs. The only delay I see is on leaving maximize and it's caused by too heavy styling of the divs (border-radius and box-shadow) which affects entire page performance (e.g. scrolling in editor). This delay does not happen on [[attachment:8587_light.html]] which has lighter styling. Of course, the delay would be lower if browser wouldn't have to rerender all those divs when leaving maximize, but in most cases it will have to do that anyway, because maximize needs to override `<html>` styles in order to get rid of scroll. 10 10 11 11 So, the situation is not so straightforward - changing the maximize behaviour perhaps makes sense because it may be beneficial, but that needs tests. I opened #11745.
