I originally did this because I didn't want to accidentally call
Tag.normalize_name and forget to pass the valid parameters. However,
having this single method be on PhotoDB while the other norms are
part of their proper class has been an eyesore.
So since there are only a few calls to this I'm just inlining them
and trusting to not forget if I add more in the future.
The upside is that we can get rid of some redundancy and reduce
the friction of adding more commit messages.
The downside of this is that the log statement always reports from
commit, instead of the function calling commit. But with unique
messages this shouldn't be too much trouble and should be worth it.
Previously, on very narrow screens, the album cards were spilling
out of the container. Now they are better contained but I am
still not 100% satisfied with the margins between them.
Without this, the grid-view album cards were displaying above
the sticky toolbox because of their position:relative, which
I can't get rid of at the moment.
- In Firefox, the image under flex would be full-res height
instead of staying screen height.
In this new Grid-based layout the image is the correct size.
Left toolbox still uses flex, no problems with it.
- Redid the classing of the photo_viewer and eliminated
photo_img_holder so that all media types follow the same markup.
- Added a CSS variable for tracking narrow mode instead of relying
on coincidental properties like flex settings.
- album card has placeholder for future thumbnail.
- replaced nested tree hierarchy lists with separate boxes.
- list/grid view also applies to the root listing.
- added a sticky right panel for all the tools. not pretty yet.
- mechanism for adding sticky panel changed. instead of applying
it to the #right, you apply it to #content_body so that its
grid layout can be updated properly.
Alright, I got tired of confusing myself with the same-named
outer and inner package.
Keep in mind that every frontend implementation is supposed to be
its own independent project where etiquette is nothing but a
dependency. So the name backend is not ambiguous with the etiquette
backend.
