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 |