As mentioned in other threads, I’m currently re-engineering the markup and style in Dragonfly. This means I’m both creating my own theme and editing the XHTML in the core Dragonfly PHP files.

Obviously editing these core files forks my site from the main project. It would be better for me to be checking these changes into CVS.

What I’d recommend at this point is branching 9.0.x off, and I’ll work on the files on the trunk for a possible 9.1, 9.5 or even 10.0 target.

Essentially, what I’m doing is reducing everything to simple, logical XHTML markup, with no extra markup for style. I’m adding class attributes to everything where a variable is included; for example, {foo} becomes, at minimum, <span class="foo">{foo}</span>, and <b>{bar}</b> becomes <strong class="bar">{bar}</strong>. Things that are lists are being converted from nested tables back to <ul/>, <ol/> and <dl/> elements, etc., etc., etc. ad nauseum, among countless other changes.

One big thing I’m going to need to do is add code to write class and ID attributes on every <body/> and <div.block/> element. I am also envisioning blocks and modules being able to include their own CSS code. They do that now, but by writing <style/> elements within the <body/>, which is invalid. Some mechanism will have to be created so that DF knows to include the style in the <head/>.

Essentially, Dragonfly will be asked to write a page given certain paramters, such as whether to write the header and footer, which columns to display, and which blocks to display. There should probably be one main page.php which includes everything else via object classes. (Do we need to go pure PHP 5 here?)

most servers do not have php 5, in fact almost none do.

Besides that, sounds interesting.

Although in my blocks i do not write <style> things i just have <div style=""> and code everything that way, which is still valid isn't it?

although to be theme friendly none of that should be in the block itself, but instead in a theme directory template file i suppose.

Pazu maybe you are interested in moocms.com/ because Dragonfly will never fully recieve what you want due to the current structure/layout.

However we could add some of your changes to the Dragonfly CVS if you provide us patch files for it.

DJMaze wrote:

Pazu maybe you are interested in moocms.com/ because Dragonfly will never fully recieve what you want due to the current structure/layout.

Maybe, but their markup is still not much improved from Dragonfly’s, and their project seems very nascent; even the Register link doesn’t work.

Quote::

However we could add some of your changes to the Dragonfly CVS if you provide us patch files for it.

Okay. I’ve done a couple of blocks as an example. Shall I attach those here for discussion?

shure

DJMaze wrote:

shure

Okay, here’s my revised User Info block, as used on my site. Note that I’ve done the things outlined in my proposal.

1. Removed all presentational markup
2. Migrated categorical image decorations to classes on the list items which are then applied using list-style-image or h3:before
3. Added classes and IDs galore

It’s not perfect, but it should give you the idea.

And, here’s the part of my new CSS that adds the images.

Code::

div.Main_Menu_category h3:before { vertical-align: middle; padding-right: 3px; } div.Main_Menu_category#_HOME h3:before { content: url('/images/blocks/CPG_Main_Menu/icon_home.gif'); } div.Main_Menu_category#_COMMUNITY h3:before { content: url('/images/blocks/CPG_Main_Menu/icon_community.gif'); } div.Main_Menu_category#_MEMBERSOPTIONS h3:before { content: url('/images/blocks/CPG_Main_Menu/icon_members.gif'); } div.Main_Menu_category#_BBFORUMS h3:before { content: url('/images/blocks/CPG_Main_Menu/icon_forums.gif'); } div.Main_Menu_category#_SEARCH h3:before { content: url('/images/blocks/CPG_Main_Menu/icon_search.gif'); } div.Main_Menu_category#Web h3:before { content: url('/images/blocks/CPG_Main_Menu/icon_web.gif'); } div.Main_Menu_category#nocatcontent { border-top: solid 1px rgb(80%, 80%, 80%); margin-top: 1em; padding-top: 1em; } div.Main_Menu_category li { list-style-image: url('/images/blocks/CPG_Main_Menu/icon_select.gif'); } div.Main_Menu_category li.unselect { list-style-image: url('/images/blocks/CPG_Main_Menu/icon_unselect.gif'); } div.Main_Menu_category li.cantselect { list-style-image: url('/images/blocks/CPG_Main_Menu/icon_cantselect.gif'); } div.Main_Menu_category li.select { list-style-image: url('/images/blocks/CPG_Main_Menu/icon_select.gif'); }

It would be far better, of course, to be able to select by “div.block#Main_Menu div.category li”, but until blocks get a relevant unique ID that can’t happen.

Nice that it is CSS based but what about all current available themes ?
They all need massive CSS editing with your idea.

won't the .css quickly become too large and in effect slow?

DJMaze wrote:

Nice that it is CSS based but what about all current available themes ? They all need massive CSS editing with your idea.

Yes, that is absolutely, 100% true. In fact, they won’t need editing, they will need to be recreated. That’s why I feel this is a good idea for a version 10 release target. That gives me/us plenty of time to both implement the changes and evangelize themers.

It’s a lot of work, but infinitely worthwhile. Themers will gain far, far more than they’ll lose.

NEMINI wrote:

won't the .css quickly become too large and in effect slow?

No, provided the markup is designed well. As I’ve mentioned before, the keys are class and ID attribute values on every body and div.block element. With those in place, compact and efficient selector programming will give us such power, you won’t believe it.

Don’t forget how slow it is now with all the spaghetti HTML it has to generate (and the browser has to parse into something recognizable). Sure, it’s faster than PHP-Nuke was, but it could be so much better. I mean, just look at most themes now. Every piece of text is enclosed in font tags, not to mention seven, eight, or more levels of nested tables to achieve some 1996 layout technique. I would not be surprised if this work speeds Dragonfly up by a factor of 2, at least when the entire system path is considered; server (PHP, HTTPD, etc.), network bandwidth, client processing time, etc.

rgb(80%, 80%, 80%);

RGB is Red Green Blue, why there 80% on it?

It's like 80% of 255 you could write it as #CCC since 255*0.8 = 204 in hex this is CC

DJMaze is right. CSS lets you write color values in much more human-readable ways than the old hex codes. You can specify the three RGB values either as 0–255 integers or 0–100 percentages; e.g., rgb(14, 255, 93) or rgb(5%, 87%, 19%).

and the average person has a much better understand just what color those percentages work out to be ... NOT! Human readable my ass.