Menu
▾
▴
Re: [Phpwebsite-developers] Panel / Menu
|
From: Mike N. <mh...@us...> - 2004-08-07 19:42:18
|
On Sat, 2004-08-07 at 11:44, Shaun Murray wrote:
> On 7 Aug 2004, at 16:40, Mike Noyes wrote:
> > I think the main difference we have is in our point of view. You want
> > standard classes available for module developers.
>
> And for theme developers. I want theme developers to know that if they
> change the "menu" class in style.css that it affects the style of each
> and every one of the menus used. Just like they know that changing
> bg_light changes one of the alternate lines in tables.
>
> I want module developers to know that if they put in their template
>
> <div id ="menu_id" class="navmenu">
> {menu}
> </div>
>
> ...or whatever we decide...
Shaun,
Agreed. I don't think we differ much here. My one caveat is
customization of specific modules should be possible.
> ...they'll get a standard menu that looks just like the other menus as
> we specify a menu class in the provided style.css as a thing that theme
> developers must provide. I don't module developers defining those
> classes in their own module code or in their own style sheets. The
> former is horrible and the second is a pain in the ass for theme
> developers who would now have to cope with extra style sheets.
I don't think module stylesheets will be as extensive as you describe.
At least I hope not.
> > I'm looking at it from
> > a theme developer/end user perspective. I want descendant selector divs
> > defined so they can be easily modified for site specific use.
>
> Those are useful for additional theme work but completely irrelevant to
> this discussion since there currently aren't any basics to descend
> from. ;-)
>
> I really don't want to see
>
> p.pagemaster
> p.announce
> p.article
> p.linkman
> ul.pagemaster
>
> etc
>
> clogging up a theme as the default situation. I'd really not like to
> see p redefined at all, or html, or body, or any of the type selectors.
Ok. I think I'm having difficulty describing my suggestion. Using div
(block) descendant selectors will avoid the scenario above. Cascading
will take care of assigning proper styles to elements within the div
(block). The stylesheet is where the formating takes place. The class/id
calls in the (x)html are minimal. However, they are necessary in certain
circumstances, and those should be documented.
Type selectors define core and all others are derived from the cascade.
<div class="menu"> -- defines div ul and li -- p is derived from
<p></p> the cascade
<ul><li></li></ul>
</div>
div.menu {foo: xxxx}
div.menu ul {foo: xxxx}
div.menu li {foo: xxxx}
<div class="pagemaster"> -- defines div p and ul -- ol is derived from
<p></p> the cascade
<ul><ol></ol></ul>
<ul><li></li></ul>
</div>
div.pagemaster {foo: xxxx}
div.pagemaster p {foo: xxx}
div.pagemaster ul {foo: xxx}
<div...
div.announce....
> Not in a basic simple style sheet at least. If we're getting fancy then
> sure, redefine your H1's to HelveticaNeue-CondensedBlack with 75%
> text-shadows, which is what I usually do in my own themes. The base set
> you provided a link to yesterday implementing most of HTML4 is a good
> start if you're looking to define every type selector, but I'm not, and
> you shouldn't have to - that's up to the browser developers to define.
Unfortunately, browser developers haven't done a good job (one in
particular). How do you account for box model, image alignment, and list
indentation peculiarities? Defining the overall font used in the site,
changing the color of h1 - h4 tags, are common as are other style
modifications. Theme designers use these often.
html, body {
font: normal normal normal medium serif;
color: #000000;
background-color: #ffffff;
margin: 0;
padding: 0;
boarder: 0 none transparent;
}
--
Mike Noyes <mhnoyes at users.sourceforge.net>
http://sourceforge.net/users/mhnoyes/
SF.net Projects: ffl, leaf, phpwebsite, phpwebsite-comm, sitedocs
|
