I wish WebFlow would provide a detail feature
that allows us to see everything connected to any element.
For example… display a list of every element - and below element
a list of every sub-element, or transitions assigned to that element.
ie:
section->container->row->column1->input-1:transition:transition 1 name
section->container->row->column1->input-:transition:transition 2 name
section->container->row->column1->input-2:transition:transition name
to do this… you would need a unique id for every element though…
which I’m sure they already have.
This is something we’ve been hoping to do for a while now! I started a new feature request in our Wish List on this. @Revolution Can you add any new ideas to this thread about this. Excited to hear feedback from the community
Some big challenges are emerging as Webflow grows and systems scale.
A navigable cross referenced detail quickly becomes essential for any site that features complex or numerous simple interactions.
A few problems due to the lack of a detail view or visual prompt:
It is easy to accidentally apply an interaction to an unintended background element and the results are pretty dramatic. Try init hide - accidentally applied to your body and your site.
Changing the name of any class element that has an interaction applied is a disaster. The new name won’t break the existing interaction, but those instances are never targetable by any new IX using the new name. To do so, you have to accurately restore the original name (from memory) or start over and rebuild the IX after removing any existing ones (ouch). I would like to somehow obviously know that the IX is affecting that class…
Some type of cross reference visual tagging to identify element and interaction use is an important portion of the the solution I think. Currently they are hidden deep in IX and completely invisible absolutely everywhere else. Especially targeted elements that have no direct application that would show lit up in the IX list as an effector / driver.
Currently you cannot browse the navigator and see when any of the directly applied interactions that would light up in the lIX list, because both tabs (navigator and IX) cannot be open at the same time. Even if they were both visible, it would not pose a solution for targeted instances.
Some type of micro tag like the one that appears top left when any element is selected would be a great help for finding and selecting an object that had an interaction applied, but targeting other elements or heavily nested elements makes that a challenge in the nested hierarchy of the designer. I think even a tiny key (colored dot) applied to the element in the navigator tree and on an object in the layout would be a huge step to identify that an interaction is applied or affects that object / class but it would need to include ones that are indirectly targeted.
A filterable by type / search based solution will eventually be a necessity I think as Webflow grows and practical site complexity explodes along with new systems and capabilities. The 3d apps I use rely on them heavily to make enormous systems and interactions and associations across numerous lists thousands of times more complex instantly scale to be become understandable.
If you would like examples let me know and I will try to put some screencasts or screenshots together for discussion.
Another way of looking at it on a potential solution side. I can look at Chrome inspect element and see from a very different perspective all of the things you have listed and a great deal more:
Selecting an element allows instant drill down.
CSS:
class hierarchy
any redundancy
unintentional properties
things that would be better appropriated or should be moved to another class
and a zillion other things. So my thought is, would having the ability to navigate and inspect code in some sort of syntax highlighted IDE editor in a similar fashion in the Webflow designer solve most cases? To me it would reveal a ton.
Having even a read only generated code view (without an editor) would also promote learning by closing the loop, make for rapid debugging and diagnosis, speed help and support in the forums, etc.
Seeing the resulting code is very revealing. I used the chrome inspect element to help someone in the forums find a mystery text shadow that was showing up on their site. They had attempted an exhaustive search in the designer. It was obvious to me in a matter of seconds looking at published code in the web inspector. The shadow was on the root / body element and I could see every overwrite or modification in the class structure to my selected instance.
