Menu
▾
▴
phpwebsite-developers — For our development team.
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
(1) |
Mar
(265) |
Apr
(166) |
May
(25) |
Jun
(17) |
Jul
(20) |
Aug
(47) |
Sep
(6) |
Oct
(14) |
Nov
(66) |
Dec
(64) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
(109) |
Feb
(64) |
Mar
(34) |
Apr
(23) |
May
(64) |
Jun
(9) |
Jul
(13) |
Aug
(6) |
Sep
(33) |
Oct
(272) |
Nov
(67) |
Dec
(75) |
| 2003 |
Jan
(264) |
Feb
(244) |
Mar
(171) |
Apr
(119) |
May
(54) |
Jun
(93) |
Jul
(51) |
Aug
(48) |
Sep
(14) |
Oct
(49) |
Nov
(47) |
Dec
(15) |
| 2004 |
Jan
(13) |
Feb
(27) |
Mar
(18) |
Apr
(44) |
May
(35) |
Jun
(24) |
Jul
(39) |
Aug
(142) |
Sep
(35) |
Oct
(34) |
Nov
(49) |
Dec
(24) |
| 2005 |
Jan
(60) |
Feb
(71) |
Mar
(19) |
Apr
(27) |
May
(68) |
Jun
(4) |
Jul
(30) |
Aug
(10) |
Sep
(23) |
Oct
(24) |
Nov
(13) |
Dec
(6) |
| 2006 |
Jan
(4) |
Feb
(46) |
Mar
(64) |
Apr
(18) |
May
(16) |
Jun
(37) |
Jul
(7) |
Aug
(19) |
Sep
(9) |
Oct
(8) |
Nov
(3) |
Dec
(23) |
| 2007 |
Jan
(25) |
Feb
(21) |
Mar
(32) |
Apr
(36) |
May
(12) |
Jun
(1) |
Jul
(7) |
Aug
(15) |
Sep
(13) |
Oct
(1) |
Nov
|
Dec
|
| 2008 |
Jan
(3) |
Feb
(5) |
Mar
(1) |
Apr
(2) |
May
|
Jun
(1) |
Jul
(2) |
Aug
(7) |
Sep
|
Oct
(5) |
Nov
(1) |
Dec
|
| 2009 |
Jan
(7) |
Feb
(1) |
Mar
|
Apr
|
May
(1) |
Jun
(2) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(3) |
| 2011 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
|
From: Shaun M. <sh...@ae...> - 2004-08-10 02:43:23
|
On 8 Aug 2004, at 21:28, Eloi George wrote: > > Personally, I think our collective coding time would be better spent > on quite a few other core class ideas than a universal section class. > There are only a very few possible uses for the page/section paradigm, > and I'm constantly looking for an easy-to-use, > non-javascript-intensive way to get away from it and still retain the > layout flexibility. > Since the sections are mostly a way to manage and layout images alongside text rather than to divide text into sections, the problem is really to solve an easy way for newbies to insert and manage images without knowing html. Maybe that is actually best served by a wysiwyg tool like htmlarea/hypertextarea as it looks like Word rather than them having to work out templates and sections. The only real (ignoring weird things like PDAs and phones) problem area is Mac users on MacIE and Safari as there isn't a solution for them. Then again, that's a small bunch to annoy and they can always use Firefox instead. Safari v1.2.3 has just been released and I could have sworn Hyatt was saying it'd have contentEditable in that version. I'll have to find out although Apple take a while to actually release changelogs. MacIE is a dead product anyway. Personally, I end up ftping my images up and typing in the html myself and not using sections a lot of the time. Maybe there should be an 'advanced' interface which just simply had a method of uploading images and a simple 'click on the thumbnail' interface that inserted the html at the cursor. A Preview button is handy also that would preview the page in a separate window so you could see your layout whilst editing. Then you just need Page breaks and TOCs. In 0.8x I just added a bit of code that looked for [PAGE BREAK] in the content. Maybe something similar. Shaun aegis design - http://www.aegisdesign.co.uk |
|
From: Julie J. <jj...@cu...> - 2004-08-09 16:31:47
|
I'm working on a large site for a private catholic highschool using phpwebsite 0.9.3-3. They need web pages created or edited by one user (editor) to be approved by another (publisher) before getting published. I have the editor user set as an administrator, belonging to a group with preferences all unchecked except for: Web Pages Create Pages Edit Pages Delete Pages which all have been checked. When I create a new web page as an editor user I get told it has been sent to the administrator for approval. However when I edit an exsisting page created by any user (including the editor user) it gets saved to the database. This occurs in web pages NOT set as a mainpage. Is this a bug or just not a feature? Or am I missing something? I'd convert the web pages into articles for this functionality, but there are already over at least 30 of them. I have not found anything in the CVS on pagemaster different from what I have on the server. No word of this problem on the forums or this email list. Any help will be appreciated, ____________ Julia A. Jacobs Currant Media Specialists in Self-Reliant Marketing www.currantmedia.com (407) 261-9351 Fax: (407) 339-4404 |
|
From: Shaun M. <sh...@ae...> - 2004-08-09 14:54:19
|
The way I've done 2 or 3 column pages in pagemaster in the past is to
define a new section template which uses float:left in the class used
on the DIV. Set the width dependent on the number of columns you want.
A clear:both afterwards is sometimes useful or put the clear:both on
the other existing section templates which you've probably modified
anyway to remove tables. ;-)
eg.
.floaty {
float: left;
width: 50%;
}
create a new section template called floaty.tpl
<div class="floaty>
<h3>{TITLE}</h3>
{CONTENT}
</div>
(or whatever you want in there.
If you want 3 columns, use 33%. If using margins/padding, watch for
IE's box model bugs.
On 9 Aug 2004, at 15:33, George Brackett wrote:
> That sounds like a very interesting approach. But I don't quite
> understand,
> Eloi, what you mean by asking whether Pagemaster 'fully supports page
> templates now'. (I don't use Article Manager any more because users
> protested the copyright message.) The default Pagemaster page template
> lumps everything together in a {CONTENT} tag, meaning it's up to
> Pagemaster
> itself to lay out the page except for add-ons like date published etc.
> Granted, the section templates (e.g., image_float_left.tpl) can lay
> out a
> section pretty much any way {IMAGE} and {TEXT} can be arranged, but
> ultimately Pagemaster just strings all those sections (each sitting in
> a
> table) in a line down the page. It's not clear to me how one would
> put that
> in a two-column layout without modifying the PageMaster code. Most of
> the
> options I can think of for a series of section templates like the one
> you
> suggest would make individual templates sensitive to the proper use of
> other
> templates (e.g. one template starts a <div> and another finishes it).
>
> George
>
> On 8/8/04 11:38 PM,
> "php...@li..."
> <php...@li...> wrote:
>
>> Send Phpwebsite-developers mailing list submissions to
>> php...@li...
>>
>> To subscribe or unsubscribe via the World Wide Web, visit
>> https://lists.sourceforge.net/lists/listinfo/phpwebsite-developers
>> or, via email, send a message with subject or body 'help' to
>> php...@li...
>>
>> You can reach the person managing the list at
>> php...@li...
>>
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of Phpwebsite-developers digest..."
>>
>>
>> Today's Topics:
>>
>> 1. Re: More phpWS and OOP (Eloi George)
>>
>> --__--__--
>>
>> Message: 1
>> Date: Sun, 08 Aug 2004 16:28:28 -0400
>> From: Eloi George <el...@re...>
>> To: php...@li...
>> Subject: Re: [Phpwebsite-developers] More phpWS and OOP
>> Reply-To: php...@li...
>>
>> I don't know why, but Sourceforge almost always delays my submissions
>> to
>> this list...
>>
>> I understand your goal a lot more now, but I think it can be achieved
>> with existing modules. Article Manager (and PageMaster if it fully
>> supports page templates now) is designed for just that purpose. A
>> specific newsletter layout is defined as the overall page template
>> design plus any particular combination of section templates. If you
>> add
>> in section templates that utilize "div"s with "float:left/right" to
>> define columns, then you can end up with any layout you choose!
>>
>> Once a particular layout is designed, then all the designers have to
>> know is that Layout#1 consists of Page Template "Layout_1" with
>> sections
>> in the order of "Right_Column_Top", any number of
>> "Right_Column_Middle", "Right_Column_Bottom", "Headline", and any
>> number
>> of "Body".
>>
>> Or if you want to make it even easier, you could submit an RFE (or a
>> patch ;)) to allow either module to clone an new article/page off of
>> an
>> existing blank one.
>>
>> On the other hand, if you wanted to make the newsletter module create
>> the articles itself, the technique is illustrated in the importation
>> scripts.
>>
>> Personally, I think our collective coding time would be better spent
>> on
>> quite a few other core class ideas than a universal section class.
>> There are only a very few possible uses for the page/section paradigm,
>> and I'm constantly looking for an easy-to-use,
>> non-javascript-intensive
>> way to get away from it and still retain the layout flexibility.
>>
>> -Eloi-
>>
>>
>>
>>
>>
>> --__--__--
>>
>> _______________________________________________
>> Phpwebsite-developers mailing list
>> Php...@li...
>> https://lists.sourceforge.net/lists/listinfo/phpwebsite-developers
>>
>>
>> End of Phpwebsite-developers Digest
>>
>
> ______________________________________
> George Brackett, Principal
> George Brackett Associates
> 617 413 4316 / gbr...@lu...
> http://www.luceatlux.com/gba/
>
>
>
>
> -------------------------------------------------------
> 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: George B. <gbr...@lu...> - 2004-08-09 14:33:48
|
That sounds like a very interesting approach. But I don't quite understand,
Eloi, what you mean by asking whether Pagemaster 'fully supports page
templates now'. (I don't use Article Manager any more because users
protested the copyright message.) The default Pagemaster page template
lumps everything together in a {CONTENT} tag, meaning it's up to Pagemaster
itself to lay out the page except for add-ons like date published etc.
Granted, the section templates (e.g., image_float_left.tpl) can lay out a
section pretty much any way {IMAGE} and {TEXT} can be arranged, but
ultimately Pagemaster just strings all those sections (each sitting in a
table) in a line down the page. It's not clear to me how one would put that
in a two-column layout without modifying the PageMaster code. Most of the
options I can think of for a series of section templates like the one you
suggest would make individual templates sensitive to the proper use of other
templates (e.g. one template starts a <div> and another finishes it).
George
On 8/8/04 11:38 PM, "php...@li..."
<php...@li...> wrote:
> Send Phpwebsite-developers mailing list submissions to
> php...@li...
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.sourceforge.net/lists/listinfo/phpwebsite-developers
> or, via email, send a message with subject or body 'help' to
> php...@li...
>
> You can reach the person managing the list at
> php...@li...
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Phpwebsite-developers digest..."
>
>
> Today's Topics:
>
> 1. Re: More phpWS and OOP (Eloi George)
>
> --__--__--
>
> Message: 1
> Date: Sun, 08 Aug 2004 16:28:28 -0400
> From: Eloi George <el...@re...>
> To: php...@li...
> Subject: Re: [Phpwebsite-developers] More phpWS and OOP
> Reply-To: php...@li...
>
> I don't know why, but Sourceforge almost always delays my submissions to
> this list...
>
> I understand your goal a lot more now, but I think it can be achieved
> with existing modules. Article Manager (and PageMaster if it fully
> supports page templates now) is designed for just that purpose. A
> specific newsletter layout is defined as the overall page template
> design plus any particular combination of section templates. If you add
> in section templates that utilize "div"s with "float:left/right" to
> define columns, then you can end up with any layout you choose!
>
> Once a particular layout is designed, then all the designers have to
> know is that Layout#1 consists of Page Template "Layout_1" with sections
> in the order of "Right_Column_Top", any number of
> "Right_Column_Middle", "Right_Column_Bottom", "Headline", and any number
> of "Body".
>
> Or if you want to make it even easier, you could submit an RFE (or a
> patch ;)) to allow either module to clone an new article/page off of an
> existing blank one.
>
> On the other hand, if you wanted to make the newsletter module create
> the articles itself, the technique is illustrated in the importation
> scripts.
>
> Personally, I think our collective coding time would be better spent on
> quite a few other core class ideas than a universal section class.
> There are only a very few possible uses for the page/section paradigm,
> and I'm constantly looking for an easy-to-use, non-javascript-intensive
> way to get away from it and still retain the layout flexibility.
>
> -Eloi-
>
>
>
>
>
> --__--__--
>
> _______________________________________________
> Phpwebsite-developers mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phpwebsite-developers
>
>
> End of Phpwebsite-developers Digest
>
______________________________________
George Brackett, Principal
George Brackett Associates
617 413 4316 / gbr...@lu...
http://www.luceatlux.com/gba/
|
|
From: Shaun M. <sh...@ae...> - 2004-08-09 14:24:20
|
On 9 Aug 2004, at 13:26, Oosterhoff, Ton wrote: > Don't forget to change php insertion from FALSE to TRUE in > layout/conf/config.php! That's now the default (TRUE) in 0.9.3-4 btw. Otherwise the w3c theme doesn't work. Shaun aegis design - http://www.aegisdesign.co.uk |
|
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: Oosterhoff, T. <ton...@dh...> - 2004-08-09 12:26:31
|
Don't forget to change php insertion from FALSE to TRUE in = layout/conf/config.php! =20 Ton Oosterhoff |
|
From: Eloi G. <el...@re...> - 2004-08-08 20:45:08
|
I don't know why, but Sourceforge almost always delays my submissions to this list... I understand your goal a lot more now, but I think it can be achieved with existing modules. Article Manager (and PageMaster if it fully supports page templates now) is designed for just that purpose. A specific newsletter layout is defined as the overall page template design plus any particular combination of section templates. If you add in section templates that utilize "div"s with "float:left/right" to define columns, then you can end up with any layout you choose! Once a particular layout is designed, then all the designers have to know is that Layout#1 consists of Page Template "Layout_1" with sections in the order of "Right_Column_Top", any number of "Right_Column_Middle", "Right_Column_Bottom", "Headline", and any number of "Body". Or if you want to make it even easier, you could submit an RFE (or a patch ;)) to allow either module to clone an new article/page off of an existing blank one. On the other hand, if you wanted to make the newsletter module create the articles itself, the technique is illustrated in the importation scripts. Personally, I think our collective coding time would be better spent on quite a few other core class ideas than a universal section class. There are only a very few possible uses for the page/section paradigm, and I'm constantly looking for an easy-to-use, non-javascript-intensive way to get away from it and still retain the layout flexibility. -Eloi- |
|
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: 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 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: 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: 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 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: 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: Daniel W. <dan...@pa...> - 2004-08-07 00:39:48
|
On the topic of style sheets, I've cut mine down to this: http://homepages.paradise.net.nz/msdtwint/style.css I have spent a bit of time removing unnecessary tables and things like "bg_light" from the public modules that I use (announcements, page master, menu manager). I think making the panel use <ul> and <li> would be a good idea. I've submitted a patch for, what I think is, better css menus: http://www.sourceforge.net/tracker/index.php?func=detail&aid=1004307&group_i d=15539&atid=315539 Should I go ahead and submit what I've done for standardised xhtml? Daniel |
|
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: Ryan R. <to...@gm...> - 2004-08-06 20:43:09
|
In response to your email calling for non-linux/mysql installation
tests, here's a few notes on Windows 2000 Server - Apache 1.3.29 - PHP
4.3.4 (no gettext) - MySQL 3.23.49
First off, let me extend my most sincere contrafibularities to you on
an impressive installation walkthrough/wizard. Looks sharp, responds
quickly, very straightforward.
Here are a few issues that I had in my installation:
1) When I'm installing, after step 1 (DB config) I get a 'Notice:
Missing a host reference." I looked at the postDatabaseConfig() in
Setup.php and (~ line 123):
if (!empty($_POST['dbhost']))
$content[] = _("Notice: Missing a host reference.") . "<br />";
It seems that if you fill-in anything (i.e. !empty) for database host,
it throws this message. Is this desired functionality?
2) After the installation process there are several undefined
constants or indexes which are displayed in PHP Notices:
Notice: Use of undefined constant PHPWS_DAY_START - assumed
'PHPWS_DAY_START' in e:\web\htdocs\phpwebsite094\core\class\Crutch.php
on line 53
Notice: Use of undefined constant PHPWS_TIME_DIFF - assumed
'PHPWS_TIME_DIFF' in e:\web\htdocs\phpwebsite094\core\class\Crutch.php
on line 54
Notice: Use of undefined constant PHPWS_DATE_FORMAT - assumed
'PHPWS_DATE_FORMAT' in
e:\web\htdocs\phpwebsite094\core\class\Crutch.php on line 57
Notice: Use of undefined constant PHPWS_TIME_FORMAT - assumed
'PHPWS_TIME_FORMAT' in
e:\web\htdocs\phpwebsite094\core\class\Crutch.php on line 58
Notice: Undefined index: users in
e:\web\htdocs\phpwebsite094\mod\layout\class\Layout.php on line 235
Notice: Use of undefined constant CURRENT_LANGUAGE - assumed
'CURRENT_LANGUAGE' in
e:\web\htdocs\phpwebsite094\mod\layout\class\Layout.php on line 448
Notice: Use of undefined constant CURRENT_LANGUAGE - assumed
'CURRENT_LANGUAGE' in
e:\web\htdocs\phpwebsite094\mod\layout\class\Layout.php on line 448
Notice: Use of undefined constant CURRENT_LANGUAGE - assumed
'CURRENT_LANGUAGE' in
e:\web\htdocs\phpwebsite094\mod\layout\class\Layout.php on line 450
3) There appears to be a localhost binding for some reason
In the page source, there's a <base>:
<base href="http://localhost/phpwebsite094/" />
This causes all relative references (most all) to be prefixed. This
means that I cannot login due to the form submission attempting to
post to a local server. It also means that all stylesheet and image
references are not found.
Just a few small things. Let me know if there is any additional
information you need (i.e. PHP build functionality). Or if there is
any other testing you need done (no, I'm not a linguist).
Thanks,
Ryan Roland
Application Developer
Information Technology
Division of Recreational Sports
Indiana University
812.855.9617
rmr...@in...
On Fri, 23 Jul 2004 12:59:31 -0400, Matthew McNaney
<ma...@tu...> wrote:
> Hello all,
>
> As work continues on 0.9.4, I am interested in getting some feedback on
> various components.
>
> I get many letters offering to assist with language translation. Well
> here is your chance!
>
> Please take a moment to check out a copy of phpwebsite 0.9.4 from CVS.
> Then take a look at the docs/Language.txt file. It contains instructions
> on how to translate phpwebsite. I have done some testing here but since
> I am monolingual it is hard to do too much.
>
> Before and while you test please be aware that this is alpha code and
> many components are not finished.
>
> Anyway, what I need to know is
> 1) if it works
> 2) if the documentation explains how to translate well enough
> 3) if I am missing a component that will be required for proper i18n
> support
> 4) if the method for storing translations is sufficient.
>
> Besides the language component, I am also interested in the installation
> outside of a linux/mysql environment. If you wish to test the
> installation outside these boundaries, please do so.
>
> Best Regards,
> 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 BEA Weblogic Workshop
> FREE Java Enterprise J2EE developer tools!
> Get your free copy of BEA WebLogic Workshop 8.1 today.
> http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
> _______________________________________________
> Phpwebsite-developers mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phpwebsite-developers
>
|
|
From: Robert B. <ro...@pr...> - 2004-08-06 18:30:36
|
I have been asked to help a charitable organization put up a simple but dignified online petition. A site they liked was using geeklog. I'm wondering if anyone has done this with phpwebsite or not and how it worked out. The idea is, is to have the signer be sent an email confirming the request- like opting into a listserve. and then placing their name on the list. I would like to use phpwebsite because of the other available options in it. If anyone has any input, I'd appreciate it. Rob -- Robert Brandtjen <ro...@pr...> Prometheusmedia |
|
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 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: 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 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: Ulf H. <U1...@ul...> - 2004-08-06 16:23:20
|
Hi,
we ran into the necessity of displaying a filtered PHPWS_List, for
example for displaying all documents of a certain category (which IMHO
is a great value add for doc manager).
This needs
- a pre-populated drop-down for categories above the list
- the ability to ass a INNER JOIN sql statement to PHPWS_List
- the ability to pass a parameter to PHPWS_Pager for the correct
pre-selection of the drop-down.
While adding the drop-down control is a piece of cake, actually passing
a JOIN statement needs customizazion in
- /core/list.php:
class variable $join, analogue to $where, including a setter functtion
setter for $params to be passed to pager.
- core/pager.php
evaulation of URI parameters with $params analogue to $anchors.
I am hesitant to post this as a core issue, as the main drivers for this
would be the models which are using the list object. However, if people
think that this is a valuable improvement of the core, I will be more
than happy to submit my code.
Ulf
|
|
From: Ulf H. <U1...@ul...> - 2004-08-06 16:12:23
|
Mike, thanks for the hint. Currently, we prefer paying a resource by the hour for a project with a still blurred scope - this makes things a little tricky when it comes to defining a bounty with a fixed price tag on it. Greetings form Munich Ulf Mike Noyes wrote: >On Thu, 2004-08-05 at 09:39, Ulf Hallmann wrote: > > >>please excuse if this is not the correct list for postings like this. >> >>Please contact myself in case there is a better place for posting >>this. >> >> > >Ulf, >The phpwebsite-comm project recently launched a 'bounties' page. You may >want to consider it. > > http://phpwebsite-comm.sourceforge.net/ > > > |
5 messages has been excluded from this view by a project administrator.
