CSS Grid Layout is getting implemented in Gecko (bug 616605), and it's the kind of layout feature that devtools could help users with.
Typically, just being able to see the grid lines in a grid container would help a lot.
I'd say this is something, which could be implemented as an add-on. Same for a possible Flexbox Inspector or other layout inspectors.
Sounds good - what platform work would we need as they implement the feature in gecko in order to create the tool? Any requirements we have should block bug 616605 as well as this bug.
The basic concept sounds fine - photoshop-esque guides that work alongside the rulers, right? Is there anything additionally we can provide that might help developer understand the grid layout, particularly how it interacts with page resize / media queries?
(In reply to Jeff Griffiths (:canuckistani) from comment #2)
> Sounds good - what platform work would we need as they implement the feature
> in gecko in order to create the tool? Any requirements we have should block
> bug 616605 as well as this bug.
> The basic concept sounds fine - photoshop-esque guides that work alongside
> the rulers, right? Is there anything additionally we can provide that might
> help developer understand the grid layout, particularly how it interacts
> with page resize / media queries?
Yeah, we would essentially show the lines, but also the named areas (which is a very important concept of the spec), as well as the line numbers and names.
Other grid-specific features are the new 'fr' unit (which is useful to occupy the remaining free space, like with flexbox), and the 'auto' length (which sizes a track to the content). So the inspector could also show the authored track sizes, and how they translate into pixels, and somehow why.
I've started an etherpad with Mats (who's doing the work in bug 616605): https://etherpad.mozilla.org/Devtools-CSS-Grids
The goal of this document is to identify platform APIs that will be needed for devtools, and work towards a roadmap to get them done.
I'd expect the tool of bug 1114973 and this one to be at one single place, i.e. a 'CSS Layout Inspector'. This tool would then have an option to switch between the different layout modes.
In case this helps, here are real-world users expressing desire for this tool… in Slack, chatting with Eric Meyer and Rachel Andrew about CSS Grid and Flexbox, and Eric said (unsolicited):
meyerweb [3:21 PM]
@jensimmons: You know what would be _KILLER_ in FF? Having a mode for Web inspector to draw the grid lines on the page. If there was a Gridset-style overlay…man, that would really help a lot of people learn grid. Not to mention really help me!
*** Bug 1241347 has been marked as a duplicate of this bug. ***
Pasting here some summary of a conversation I've had with Mats:
I think the first thing we'll want to do is a tool that overlays the grid structure on the page. It might not always be easy to "see" the grid visually when you have backgrounds, borders, items covering multiple rows/columns, not elements at all, etc...
so if devtools could just highlight the grid as it was defined in css, it would already be a good debugging tool.
That means being able to get the list of columns and their sizes and names, the list of rows with sizes and names, and the list of areas if any, with their names and coordinates.
"resolved values for grid-template-rows/columns" has landed (bug 978212), this should be pretty useful for this (although would still require parsing a potentially complex string).
Since it is possible to have more than one grid on the page (nested inside each other, or simply attached to different sections of content), it makes sense to me to consider color coding each one. For instance, one could have blue lines, another orange, etc. And provide a way to toggle the different visual grid overlays on and off, so a user can look at just one or several.
> The basic concept sounds fine - photoshop-esque guides that work alongside the rulers, right?
> Is there anything additionally we can provide that might help developer understand the grid layout,
> particularly how it interacts with page resize / media queries?
> I think the first thing we'll want to do is a tool that overlays the grid structure on the page.
> It might not always be easy to "see" the grid visually when you have backgrounds, borders, items
> covering multiple rows/columns, not elements at all, etc... so if devtools could just highlight
> the grid as it was defined in css, it would already be a good debugging tool.
Do you all know about Gridset App? https://gridsetapp.com
Of all the existing tools, this is the closest what we need for CSS Grid. (Of course, with big changes since the mental model of CSS Grid is very different than that of float-based frameworks.)
There are two parts to Gridset App. The first is the overlay which shows the grid in action on a site-in-progress. If you go to thewebahead.net, you can turn on the grid overlay and see my grid.
Change the viewport size, and see the overlay change at each of my breakpoints. (The tool only ever shows the grid lines for the grids that are currently active.)
Having more information about the grid design as overlaying labels at the top and bottom on the viewport is very helpful. As a designer and developer, those labels become invaluable references.
The second part of Gridset App is toolset used to design the grid. You have to make an account and login to see it. There's a screenshot of it here: https://gridsetapp.com/img/gridset_interface.png
or annotated: https://gridsetapp.com/features/
Basically it's a very-simple set of dropdowns and form fields which allow you to create and manipulate the design of the grid. Click to add another column. Type a number to change the width of an existing column. Click a dropdown to change all the widths to a golden-ratio-based array. While the tools are simple, what a designer can do with them is incredible powerful.
I could see us going gangbusters over-engineering the edge cases, but truly, what Gridset App has is incredible in allowing designers to create a custom grid very easily, without going nuts.
The big limitation of Gridset App, is that when you manipulate the grid, you are doing so in a separate environment from the web page itself. You have to republish the CSS, and deploy it to see the results on a real-world prototype. (Which, btw, is *way* faster than the alternative, designing the grid with pencil, paper, and calculator, but still).
If Firefox ships a tool to allow folks to:
1) see the existing grid that's been defined with an overlay, overtop of the current page;
2) change the values for the definition of the grid, including with some of these tools for setting multiple columns at the same time using a math ratio; and
3) see the overlay change in real time, on a real webpage
I think that'd be enough. And let people change the assignment of the content items to the grid as a separate step, without a special tool?? [-- or, at least, I haven't articulated anything for that part of the process in this comment]. What I've expressed so far would focus the tool on assisting in the editing of grid-template-rows, grid-template-columns, grid-template-areas. (Not grid-column-start, grid-row-start, grid-column-end, grid-row-end, etc.)
Gridset App was made by Mark Boulton and Nathan Ford. Mark is one of the leading designers in the world, who has a classical art-school-trained background in designing grids. Nathan has worked for Mark for years, and wrote this article on A List Apart, summarizing the thinking about design that inspired the tool:
And here are some amazing additional must-read articles:
(In reply to Jen Simmons [:jensimmons] from comment #10)
Thanks Jen, this is very helpful.
> Since it is possible to have more than one grid on the page (nested inside
> each other, or simply attached to different sections of content), it makes
> sense to me to consider color coding each one. For instance, one could have
> blue lines, another orange, etc. And provide a way to toggle the different
> visual grid overlays on and off, so a user can look at just one or several.
Hm, I hadn't thought about highlighting multiple grids at the same time, but I guess that would be useful indeed. Especially with sub-grids.
We'll need to find the right way to toggle this tool. I can think of several options, none of which I think are really good:
- from the command line (shift-F2): traditionally, we've used this for toggling some of our more experimental tools when we didn't know where to fit them in the toolbox UI. I think that's good solution for beta testing the tool (we don't need to make a new button somewhere for it), but it's way to hidden away for real usage.
- from the CSS rules panel (in the inspector sidebar): this is where you've put other CSS related visual tools, like highlighting all elements that match a selector, or previewing a css transform, or changing a color, a css filter, etc... One idea would be to add a little grid icon next to any grid property (like grid-template-rows, and others).
- from the toolbar button list (top right corner of the toolbox, where the split-console, responsive design mode, etc. buttons are displayed): this is a simple way to add an ON/OFF toggle button, but it's not very discoverable. We're working on ways to present these buttons better, but we keep on adding more and more, and so we have to make a choice as to which ones are displayed by default, and which ones can be added later.
> Do you all know about Gridset App? https://gridsetapp.com
> Of all the existing tools, this is the closest what we need for CSS Grid.
> (Of course, with big changes since the mental model of CSS Grid is very
> different than that of float-based frameworks.)
Thanks for sharing, I hadn't come across that one yet. I really like their grid overlay tool indeed! This is really what I had in mind.
> Having more information about the grid design as overlaying labels at the
> top and bottom on the viewport is very helpful. As a designer and developer,
> those labels become invaluable references.
Definitely, the css-grid overlay should at the very least provide line names and area names. I think it should also display computed track sizes, because this helps debugging too.
> what Gridset App has is incredible in allowing designers to create a custom
> grid very easily, without going nuts.
Coming up with a tool that lets people *create* grids would be both super useful and hard in terms of new UI to build and new UX patterns to come up with. I think we should take things in steps and first work on the overlay tool.
I'm convinced that we need to do it, and not just for grids too. There is so much we could do in devtools to allow people to create markup, layout and style from scratch without necessarily having them write CSS for a lot of it. And we intend to dive deep into it this year, but there's just so much unknown as to how that would look and behave in devtools, that I'd prefer to keep this for a later bug.
> If Firefox ships a tool to allow folks to:
> 1) see the existing grid that's been defined with an overlay, overtop of the
> current page;
> 2) change the values for the definition of the grid, including with some of
> these tools for setting multiple columns at the same time using a math
> ratio; and
As a next step. Knowing that in the meantime, changing grid-template-* values in the css rules sidebar would work fine.
> 3) see the overlay change in real time, on a real webpage
Definitely agree on that! That's why devtools is a powerful tool when working for the web, immediate visual feedback on whatever you're doing.
Created attachment 8712695 [details]
Here's a screencast of a WIP I'm working on to show the lines (and only the lines for now).
It's pretty amazing how helpful that is already, even though it misses the line names, track sizes, areas ...
Created attachment 8712696 [details]
And a second, similar one.
(Oh, don't worry about the big ugly 'toggle' button in the css rules view, this is just my work-in-progress way to work on the overlay)
I've been thinking a lot about this — what would be most useful (v1) vs. every idea. I've been coding quite a few demos in Grid lately, and it gets confusing quickly.
Of course, simply having lines is number one.
Having names on all the lines would be cool. And the areas. And… but, Grid allows for a *lot* of names. An author might easily end up with 3-5 names for every line. It'll be complicated to make a tool that works and is useful (without simply becoming too much information). If a tool that revealed names needed to get pushed to v2, while the lines alone were in v1, that would still be very helpful.
It's very easy when planning content into cells, to not know where you put things. If you put the wrong number (or name) into a property, it ends up someplace unexpected. Which could be no big deal — except it's common to have items placed into the same cell, one covering up the other. And then, it's a big hunt for a hidden thing, one that burns up a lot of time and frustration.
It would be very helpful to have a simple button that could be clicked to put the page into some kind of translucent/vellum/onion-skin mode. Where every grid child gets 50% opacity, so you can see the items that are hidden behind other items. Quickly toggle into onion-skin mode, see — oh, that items is over there, behind that thing (z-index wise)? Ok, that's not what I wanted, let me fix that.
It seems this kind of tool would be much easier to build, and perhaps can go into v1.
*** Bug 1170734 has been marked as a duplicate of this bug. ***
Created attachment 8730520 [details]
grid fragmentation testcase
Now that we support grid fragmentation, this might affect the devtools grid
overlay design. Load this testcase in the very latest Nightly and then resize
the height of the window to cause fragmentation.
I'm assuming you will use getClientRects to get the box geometry for the grid
container? Note that there may be multiple rects now.
Fragmentation breaks only occurs between rows and may also occur before
the first row and the last row. (a break before the first row happens in
this testcase if you make the window height extremely small).
Grid items may overflow the grid container and the fragmentainer too,
so they may stretch into a column* where there are no rows. (the blue
grid items in this testcase)
(*and by column here I mean a -moz-columns column, not a grid column)
The grid columns are always identical between all fragments.
Created attachment 8733126 [details]
Grid by Example 1: Defining a Grid 2016-03-21 15-01-44.jpg
I drew this today, in talking to someone about what would be great for a Grid Dev Tool. The dashed blue lines are the grid lines. The yellow stripes are the grid-gaps.
The DevRel team built a tool. For now, it's an Add-on —— something to give us running code to test, and use.
The Add-on is at https://github.com/potch/gridviz/releases. Download the latest version of the file, for example: "css_grid_visualizer-1.4.0-fx.xpi". Download and open Firefox Nightly (which has CSS Grid implemented without requiring a flag to be flipped. If you want to use another version of Firefox, you must turn Grid on). Install the Add-on from the file. And look in the upper right corner of the toolbar to see the grid toggle.
You can test it out on this example of Grid: http://labs.jensimmons.com/examples/grid-content-1.html. Or find others at http://labs.jensimmons.com.
We've been gathering feedback here: https://github.com/potch/gridviz/issues and in person from folks.
A couple of weeks ago, :jensimmons, :potch, :helenvholmes, :mats, :bradwerth and I met in London to discuss about CSS Grid tooling. Here are some of my notes from this discussion:
- The CSS Grid implementation is very close the being complete, it should ship in under a couple of months.
- The platform API to get grid data is coming very soon too. In fact, I've already had a play with the patches in bug 1241932 and they work great.
- Devtools is planning to work on this in Q3/Q4 2016.
- Being able to ship both CSS Grid *and* the tooling for it at the same time would be awesome.
- In the meantime, as mentioned in comment 20, the DevRel team has built an addon that should act as a simple stopgap that is supposed to go away when we have devtools support.
In terms of features, the following things have been discussed:
- Detect all grids on the page, and highlight them all, in different colors. I think users should have a choice to toggle the grid overlay for grids individually, so that it's possible to check alignments of several grids at once, but it's also possible to work on just one grid.
- The grid overlay should refresh when the container reflows, or the window size changes, or any of the template property is changed.
- A first good step for this tool would be for it to just be an inspector, rather than an editor. Highlighting grid tracks and lines is already a life saver when working with grids, so we should do this first, and then think of more complex editing cases.
- The addon mentioned in comment 20 has already received some feedback on github: https://github.com/mozilla/css-grid-inspector/issues . Of the current list of issues, the following seem important to keep in mind while working on this tool:
- it should work across iframes: https://github.com/mozilla/css-grid-inspector/issues/7
- toggle each grid individually: https://github.com/mozilla/css-grid-inspector/issues/8
- preserve state and highlight again after page reload: https://github.com/mozilla/css-grid-inspector/issues/12 or highlight all grids even while navigating: https://github.com/mozilla/css-grid-inspector/issues/15
- easily detect grids on a page: https://github.com/mozilla/css-grid-inspector/issues/16
- The tool should also support grid gaps.
- Lines have numbers, both positive and negative, they should both be displayed.
- Lines can have many many names, some authored, some generated. The tool should know how to deal with this, probably offer a way to toggle them, or some of them.
- Extending lines all the way to the viewport may be helpful in certain situations, but in others, containing the lines to the implicit grid would work better. The tool might need a toggle for this.
- Maybe 2 modes exist: general overview of all grids, with few information, and then select just one grid and get all the information about it.
Created attachment 8781131 [details]
I'm only attaching the png to be able to flag something for review, but if you could actually look at the Invision link, it's guaranteed to be the most update-to-date version of my Sketch file.
This proposal includes a new panel, which is worth an explanation. I've been ideating on a new panel called "Layout", where we could potentially put the box model enhancements we've discussed in bug 1150496 without crowding the computed panel; better flexbox inspector tooling, if/when we create it; and grid tools. It would block on sidebar improvement bugs, such as bug 1292054.
As for the superreview tag, Brian: I just wanted multiple people to review this, so didn't really mean anything special by the "superreview" tag, if that makes sense :)
Comment on attachment 8781131 [details]
Overall, I like the grid highlight design and layout panel proposal. Will want to talk some more about some of the items in the actual design to better help my own understanding.
Comment on attachment 8781131 [details]
Welcome back, Patrick!
There's some intro discussion to this work in comment #22 that I'd like you to look at, but looking over your email, I think there's more worth introducing for these designs:
I'd love for grid lines to show after a user clicks the "inspect element" command-pick. If toggling grid lines isn't an additional step to inspect, I think inspection tools for it are going to be adopted better. I'd love your and Brian's help to figure out where that falls down. I think this makes more sense than toggling a button to see grid lines, however, as I imagine people will want to immediately begin inspecting grid lines, and inspecting grid cells without seeing the grid will be confusing.
Also: I flagged you for review on a PNG, but Gabe brought up that designs would often fall out of sync between what I have on my system and what was attached to bugs. I have Invision sync set up now, so looking at Invision links in the URL field is your best best as they should be 100% up-to-date.
Comment on attachment 8781131 [details]
Thanks for this Helen. That's a lot of work! I really like the layout panel. I've asked a few questions and made a few comments in the design to keep the discussion there.
Comment on attachment 8781131 [details]
I like it very much. I used the Invision link to add a few comments and answered the questions I could answer.
Comment on attachment 8781131 [details]
Looks like these designs have had a lot of good feedback in Invision already. A couple of general questions about the layout panel and highlighter:
1) For the box model are you thinking of 'moving' the box model UI into the Layout panel or 'copying' it (keeping it in the computed styles as well). If copying, will it be identical or some different version when it opens in layout panel?
2) Is there a way to / do we want to let people to turn off the grid lines while the element is being inspected? For instance, if tweaking some CSS values unrelated to the layout possibly the grid UI could be in the way
3) What happens if you use the eyedropper / screenshot buttons while the grid lines are drawn? Should they be included or hidden for that?
(In reply to Brian Grinstead [:bgrins] from comment #27)
> Comment on attachment 8781131 [details]
> Looks like these designs have had a lot of good feedback in Invision
> already. A couple of general questions about the layout panel and
I can probably help answer some of those
> 1) For the box model are you thinking of 'moving' the box model UI into the
> Layout panel or 'copying' it (keeping it in the computed styles as well).
> If copying, will it be identical or some different version when it opens in
> layout panel?
I think the plan is to have 2 versions of the box model UI. We would keep the "simple" box model UI in the computed-view panel, and have a richer one in the new Layout panel (with info about z-index, stacking context, position, display, box-sizing, floats, containing block, ...)
> 2) Is there a way to / do we want to let people to turn off the grid lines
> while the element is being inspected? For instance, if tweaking some CSS
> values unrelated to the layout possibly the grid UI could be in the way
I think we should let people turn off the grid highlighter. In fact, we're discussing about current highlighter + grid highlighter integration in bug 1297100.
As you hover over elements in the page with the element picker, we should show the grid lines when relevant, and hide them otherwise. Now, we need to define what relevant means here, but it would be really useful.
*** Bug 1282730 has been marked as a duplicate of this bug. ***
I've added this to the experimental features page:
Created attachment 8835921 [details]
I found that the current devtools shows that the line number is inconsistent with this picture.