Bug 102538

Summary: Introduce a new renderer for grid areas
Product: WebKit Reporter: Julien Chaffraix <jchaffraix>
Component: Layout and RenderingAssignee: Nobody <webkit-unassigned>
Status: RESOLVED WONTFIX    
Severity: Normal CC: donggwan.kim, ojan, tony, xan.lopez
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: All   
OS: All   
Bug Depends on:    
Bug Blocks: 60731    
Attachments:
Description Flags
Prototype, RFC: Patch that adds support for percent resolution without grid areas none

Julien Chaffraix
Reported 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.
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
Ojan Vafai
Comment 1 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.
Julien Chaffraix
Comment 2 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.
Julien Chaffraix
Comment 3 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.
Julien Chaffraix
Comment 4 2012-11-30 18:25:00 PST
This was fixed differently without the need for a new renderer. See bug 102968.
Note You need to log in before you can comment on or make changes to this bug.