Powerful New Additions to the CSS Grid Inspector in Firefox Nightly | Hacker News Reader

Powerful New Additions to the CSS Grid Inspector in Firefox Nightly

hacks.mozilla.org

134 pointsjanober33 comments

I work at Mozilla, but I'm excited about this because I'm a web developer!

If you've ever tried to use flexbox to align content across multiple rows (like laying out a form with labels), you'd know that it's not a true two-dimensional layout tool. CSS Grid is, and will likely supplant flexbox as a flexbox is merely a one row/column grid.

The inspector is a pretty handy way to see what's going on under the hood, and being able to see the line numbers and named areas is great for visual debugging.

I'm sure this is not the correct way to ask but still, I just logged in to ask you this: Can you guys please add this feature other consoles have where you can use the mouse scroll-wheel to add or substract to CSS properties on the console? IE. font-size, border size, width, etc.

Hi Mozilla, this is great, very impressive.

Quick question: how do I search through all CSS styles loaded on a page using Developer Tools? For example, if I wanted to search for all the instances of "float: right" in all stylesheets, how would I do it?

Not that I don't love all the new tech, but I really wanted to search for all instances of "float: right" today, and I couldn't figure out how to do it. I recall I could do this global search through the Styles panel with Firebug in the good old days. I consider the weak global search in the various Developer Tools panels to be a painful regression.

While I'm on my global search grumbles soapbox, the search results popunder that appears below the search bar in the Developer Tools|Debugger tab is very annoying. When I did similar searches in Firebug, as I cycled through matches to my search, it just switched from file to file and then scrolled to each matching row. Why can't you do it like that? You don't get enough screen real estate when Developer Tools is docked for a pop-under to work UX-wise. If I wanted an "IDE experience", I'd run your WebIDE.

It also occurs to me that the popunder search results preview encourages haphazard mouse interaction with the search results rather than keyboard interaction. Please load a pre-e10s version of Firefox with Firebug and do a global search (look mom, no bang prefixes required!) on a page to see how nice and natural search in your browser can be.

You can search using the Style Editor: https://developer.mozilla.org/en-US/docs/Tools/Style_Editor

Press Ctrl/Cmd+F to search.

It's not presently possible to search across all files at once, but the Style Editor is one of the tools is due for an update to match the current Debugger tool which has a better interface!

> .. the current Debugger tool which has a better interface

Respectfully, I disagree. The debugger tool's search in files is klunky with the bang prefix required to search all files and the search results shown in a scrollable popunder panel. Search should operate over all files/nodes in the current tab's category by default. And, it is bad UX for a tool that itself is (usually) a docked panel in the main browser window to have temporary panes appear that crowd out or obscure their neighbors. You've already got a file tree on the left, why not make that a twisty tree and categorize the search results under their parent files there - that is, if you feel your developers must have fancy clicky bits.

For those interested, here's some related bugs to look at:

Can't search in multiple sources in the Style Editor https://bugzilla.mozilla.org/show_bug.cgi?id=889571 (4 years old)

Firebug gaps https://bugzilla.mozilla.org/show_bug.cgi?id=991806 (3 years old)

The comments in that Firebug gaps ticket hurt me to read. Firebug got shanked by you guys like over a year ago and Developer Tools aren't close to feature parity.

Dear Firefox product owners: developer tools have to be great for the boring use cases -AND- the sexy HTML5 debugging use cases. Please put more resources into the Firebug gaps ticket and knock that one out.

When they said "current debugger tool" they were referring to this Debugger[0].

[0] https://github.com/devtools-html/debugger.html

There's lots of great UX enhancements there! I'm so looking forward to this!

Is this really the "current debugger tool" though? It doesn't ship with Firefox yet, does it? It's vaporware to users until it's displayed in developer tools and WebIDE.

I really wish this new Debugger would not show search results as a popunder/panel replacement the way that devtools does though! You have a massive amount of precious screen real estate in the debugger already devoted to the script sources panel. Why wouldn't you just cycle through matches in the actual script sources where the most characters surrounding each search result can be viewed by the user? Not only is using the script sources as the viewer for search results simpler to code, but the user is not taken out of the flow of their script editor/viewer in order to cycle through the results they've requested. What's the usecase that is being satisfied by breaking the user out of the script editor here?

The irony here is that this kind of styling used in this devtools example(hovering over one element, highlighting another), cannot be done by css itself.

Here is a horrible hack with a hidden input https://codepen.io/bushyn/pen/pwwXXY

Next-sibling selectors (+) are not a hack. No reason to do this with an input, any element will do.

No, next-sibling selector was not the point. You need that label+input combo to do something like in the video using only css https://codepen.io/bushyn/pen/owevJO

Sorry, I didn't get that your example was trying to not just take advantage of the next sibling selector but also the relationship between inputs and their labels, which don't have to be close to each other in the DOM. I can see why you'd call it a "hack."

However, in the Pen, all I'm seeing is the square over which I hover turns purple. That is, .item:hover { background: blueviolet; } does what it's supposed to and that's it. I get the impression that what you expect to happen is hovering over box #1 in .grid will also change the background of box #1 in .grid2, but it doesn't. I tried it in Chrome and in Safari 10.1.1.

I assume this is because A) hovering over a label is not equivalent to hovering over its associated input and B) you can't hover over an element set to display: none; (as input is).

Interesting! I got it to work. Turns out hovering over a label can be equivalent to hovering over its associated input, the problem was input { display: none;}. I changed the input declaration like so and it started working:

input { position: absolute; width: 1px; height: 1px; padding: 0; margin: -1px; overflow: hidden; clip: rect(0,0,0,0); border: 0; }

Part of the horribleness of this label - input hack is while the semantics of those elements may not be apparent visually, they are very apparent and intrusive to a screenreader user.

Not entirely true, below is the adjacent sibling example (+).

It's true you can't highlight an arbitrary element by hovering/focusing on another element.

CSS grid looks interesting, but we still need to support IE. Is there a shim/poly fill available that has been tested in production?

IE 10 and 11 support an earlier revision of CSS Grid via -ms-grid (old enough to still have prefixes!). You may be able to polyfill the basic support that way.

Note though, it’s a very different grid (syntax/properties evolved): https://rachelandrew.co.uk/archives/2016/11/26/should-i-try-...

autoprefixer should be able to handle this: https://github.com/postcss/autoprefixer#disabling

> grid: true will enable Grid Layout prefixes for IE.

this should have been an extension... seems too specialized to a technic I hope will not endure the test of time.

You could just as easily say all dev tools should be omitted from all browsers and made available as extensions instead.

You hope web designers won't take to using CSS Grid? Do you think sticking with hacks like floats is better?

Use Flexbox. CSS Grid doesn't solve anything you can't already do with Flexbox. They're both optimized for user interface design.

Many css grids are todays actually made with flexbox. Bootstrap 4 does that.

But this tool is actually about the "grid" property, which is a nice tool to do grids natively.

The entire CSS Working Group just facepalmed.

Here are a couple of articles that should help explain when CSS Grid would be a better choice than Flexbox.

https://rachelandrew.co.uk/archives/2016/03/30/should-i-use-...

https://css-tricks.com/css-grid-replace-flexbox/

BTW, Microsoft Edge has the current CSS Grid syntax available behind a feature flag (available in Windows 10 Insider Preview build 16226).

https://wpdev.uservoice.com/forums/257854-microsoft-edge-dev...

This is categorically false. CSS Grid and Flexbox do have overlap, but Grid complements Flexbox, and the two together get a LOT closer to the "holy grail" of purely semantic markup then either alone.

That, in turn, has real benefits: the less "styling" nonsense is baked into your markup, the more powerful the ability to use CSS media queries and other tools to transform the presentation based on device and other contextual information (e.g. different embedding of the same content)

FWIW, I've shipped "grid in Flexbox" sites. Flexbox was better than the-bad-old-days, but still kinda sucked, simply because of the hacks needed to make Flexbox approach grid layout.

The purpose of Firefox Developer Tools is to make debugging web pages easier for web developers. It’s not meant to be used by regular users. Inspecting elements and their applied styles is an integral part of web development, and this just makes it easier to debug grid layouts.

> It’s not meant to be used by regular users.

That, I believe, was the foundation of @gbc0's point.

And on that basis I'm inclined to agree - why download, install and run for every user a set of tools that could as easily be installed the first time they are accessed?

Because while it's not for every "regular user", it's a tinkering tool which allows some "regular users" to start diving into the guts of the machine, get better insight and possibly decide to make it their life's work, in much the same way many of us got started because we had machines which let us peek and prod "under the cover" so to speak.

Yes. "View source" being in pretty much every browser from the beginning has been an important part of the democratizing nature of the web. As web sites and development have gotten more complex, have dev tools baked into most browsers and continually adding capability helps reduce the barrier to entry.

I appreciate that Firefox has chosen to differentiate their dev tools from others by adding a tool like this. Google Chrome dev tools seem to be more focused on performance testing. It wouldn't be a bad thing if one set of dev tools was better for performance and JavaScript debugging and other was better for solving visual design problems.

Indeed. Expressiveness has not been a big focus in the past. We'd like to change that with Firefox. What kinds of tools would you like to see for solving visual design problems?

Sure, since these features are just written in HTML and JS (the modern Firefox devtools use HTML, not XUL), they could certainly be downloaded on demand. The added complexity of that combined with the relatively small size of the code that implements the the UI means that there's not much reason to do so. And it's only the UI that could be downloaded on demand; it'd be pretty hard to break the JS engine in half to put breakpoints into an extension, or to ruin the layout engine so that you need an extension use the CSSOM.

Having the dev tools integrated means that they are still available if you're using some machine (e.g. a school PC) where you cannot install extensions.

Reply on news.ycombinator.com