Analizing page layout and CSS use

Serge D
Serge D's picture

Joined: 2009-06-11
Posts: 2139
Posted: Fri, 2009-10-16 02:20

I was analyzing some of the layout decisions and CSS names used by the theme.

First observation - .g-menu is used to mark <ul> in two contradicting situations: navbar menu and toolbar menu... First has drop down structure, while another is simply a set of buttons.

There is a sample of better use on names - .g-context-menu - which really represents a popup context menu.

I think it would be better to use .g-navmenu for nav menu and .g-buttonmenu for the button menu.
It would allow better CSS structure and better maintainability/customization.
 
thumb
thumb's picture

Joined: 2004-05-26
Posts: 228
Posted: Fri, 2009-10-16 04:20

I think .g-menu is sufficient. My concern is a proliferation of CSS class names. I suppose with this said that one could argue that we don't need .g-context-menu as the JavaScript which initializes the behavior could access the menus through .g-item .g-menu.

Can you give a more detailed, general-purpose scenario to justify these additions? Think about this, although the Wind theme uses icons in one of those menus there's nothing stopping another theme developer as rendering them as text.

Support the Gallery project with a donation
--
2tbsp.com

 
Serge D
Serge D's picture

Joined: 2009-06-11
Posts: 2139
Posted: Fri, 2009-10-16 04:46

Sorry, I disagree with your first assumption.
Even worse to assume that G3 themes must be jQuery/JS hacked for all behaviour logic.

Toolbar and Nav bar are two different styles of the menu. Current implementation (if no JS is used) forces to define all behaviour styles for box ID element and not for class (.g-menu) itself.

Current structure is as following

Main menu is defined as

Quote:
<div id="g-site-menu" ...>
<ul class="g-menu...">

Toolbar on the right

Quote:
<div class="g-toolbar">
<div id="g-view-menu" class="g-buttonset g-clearfix">
<? if ($page_type == "album"):?>
<?= $theme->album_menu() ?>

Which end up as

Quote:
<div class="g-toolbar">
<div id="g-view-menu" class="g-buttonset g-clearfix">
<ul class="g-menu">

But with JS "magic" we would actually get even more "advanced" version

Quote:
<div id="g-view-menu" class="g-buttonset">
<ul class="sf-js-enabled sf-shadow" serial="1">

Anyway, let's concentrate on main menu and toolbar. Being different by behavior they both use the same class.
Since class menu for <ul> element is not managed by theme, it would be unfortunate to hack toolbar code just for that.
 
Serge D
Serge D's picture

Joined: 2009-06-11
Posts: 2139
Posted: Fri, 2009-10-16 04:55

After spending significant time modifying/managing theme in G3 I have general complain about overuse of jQuery/JS hacks.
I think logic which is coming from inside of the modules should be as light as possible on JS use for core modules especially one which affect the visual elements.
As it seems there is general idea to follow Google "good practices and optimization rules" while JS overuse "kills" all the effort of G3 being light.
At this point my feel is that G3 becomes more complex to manage on the visual part then it was in G2.
With original intention to make core simpler, it is actually become more complex.
There is a good intention to use Kohana core, but then something went out of sync and many Kohana modules become not usable (pagination as an example).
Sorry.