Menu
▾
▴
SV: [Phpwebsite-developers] Template system: Proposal
|
From: Frits J. <FJ...@uv...> - 2001-03-30 16:55:20
|
Pardon for the way too long mail - I do not dare to edit in others material
- Regarding CSS standardizing, Todd, Karsten, Frits:
> -----Oprindelig meddelelse-----
> Fra: Karsten Dambekalns [mailto:k.d...@tu...]
> Sendt: 30. marts 2001 15:40
> Til: php...@li...
> Emne: Re: [Phpwebsite-developers] Template system: Proposal
>
>
> On Fri, Mar 30, 2001 at 07:56:17AM -0500, Todd Owen wrote:
> > > leftbox
> > > rightbox
> > > main
> >
> > I think we're selling the project short if we have leftbox
> and rightbox,
> > etc. The themes need to be more generic and flexible. Such as the
> > following:
> >
> > --Objects on a certain page
> > nav_bar, weather, articles, poll1, poll2 (second instance),
> job_posts,
> > header, footer
>
> Right. But will these be "blocks" or not? That is, do we need
> special styles
> for those?
>
> I think we should stick with something like left,right,main,
> for the sake of
> simplicity. If we jave something like {leftblocks}, we have
> the opportunity
> to let the system reorder the single blocks within that.
Yeah! It should be
'PrimaryBox', 'SecondaryBox', 'MainBox', 'SpecialStrong', 'SpecialFaint',
and 'Ident'.
You see each of these should have a full set of full descriptions on
_everything_ possible in CSS.
This way you could end op using <h1> in 6 different places, and having this
to be 6 completely different looks! My graphic teacher put emphasis on never
having more than 3 font types on a page, but within this system you could
have <h1> -> <h6> and <body> = 7 different fonts, times the 6 different
categories = 42 different fonts on your page at once. Combinations with
links not counted for. I am telling you *if* this system will act as a
limit, it is only good for the overall looks :)
Let me try and explain the use of the 'subsets' I was thinking of, in
*typical* use. Each of the following would have _complete_ CSS control (for
those who dont know; this is way much control).
Tell me in which situation, other than the one where you would like a mess,
the following would not be enough:
'PrimaryBox': Typically used as what is now typically Left Box. This kind of
object is on all the time, like menus and navigators. To this category, also
other objects that is displayed in a similar way, typically benieth,
belongs. To emphasize; Each of the 8 parts
+------1------+
| |
2 Headline 3
| |
+------4------+
+------5------+
| |
| |
6 Body text 7
| |
| |
+------8------+
of this (and all other subsets) will have individual "margin", "body" and
"padding" to be set with each of the subsets like color, thicknes and so on.
I should invent a system for naming the levels. Also you will have complete
control of everything else, like <h1> -> <body>, <hr> and so on in the
subset.
'SecondaryBox': Typically polls, newsflash-boxes, adverts, more flashy stuff
that you would only want on your front page. Typically is the use of what
now is Right Box.
'MainBox': The body of the pages, all that is brought to focus; Calenders,
searchresults, main stories, threads and so on. To emphasize; within this,
as in all other, you could have <h1> -> <h6> and <body> etc, giving you
plenty of playroom for your design.
'SpecialStrong': On occations you'd like to break out of your design - YOU'D
LIKE TO SHOUT, like on errors, administration notes, etc. This subset is for
defining how "things in red" should look like.
'SpecialFaint': Copyright notes, picture descriptions, hints on forms. You
would not have to have this in a design that would differ from the rest, but
this set of subsets for design would give you the possibility.
'Ident': The final one; Just in case you'd want to use CSS on your logo.
Coded to be used on what is now 'the top-bar'.
Some might argue that you'd need the possibility of having a plugin-subset,
but as plugins should end up being the main generator of public content, the
output should slide in with the rest of the web - Plugins should not be
plugins for the ordinary user. Also see Karstens argument on 'Knowing which
plugin to belong to' hereunder.
All the tables should have 0 in 'border', 'cellspacing', and 'cellpadding',
'width' and 'height' not defined, as this should be defined by the CSS, and
be neutral without.
I will try and document the above with illustrations in a document, that
should be handed out to those who would like to design a CSS for
PhpWebsite.. More thoughts welcome.
Frits
>
> > --Theme/template
> > <html><body>
> > <style sheet here>
> > {header}<br />
> > <table>
> > <tr><td>{nav_bar}</ td><td>{articles}</ td>
> > <td>{poll1}</ td><td>{poll2}</ td></ tr> <hr />
> > <tr><td>{weather}</ td><td>{job_posts}</ td></ tr>
> > </ table>
> > <br />{footer}
> > </ body></ html>
>
> How would the system know that those placeholders exist? And
> what about a
> plugin? Is this was to go into the {plugin} part of the
> template, all would
> be well. But if that plugin neede something like {my_blah_plugin}, you
> wouldn't be able to use that plugin with some other theme...
>
Excactly! Frits.
> > You see my point. We need to have each of the page objects
> separate, then
> > allow the theme/template to arrange them independant of
> left, main and top.
>
> Yes, seperatley, but following some rules. If I may lay out
> some ideas...
> (we might have something like this as documentataion on "how to write
> themes"):
> --------------------------
> - A theme has to provide at least one page template, one
> block template and
> exactly one stylesheet.
>
> - The stylesheet *must* define the following classes and tags
> in that classes:
> (insert with what Frits and/or others come up) [1]
>
As above..
> - The stylesheet *may* define additional styles for classes
> or tags used
> solely in the corresponding template. The must not interfer with the
> standard PHPWS style/class names. [1]
>
> - The page template *must* provide placeholders for:
> - blocks1, blocks2, blocks3, blocks4 [2]
> - plugins1, plugins2 [2]
> - header [3]
> - footer [3]
> - main [4]
> - menu
>
> - The block template *must* define a standard block for use with the
> format_block($title,$content) function (or whatever
> function there may
> be).
>
> - The theme *may* define more block templates, which can be
> assigned to
> individual blocks through the admin interface.
> --------------------------
>
> This is mainly a proposal, although I would consider it
> thought through, at
> least in a basic way :-)
>
> [1] By setting up rules for the stylesheet, we achieve a
> minimum level of
> compatibility between templates. By allowing additional rules
> in them, we
> give designers some more freedom.
>
> [2] The page must define 4 block and 2 plugin placeholders,
> because we could
> give the possibility to assign a plugin or block to one of
> the block or
> plugin "places". I do not name them blocks_left, blocks_top,
> et al, because
> that would imply a position. Having them numbered, gives a
> theme author the
> possibility to place blocks1 and blocks2 directly above each
> other, for
> example.
> - Question: shall we seperate blocks and plugins, or shall
> plugins be plced
> like blocks?
> - Question: Are 4 (6) blocks/block positions enough?
>
> [3] These would be for placing some smallprint (like at the
> bottom of the
> page and what is $titlebar in config.php now)
>
> [4] Here would go anything else that is produced dynamically
> (except the
> menu, of course).
>
> REMEMBER: These rules are for standard themes (and their
> authors), they make
> sure that a theme is fully compatible with an out-of-the-box
> install of
> PHPWS. If one wants to develop a theme for personal use,
> he/she could easily
> omit blocks3 and blocks4, as well as the header. He wouldn't
> be able to
> complain about being able to assign plugin x to blocks3,
> though :-) And such
> a template wouldn't pass QA at Appstate and therefore
> wouldn't be offered on
> the download page.
>
> That's it, sorry for the much too long post (again!) :o)
>
> Regards,
> Karsten
> --
> Why do we have to hide from the police, daddy?
> Because we use emacs, son. They use vi.
> -----------------------------
> mailto:k.d...@tu... w³: http://www.k-fish.de/
> gpg: http://www.k-fish.de/mykeys.gpg
>
|
