I think it should be relatively easy to implement this without a major code complexity penalty and without a performance penalty for pages that do not use border-radius with non-visible 'overflow'. You already have to track clip rects for the children of the element with non-visible 'overflow'. So extend the abstraction from 'clip rect' to 'clip rect or the intersection of a list of clip paths'. I disagree with the argument that we should ease the implementation burden by inducing a stacking context because we did for opacity < 1. I think we induce a stacking context for opacity < 1 not because of implementation issues, but because group opacity is meaningless if the elements in the group are not contiguous in z-order ... at least, I don't know of any rational way it could be defined. I agree that making non-visible 'overflow' induce a stacking context would have been a good idea, but it's too late now. Given we have to deal with interleaving of clipped and non-clipped content, generalizing the clipping shapes without adding strange new side effects seems the most reasonable thing to do. Rob -- "Now the Bereans were of more noble character than the Thessalonians, for they received the message with great eagerness and examined the Scriptures every day to see if what Paul said was true." [Acts 17:11]
Received on Sunday, 21 November 2010 23:59:04 UTC