Backend HTML and CSS cleanup

[acrylian]

Longterm project probably not managable exactly for 1.4.5 but later.

General tasks (this is a test of the new GitHub markdown feature):

• Remove all inline CSS and generalize CSS classes/ids
• Add classes to better address elements
• Remove tables where not really applicable
• Remove <br clear="all" /> calls being deprecated in HTML5
• Replace icon graphics using icon webfonts for coming flood of HiDPI displays
• Responsive layout

[acrylian]

I move this to 2.0 for now as I don't think I will manage anything for 1.4.5. Most likely I will get on it for 1.4.6 first.

[pju-]

Would it be possible to make the markup more verbose at the same time with specific ids and/or classes for the different backend elements?

This would allow for easy customization via css/js - for example allowing to mark necessary fields, hide unused fields or adding a comment on how to use codeblocks or similar things. This would make it easier for me as a developer to show my clients how to use the backend. I wrote a bit more on the topic in the forum: http://www.zenphoto.org/support/topic.php?id=329938&replies=1#post-476592

[acrylian]

That would probably be doable and makes actually sense. However this will take a quite some time since it is a major rework so I am not sure when I will actually start with this. Probably next year sometime. Too much to do and too less time…

[sbillard]

As a developer, perhaps you would wish to contribute to this. You could make a branch of the 1.4.6 release, make changes to it, and make pull requests to 1.4.6 for your changes. We welcome contributions.

[acrylian]

Contributions are of course welcome. We do use some already but adding more ids where missing would be possible probably.

But the cleanup of the backend will be major work affecting whole admin including lots of functions since both is not directly separated. Also indeed things might be changed regarding usability and layout (who knows) then all this might be too soon. I think that should not be done inbetween (think of all the merge issues that will cause, too).

[sbillard]

Of course that presumes that both are being worked on simultaneously. So I guess each of you needs to declare his timeframe for making changes. We don't want unneeded conflict, but it is also not reasonable to delay doing something because someone else might at some unspecified time in the future do something.

[acrylian]

True indeed. Then I suggest @pju- takes a look at adding the ids then.

[acrylian]

An idea for the naming convention: The main parent elements like the boxes on the right should probably be named like "album-editbox", "image-editbox", "page-editbox", "news-editbox" etc. and the child elements to address like "album-editbox_" etc.

[pju-]

Alright, I'll have a look. I'll start with admin-edit.php as I guess it is the top priority. Not sure though what you mean with the "boxes on the right". I'll have a closer look at the html structure and get back to you with a suggestion.

[acrylian]

I was referring to these one the right which every edit page gallery or Zenpage has.
http://www.zenphoto.org/screenshots/zenphoto-admin/album-edit.jpg.html
We we add ids to hide fields we probably should add some there as well.

[pju-]

One thing I didn't really think of before is that in the image edit view each element appears several times, so IDs
are out. Not optimal for javascript performance, but much better from a usability standpoint anyways.

I think chaining the names should be kept to a minimum. After all, specificity can be achieved by chaining selectors. Right now, every tag is prefixed with edit_ to categorize.

Here's a suggestion:

    <div id="tab_albuminfo">
      <form id="edit_album">
        <table class="edit_main">
          <tr class="edit_owner>
            <td class="edit_label">
              Owner
            </td>
            <td class="edit_input">
              <select name="owner">

For the boxes e.g.:

<div class="edit-box edit-box_general">
<div class="edit-box edit-box_tools">

For fields with a locale, append the locale:

<input class="albumtitle-de_DE">

Couple of examples:

Select the album owner row:

#edit_album tr.edit_owner

Select the description textarea for albums AND images:

tr.edit_desc td.edit_input

It might be better to make the edit_input class more specific - edit_textarea, edit_select etc, but then you would always have to look up the type.

There's a couple of questions arising, but I'd rather discuss them once we've settled on a general structure.

[acrylian]

Looks good so far. Each plugin that adds something to those boxes for example would have to follow those naming conventions.

Speed is probably regarding class vs id not really much an issue since we are on the backend that is probably not with that much traffic.

We may need to suffix/prefix the edit-box-general/tools/etc additionally or add another class since we have these boxes on Zenpage items as well. edit-box-album, edit-box-image etc.
We might want to be able to address those independently. We probably could do by a general parent class on the main content wrapper though as well.

(As you notice there a lot of tables used, those of course are on top of the list to be removed when this is being reworked :-))

[pju-]

Okay, so should I just create a fork and come back to you whenever questions arise?
One thing for example would be whether it would be possible to edit existing class names as well if it serves consistency - for examples the edit boxes have a class box-edit for styling. With the new naming scheme it would make sense to reverse that to edit-box, but that would mean a break with tradition of course.
There's also some inconsistencies with what gets an id and what doesn't between the album and image views ...

[acrylian]

With the new naming scheme it would make sense to reverse that to edit-box, but that would mean a break with tradition of course.

I think those are not "written in stone" and if we manage to get the styles right. But it needs testing since there might be some functionality like js or else tied to that. I don't know offhand. Similar probably with the id vs class inconsistencies. A lot is grown as with all year old projects (thus the ticket :-)).

[youssefelmourabit]

Is what the icons will be integrated in the next version as in piwigo:
http://piwigo.org/screenshots/piwigo-2.9-admin-redesign.png

[acrylian]

A little weird question, don't you think? ;-) No icons in that way probably, but a similar main menu on the left most certainly yes.

You will have to wait until all is ready ;-)

[youssefelmourabit]

Thank you @acrylian I'm looking forward to seeing the next big update