LBSE doesn't handle the 'viewBox' attribute for outermost <svg> elements at present. Downstream LBSE handled this specifically via a few special cases in RenderLayer, that are quite intrusive. The reason for that is that the transformation matrix resulting from the 'viewBox' shall only be applied to _child_ elements of the <svg>, not the <svg> itself. Therefore one cannot simply map the 'viewBox' induced transformation as regular CSS transformation, as that would also be applied when rendering the <svg> element itself (background, border, ...). In the past few months (most noticeable after webkit.org/b/211787 was solved) a new opportunity was opened to handle 'viewBox' for SVG without having to change RenderLayer at all, since CSS/HTML actually offers a similar feature: perspective transformations. Specifying 'perspective: 500px' / 'transform-style: preserve-3d' on a container <div> element does not change the rendering of the <div> in any way, only its children: an additional transformation is applied, that only affects the child elements. That's very similar to the needs for SVG 'viewBox'. As a test, I followed this approach to implement 'viewBox' as unintrusive as possible in the new upstream LBSE. Specifying 'viewBox' on an outermost <svg> element will require an additional compositing layer that carries a 'sublayerTransform' similar to how perspective transformations are handled. The benefit is that neither painting, layout, nor hit-testing require any changes: getTransformFromContainer() / RenderLayerBacking / RenderLayerCompositor already handle sublayer transformations. During development I expanded the scope of the RenderSVGRoot sublayer transformation: it also handles zooming & panning for the SVG subtree. We can implement all these features in a straight-forward way, without having to extend RenderLayer with additional concepts/branches to handle SVGs needs. Obviously the cost is an additional compositing layer, but panning is then really cheap: it can be handled completely via composition, not requiring any relayout or repainting, which is much faster than any previous approach. Zooming can also be handled without relayout, but needs additional repaints, which is still cheaper than previous attempts. In my WIP branch, viewBox handling works perfectly fine, except that the content looks blurry: webkit.org/b/27684 strikes back once again. I will concentrate on fixing bug 27684, at least in such a way that I can use it for SVG viewBox. Stay tuned!