[Webkit-unassigned] [Bug 12207] RenderSVGContainer should be split into two classes, one for SVG and one for G

[bugzilla-daemon at webkit.org]

http://bugs.webkit.org/show_bug.cgi?id=12207


macdome at opendarwin.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mjs at apple.com




------- Comment #2 from macdome at opendarwin.org  2007-01-14 22:00 PDT -------
We may need more than 2.

Here are all the SVG containers I can think of, grouped by behavior:

Have a viewBox and establish a viewPort:
<svg> - new SVGRenderRoot
<image> - RenderSVGImage
<foreignObject> - RenderSVGForeignObject

No viewbox, sometimes establishes a viewport:
<symbol> - only when referenced by <use>, the logic should probably be in the
<use> renderer(s)

Has viewbox, but does not establish a viewport:
<pattern>
<marker>
Neither of these draw their content directly.

Has no viewport:
<defs> - does not draw its content directly, but probably should have a
renderer to allow proper style resolution of its kids (right now it has no
renderer)
<g> - should probably be RenderSVGContainer

<view> also has a viewBox, but it's never drawn, so we don't need a renderer
for it.

I propose adding 3 new container types in this bug:

RenderSVGRoot - for <svg>, is a RenderBlock, only trickiness occurs when inside
another <svg>
RenderSVGGroup - for <g>, only supports localTransform
RenderSVGUseable - for <symbol>, <pattern>, <marker>, viewbox is simply ignored
for <symbol>, does not draw content via normal paint() method.

Optionally, you could also make <defs> a RenderSVGUsable, although then maybe
it should be called RenderSVGHidden, not sure.


-- 
Configure bugmail: http://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.