Menu
▾
▴
phpwebsite-developers
|
From: Daniel W. <dan...@pa...> - 2004-08-06 12:27:39
|
Are there any ideas / plans for standardising the panel thingy that's used in mods like the user admin and layout?... I think this would be good if it was available as a feature in the layout mod (by code). I believe mods that have a menu like announcements and menu manager should use something like this, would also make things a bit more consistent. The way I currently have things set up is: (for example) <h2>Announcements</h2> <p class="inner menu">New Announcement | List Announcements | Settings</p> <h3>Current announcements (1 - 10 of 98)</h3> [list table] inner menu would be good suited as the panel. And with user and layout admin it has a table above h2, which im sure would be possible to after the h2 (is the title of content vars). Daniel |
|
From: Shaun M. <sh...@ae...> - 2004-08-06 13:53:57
|
It has been mentioned a few times and in IRC. There's a number of different styles in use. eg. compare FAQ with Fatcat or RSS. It does need unifying. I'd suggest using <ul> and <li> tags, then each element can be styled and it'd be possible to create proper tabs like in these two ala articles here... http://www.alistapart.com/articles/taminglists/ http://www.alistapart.com/articles/slidingdoors/ It'd be nice to pin down some class names and put them in as a requirement in any style.css though. There are some already like the background colours that are mandatory and more should be specified as a common resource that module developers can rely on. On 6 Aug 2004, at 13:28, Daniel Winter wrote: > Are there any ideas / plans for standardising the panel thingy that's > used > in mods like the user admin and layout?... I think this would be good > if it > was available as a feature in the layout mod (by code). I believe mods > that > have a menu like announcements and menu manager should use something > like > this, would also make things a bit more consistent. > > The way I currently have things set up is: (for example) > > <h2>Announcements</h2> > > <p class="inner menu">New Announcement | List Announcements | > Settings</p> > > <h3>Current announcements (1 - 10 of 98)</h3> > > [list table] > > > inner menu would be good suited as the panel. > > And with user and layout admin it has a table above h2, which im sure > would > be possible to after the h2 (is the title of content vars). > > Daniel > > > > ------------------------------------------------------- > This SF.Net email is sponsored by OSTG. Have you noticed the changes on > Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, > one more big change to announce. We are now OSTG- Open Source > Technology > Group. Come see the changes on the new OSTG site. www.ostg.com > _______________________________________________ > Phpwebsite-developers mailing list > Php...@li... > https://lists.sourceforge.net/lists/listinfo/phpwebsite-developers > > > Shaun aegis design - http://www.aegisdesign.co.uk |
|
From: Mike N. <mh...@us...> - 2004-08-06 15:47:35
|
On Fri, 2004-08-06 at 06:53, Shaun Murray wrote: > It has been mentioned a few times and in IRC. There's a number of > different styles in use. eg. compare FAQ with Fatcat or RSS. It does > need unifying. Shaun, Work in this area is underway for 0.9.4. > It'd be nice to pin down some class names and put them in as a > requirement in any style.css though. There are some already like the > background colours that are mandatory and more should be specified as a > common resource that module developers can rely on. I proposed descendant selector sets for modules. I believe is a much simpler solution. Feedback is welcome. Selectutorial http://css.maxdesign.com.au/selectutorial/selectors_descendant.htm http://css.maxdesign.com.au/selectutorial/selectors_class.htm#less Proposal Example: http://phpwebsite-comm.sourceforge.net/temp.html http://phpwebsite-comm.sourceforge.net/temp.css -- Mike Noyes <mhnoyes at users.sourceforge.net> http://sourceforge.net/users/mhnoyes/ SF.net Projects: ffl, leaf, phpwebsite, phpwebsite-comm, sitedocs |
|
From: Matthew M. <ma...@tu...> - 2004-08-06 14:48:31
|
> Are there any ideas / plans for standardising the panel thingy that's used > in mods like the user admin and layout? Yes. In 0.9.4, a main panel holds the links to the modules. Then modules can have subpanels within the control panel. Once people start testing we can look at standardazation. Currently, the control panel uses div tags and control panel has its own style sheet. Matt |
|
From: Shaun M. <sh...@ae...> - 2004-08-06 16:47:21
|
Perhaps I'm getting the wrong end of the stick but the introduction of extra style sheets on a per module basis doesn't sound very conducive to cross-module standization or making the life of site theme designers any easier. There's elements in each module that are pretty standard fare - tabs, menus, forms, fieldsets, table lists, sections, images. I just want to define the style of these once, in one place, and that that style is picked up so it's consistent across all modules. Per module stylesheets don't do that and add to maintenance issues and increases complexity. Descendent selectors based on the module name alone don't do that. The only way to do it, although I'm open to suggestions, is to specify base classes for each element in style.css or perhaps even in a core stylesheet as these elements don't often need tweaking across styles provided you keep the colour styling out. Use descendent selectors to override these but there still needs to be a base set usable across modules. Shaun aegis design - http://www.aegisdesign.co.uk |
|
From: Matthew M. <ma...@tu...> - 2004-08-06 17:20:51
|
> The only way to do it, although I'm open to suggestions, is to specify > base classes for each element in style.css or perhaps even in a core > stylesheet as these elements don't often need tweaking across styles > provided you keep the colour styling out. Use descendent selectors to > override these but there still needs to be a base set usable across > modules. Actually I have no problem with that. What I was trying to avoid was the insertion of "bg_light" in the code. Style sheets per module allowed developers to stay away from that. If someone wants to create a persistent style sheet as the foundation of 0.9.4. go for it. I'll abide by it. I figured I would get into this once 0.9.4 was completely functional but we can start now if you'd like. I suggest we get a basic style sheet up, toss it around the developer list, and agree on the style names and definitions. Once approved by all, I (and later we) can code around it. As I have told others, I would like 0.9.4 to ship with a strong foundation theme with really nice style sheets (see Zen Garden for examples). Thanks, Matt Matthew McNaney Internet Systems Architect Electronic Student Services Appalachian State University Phone: 828-262-6493 http://phpwebsite.appstate.edu http://ess.appstate.edu |
|
From: Shaun M. <sh...@ae...> - 2004-08-06 17:36:46
|
On 6 Aug 2004, at 18:14, Matthew McNaney wrote: >> The only way to do it, although I'm open to suggestions, is to specify >> base classes for each element in style.css or perhaps even in a core >> stylesheet as these elements don't often need tweaking across styles >> provided you keep the colour styling out. Use descendent selectors to >> override these but there still needs to be a base set usable across >> modules. > > Actually I have no problem with that. What I was trying to avoid was > the > insertion of "bg_light" in the code. Style sheets per module allowed > developers to stay away from that. I can see that. From a theme designers perspective though, having one module developer defining their table rows as alternating red/white and another as beige/pink never mind any other padding or style variances, in multiple style sheets is a pain. Especially if the style sheets are embedded in the /mod/ hierarchy instead of the theme hierarchy. It's a chore enough with making sure template changes in the module releases are reflected in updated themes. > > If someone wants to create a persistent style sheet as the foundation > of > 0.9.4. go for it. I'll abide by it. I figured I would get into this > once > 0.9.4 was completely functional but we can start now if you'd like. > OK, I'll have a bash later at defining a style sheet and set of UI guidelines for where they should be used. Hopefully I can come up with some standard elements of the UI so that module developers don't have to reinvent the wheel. > I suggest we get a basic style sheet up, toss it around the developer > list, and agree on the style names and definitions. Once approved by > all, I (and later we) can code around it. As I have told others, I > would > like 0.9.4 to ship with a strong foundation theme with really nice > style > sheets (see Zen Garden for examples). > Yep, good example. Shaun aegis design - http://www.aegisdesign.co.uk |
|
From: Mike N. <mh...@us...> - 2004-08-06 18:10:54
|
On Fri, 2004-08-06 at 10:36, Shaun Murray wrote:
> On 6 Aug 2004, at 18:14, Matthew McNaney wrote:
> > If someone wants to create a persistent style sheet as the foundation
> > of 0.9.4. go for it. I'll abide by it. I figured I would get into
> > this once 0.9.4 was completely functional but we can start now if
> > you'd like.
>
> OK, I'll have a bash later at defining a style sheet and set of UI
> guidelines for where they should be used. Hopefully I can come up with
> some standard elements of the UI so that module developers don't have
> to reinvent the wheel.
Shawn,
Can we just use type selectors for the persistent stylesheet? I'd like
to avoid Class, ID, descendant, child, etc. selectors in the
core/persistent stylesheet if possible.
W3C has a sample recommended set for browser UAs. It may provide a place
for us to start discussion.
Appendix A. A sample style sheet for HTML 4.0
http://www.w3.org/TR/REC-CSS2/sample.html
We'll be able to use persistent, preferred, and alternate styleshets
with title grouping in 0.9.4 also. See the debug theme for examples. In
additional Mozilla is working on tracking alternate stylesheet selection
by users. There is an extension for Firefox available that demonstrates
this functionality. No javascript or cookies are necessary.
XML-Stylesheet PI
http://www.w3.org/TR/xml-stylesheet/
Style Sheet Chooser 0.1
http://update.mozilla.org/extensions/moreinfo.php?id=192
--
Mike Noyes <mhnoyes at users.sourceforge.net>
http://sourceforge.net/users/mhnoyes/
SF.net Projects: ffl, leaf, phpwebsite, phpwebsite-comm, sitedocs
|
|
From: Shaun M. <sh...@ae...> - 2004-08-06 20:49:47
|
On 6 Aug 2004, at 19:16, Mike Noyes wrote: > > Shawn, > Can we just use type selectors for the persistent stylesheet? I'd like > to avoid Class, ID, descendant, child, etc. selectors in the > core/persistent stylesheet if possible. > > W3C has a sample recommended set for browser UAs. It may provide a > place > for us to start discussion. > > Appendix A. A sample style sheet for HTML 4.0 > http://www.w3.org/TR/REC-CSS2/sample.html > Why would I change those? Is there a point in redefining the standard tags. I'd rather leave them alone entirely to the browser or the particular theme. I'd tighten up on where they are used in the templates but not in defining their looks at all. That's not the aim for core styles. The point I was making was that there is currently no standard way of building a CSS based menu so defining one, and specifying it as a standard to be used and be available, lessens the likelihood of developers creating their own, perhaps incompatible or badly styled, method. In the same way we can all roll our own list/item managers but they'd all look different to everyone else's. Standards are good. They set a base line, even if it's only used a point to deviate from. What I'm suggesting is not that we redefine the H1 tag, but that we come up with a standard for interface elements. A style guide, a set of standard CSS classes as needed, some template examples, maybe even think about some core PHP classes if it makes life easier. Kind of a cookbook where developers and designers trying to work out how to do something the phpWebSite way is done. Eg. How nice would it be for a mod developer to pass an array to a function and a tabbed menu is built with the right tab selected? Behind that though, it needs some CSS classes defined or the developer would have to supply their own, breaking consistency. Or simple things like the extra info lines at the bottom of summaries. Should they have square brackets around each? Should they have a pipe between each? Should they have graphics? What if I want » instead of a pipe for a breadcrumb trail? It'd be nice to not have to hack templates and mods for that level of consistency. > We'll be able to use persistent, preferred, and alternate styleshets > with title grouping in 0.9.4 also. See the debug theme for examples. In > additional Mozilla is working on tracking alternate stylesheet > selection > by users. There is an extension for Firefox available that demonstrates > this functionality. No javascript or cookies are necessary. > OK but it's not the problem I'm aiming at and it's never been a problem anyway - why use Javascript when you've got PHP, it's easy to do now in theme.php and using Chris Clark's php switcher on ala. I'm trying not to sound 'ranty' and I'm trying not to be the UI police but it's the little things that get me and it'd be nice to push the little things forward so the interface is as nice and consistent as apps like phpAdsNew, Bricolage (fantastic workflow features btw) or Drupal 4.50 (no I'm not defecting but it is cool in places - the node system is cool, the taxonomy/vocabulary thing isn't). See http://drupal.org/ http://buytaert.net/temporary/drupal-tabs-and-submenus.jpg - good example of tabs http://phpadsnew.com/two/features-gallery.html http://www.bricolage.cc/docs/screenshots/ Shaun aegis design - http://www.aegisdesign.co.uk |
|
From: Mike N. <mh...@us...> - 2004-08-07 15:08:20
|
On Fri, 2004-08-06 at 13:49, Shaun Murray wrote:
> On 6 Aug 2004, at 19:16, Mike Noyes wrote:
> > Can we just use type selectors for the persistent stylesheet? I'd like
> > to avoid Class, ID, descendant, child, etc. selectors in the
> > core/persistent stylesheet if possible.
> >
> > W3C has a sample recommended set for browser UAs. It may provide a
> > place for us to start discussion.
>
> Why would I change those? Is there a point in redefining the standard
> tags. I'd rather leave them alone entirely to the browser or the
> particular theme.
Shaun,
Let me preface my comments with: I'm no CSS expert. However, type
selectors are the major method for styling. Unlike class and ID
selectors, type selectors don't require style calls in the html markup.
http://css.maxdesign.com.au/selectutorial/selectors_type.htm
"The most common and easy to understand selectors are type
selectors."
In addition, the vast majority of stylesheets I've looked at use type
selectors to correct browser inconsistencies. Example (viewport):
html, body {margin: 0; padding: 0}
> I'd tighten up on where they are used in the templates but not in
> defining their looks at all. That's not the aim for core styles.
It sounds like we may have a different view. Let me attempt to explain
my view.
Core style is global in scope and limited in size. Core is
defined in the persistent stylesheet.
Do we agree so far?
Core style uses type selectors where possible to define element
presentation, and correct browser inconsistencies.
We may have some semantic differences above. I believe the following
section is what you're concerned with.
Site specific styles (themes) will be defined in the default and
alternate stylesheets. Default style will use div descendant
selectors to provide style blocks for menu, module, image float,
etc. use. Class/ID types used in phpwebsite will be written down
for module and theme developer reference.
> The point I was making was that there is currently no standard way of
> building a CSS based menu so defining one, and specifying it as a
> standard to be used and be available, lessens the likelihood of
> developers creating their own, perhaps incompatible or badly styled,
> method. In the same way we can all roll our own list/item managers but
> they'd all look different to everyone else's. Standards are good. They
> set a base line, even if it's only used a point to deviate from.
Agreed, provided you're not suggesting adoption of a template system
like smarty.
> What I'm suggesting is not that we redefine the H1 tag, but that we
> come up with a standard for interface elements. A style guide, a set of
> standard CSS classes as needed, some template examples, maybe even
> think about some core PHP classes if it makes life easier. Kind of a
> cookbook where developers and designers trying to work out how to do
> something the phpWebSite way is done.
Are you suggesting a best practices document?
--
Mike Noyes <mhnoyes at users.sourceforge.net>
http://sourceforge.net/users/mhnoyes/
SF.net Projects: ffl, leaf, phpwebsite, phpwebsite-comm, sitedocs
|
|
From: Mike N. <mh...@us...> - 2004-08-07 15:34:24
|
On Fri, 2004-08-06 at 13:49, Shaun Murray wrote: > The point I was making was that there is currently no standard way of > building a CSS based menu so defining one, and specifying it as a > standard to be used and be available, lessens the likelihood of > developers creating their own, perhaps incompatible or badly styled, > method. In the same way we can all roll our own list/item managers but > they'd all look different to everyone else's. Standards are good. They > set a base line, even if it's only used a point to deviate from. Shaun, I think the main difference we have is in our point of view. You want standard classes available for module developers. 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. -- Mike Noyes <mhnoyes at users.sourceforge.net> http://sourceforge.net/users/mhnoyes/ SF.net Projects: ffl, leaf, phpwebsite, phpwebsite-comm, sitedocs |
|
From: Shaun M. <sh...@ae...> - 2004-08-07 18:44:12
|
On 7 Aug 2004, at 16:40, Mike Noyes wrote:
> On Fri, 2004-08-06 at 13:49, Shaun Murray wrote:
>> The point I was making was that there is currently no standard way of
>> building a CSS based menu so defining one, and specifying it as a
>> standard to be used and be available, lessens the likelihood of
>> developers creating their own, perhaps incompatible or badly styled,
>> method. In the same way we can all roll our own list/item managers but
>> they'd all look different to everyone else's. Standards are good. They
>> set a base line, even if it's only used a point to deviate from.
>
> Shaun,
> 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...
...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'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.
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.
Shaun
aegis design - http://www.aegisdesign.co.uk
|
|
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
|
|
From: Mike N. <mh...@us...> - 2004-08-29 18:00:07
|
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...
>
> ...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.
Shaun,
I just put up another prof-of-concept. It shows descendant selectors,
cascade, and collision resolution in action. A cascade list is liked, so
you can understand the structure I'm proposing.
http://phpwebsite-comm.sourceforge.net/temp/
Any comments and/or suggestions are welcome.
--
Mike Noyes <mhnoyes at users.sourceforge.net>
http://sourceforge.net/users/mhnoyes/
SF.net Projects: ffl, leaf, phpwebsite, phpwebsite-comm, sitedocs
|
|
From: George B. <gbr...@lu...> - 2004-08-29 18:44:54
|
VERY interesting, Mike. For those of us who are CSS-challenged, what
changes to the mod code of menuman and pagemaster are required for this to
work? Just the importation of the corresponding CSS files?
George
On 8/29/04 2:07 PM, "Mike Noyes" <mh...@us...> wrote:
> 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...
>>
>> ...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.
>
> Shaun,
> I just put up another prof-of-concept. It shows descendant selectors,
> cascade, and collision resolution in action. A cascade list is liked, so
> you can understand the structure I'm proposing.
>
> http://phpwebsite-comm.sourceforge.net/temp/
>
> Any comments and/or suggestions are welcome.
______________________________________
George Brackett, Principal
George Brackett Associates
617 413 4316 / gbr...@lu...
http://www.luceatlux.com/gba/
|
|
From: Shaun M. <sh...@ae...> - 2004-08-29 19:36:19
|
On 29 Aug 2004, at 19:44, George Brackett wrote: > VERY interesting, Mike. For those of us who are CSS-challenged, what > changes to the mod code of menuman and pagemaster are required for > this to > work? Just the importation of the corresponding CSS files? It won't yet, this is for a future version we're thinking of - 0.9.4 or so. You can get pretty close using ul/li and css already with the existing css menuman templates though. BUT, this is more about making sure it can be used as a model throughout phpWebSite. Shaun aegis design - http://www.aegisdesign.co.uk |
|
From: Mike N. <mh...@us...> - 2004-08-29 20:27:53
|
On Sun, 2004-08-29 at 11:44, George Brackett wrote: > VERY interesting, Mike. For those of us who are CSS-challenged, what > changes to the mod code of menuman and pagemaster are required for this to > work? Just the importation of the corresponding CSS files? George, I have a patch for phpwsrssfeeds that will give you some of this functionality in 0.9.3x. However, the @import is in html head. This means you'd have to use embedded styles to override the stylesheet. Currently, phpwsrssfeeds embeds its css in head. I'd like to see boost handle the @import of module stylesheets into /conf/mod.css. Writing that code in php may be difficult. -- Mike Noyes <mhnoyes at users.sourceforge.net> http://sourceforge.net/users/mhnoyes/ SF.net Projects: ffl, leaf, phpwebsite, phpwebsite-comm, sitedocs |
|
From: Shaun M. <sh...@ae...> - 2004-08-29 19:28:58
|
On 29 Aug 2004, at 19:07, Mike Noyes wrote: > > Shaun, > I just put up another prof-of-concept. It shows descendant selectors, > cascade, and collision resolution in action. A cascade list is liked, > so > you can understand the structure I'm proposing. > > http://phpwebsite-comm.sourceforge.net/temp/ > > Any comments and/or suggestions are welcome. That works although I don't see why you hang everything off a div, it's unnecessary and introduces an arbitrary structure into a document that need not be there. Instead of <div class="menuman horizontal"> <ul> ... </ul> </div> Just use <ul class="horizontal"> ... </ul> then in the css define .horizontal ul { ... } If you want special treatment in a particular mod, then enclose the content in a <div class="menuman"> </div> in the template, and the mod's stylesheet will cascade the specifics. Shaun aegis design - http://www.aegisdesign.co.uk |
|
From: Mike N. <mh...@us...> - 2004-08-29 20:14:52
|
On Sun, 2004-08-29 at 12:29, Shaun Murray wrote: > On 29 Aug 2004, at 19:07, Mike Noyes wrote: > > > > http://phpwebsite-comm.sourceforge.net/temp/ > > > > Any comments and/or suggestions are welcome. > > That works although I don't see why you hang everything off a div, it's > unnecessary and introduces an arbitrary structure into a document that > need not be there. Shawn, I think you missed the global div styles for menuman. Extending menuman styles to use variants (vertical, horizontal, tabbed, rollover, etc.) required the double class. At least that was the only reasonable solution I found. > Instead of > > <div class="menuman horizontal"> > <ul> > ... > </ul> > </div> > > Just use > > <ul class="horizontal"> > ... > </ul> > > then in the css define > > .horizontal ul { ... } A global class name of 'horizontal' isn't very descriptive, and can easily cause a conflict that is resolved improperly. I believe specificity is very important when dealing with multiple stylesheets in this proposal. Note the overrides in persistant.css, and the override in pagemaster.css. > If you want special treatment in a particular mod, then enclose the > content in a <div class="menuman"> </div> in the template, and the > mod's stylesheet will cascade the specifics. I'm still learning things about cascade, so I might well be wrong. -- Mike Noyes <mhnoyes at users.sourceforge.net> http://sourceforge.net/users/mhnoyes/ SF.net Projects: ffl, leaf, phpwebsite, phpwebsite-comm, sitedocs |
|
From: Mike N. <mh...@us...> - 2004-08-29 20:45:16
|
On Sun, 2004-08-29 at 13:21, Mike Noyes wrote: > Note the overrides in persistant.css, and the override in > pagemaster.css. Correction: s/persistant.csss/preferred.css/ -- Mike Noyes <mhnoyes at users.sourceforge.net> http://sourceforge.net/users/mhnoyes/ SF.net Projects: ffl, leaf, phpwebsite, phpwebsite-comm, sitedocs |
|
From: Shaun M. <sh...@ae...> - 2004-08-07 19:30:03
|
On 7 Aug 2004, at 16:14, Mike Noyes wrote: > > Shaun, > Let me preface my comments with: I'm no CSS expert. However, type > selectors are the major method for styling. Unlike class and ID > selectors, type selectors don't require style calls in the html markup. > > http://css.maxdesign.com.au/selectutorial/selectors_type.htm > "The most common and easy to understand selectors are type > selectors." > They are correct and it's why they should be used wherever possible. > In addition, the vast majority of stylesheets I've looked at use type > selectors to correct browser inconsistencies. Example (viewport): > > html, body {margin: 0; padding: 0} > That's wrong. You aren't 'correcting' a browser inconsistency there, you're replacing inconsistent behaviour of the browsers to something that will be consistent. I agree that html, body {margin: 0; padding: 0} is good though I don't think that should be enforced if a designer doesn't want to use it. God forbid there's any Netscape 4.7 users around but you might have to design a consistent interface for that as well as other browsers. Some government bodies were still speccing 4.7 support last I was involved with one. > >> I'd tighten up on where they are used in the templates but not in >> defining their looks at all. That's not the aim for core styles. > > It sounds like we may have a different view. Let me attempt to explain > my view. > > Core style is global in scope and limited in size. Core is > defined in the persistent stylesheet. > > Do we agree so far? > Not really but I think it's mostly because you want to define a standard to replace the HTML standard set whereas I'm not really bothered with that at all and want to add to it, not alter it per se. > Core style uses type selectors where possible to define element > presentation, and correct browser inconsistencies. You mentioned http://www.w3.org/TR/REC-CSS2/sample.html as the basis of a core persistent style sheet. I don't know a single browser that doesn't implement that already so why should we ship it and users download it? OK, we could correct a few IE bugs like centering, perhaps even box models but it's a big hunk of css for little reason IMHO. I really think that's an entirely different discussion. > We may have some semantic differences above. I believe the following > section is what you're concerned with. > > Site specific styles (themes) will be defined in the default > and > alternate stylesheets. Default style will use div descendant > selectors to provide style blocks for menu, module, image > float, > etc. use. Class/ID types used in phpwebsite will be written > down > for module and theme developer reference. > That's the discussion. I just want to avoid inconsistent style, which means defining one. We're still going to need to define some classes as you can't do everything with descendent type selectors. eg. You can make tree menus, tab menus and breadcrumbs all with ul/li but you'd still need three classes. I want to define those classes so they are available in a base definition that theme developers can adhere to. > > Agreed, provided you're not suggesting adoption of a template system > like smarty. > Er, no. Having just suggested Sigma to Matt for 0.94 and getting that through I'll stick there. ;-) >> > > Are you suggesting a best practices document? > [shivers] No I hate that phrase. Reminds me of when I was an ISO9001 Auditor. But I guess so. I notice the term 'best practice' only appears in the Perl docs on Apple's developer docs site. I'll crack on with a review of the UI next week, identify and report. Then we can talk UI guidelines and how they are implemented such that we've a rich UI experience with as least hassle for developers, admins and designers as possible. Shaun aegis design - http://www.aegisdesign.co.uk |
|
From: Mike N. <mh...@us...> - 2004-08-07 20:25:16
|
On Sat, 2004-08-07 at 12:30, Shaun Murray wrote: > On 7 Aug 2004, at 16:14, Mike Noyes wrote: > > We may have some semantic differences above. I believe the following > > section is what you're concerned with. > > > > Site specific styles (themes) will be defined in the default > > and > > alternate stylesheets. Default style will use div descendant > > selectors to provide style blocks for menu, module, image > > float, > > etc. use. Class/ID types used in phpwebsite will be written > > down > > for module and theme developer reference. > > > > That's the discussion. I just want to avoid inconsistent style, which > means defining one. We're still going to need to define some classes as > you can't do everything with descendent type selectors. Shaun, I think I should read through this thread a couple of more times. I think we're making similar suggestions, but I'm not communicating well. I'll ponder the conversation, and hopefully gain some understanding of the concepts discussed. -- Mike Noyes <mhnoyes at users.sourceforge.net> http://sourceforge.net/users/mhnoyes/ SF.net Projects: ffl, leaf, phpwebsite, phpwebsite-comm, sitedocs |
|
From: Mike N. <mh...@us...> - 2004-08-07 22:06:16
|
On Sat, 2004-08-07 at 12:30, Shaun Murray wrote: > On 7 Aug 2004, at 16:14, Mike Noyes wrote: > Not really but I think it's mostly because you want to define a > standard to replace the HTML standard set whereas I'm not really > bothered with that at all and want to add to it, not alter it per se. Shaun, I'm not suggesting or advocating a replacement for html. I'm just suggesting a way for us to separate persistent and preferred/alternate stylesheets. > > Core style uses type selectors where possible to define element > > presentation, and correct browser inconsistencies. > > You mentioned http://www.w3.org/TR/REC-CSS2/sample.html as the basis of > a core persistent style sheet. I don't know a single browser that > doesn't implement that already so why should we ship it and users > download it? I suggested it as a starting point for discussion. I think a _very small_ subset of that sample is warranted. Just the minimum necessary to do the job. > OK, we could correct a few IE bugs like centering, perhaps even box > models but it's a big hunk of css for little reason IMHO. It would provide consistent behavior to style from (e.g. a persistent base/core). > I really think that's an entirely different discussion. You're probably correct. It wouldn't be the first or last time I'm off on a tangent. :-( -- Mike Noyes <mhnoyes at users.sourceforge.net> http://sourceforge.net/users/mhnoyes/ SF.net Projects: ffl, leaf, phpwebsite, phpwebsite-comm, sitedocs |
|
From: Matthew M. <ma...@tu...> - 2004-08-09 13:31:48
|
Mike and Shaun,
What a great discussion =) The developer's list surely hasn't been this
active in a while.
Shaun sez:
> It'd be nice to pin down some class names and put them in as a
> requirement in any style.css though. There are some already like the
> background colours that are mandatory and more should be specified as
> a common resource that module developers can rely on.
You know, at first I was against this. I figured it wasn't 'clean' or
'efficient'. However, usability is going to blast these concerns out of
the water. If structure complicates usability then it isn't beneficial
(I'm looking at you W3C). Having a central location (the style sheet) to
completely reform the theme far outweighs the division of execution. I
am going to leave in the module style sheets, but I think we should
define the rules as to when they should used.
After reading the letters you guys have submitted, I suggest the
following:
1) The persistent style sheet ('PSS' from here on) only has one rule as
far a theme developer is concerned: it contains the elements that are
'persistent' between the alternate style sheets (no duh).
2) The PSS is not a phpWebSite defined sheet. We don't ship with
expectations on font size, body padding, etc.
3) I believe the PSS should NOT (as Mike suggested) contain class
selectors. This includes phpWebSite specific selectors.
4) The PSS should not contain colors, images, or positioning unless they
remain persistent through all alternates. I would like to see a PSS
present a clean, basic layout as a fall back position.
5) The default style sheet and its alternatives will contain the
phpWebSite specific class selectors and the theme developers personal
class selectors.
6) PhpWebSite will define style components. This list should be varied
enough that both module and theme developers can choose from enough
tags.
7) The components list should not be lengthy.
8) Any theme that does not follow these guidelines will NOT be rejected.
9) The MAIN goals of theming are to be usable, friendly, and orderly. We
want to lead by example and get people excited about theming for
phpWebSite. See 8. We don't want to chastise people for not following
protocol. We want to lead by example.
10) PSS rules can be ignored if a theme contains only that style sheet
and no alternates.
Please discuss these guidelines. After we agree on which guidelines to
follow, we can begin to create our list of class and id selectors.
Thanks,
Matt
Matthew McNaney
Internet Systems Architect
Electronic Student Services
Appalachian State University
Phone: 828-262-6493
http://phpwebsite.appstate.edu
http://ess.appstate.edu
|
|
From: Wendall C. <wen...@83...> - 2004-08-12 18:59:06
|
+1 on all Matt's suggestions.
Wendall
On Mon, 2004-08-09 at 06:28, Matthew McNaney wrote:
> Mike and Shaun,
>
> What a great discussion =) The developer's list surely hasn't been this
> active in a while.
>
> Shaun sez:
> > It'd be nice to pin down some class names and put them in as a
> > requirement in any style.css though. There are some already like the
> > background colours that are mandatory and more should be specified as
> > a common resource that module developers can rely on.
>
> You know, at first I was against this. I figured it wasn't 'clean' or
> 'efficient'. However, usability is going to blast these concerns out of
> the water. If structure complicates usability then it isn't beneficial
> (I'm looking at you W3C). Having a central location (the style sheet) to
> completely reform the theme far outweighs the division of execution. I
> am going to leave in the module style sheets, but I think we should
> define the rules as to when they should used.
>
> After reading the letters you guys have submitted, I suggest the
> following:
>
> 1) The persistent style sheet ('PSS' from here on) only has one rule as
> far a theme developer is concerned: it contains the elements that are
> 'persistent' between the alternate style sheets (no duh).
>
> 2) The PSS is not a phpWebSite defined sheet. We don't ship with
> expectations on font size, body padding, etc.
>
> 3) I believe the PSS should NOT (as Mike suggested) contain class
> selectors. This includes phpWebSite specific selectors.
>
> 4) The PSS should not contain colors, images, or positioning unless they
> remain persistent through all alternates. I would like to see a PSS
> present a clean, basic layout as a fall back position.
>
> 5) The default style sheet and its alternatives will contain the
> phpWebSite specific class selectors and the theme developers personal
> class selectors.
>
> 6) PhpWebSite will define style components. This list should be varied
> enough that both module and theme developers can choose from enough
> tags.
>
> 7) The components list should not be lengthy.
>
> 8) Any theme that does not follow these guidelines will NOT be rejected.
>
> 9) The MAIN goals of theming are to be usable, friendly, and orderly. We
> want to lead by example and get people excited about theming for
> phpWebSite. See 8. We don't want to chastise people for not following
> protocol. We want to lead by example.
>
> 10) PSS rules can be ignored if a theme contains only that style sheet
> and no alternates.
>
> Please discuss these guidelines. After we agree on which guidelines to
> follow, we can begin to create our list of class and id selectors.
>
> Thanks,
> Matt
>
>
> Matthew McNaney
> Internet Systems Architect
> Electronic Student Services
> Appalachian State University
> Phone: 828-262-6493
> http://phpwebsite.appstate.edu
> http://ess.appstate.edu
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by OSTG. Have you noticed the changes on
> Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
> one more big change to announce. We are now OSTG- Open Source Technology
> Group. Come see the changes on the new OSTG site. www.ostg.com
> _______________________________________________
> Phpwebsite-developers mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phpwebsite-developers
--
"Only the ideas that we really live have any value." --Hermann Hesse
(Demian)
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X