| 36 | | * Perhaps a new <img> property that says "decode on background thread", and perhaps a way to be notified when decoding is complete. |
| | 36 | * Perhaps a new <img> or <picture> element property: |
| | 37 | 1. Causes us to decode on background thread". |
| | 38 | 1. Notified when decoding is complete. |
| | 39 | 1. Show a placeholder for the image and then trigger. |
| | 40 | 1. Major point: Tell WebKit not to block main thread on decoding of this image. |
| | 41 | * Might need a way to animate the pop-in of the decoded image to replace the placeholder. |
| | 42 | * Many sites do this manually in JavaScript right now. Would be nice to codify these "hacks" in an official way. |
| 39 | | |
| 40 | | == Hackability == |
| 41 | | * Renaming. |
| 42 | | |
| 43 | | == Text Measurement == |
| | 45 | Need stronger rules (assertions) about when we mark the tree as needing layout, or nodes as needing style recalculation. |
| | 46 | Want to assert when hit tests or other things are triggered during layout. |
| | 47 | Tasks would involve the following: |
| | 48 | 1. FrameView and document updates to make these assertions. |
| | 49 | 1. Correct the places where our tests cause assertions. |
| | 50 | * This task would not be necessary with immutable render trees. This task might be a good step towards that goal. |
| | 51 | * We have certain places where layout is done bottom up (e.g., MathML or some tables logic), which is extremely confusing because our normal CSS layout is top-down. |
| | 52 | * In general, we should be using assertions to document these kinds of assumptions (or requirements) about the model state during layout or other operations. |
| | 53 | * A precondition to this might be to address assertions in existing code; we have some assertions that fire in conditions that are valid. |
| | 54 | * We should use asserts with messages. |
