- From: MarkUK via GitHub <sysbot+gh@w3.org>
- Date: Tue, 08 May 2018 11:24:14 +0000
- To: public-css-archive@w3.org
I guess it makes sense for me to make a proposal then, to get things going. The first thing is probably to split my original request into three parts: 1) Getting information about an item in the grid 2) Getting information about the grid itself 3) Getting information about the element(s) at a particular grid location **1:** For the first case the requirement is to know the bounds of the item, in terms of grid lines. One possibility, therefore, would be to extend getComputedStyle() to also return the following properties: * gridRowStartNumber * gridRowEndNumber * gridColumnStartNumber * gridColumnEndNumber Each of these properties should contain the computed line number, based on counting upwards from 1, even if the element itself is positioned using a negative index or with reference to a named area or lines. For the sake of completeness, it may also be useful to return the following properties: * gridRowStartName * gridRowEndName * gridColumnStartName * gridColumnEndName Each of these properties should contain the explicitly defined line name, or the implicitly generated name if one exists. Where a line name is defined more than once in a grid, the returned value should be followed by a single space and a numeric index, starting at 1. Where a line has more than one name (e.g. an explicit name, plus an implicit one from a grid area), a comma-separated list of name values should be returned. Grid areas are not considered, other than through the fact that implicit line names are created when areas are used. If the target element is already positioned in a grid area through the "grid-area" CSS property this should already be exposed via the "gridArea" property returned from getComputedStyle() (see note below). If the target element happens to be positioned over a grid area (e.g. positioned using explicit line numbers which coincide with a defined grid area), this is only reflected through the line names that are returned. **NOTE:** In my brief testing with Firefox and Chromium, it appears that getComputedStyle() returns less than useful values for elements positioned using "grid-area". For example "gridColumnStart" and "gridColumnEnd" both return the name of the grid area, without the implicit "-start" and "-end" suffixes of the line names, whilst "gridArea" returns distinctly different values between the browsers, neither of which directly reflects the simple area name used in the original CSS. Perhaps this spec *does* need to be expanded to include definitions for the existing grid properties, to aid compatibility. **2:** For the second situation, of returning information about the grid itself, once again getComputedStyle() could be extended, this time to include: * gridComputedColumns * gridComputedRows Each property would contain a comma-separated list of pixel values, corresponding to the relative position of each line within the grid container. From this it would be easy for a competent developer to determine the number of rows and columns in the rendered grid, and the width and height of each of them. **3:** Finally, for the third situation, of determining which children of the grid are positioned at a given location, I propose a method on the grid container, along the following lines: NodeList getGridItemsAtLocation(startColumn, startRow) where startColumn and startRow are grid lines, defined by positive or negative number, or by reference to an explicit or implicitly named line. This would return a static NodeList of all immediate grid children that have been positioned such that the cell whose top-left corner is at the intersection of the startColumn and startRow lines falls within the boundary of the child, ignoring any grid-gap values. Examples: getGridItemsAtLocation(1, 1) // Returns all grid children that are positioned at the top-left of the grid getGridItemsAtLocation(-1, 1) // Returns all grid children that are positioned at the top-right of the grid getGridItemsAtLocation(3, 4) // Returns all grid children that are positioned such that they include the cell // defined by the overlap between the third column and fourth row getGridItemsAtLocation("fred", "wilma") // Returns all grid children that are positioned such that they include the cell defined by // the overlap between the column which starts at the line named "fred" and the row which // starts at the line named "wilma" getGridItemsAtLocation("sidebar-start", "sidebar-start") // Returns all grid children that are positioned such that they include the cell at the // top-left of the "sidebar" named area, based on the implicit naming of lines // when grid-template-areas is used. **Note:** I have not considered subgrids in any of this. My immediate thoughts are: * For the first item: children of subgrid elements should return values that correspond to the grid lines of the parent grid * For the second item: the line positions returned when querying a subgrid should include those lines of the parent grid that intersect with the subgrid element, but the values should be pixel positions relative to the top-left corner of the subgrid element, not the parent grid. * For the third item: the API should also be available on subgrid elements. When called on a grid that contains a subgrid, it should simply return the subgrid element in the NodeList if it overlaps with the specified position. It is down to the developer to further query the subgrid to identify which of *its* children overlap the position. -- GitHub Notification of comment by MarkUK Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/1465#issuecomment-387371281 using your GitHub account
Received on Tuesday, 8 May 2018 11:24:20 UTC