Re: [Phpwebsite-developers] Defining and implementing design standards in phpWebSite

[Mike N. <mh...@us...>]

On Wed, 2005-01-05 at 09:58, Shaun Murray wrote:
> On 5 Jan 2005, at 16:51, Mike Noyes wrote:
> > On Wed, 2005-01-05 at 04:34, Shaun Murray wrote:
> >> It would also have to have a template module css import as well. So 4
> >> style sheets. I do hope theme developers never have to modify anything
> >> other than the /themes/zen/style.css in this example and that the
> >> module css is largely free of fonts, colours, alignment and spacing
> >> unless it does something out of the ordinary for a good reason.
> >
> > Any class can be modified or overridden by the theme developer in
> > /themes/zen/style.css. The css cascade loads that last and it therefore
> > gets preferred status in the cascade.
> 
> That's merely a bandaid over a self inflicted wound IMHO.

Shaun,
No it isn't. From my point of view, you are confusing the current
situation with what is being proposed for fallout.

> Perhaps I should clarify that with an example before donning my nomex 
> pants.
> 
> phpwsRSSFeeds includes it's own module css to alter the look and feel 
> of the menu from that of the system default (yes, I know we don't have 
> one defined but go with me for now). As you say above, I could override 
> that in /themes/zen/style.css or even in 
> /themes/zen/templates/phpwsrssfeeds/module.css which would probably be 
> a better place. Great. Fantastic. Powerful even.

Current phpwsrssfeeds css isn't relevant.

> However, that's merely masking the problem, that the module developer 
> has chosen to override the system default. Personally, I'd rather edit 
> the module css, removing the change, than patching over it in all my 
> themes by introducing extra css in the themes themselves.

The core css would only be extended by mod css in situations where a
needed class isn't defined. Theme developers should _never_ modify core
or module css directly.

> The problem then is that you have to either persuade the module 
> developer to conform or continue patching module css every time they 
> release a new version, just to make it look like the rest of the 
> system.

Yes. This is what core css is all about. Did I miss something?

> This is the exact same situation we have with templates currently where 
> the module developer has chosen to do something differently to the 
> 'standard'. The problem is, we've no 'standard' to which a module 
> developer can conform to, and you can't slap wrists without one. 
> Michael's article perhaps is a good start on one. We need to be much 
> stricter on the UI otherwise my fear with the new css system will be 
> the proliferation of admin across 100's of extra files just to strip 
> out fancy css that shouldn't be there.

No it isn't. The new system is very close to xaraya's implementation.
Don't look at 0.10.0 mod css as an indication of what will be in
fallout.

> The module css and templates need to be as bland and generic as 
> possible in order that they don't have to be overridden on a per module 
> basis. It's also why I'm so hot for core functions/classes to produce 
> most UI elements so that it's less likely a mod developer will roll 
> their own.

Agreed! We need to concentrate on this task. You'll see how the mod css
is beneficial as the process develops.

> How that is policed and by who might be interesting but it needs doing.

This goes in a coding standards doc, just like other projects. It isn't
complicated.

-- 
Mike Noyes <mhnoyes at users.sourceforge.net>
http://sourceforge.net/users/mhnoyes/
SF.net Projects: ffl, leaf, phpwebsite, phpwebsite-comm, sitedocs