Transription layout and acid2

Schedule

Wait for box builder / incremental reflow

• position
• generated content
• tables (pcwalton has documents on how they are done in gecko)

Can do before incremental reflow

• Paint order / clipping can be done before incremental reflow
• data url should work, but may have a bug. need alpha channel PNG
• z-index (multiple display list).
• overflow:hidden
• local bookmark
• border painting (just a graphics change with line style in azure)
• list is coming up as inline-block instead of block
• need generated content for lists
• :hover, :active, :focus

Questions

• Do we need to support multiple layers for z-index? Need it for position:fixed regardless.

Pseudo-class

How can we find the position for the hover?

• jack: traverse the display list, which will point to the DOM
• pcwalton: lots of traffic to the layout task when the mouse is moved, though
• kmc: can cache the structure as part of compositing
• pcwalton: maybe cache the display list?
• jack: dont worry about it all for now
• pcwalton: make sure we don't get hurt for the future
• kmc: the compositor can assemble tiles of pictures AND a map of what's under the pixels
• pcwalton; only works for this case, but not for a mousemove event in script
• jack: have the renderer send the display list to the compositor as well, and the compositor can use it to disambiguate mouse events. How does gecko handle it?
• pcwalton: floods script with them. We can check after this, but I bet that if we put a mouse_move on something, gecko constantly is building display lists. Our architecture is not that different from gecko.
• kmc: uses display list for hit testing.
• pcwalton: webkit does not; it has separate paths, uses walks through the layout, which requires tracking z-order How do we propagate event on DOM tree originally in servo?
• jdm: Which events are needed? Are they DOM events?
• pcwalton: mouse_move. It's special because it's related.
• jdm: usually have optimizations so that pages without mouse_move events do not fire DOm events
• pcwalton: if you call preventDefault, it will stop the hover from happening. If you have something further up in the chain, does that stop the hover from happening? We should test it.
• QUESTION: how does gecko do hover?
• QUESTION: does preventDefault() stop hover from happening? -jdm: possible we have mouseMove events that are covered
• pcwalton: In the DOM, there is an order in which events are delivered. They go inner to outer. Javascript can say stop at any point, which includes it. Don't know if this covers acid2 or not. If it is, then hover needs to be integrated into the JavaScript event system so that JS can prevent it. If it's not the case, then we don't need to have the JavaScript event and can have mouseMove be separate. Need to figure out if its integrated in that way

hover test

• pcwalton: don't we need to CSS cascade for hover?
• jack: and anything that's hovered? But gecko already has a table for all the things for this, right?
• pcwalton: may be pretty fast. We need to match selector document damage. With incremental reflow, we know that only the one needs incremental layout. We should optimize this case so that it's very fast. We can skip layout calculations. We have an enum that prevents only some of them.
• pcwalton: We have a pass that computes the overflow regions, and that will tell us the rectangle we need to repaint. So then, we can repaint only that one tile. We know how much space it took up, so when that element changes, all we need to do is repaint that area. It is called overflow calculation because if you have a box with a lot of words, even if the dimensions of the box were smaller than the contents, we still need to repaint the whole thing.

:visited

• pcwalton: We could store a simple session manager in the compositor, and that would be the most forward-thinking way to do it. Ultimately, the embedding application (the compositor) should maintain that and history as well. If we want to do this the right way, we should send a message to the consteallation which would then send one to the compositor that would then request browser history. But I am fine with a temporary cache for now.
• jack: I say we do it like the imagecachetask for now. Send it a message, get a response, and worry about doing something fancier later.
• pcwalton: As long as you have a task, you can change where the message passing goes easily, so I like this. That's a good idea: a history task.
• jack: And I think that for anything we need, like a temporary cache/data store, we should just create a task, send it messages, and be set.
• pcwalton: Should not block on knowing whether a link is visited or not. Should request the info, but should not wait to paint. Need to paint unvisited right away and then paint it the right color.
• brson: Specs have anything to say about this?
• pcwalton: We do whatever we want.
• kmc: There's a timining information problem there.
• pcwalton: Eventually, dbaron's stuff, where we have to lie about the color (and other attributes) related to visited information.

table

• pcwalton: We haven't thought about the flow classes heavily. They were not designed up front. InlineBlockFlowClass will probably not exist in the future. It's useful as a marker to have to show that something is Absolute and not part of the flow. So an AbsoluteFlow might always contain a BlockFlow, but the AbsoluteFlow is probably a marker.
• pcwalton: For tables, I'm not sure how it will fall out. How we do everything is different from gecko and webkit. There will be some experimentation. I can imagine having a TableFlow and TableRowFlow and then InlineFlows for the table cells. The answer is: feel free to make whatever flow classes make sense to you. You don't need to worry about staying in our current model. If there is something that makes more sense, feel free to do it. Things like AbsoluteFlow and TableFlow are not implemented and may not work, so feel free to change things as they fit your needs.
• parkjaeman: Wondering. tables work similarly to block, and table rows similar to inline flow. So, how can TableFlow cover all the table elements.
• pcwalton: Maybe there's a TableFlow that are like block flows but not the same. And TableRowFlows are like inline flows, and then have RenderBoxes below them. As another idea, we might have TableFlow, TableRowFlow, and then RenderBoxes for the cells in them. That is an idea to try first, treating them like a BlockFlow (TableFlow) and InlineFlow (TableRowFlow).