Closed Bug 1289200 Opened 3 years ago Closed 3 years ago

Add grid areas to css grid properties exposed to dev tools

Categories

(Core :: CSS Parsing and Computation, defect)

defect
Not set

Tracking

()

RESOLVED FIXED
mozilla51
Tracking Status
firefox51 --- fixed

People

(Reporter: bradwerth, Assigned: bradwerth)

References

Details

(Keywords: DevAdvocacy, Whiteboard: [DevRel:P1])

Attachments

(1 file, 3 obsolete files)

Augment the properties exposed in bug 1241932 to include information on implicit and explicit grid areas.
Attached patch gridAreas2.patch (obsolete) — Splinter Review
Adds areas property to the grid objects returned by <element>.getGridFragments().

https://treeherder.mozilla.org/#/jobs?repo=try&revision=79379f4496c8
Attachment #8774457 - Flags: review?(mats)
Keywords: DevAdvocacy
Whiteboard: [DevRel:P1]
Blocks: 1249558
Attached patch gridAreas3.patch (obsolete) — Splinter Review
Quick update to support Gabe's prototype. Explicit GridAreas get bounding lines, but implicit GridAreas do not (yet).
Attachment #8774457 - Attachment is obsolete: true
Attachment #8774457 - Flags: review?(mats)
Attachment #8782147 - Flags: feedback?(gl)
Comment on attachment 8782147 [details] [diff] [review]
gridAreas3.patch

Current patch to get the bounding star/end row and column for css grid area has been working great!
Attachment #8782147 - Flags: feedback?(gl) → feedback+
Blocks: 1297189
Attached patch gridAreas4.patch (obsolete) — Splinter Review
Adds grid areas, add comments to the Grid.webidl explaining which numbers are 0-indexed and which are 1-indexed. Explicit grid areas get correct boundary lines; implicit grid areas get 0 for all boundary lines until Bug 1297189 resolves that.

I'd like to land this to get the areas and the implicit/explicit state stuff to the dev tools team while working on the implicit boundary lines.

https://treeherder.mozilla.org/#/jobs?repo=try&revision=072ad0d350fe
Attachment #8782147 - Attachment is obsolete: true
Attachment #8783717 - Flags: review?(mats)
Blocks: 1249555
Comment on attachment 8783717 [details] [diff] [review]
gridAreas4.patch

r=mats on the layout changes.  You should ask a DOM peer to review the rest.
Attachment #8783717 - Flags: review?(mats) → review+
Comment on attachment 8783717 [details] [diff] [review]
gridAreas4.patch

Requesting webidl review from bz as a DOM peer.
Attachment #8783717 - Flags: review+ → review?(bzbarsky)
Comment on attachment 8783717 [details] [diff] [review]
gridAreas4.patch

This is going to return the implicit areas in some random order, right?  Is that OK?

Is there a reason for the separate SetAreaValues function instead of just passing that stuff to the constructor?  Can any of those values change on a GridArea object?  If not, it would be good to make them const on GridArea and pass them to the constructor.

>+          (i > aTrackInfo->mNumLeadingImplicitTracks +
>+               aTrackInfo->mNumExplicitTracks) ?

Should this be > or >=?  That is, if mNumExplicitTracks and mNumLeadingImplicitTracks are both 0, what should happen for i == 0?  Should it be explicit or implicit?

It's not clear to me why it should be explicit in that situation; the comment seems to say it should, but not _why_...

>+  [Cached, Pure]
>+  readonly attribute sequence<GridArea> areas;

It's actually [Constant], not just [Pure], right?

>+  readonly attribute sequence<DOMString> names;

And this one too?  Also, please put the extended attributes (the stuff in []) right before this line, not way off before the comment.

r=me with those fixed.
Attachment #8783717 - Flags: review?(bzbarsky) → review+
Attached patch gridAreas5.patchSplinter Review
Per review from bz: Consolidated GridArea setter into constructor, improved comments, and updated GridLine type.

https://treeherder.mozilla.org/#/jobs?repo=try&revision=b263a9513cf7
Attachment #8783717 - Attachment is obsolete: true
Keywords: checkin-needed
https://hg.mozilla.org/mozilla-central/rev/c98b8c992c2f
Status: NEW → RESOLVED
Closed: 3 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Target Milestone: --- → mozilla51
You need to log in before you can comment on or make changes to this bug.