Ply: A Visual Web Inspector (2018) [slides](slim.computer)
slim.computer
Ply: A Visual Web Inspector (2018) [slides]
https://slim.computer/ply-uist-2018/#/title-slide
11 comments
Neat, it would be an interesting linting tool to help minify CSS. I was wondering why the pruning tool took so long but I can see they are using visuals to determine if a a style is needed or not. That's a really smart way to do it, I wonder what other use cases there are for mapping visual images to code. This is almost like a selenium test for CSS.
I wonder how broad the definition of effectiveness is in their implementation. The visual method might have limitations, considering that many CSS properties are only "effective" when you start moving/interacting with elements, e.g. resizing the window/elements, or hovering over elements or using other cursor actions.
Looks like good ol’ screen diffing. It may be possible to use heuristics to detect when a rule might be important for layout in other configurations but this is probably good enough for the stated purpose of highlighting what CSS is important for learning.
What happens in the case where you have two properties, A and B that "work together"? For example disable A and visually the element stays the same, disable B and visually the element stays the same, but disable A and B and the element changes (and based on the way you regress it might falsely tell you that A or B is effective depending which one you disable latest).
I like the idea but I think it's applied in the wrong end of the stack. Learning that z-index requires a defined position value is just part of learning CSS, however frustrating that may be. The answer to the question “How do I make a form like this?” is one that involves the pros/cons of using flex or grid or floats or tables, class name hierarchy, style inheritance, etc. Instead, what we have are junior devs thinking "I know how to do this with Material UI but I've never done it from scratch" so they search for 'booking bar layout' and only learn how to tweak other people's code and not have the confidence in writing their own. What's worse is that this tool is further encouraging devs to reverse-engineer first and learn later, rather than learning as you engineer.
It's exceedingly common that programmers don't know how to do frontend web development, but are tasked to do it anyway, often with unrealistic time constraints. Tools that help them achieve their objectives successfully are always welcome.
"Learning CSS" is a years-long pursuit, and it's constantly evolving. I was a frontend developer most of my career (and by all accounts a pretty damn good one), but I've spent the last four years almost completely on backend work. I have some frontend work coming up and I am honestly nervous that it will take quite a bit of time and consternation for me to become productive with whatever has changed. (It's almost certain I'm going to need to learn grid, who knows what else.)
Am I going to look to a tool like this to help me get back up to speed? You bet your ass I am.
"Learning CSS" is a years-long pursuit, and it's constantly evolving. I was a frontend developer most of my career (and by all accounts a pretty damn good one), but I've spent the last four years almost completely on backend work. I have some frontend work coming up and I am honestly nervous that it will take quite a bit of time and consternation for me to become productive with whatever has changed. (It's almost certain I'm going to need to learn grid, who knows what else.)
Am I going to look to a tool like this to help me get back up to speed? You bet your ass I am.
Looks cool. On the other hand having to figure out what CSS properties do and dependencies I think has helped in the long run. This seems like a tool that is good for short term success but may slow down long term success.
I appreciate the effort in improving CSS dev tools. I rely on them a lot, and just looking at those slides you can see how difficult of a problem it is to solve.
Flexbox and CSS Grid have introduced another level of complexity, in that, the display value of an element turns its direct children into flexbox/grid elements, making their display value irrelevant. It also makes their flex-* properties effective. You'd have to parse the DOM tree to detect such dependencies.
Also, pruning innefective properties isn't that easy because you need to take into account the context. Let's say you have a blue button with white text. This button is in dark navbar that also has white text. Apparently, the button's color is ineffective because inheriting its value from the navbar would suffice. But that same button in a dark text context would make the color property effective again. Since the button would have the same CSS class, you can't prune the color for all instances.
Definitely a hard problem to tackle.
Flexbox and CSS Grid have introduced another level of complexity, in that, the display value of an element turns its direct children into flexbox/grid elements, making their display value irrelevant. It also makes their flex-* properties effective. You'd have to parse the DOM tree to detect such dependencies.
Also, pruning innefective properties isn't that easy because you need to take into account the context. Let's say you have a blue button with white text. This button is in dark navbar that also has white text. Apparently, the button's color is ineffective because inheriting its value from the navbar would suffice. But that same button in a dark text context would make the color property effective again. Since the button would have the same CSS class, you can't prune the color for all instances.
Definitely a hard problem to tackle.
With the "pruning" feature I see a possible path for advanced minification in CSS and possibly in other parts of the web stack. Instead of having each element inherit from several classes, a build step could reduce all dependencies on each element and pack an optimized CSS file while ensuring visual integrity.
[deleted]
I like this. One of the things that has always bugged me about CSS is that after a few iterations you get non-obvious interactions between rules.
In fact, I’d love to have a CLI tool that would take a website (or a set of CSS files and a sample HTML layout) and spat out the minimally effective CSS required for it — an optimizing compiler, if you would.
In fact, I’d love to have a CLI tool that would take a website (or a set of CSS files and a sample HTML layout) and spat out the minimally effective CSS required for it — an optimizing compiler, if you would.
Even though it's not a compiler, SingleFile [1](and SingleFileZ [2]) can do that. It will compute the cascade, remove almost all the unnecessary rules, and minify the CSS.
[1] https://github.com/gildas-lormeau/SingleFile [2] https://github.com/gildas-lormeau/SingleFileZ
[1] https://github.com/gildas-lormeau/SingleFile [2] https://github.com/gildas-lormeau/SingleFileZ
This is neat. Kinda related: For anybody new to CSS (or anybody that just finds it a pain) I found using Tailwind CSS upped my design game.
Using a limited number of selectors helps you reason about what each property is doing and highlights how many superfluous properties you've been using to accomplish what could be done rather simply.
Using a limited number of selectors helps you reason about what each property is doing and highlights how many superfluous properties you've been using to accomplish what could be done rather simply.
Really neat tool.
So the way Ply works is it deletes each CSS property and looks for visual regression; but what if the deletion of a CSS property introduces visual differences only under certain screen sizes due to the use of media query?
So the way Ply works is it deletes each CSS property and looks for visual regression; but what if the deletion of a CSS property introduces visual differences only under certain screen sizes due to the use of media query?
and Github:
https://github.com/sliminality/ply
"Several of Ply's core features have been released as Inactive CSS in Mozilla Firefox 70."