Home Private Messages Search
CPG Dragonfly™ CMS Dedicated Server & Bandwidth Sponsored by DedicatedNOW
Toggle Content
 
Forums ⇒ CMS (All) ⇒ Requests :: Archives ⇒ Markup re-engineering :: Archived


Markup re-engineering :: Archived
Requests for core changes must be submitted through the Projects Features section.
Go to page Previous  1, 2
This forum is locked: you cannot post, reply to, or edit topics.    This topic is locked: you cannot edit posts or make replies.    Printer Friendly Page     Forum Index ⇒  Requests

Topic Archived View previous topic :: View next topic  
Author Message
DJ Maze
Developer
Developer

Offline Offline
Joined: Apr 19, 2004
Posts: 5683
Location: http://tinyurl.com/5z8dmv
PostPosted: Thu Oct 06, 2005 2:27 pm
Post subject: Re: Markup re-engineering

body {
background-color: red;
}

now that's human readable Smile


DJ Maze's server specs (Server OS / Apache / MySQL / PHP / DragonflyCMS)
Fedora 15 / 2.2.22 / 5.5.20 / 5.3.10 / CVS
Back to top
View user's profile Visit poster's website Yahoo Messenger Photo Gallery
mc__
Debugger
Debugger

Offline Offline
Joined: Jul 12, 2005
Posts: 452
Location: QLD, Australia
PostPosted: Fri Oct 07, 2005 5:14 am
Post subject: Re: Markup re-engineering

hex is the best in my opinion. Reason why is because hex is the norm, and how is the browser meant to know if 12 is 12 decimal or 12 hex? how is the theme dsigner meant to know? different browser may implement it differently...

i think that they put too much option in there.

Also, do not forget that the css file gets redownloaded by the browser on every page refresh (but thankfully not every page view).

This means that unless dragonfly cms dynamically generates the css for each page view (more processing time needed) then the much larger css file would be continually downloaded again and again and again and again, seems pointless to me.

I agree that there are big advantages here, but don't go overboard on the idea...

I still use tables and such, they're handy for certain things. Although font tags should be well and trully deprecated. Div's are generally better than tables, but for example if you are making a form and you want the labels to be all nice and neat with their inputs, then using a table is MUCH quicker and easier than using divs (although i suppose that with floating divs it could take up as many "columns" as can be fit on the screen, whereas with tables you will have to cater for the lowest likely viewer resolution).

_________________


mc__'s server specs (Server OS / Apache / MySQL / PHP / DragonflyCMS)
Linux (Kernel: 2.4.21-27.0.2.ELsmp)/1.3.33 (Unix)/4.0.24-standard/4.3.11/9.0.5.0
Back to top
View user's profile Visit poster's website MSN Messenger
Pazu
Nice poster
Nice poster

Offline Offline
Joined: Feb 14, 2005
Posts: 86

PostPosted: Fri Oct 07, 2005 8:03 am
Post subject: Re: Markup re-engineering

mc__ wrote:
hex is the best in my opinion. Reason why is because hex is the norm, and how is the browser meant to know if 12 is 12 decimal or 12 hex? how is the theme dsigner meant to know? different browser may implement it differently...
Hex isn’t the norm. Do you use hex in Photoshop? In any other graphic program? No, you convert to hex purely and exclusively for web pages. Hex is on the way out. You can use it in CSS, but why bother when you can just copy RGB values straight from Photoshop?

The browser knows because of the format of the value. Hex codes are still preceded by #. E.g., color:#b1093a, color:#ccc or color:rgb(12, 40, 213) (and, yes, keywords still work, too; e.g., color:cyan.)

mc__ wrote:
Also, do not forget that the css file gets redownloaded by the browser on every page refresh (but thankfully not every page view).

This means that unless dragonfly cms dynamically generates the css for each page view (more processing time needed) then the much larger css file would be continually downloaded again and again and again and again, seems pointless to me.
The CSS file gets cached like any other file. If it’s unchanged, it is not redownloaded unless you force reload.

mc__ wrote:
I still use tables and such, they're handy for certain things. Although font tags should be well and trully deprecated. Div's are generally better than tables, but for example if you are making a form and you want the labels to be all nice and neat with their inputs, then using a table is MUCH quicker and easier than using divs (although i suppose that with floating divs it could take up as many "columns" as can be fit on the screen, whereas with tables you will have to cater for the lowest likely viewer resolution).
The problem with that approach is that it continues to lock your layout idea in the PHP code, and gives themers little or no possibility of changing it. In forms, grouping things in fieldsets with legends and labels (and relevant classes and IDs) provides all the markup you need to achieve the same visual style you get with your tables.


Pazu's server specs (Server OS / Apache / MySQL / PHP / DragonflyCMS)
Linux 2.6.17.11-grsechg / Apache 1.3.37 / MySQL 4.1.21-standard / PHP 5.2.1 / Dragonfly 9.1.1
Back to top
View user's profile Visit poster's website
mc__
Debugger
Debugger

Offline Offline
Joined: Jul 12, 2005
Posts: 452
Location: QLD, Australia
PostPosted: Wed Oct 26, 2005 6:07 am
Post subject: Re: Markup re-engineering

Fieldsets and labels?

no, not really, because then it is all stagered.

If i grouped them into divs and made them float left and right appropriately it'd have a similar effect, but then it's less text therefore smaller loading times to just use table syntax.

Mind you i difinitely agree with the fact that all html should be themable (templated), and i am going to convert all of my exisitng work to do this when i get the time to do it. At least that way you can easily modify the output without doing too much to the php script (which'd probably make some people feel more comfortable).

_________________


mc__'s server specs (Server OS / Apache / MySQL / PHP / DragonflyCMS)
Linux (Kernel: 2.4.21-27.0.2.ELsmp)/1.3.33 (Unix)/4.0.24-standard/4.3.11/9.0.5.0
Back to top
View user's profile Visit poster's website MSN Messenger
Phoenix
• Many Posts •
• Many Posts •

Offline Offline
Joined: Apr 19, 2004
Posts: 8799
Location: Netizen
PostPosted: Wed Oct 26, 2005 6:24 am
Post subject: Re: Markup re-engineering

Have fun floating your divs Wink


Phoenix's server specs (Server OS / Apache / MySQL / PHP / DragonflyCMS)
Back to top
View user's profile Visit poster's website Photo Gallery
Pazu
Nice poster
Nice poster

Offline Offline
Joined: Feb 14, 2005
Posts: 86

PostPosted: Tue Apr 25, 2006 2:37 pm
Post subject: Re: Markup re-engineering

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

You honestly believe #CCCCCC is more readable and portable than rgb(80%, 80%, 80%)? No, you couldn't possibly...no, it must be a joke.


Pazu's server specs (Server OS / Apache / MySQL / PHP / DragonflyCMS)
Linux 2.6.17.11-grsechg / Apache 1.3.37 / MySQL 4.1.21-standard / PHP 5.2.1 / Dragonfly 9.1.1
Back to top
View user's profile Visit poster's website
Pazu
Nice poster
Nice poster

Offline Offline
Joined: Feb 14, 2005
Posts: 86

PostPosted: Tue Apr 25, 2006 2:42 pm
Post subject: Re: Markup re-engineering

I haven't been able to pay this any attention for a few months, but I'm thinking of starting up again. If people are really opposed to the idea of converting from table layout to CSS positioning with floated DIVs and such, would you at least be unopposed to ripping out all the 1995-esque HTML attribtes from the tables, and making them nonnested?

That is, instead of thirteen (or more!) levels deep of:

table>tr>td>table>tr>td>table>tr>td>table>tr>td...

with all the accompanying hardcoded cellpadding, cellspacing, widths, heights, aligns and valigns, ad nauseum on each level, would you be interested in seeing one table for main column layout, and one-level-deep tables as needed inside the various columns and blocks and such, all labelled with appropriate classes and IDs?

If there's interest, I'll post a mockup. (Note this would be a markup mockup, not a theme markup.)


Pazu's server specs (Server OS / Apache / MySQL / PHP / DragonflyCMS)
Linux 2.6.17.11-grsechg / Apache 1.3.37 / MySQL 4.1.21-standard / PHP 5.2.1 / Dragonfly 9.1.1
Back to top
View user's profile Visit poster's website
t31os
Supporter
Supporter

Offline Offline
Joined: Sep 22, 2004
Posts: 2025
Location: Somewhere in the intertubes... lolz
PostPosted: Tue Apr 25, 2006 4:03 pm
Post subject: Re: Markup re-engineering

Any improvements are a good idea.

How do older browsers handle your method compared to how things are now?

Realisticly i have to ask if all the browsers supported now will still work to the same degree using the above.


t31os's server specs (Server OS / Apache / MySQL / PHP / DragonflyCMS)
XP / 2.0 / 5.1 / 5.2 / none
Back to top
View user's profile Visit poster's website
mc__
Debugger
Debugger

Offline Offline
Joined: Jul 12, 2005
Posts: 452
Location: QLD, Australia
PostPosted: Wed Apr 26, 2006 11:34 am
Post subject: Re: Markup re-engineering

Yeah i can see what you mean.

I believe that there is plenty of interest, but i also believe that it is maybe a whole lot of work for little gain for this cms? But don't let that stop you.

_________________


mc__'s server specs (Server OS / Apache / MySQL / PHP / DragonflyCMS)
Linux (Kernel: 2.4.21-27.0.2.ELsmp)/1.3.33 (Unix)/4.0.24-standard/4.3.11/9.0.5.0
Back to top
View user's profile Visit poster's website MSN Messenger
DJ Maze
Developer
Developer

Offline Offline
Joined: Apr 19, 2004
Posts: 5683
Location: http://tinyurl.com/5z8dmv
PostPosted: Wed Apr 26, 2006 11:48 am
Post subject: Re: Markup re-engineering

mc__ wrote:
Also, do not forget that the css file gets redownloaded by the browser on every page refresh (but thankfully not every page view).

This means that unless dragonfly cms dynamically generates the css for each page view (more processing time needed) then the much larger css file would be continually downloaded again and again and again and again, seems pointless to me.
Pazu wrote:
The CSS file gets cached like any other file. If it’s unchanged, it is not redownloaded unless you force reload.

That fully depends on your browser behavior.
Some poll the HTTP header "Date-Modified" or post an correct data request to check if it is still the old file using "If-Modified-Since"
www.w3.org/Protocols/r...l#sec14.25


DJ Maze's server specs (Server OS / Apache / MySQL / PHP / DragonflyCMS)
Fedora 15 / 2.2.22 / 5.5.20 / 5.3.10 / CVS
Back to top
View user's profile Visit poster's website Yahoo Messenger Photo Gallery
Display posts from previous:   
This forum is locked: you cannot post, reply to, or edit topics.    This topic is locked: you cannot edit posts or make replies.    Printer Friendly Page    Forum Index ⇒  Requests
Page 2 of 2
All times are GMT
Go to page Previous  1, 2

Archive Revive
Username:
This is an archived topic - your reply will not be appended here.
Instead, a new topic will be generated in the active forum.
The new topic will provide a reference link to this archived topic.
 
   Toggle Content User Info

Welcome Anonymous

Nickname
Password
(Register)

   Toggle Content Last CVS commits
· Fixed .ico Expires header.
· Removed domain name from cookies so subdomains wont access them anymore.
· CSS and JS, case insensitives.
· CSS and JS, send correct HTTP 1.1 headers and fixed issues where themes and...
· Further security class improvements.
· 301 redirects on LEO changes
· Option to force 3xx http status codes
· Validate googlebot.com and google.com crawlers.
· CCBot
· Rss with etag and atom.

read more...

   Toggle Content Community

Support for DragonflyCMS in a other languages:

Deutsch
Español

   Toggle Content X-links
UltraEdit Browse Happy logo Firefox MySQL PostgreSQL Valid CSS! Valid XHTML 1.0! Unicode Encoded Badge NukeBiz Resources Raven DragonflyCMS Dedicated Now InsideSupport Lampe Berger

You are seeing squares or questionmarks on this page?

All content of this website is copyrighted by the Creative Commons NC-SA
The logos and trademarks used on this site are the property of their respective owners
We are not responsible for comments posted by our users, as they are the property of the poster.
Our server runs on a P3 1.2GHz with 512MB RAM with no accelerators
Support GoPHP5.org
Interactive software released under GNU GPL, Code Credits, Privacy Policy