Bug 102538 - Introduce a new renderer for grid areas
Summary: Introduce a new renderer for grid areas
Status: RESOLVED WONTFIX
Alias: None
Product: WebKit
Classification: Unclassified
Component: Layout and Rendering (show other bugs)
Version: 528+ (Nightly build)
Hardware: All All
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks: 60731
  Show dependency treegraph
 
Reported: 2012-11-16 11:02 PST by Julien Chaffraix
Modified: 2012-11-30 18:25 PST (History)
4 users (show)

See Also:


Attachments
Prototype, RFC: Patch that adds support for percent resolution without grid areas (10.69 KB, patch)
2012-11-20 15:08 PST, Julien Chaffraix
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Julien Chaffraix 2012-11-16 11:02:13 PST
Per the editor's draft (section 6.3 anonymous Grid Areas):

Each Grid item is contained by a Grid area, i.e. the Grid area serves as the containing block for the Grid item. The dimensions of an anonymous Grid area are determined by naming the starting and ending Grid lines using the ‘grid-row’ and ‘grid-column’ properties on the Grid item which the Grid area surrounds. 

In order to implement that part of the specification, we need to add a new (anonymous) renderer that represents a grid area.
Comment 1 Ojan Vafai 2012-11-16 11:27:51 PST
I've thought about this more since we last talked about it and I think we probably don't want anonymous grid areas. Before, I was confused and thought containing block implied it would also be a positioning root. But, since you can't style the grid area, it can never be a positioning root.

I think we'll end up with something easier to manage that uses less memory and performs better if we avoid creating grid area renderers since they are only there for positioning/sizing the grid items.

The only complexity here is that we need to make sure to resolve percentage/calc values using the grid-area as the containing block. We will already need to do this calculation for the margins, width and height. So, I think the only complexity added by not having grid area renderers is that we'll also need to do so for percentage paddings.
Comment 2 Julien Chaffraix 2012-11-16 15:07:09 PST
(In reply to comment #1)
> I've thought about this more since we last talked about it and I think we probably don't want anonymous grid areas. Before, I was confused and thought containing block implied it would also be a positioning root. But, since you can't style the grid area, it can never be a positioning root.

You are right, they don't impact positioned elements.

> I think we'll end up with something easier to manage that uses less memory and performs better if we avoid creating grid area renderers since they are only there for positioning/sizing the grid items.
> 
> The only complexity here is that we need to make sure to resolve percentage/calc values using the grid-area as the containing block. We will already need to do this calculation for the margins, width and height. So, I think the only complexity added by not having grid area renderers is that we'll also need to do so for percentage paddings.

I will have to think / prototype your idea to see if I agree. My main concern with that is that your proposal could end up peppering grid knowledge all over the render tree or force us to do horrible hacks in RenderGrid (the grid items' containing block per your proposal) to properly resolve our sizes.
Comment 3 Julien Chaffraix 2012-11-20 15:08:30 PST
Created attachment 175285 [details]
Prototype, RFC: Patch that adds support for percent resolution without grid areas

It turns out that we don't need to hack around too much as most elements fall back to RenderBox. This matches table cells FWIW.

The nasty side of this patch is that you have to override RenderGrid's size in order to properly lay out the grid items (RenderGrid pretends to have the grid area's size).

All in all, it should be OK and I can't think of other issues with this approach.
Comment 4 Julien Chaffraix 2012-11-30 18:25:00 PST
This was fixed differently without the need for a new renderer. See bug 102968.