I'm probably being picky here, but the opening/closing animation of the trays behind the right sidebar is a little ugly. I think it shouldn't be visible behind the sidebar.
@jbudd I can see the dashboard sidebar content causes the whole panel to scroll - so that header scrolls off the top, but it scrolls back into view. Is that what you're seeing here? Can you just scroll the panel down to see the toolbar fully?
For me, the behaviour is the same in v4 and v5.
The new headers on the panels are completely outside the container of their content.
Quite possibly. We left the default to light initially as that's what all users will be used to and didn't want to cause a panic. I can see pros/cons either way with that.
Fair comment. We wanted to keep all the sidebar controls together. I can point to other applications that do a similar thing. For example, VSCode puts all of its sidebar toggles together in one place:
Fair comments. The goal here was to get feedback on it and to help us fine tune it.
With the slide animation, it felt odd having it appear out of no where, and with the panel overlaying the workspace appearance, this is the result. We'll likely leave it as-is for now, but something to revisit.
A PR to remove them would be welcome
NR5 will recommend Node 24 (which will also be the default node version in the docker container). The minimum supported version... we haven't introduced anything that requires Node 24 to be the minimum - it's always a challenge to pick a version for that. We want to ensure a smooth upgrade path, but equally recognise that the npm ecosystem moves forward faster than we do sometimes.
Well I was not scrolling up or down and of course I can not now duplicate the situation where the sidebar is wide enough to show all 3 tabs Layout, Theming & Client Data, yet the scrollbar is shown.
I'm sure you are right, the overlap is just because of the position of the scrollbar.
Having a selection highlight that borders the element with a small gap is a super common pattern. I can point to a dozen existing tools that use that sort of style.
You keep making aggressive and unfounded accusations of us stealing your work, so I'm simple not going to look at your work.
Instead of using a padded border, perhaps applying a blend-mode to the background color+border color of the node would be more subtle and still 'obvious', although i personally never had a problem with the current selection, still blend modes could be used for it as well.
@knolleary I like your mockup? or beta whatever, I don't like the idea of making the highlight the same colour as then it's not really a highlight, too easy for my eyes to blend them together and miss it
Agree, multiple selected nodes would look a mess (imho) and then you will have edge cases of white nodes (eg comment) with white border on white background. (Ditto black) Better to have one “this is selected” colour. (Even if it can then be styled/themed)
Yes, we want a consistent colour to indicate the selected state.
As part of the focus of NR 5 has been a general accessibility review of the default theme, we've made lots of small changes to things that haven't been touched for a long time.
Having just the border of the node change colour when selected didn't pass accessibility testing consistently. Having the small gap between the node and the selection 'halo' helps solve those problems as it doesn't rely on just a change in colour to show the state, and works well regardless the body colour of the node.
Really hoping to see a gradual reduction in the use of px sizing as well. Not only does that hamper accessibility, it also hampers the adjustability of the UI.
