Navigator Panel #144
Comments
taylornowotny
added
help wanted
|
Oleg: So the component name = the name displayed for that element in the Navigator panel, correct? As far as I know that will work just fine As a low-priority feature in the future, many Webflow users wish they had the ability bulk re-name elements via the navigator panel. Figma has a UX flow for this that we can imitate |
yep
How can one bulk-rename components which have each different names? I mean do they need a name that has a base part and some generated suffix (e.g. 1,2,3) ? In any case, for bulk-renaming we should have a separate issue. |
|
What if the user could hide an element from the Navigator like you can hide layers in design programs like Figma? We'd have an eye icon that shows when the element is hovered in the Navigator. Clicking it would apply display: none to the element. Clicking it again would apply the display settings that were previously applied before it was hidden. (Is this a technical challenge?) Hidden items would grey-out in the Navigator to indicate that the item is hidden. Webflow doesn't have this, so keeping track of hidden items is a bit of a pain. For example anything that doesn't show on the page by default but is revealed by an interaction, such as a dropdown menu, would be hidden. In Webflow you just have to remember that it's hidden. But if we grey-out hidden items in the Navigator, that makes it easy to keep track. Thoughts? |
|
@taylornowotny lest make this hiding a separate issue, if doing it I would not set display, I would mark it as hidden in the data structure and not render it at all. Setting display still renders it in the dom, but doesn't paint it. |
|
Display: none is actually what we want I think The Navigator should represent the HTML structure of the page, so if an element is hidden but still in the Nav, I would expect it to still exist in the DOM but not be rendered on the canvas For example a modal. Meant to be hidden at first, then show when appropriate. We don't want the content of the modal to be removed from the DOM we just want it to not display |
|
And if it was display: none but still part of the page then it could still be moved around in the navigator and have properties applied to it, it just wouldn't display Basically the same behavior that a designer would expect from layers in any design program |
That's not a great way to render modal or generally render any hidden element that will be used once upon the time.
Why? Just because something is in the navigator but isn't on canvas dom tree? What is the problem I don't see |
|
@taylornowotny for you to understand why UI engineers think this way: DOM has a cost, high cost. We don't put in the dom anything that we don't need to show. |
|
@kof Well I don't have a great understanding of how engineers use the dom so you can let me know if these are valid concerns: The main concern I have is SEO. Search engines needs to be able to crawl all the content on the page, even if it's inside a modal or a menu that is hidden from view. Will that still be possible if the element is removed from the DOM? Also, if a code embed element is hidden, would that code still be able to execute as part of the page? My phrasing might not be perfect here but in Webflow I have a set of code snippets that goes on every page. I put them all into an embed element. In Webflow the embed element takes up no space so it doesn't show anyway. But what if I hid a Webstudio embed element, would that prevent the code from working? |
That's a whole different topic. Not an expert in SEO, but it was considered a red flag by google crowler if something is in the HTML but something else is actually rendered on the page to the user. Basic rule I remember is that google wants to index same content users can see. Its probably not as simple as that and they may be smart to identify stuff like modal. So what you are trying to do is to show to the user one thing, but show to the search engine another thing. This is generally considered as an attempt to trick the search engine, back in the days sites were blocked from search entirely which tried to do stuff like that, but I don't know how things are nowdays. |
That would depend on how we decide to implement such embeds. It does seem logical to me right now that if you hide an embed then it won't get executed. |
Not exactly. What I mean is, the google crawler doesn't use a website like a human. It can't open menus or show modals. If those menus are set to display: none in CSS then they aren't hidden from google at all, only from the human users, and only conditionally. If google had a problem with display: none then every site with a hamburger menu would be problematic for SEO. For many companies SEO is the #1 factor when choosing a site builder so this is something we want to get right. I know Webflow gets a lot of market share from SEO-minded marketing teams because it allows more control over the HTML structure than WYSIWYGs |
|
If the element is style |
It actually tries to use a website like a human, they use browser engine to render things.
it totally can and probably does and if you build something that opens for humans one text and for crowler another text it may consider this an attempt to trick it.
yes but also if its not visible to the user, they will not index this part or will keep the ranking for that piece low
Yeah, they are probably smart enough to differentiate actual attempt at tricking them from just a closed menu I know SEO is very important and I also know that webflow has a lot of problems there too. Let me involve an expert here to give you a full picture. |
|
@natlusyht I was thinking that hiding from navigator should be removing the instance from render tree. It should not do the same thing we can already do in the style panel: display: none |
|
@natlusyht more specifically, I'm wanting to know if we can apply I am not certain but I think |
|
@kof That's a good idea. It would be great to have ongoing support from an SEO expert who has used site builders before. In this issue and others we want to have a platform that is optimized for SEO |
|
@taylornowotny I am not sure how this compares to figma, because in figma it just doesn't show on canvas, there is no dom behind canvas in figma, that element simply doesn't exist on canvas when its hidden, right? |
|
@kof yea the figma reference is just for the UX, to show what I want it to look like To clarify, the reason I think it would be valuable to apply |
|
@taylornowotny all those benefits seem to apply also if we remove the element from the tree on canvas |
|
@kof yes for sure, but we don't want to negatively impact SEO in the process |
I am 90% certain we are not, will get a 100% statement from expert. |
|
Also what I don't get is why would you want to hide something and yet assume SEO benefits. Its literally trying to hide information from user but give it to the crowler. If intentional its not a thing search engines like to see. |
Dropdown menus, mobile nav (hamburger) menus, modals, and tabs. They are meant to be seen by the user and meant to be crawled by search engines. But the functionality of these components requires that they only be conditionally visible to the user. |
|
Ok in such cases you don't want to use the hide/show button in the navigation, you want to use the display style property. To me this seems very logical |
|
Hide/show in the navigator would be for things you don't want to be rendered because they are not ready or because you decided to stop showing them to the user entirely. E.g. some promo event that you enabled for a month and then disabled. |
|
The hide/show button in the navigator is just meant to be a shortcut for the the display style property It's not essential, but would make it significantly easier to work on things like nav menus with a lot of dropdowns. And it would mean that you can see at a glance which elements have display: none applied, without having to select the element first |
|
@taylornowotny I think I get it now, its how it works in figma apparently, I didn't realize it is essentially a shortcut for the layer visibility that you can as well toggle in the layer on the right. |
|
ah sorry if I didn't make that clear Should I go ahead and include this in the design then or wait? |
|
Yeah, we will figure out this rendering detail as we go, but I think its useful either way to have it |
|
Whether it's rendered to the DOM is semantic on the implementation front. But it would be better rather than not to be able to glean the hidden/display nature of the element in the navigator. There's no doubt that someone could set display to none regardless of what that does to SEO, it's not like we would disallow this in the style panel; with that in mind, the only other way to find that element after it has been set to display:none is through the navigator, an indication of the nodes that are indeed display:none/hidden should thus be accessible through the navigator: beyond the added action of clicking a node to see it's style/hidden properties. For example Chrome dev-tools has this indicator for flex parents, has hidden attributes for hidden elements, etc.
|
This issue is to discuss all details of the Navigator panel that are not already covered in Issue #131
Suggestions:
Make it pinnable - As a user I want the ability to pin the navigator panel so it's always open on the left side (I have this permanently enabled in Webflow). I use the Navigator in Webflow frequently so it saves me a lot of clicks to have it always open. Having the Navigator always pinned is like having the layers panel always open in figma.
There's also the issue of naming elements.
In Figma you can name layers directly (and most users don't). In Webflow the element name in the navigator is the name of the class.
What do you think our approach should be here?
The text was updated successfully, but these errors were encountered: