[drupal-devel] phptemplate in core?
Adrian et al, here is what I'd like to see happen: get PHPTemplate in core. We'd need to: 1. remove Xtemplate from core. 2. remove the Bluemarine theme from core (Xtemplate based). 3. remove the Pushbutton theme from core (Xtemplate based). 4. add PHPTemplate to core. 5. add a PHPTemplate-based theme to core. Steps 1, 2 and 3 are easy. Steps 4 and 5 need to be discussed. - What needs to be done to get PHPTemplate in core? From what I can tell, PHPTemplate's engine-specific settings (eg. the primary and secondary links) need some work. - What PHPTemplate-based theme should we ship with core? Should we port either Bluemarine or Pushbutton to PHPTemplate or should we go with fresh themes? My requirements for such theme would be: 1. The theme must validate as XHTML. 2. The theme's CSS classes/IDs must comply Drupal's naming conventions. 3. The theme should work on all browsers without hacks. 4. The theme should be simple and easy to customize. No themes with a bazillion of small images that no one will ever change. -- Dries Buytaert :: http://www.buytaert.net/
- What PHPTemplate-based theme should we ship with core? Should we port either Bluemarine or Pushbutton to PHPTemplate or should we go with fresh themes? My requirements for such theme would be: 1. The theme must validate as XHTML. 2. The theme's CSS classes/IDs must comply Drupal's naming conventions. 3. The theme should work on all browsers without hacks. 4. The theme should be simple and easy to customize. No themes with a bazillion of small images that no one will ever change.
Marvin2k for phptemplate might be a candidate since it is already done (it might need a polish though). It was directly ported from a custom theme format which was used by the original Marvin2k theme. Info from the original theme: | An update to the original marvin theme, using the latest | web standards. | | A complete update to the original marvin theme, marvin_2k | provides many new features. Some of the features include a | new tableless, CSS based design which takes advantage of | the latest web standards. I am in no doubt that someone will be able to do an aestetically better theme, if given some time. I am just here to point out that this is there as an option. Goba
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 01 May 2005, at 5:49 PM, Dries Buytaert wrote:
- What needs to be done to get PHPTemplate in core? From what I can tell, PHPTemplate's engine-specific settings (eg. the primary and secondary links) need some work.
My plan was to get this done this weekend, but unfortunately I didn't have the time for it this week. First step I would see, is moving the phptemplate primary link configuration from the theme specific section and move it to the admin/themes/settiings, making it use the theme variables, and not just the phptemplate_primary_links variable. This is very little in the way of work, and I could do it tomorrow. - -- At this point I feel it should go into core. It will be internally consistent, and we can continue making the link configuration optimal in core. Step 2, is adding the menu functions that ber wrote to allow you to use a menu block as the source for your links. Then we need to remove the link configuration we currently use, and replace it with a drop down to select a menu block, and probably a link to configure the menu using the menu module. The settings screen should probably create a secondary menu block if none was available ( like the forum module creates a taxonomy ). Step 3, is finding a way to allow modules to define their pre-defined entries, which will be disabled by default and admins can enable them. What did we decide about this at the phptemplate links meeting again ?
- What PHPTemplate-based theme should we ship with core? Should we port either Bluemarine or Pushbutton to PHPTemplate or should we go with fresh themes? My requirements for such theme would be:
I vote for fresh themes. Or atleast , I vote for a new default theme. Is chameleon going to stay as it is (a .theme), or can we convert it to .tpl.php too (which is rather simple to do). - -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) iD8DBQFCdRyfgegMqdGlkasRAuB6AJkBua9/24kcNNaZAd8fH3Tj+dEJ6wCgmZlj mSKfSsVchE8K1R0vOowIsYQ= =DdMF -----END PGP SIGNATURE-----
I vote for fresh themes. Or atleast , I vote for a new default theme. Is chameleon going to stay as it is (a .theme), or can we convert it to .tpl.php too (which is rather simple to do).
IMHO it is a good idea to keep a .theme based theme in core, as long as this method of themeing is supported. I use this approach heavily for one. Goba
+1 for keeping chameleon in core and .theme based. It reminds people that Drupal theming is really a simple matter. It is too easy to forget that Drupal php code generates all the HTML one would really ever need to run a full website. The theme overriding is the first layer of possibility for design and templating engines are a further layer.
IMHO it is a good idea to keep a .theme based theme in core, as long as this method of themeing is supported. I use this approach heavily for one.
On 5/1/05, Gabor Hojtsy <gabor@hojtsy.hu> wrote:
I vote for fresh themes. Or atleast , I vote for a new default theme. Is chameleon going to stay as it is (a .theme), or can we convert it to .tpl.php too (which is rather simple to do).
IMHO it is a good idea to keep a .theme based theme in core, as long as this method of themeing is supported. I use this approach heavily for one.
Goba
I wholeheartedly agree. I fear that if the last .theme in core is removed, people may be tempted to remove this style of theming altogether, to be replaced with template-based themes. The ability to define (whole or partial) .theme files is what makes Drupal's theme system great, so this would be a great tragedy. Tom
On Sun, 1 May 2005, Adrian Rossouw wrote:
I vote for fresh themes. Or atleast , I vote for a new default theme.
Would be nice, yes.
Is chameleon going to stay as it is (a .theme), or can we convert it to .tpl.php too (which is rather simple to do).
I'd like to keep it as it is. But I'd like to see a converted version too in order to do benchmarks. :) Cheers, Gerhard
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 01 May 2005, at 7:55 PM, Gerhard Killesreiter wrote:
I'd like to keep it as it is. But I'd like to see a converted version too in order to do benchmarks. :)
It's mostly just for designer friendliness I'd consider changing it. I don't think there's anything complex enough about it that it warrants a .theme. But I suppose that's kind of hard to say, since most of the complex themes out there are being implemented in phptemplate, and the template.php file makes it more flexible, and still copy-able (which the chameleon theme doesn't). - -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) iD8DBQFCdS97gegMqdGlkasRAtlnAKDUye0PPckyBUWjjlrcpgZG8eCwHgCgjPnI mQs0kf5fgtW/Z0zMvuZG6jY= =Idzu -----END PGP SIGNATURE-----
I'd like to keep it as it is. But I'd like to see a converted version too in order to do benchmarks. :)
It's mostly just for designer friendliness I'd consider changing it.
I don't think there's anything complex enough about it that it warrants a .theme.
But I suppose that's kind of hard to say, since most of the complex themes out there are being implemented in phptemplate, and the template.php file makes it more flexible, and still copy-able (which the chameleon theme doesn't).
IMHO it is worth to keep a "showcase" (even if such a simple one) in core of such an important feature as the native PHP themes. It shows the versatility of the theme system quite well. If only phptemplate based themes are going to end up in core, it will be a hard time getting out the perception from some guys' minds that Drupal is phptemplate oriented. Goba
Op zondag 01 mei 2005 20:14, schreef Adrian Rossouw:
Step 2, is adding the menu functions that ber wrote to allow you to use a menu block as the source for your links. Then we need to remove the link configuration we currently use, and replace it with a drop down to select a menu block, and probably a link to configure the menu using the menu module. The settings screen should probably create a secondary menu block if none was available ( like the forum module creates a taxonomy ).
Because of this, I just revived that module and contributed it. http://drupal.org/cvs?commit=15664. I will not tag it 4.6, nor make a project for this on drupal.org until its more clear what will happen to this. Will we include this in phptemplate, in core theme system, in the menu system? etc. Feel free to commit any changes made to the module directly in CVS. Regards, Bèr -- [ Bèr Kessels | Drupal services www.webschuur.com ]
Hello, I think this is a qreat idea as I do feel that phptemplate is becoming the most popular theme engine. The primary and secondary menus are I think an issue in all theme engine, not just the phptemplate one which is pretty bad. One thing that I have done with my web site is that I am using the menu.module to control my primary menu and it works great. My theme is a derived marvin2k theme that I made changes to. At the moment I am working on using phplayersmenu to give me drop down menus, so I can take advantage of the tree structure of the menu module. I do not have any submenus yet, but once I have my theme for phplayersmenu working I will have and it will all be controlled with the same tools that is used for the navigation menu. As I said I am using the phplayersmenu by re-theming the menu theme. But I did have this all working with with the marvin2k them and the standard menu themes, when I was doing my proof of concept. As for themes I have already converted the bluemarine theme to phptemplate and I am taken a lot of effort to make this mimic the xtemplate theme as closely as possible. As I have said before I actually did this so that I could create a document on how to do this conversion. See http://www.heydon.com.au/?q=node/636 for the instructions on how to do this. This is a great idea. I give it a big +1 Gordon. -----Original Message----- From: drupal-devel-bounces@drupal.org [mailto:drupal-devel-bounces@drupal.org] On Behalf Of Dries Buytaert Sent: Monday, 2 May 2005 1:49 AM To: drupal-devel@drupal.org Subject: [drupal-devel] phptemplate in core? Adrian et al, here is what I'd like to see happen: get PHPTemplate in core. We'd need to: 1. remove Xtemplate from core. 2. remove the Bluemarine theme from core (Xtemplate based). 3. remove the Pushbutton theme from core (Xtemplate based). 4. add PHPTemplate to core. 5. add a PHPTemplate-based theme to core. Steps 1, 2 and 3 are easy. Steps 4 and 5 need to be discussed. - What needs to be done to get PHPTemplate in core? From what I can tell, PHPTemplate's engine-specific settings (eg. the primary and secondary links) need some work. - What PHPTemplate-based theme should we ship with core? Should we port either Bluemarine or Pushbutton to PHPTemplate or should we go with fresh themes? My requirements for such theme would be: 1. The theme must validate as XHTML. 2. The theme's CSS classes/IDs must comply Drupal's naming conventions. 3. The theme should work on all browsers without hacks. 4. The theme should be simple and easy to customize. No themes with a bazillion of small images that no one will ever change. -- Dries Buytaert :: http://www.buytaert.net/ !DSPAM:4274fbe3148056219212100!
The (PHPTemplate-based) theme that I would like to see in core more than any other is FriendsElectric. This is the only Drupal theme, that I know of, that uses a tableless CSS layout, and that fully validates as XHTML. All of the themes currently in core use a table-based layout, and I don't think that this helps at all, if we're trying to give Drupal an image of being a modern and standards-compliant web platform. FriendsElectric also looks really good - better than most of the current core themes, IMO. It does use a 'bazillion' of small images to do this, but they're all part of the CSS, rather than the XHTML, so this is not a huge problem. Jaza. On 5/2/05, Dries Buytaert <dries@buytaert.net> wrote:
- What PHPTemplate-based theme should we ship with core? Should we port either Bluemarine or Pushbutton to PHPTemplate or should we go with fresh themes? My requirements for such theme would be: 1. The theme must validate as XHTML. 2. The theme's CSS classes/IDs must comply Drupal's naming conventions. 3. The theme should work on all browsers without hacks. 4. The theme should be simple and easy to customize. No themes with a bazillion of small images that no one will ever change.
-- Dries Buytaert :: http://www.buytaert.net/
On 02 May 2005, at 03:29, Jeremy Epstein wrote:
The (PHPTemplate-based) theme that I would like to see in core more than any other is FriendsElectric.
FriendsElectric is a good candidate indeed. Let's see what Steven has to say about this. -- Dries Buytaert :: http://www.buytaert.net/
Why don't we get rid of primary and secondary links altogether? We could replace them with custom menus from the menu module and position them using the new block region code. We could then write menu theme functions that render any menu in a suitable way for different kinds of links (tabbed, dhtml, etc). The best code for generating hyperlinks is in the menu module - that's the base we should be resting on. -Robert
On Mon, 2 May 2005, Robert Douglass wrote:
Why don't we get rid of primary and secondary links altogether?
We could replace them with custom menus from the menu module and position them using the new block region code. We could then write menu theme functions that render any menu in a suitable way for different kinds of links (tabbed, dhtml, etc). The best code for generating hyperlinks is in the menu module - that's the base we should be resting on.
I second this request. I am using some hack to achieve this for over a year now and don't want to miss it. Cheers, Gerhard
On 02 May 2005, at 08:32, Gerhard Killesreiter wrote:
On Mon, 2 May 2005, Robert Douglass wrote:
Why don't we get rid of primary and secondary links altogether?
We could replace them with custom menus from the menu module and position them using the new block region code. We could then write menu theme functions that render any menu in a suitable way for different kinds of links (tabbed, dhtml, etc). The best code for generating hyperlinks is in the menu module - that's the base we should be resting on.
I second this request. I am using some hack to achieve this for over a year now and don't want to miss it.
This has been discussed at length, and if I remembered correctly, JonBob outlined the required menu system changes in a post (whose URL I can't find). This can be worked on independently from the phptemplate engine. I don't think anyone is working on this. -- Dries Buytaert :: http://www.buytaert.net/
On Mon, 2 May 2005, Dries Buytaert wrote:
On 02 May 2005, at 08:32, Gerhard Killesreiter wrote:
On Mon, 2 May 2005, Robert Douglass wrote:
Why don't we get rid of primary and secondary links altogether?
We could replace them with custom menus from the menu module and position them using the new block region code. We could then write menu theme functions that render any menu in a suitable way for different kinds of links (tabbed, dhtml, etc). The best code for generating hyperlinks is in the menu module - that's the base we should be resting on.
I second this request. I am using some hack to achieve this for over a year now and don't want to miss it.
This has been discussed at length, and if I remembered correctly, JonBob outlined the required menu system changes in a post (whose URL I can't find).
I might be missing something, but I didn't make any changes to the menu system. The only thing I changed was the way the theme puts out the primary links block I use as top navigation. $primary_links = theme('menu_tree', some number); Then Bèr made me some nice CSS to render the ul vertically.
This can be worked on independently from the phptemplate engine.
True, but that would mean double work and some would go to waste, wouldn't it?
I don't think anyone is working on this.
Bèr has been, I think. Before we hadn't the possibility to have more than two block regions it didn't make sense to work on it. What we need is a design decision: Do we want to leave primary /secondary links as something that is implemented by the theme engine or by the menu system? In my scenario, all that would be in the theme's configuration is a selector of which menu blocks to chose for primary and secondary links and a link to the menu admin screen to add or expand those blocks. Cheers, Gerhard
I second this request. I am using some hack to achieve this for over a year now and don't want to miss it.
This has been discussed at length, and if I remembered correctly, JonBob outlined the required menu system changes in a post (whose URL I can't find).
I might be missing something, but I didn't make any changes to the menu system. The only thing I changed was the way the theme puts out the primary links block I use as top navigation.
(Gerhard: where did I say you made changes to the menu system?) I'd like to get JonBob's input on this. After all, he is the official maintainer of the menu system (see MAINTAINERs.txt). If JonBob thinks we should integrate Ber's module into menu.inc/menu.module, than I'm OK with it. Ideally, such a patch would be "JonBob Approved" or would come directly from him. Drupal's callback mechanism (_menu() hook) is killer, but the menu and link administration (GUI-part) has been a sore points for long enough now. It is time for the menu system to evolve a bit. JonBob? -- Dries Buytaert :: http://www.buytaert.net/
On Mon, 2 May 2005, Dries Buytaert wrote:
I second this request. I am using some hack to achieve this for over a year now and don't want to miss it.
This has been discussed at length, and if I remembered correctly, JonBob outlined the required menu system changes in a post (whose URL I can't find).
I might be missing something, but I didn't make any changes to the menu system. The only thing I changed was the way the theme puts out the primary links block I use as top navigation.
(Gerhard: where did I say you made changes to the menu system?)
Maybe this was the part I was missing. :)
JonBob outlined the required menu system changes in a post
I inferred from this quote that changes to the menu system would be neccesary in your or JonBob's opinion.
I'd like to get JonBob's input on this. After all, he is the official maintainer of the menu system (see MAINTAINERs.txt). If JonBob thinks we should integrate Ber's module into menu.inc/menu.module, than I'm OK with it. Ideally, such a patch would be "JonBob Approved" or would come directly from him.
I agree.
Drupal's callback mechanism (_menu() hook) is killer, but the menu and link administration (GUI-part) has been a sore points for long enough now.
True. I think it would be nice to not only have the complete menu on one page, but also to have an extra screen per menu. Maybe we could make it similar to the new taxonomy admin screen. Both screens would be ideal candidates for some Ajax integration, I think. Items could be moved up or down and at the end, the whole thing is saved.
It is time for the menu system to evolve a bit.
JonBob?
He is most likely afk today. Today is a holiday in the US. They have the nice habit to move holidays that happen to be on a Sunday to the following Monday. Cheers, Gerhard
Gerhard Killesreiter wrote:
He is most likely afk today. Today is a holiday in the US. They have the nice habit to move holidays that happen to be on a Sunday to the following Monday.
It is? Nobody told me or my employer. :-/ If you're referring to May Day, it's not widely observed as a work holiday in the US. -Eric
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 02 May 2005, at 9:09 AM, Gerhard Killesreiter wrote:
Then Bèr made me some nice CSS to render the ul vertically.
Yeah. That was step 2 of my post.
What we need is a design decision: Do we want to leave primary /secondary links as something that is implemented by the theme engine or by the menu system? The plan is to move it to the menu system.
But I don't believe this should hold up getting phptemplate in core first.
In my scenario, all that would be in the theme's configuration is a selector of which menu blocks to chose for primary and secondary links and a link to the menu admin screen to add or expand those blocks.
Which is exactly what I said =) - -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) iD8DBQFCdhF1gegMqdGlkasRAsBWAKCmbiIcrqbjoFr37zNDLR9Ebcv2fgCgwUqu 5PqoT6W0ZyuxJTpTQgaRI3E= =PAkx -----END PGP SIGNATURE-----
On Monday 02 May 2005 02:18 am, Robert Douglass wrote:
Why don't we get rid of primary and secondary links altogether?
We could replace them with custom menus from the menu module and position them using the new block region code.
I agree. And it becomes even easier when the menu GUI is integrated with the node creation form, http://drupal.org/node/9178 http://asitis.org/images/motf/motf-add-item.png Matt (aka mathias on drupal.org)
On 02 May 2005, at 17:50, Matt Westgate wrote:
On Monday 02 May 2005 02:18 am, Robert Douglass wrote:
Why don't we get rid of primary and secondary links altogether?
We could replace them with custom menus from the menu module and position them using the new block region code.
I agree. And it becomes even easier when the menu GUI is integrated with the node creation form,
Yep, but for that we need collapsible page regions so we can rework the submission form. -- Dries Buytaert :: http://www.buytaert.net/
On Monday 02 May 2005 01:04 pm, Dries Buytaert wrote:
On 02 May 2005, at 17:50, Matt Westgate wrote:
On Monday 02 May 2005 02:18 am, Robert Douglass wrote:
Why don't we get rid of primary and secondary links altogether?
We could replace them with custom menus from the menu module and position them using the new block region code.
I agree. And it becomes even easier when the menu GUI is integrated with the node creation form,
Yep, but for that we need collapsible page regions so we can rework the submission form.
Right. The menu on-the-fly module (which is where the above screenshot is coming from) uses the collapsible form groups patch [1], and so far no usability issues have been reported. It's been released since 4.5.2. [1] http://drupal.org/node/16204 Matt
Will this MOTF module allow adding links to non node pages. For example, I want the menu to have "Home | Search | Sitemap | Contact" Home is a link to the home page, the other 3 are basically module generated pages, and one cannot use MOTF for it. Please keep this in mind for the new theme system, so people can add anything, not just nodes to the menus.
Yep, but for that we need collapsible page regions so we can rework the submission form.
Right. The menu on-the-fly module (which is where the above screenshot is coming from) uses the collapsible form groups patch [1], and so far no usability issues have been reported. It's been released since 4.5.2.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 You could add them through the menu admin. It would basically be a second block, that you can set as your primary/secondary links. On 02 May 2005, at 8:29 PM, K B wrote:
Will this MOTF module allow adding links to non node pages. For example, I want the menu to have "Home | Search | Sitemap | Contact"
Home is a link to the home page, the other 3 are basically module generated pages, and one cannot use MOTF for it.
Please keep this in mind for the new theme system, so people can add anything, not just nodes to the menus.
Yep, but for that we need collapsible page regions so we can rework the submission form.
Right. The menu on-the-fly module (which is where the above screenshot is coming from) uses the collapsible form groups patch [1], and so far no usability issues have been reported. It's been released since 4.5.2.
- -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) iD8DBQFCdnTOgegMqdGlkasRAvjtAJ9Td2Oo/NhM/pKqPPnTFDoHOUvxKwCfZfDF 94Vb+rJun+BerV5osoewscI= =63rY -----END PGP SIGNATURE-----
On Monday 02 May 2005 01:29 pm, K B wrote:
Will this MOTF module allow adding links to non node pages. For example, I want the menu to have "Home | Search | Sitemap | Contact"
Home is a link to the home page, the other 3 are basically module generated pages, and one cannot use MOTF for it.
Please keep this in mind for the new theme system, so people can add anything, not just nodes to the menus.
Yep. I wasn't dealing with external URLs or module paths at the moment. I was just following up on Robert's statement that primary and secondary links should be integrated into Drupal's menu system (which can handle external URLs and module paths), and if we went that route, part of the way to make the menu system more accessible is by integrating it into the node creation form. The menu_otf module is a proof of concept for functionality I'd like to see the Drupal core have. Matt
Op maandag 02 mei 2005 21:11, schreef Matt Westgate:
The menu_otf module is a proof of concept for functionality I'd like to see the Drupal core have.
The MOTF is nice, but has very litle to do with primary links. The primary links management 5or tab management or whatever it will be named° will allow us to /a/ or /the/ menu UI to administer those links. MOTF is just a way to add nodes to that menu. Regards, Bèr -- [ Bèr Kessels | Drupal services www.webschuur.com ]
Op maandag 02 mei 2005 09:18, schreef Robert Douglass:
Why don't we get rid of primary and secondary links altogether?
We could replace them with custom menus from the menu module and position them using the new block region code. We could then write menu theme functions that render any menu in a suitable way for different kinds of links (tabbed, dhtml, etc). The best code for generating hyperlinks is in the menu module - that's the base we should be resting on.
This is exactly what my proposed changes do. Please try primary_links.module. (http://cvs.drupal.org/viewcvs/drupal/contributions/modules/primary_links/) Regards, Bèr -- [ Bèr Kessels | Drupal services www.webschuur.com ]
On 2-May-05, at 3:18 AM, Robert Douglass wrote:
Why don't we get rid of primary and secondary links altogether?
We could replace them with custom menus from the menu module and position them using the new block region code. We could then write menu theme functions that render any menu in a suitable way for different kinds of links (tabbed, dhtml, etc). The best code for generating hyperlinks is in the menu module - that's the base we should be resting on.
+1 -- James Walker :: http://www.walkah.net/
The (PHPTemplate-based) theme that I would like to see in core more than any other is FriendsElectric.
FriendsElectric is a good candidate indeed. Let's see what Steven has to say about this.
The only big issue with this is that FriendsElectric does not render pages with wide tables correctly. This is because of the tableless layout. There is also a problem when the left sidebar is longer than the rest. I've been unable to come up with a good solution for this, as something in the theme triggers a weird Mozilla fieldset stretching bug when I try the conventional way to fix it. Typically, overflow: auto; is used to make scrollbars appear on wide content, but this doesn't really work for big tables like we have in Drupal. Really, tableless CSS simply does not mesh with a complicated system like Drupal. Sure, it's doable for a limited site with a limited amount of options. But as a generic theme for a CMS? I have my doubts. It is trendy, and a very viable option for blogs and other simple sites, but the fact that 99% of all tableless designs can't even handle clears inside them says enough about the robustness of the whole thing. The world would be a much better place without IE: then you could actually use the table-layout model through CSS. Every other browser that matters supports it as far as I know. Finally: if FriendsElectric goes into core, who will maintain it? Putting the theme into core gives it a much higher exposure, but are any of you willing to handle the CSS that tableless layout requires? Or will it just mean more support requests to handle? Steven Wittens
FriendsElectric has quite a few bugs, true - but IMO, none of them are so critical that they make it an unusable theme. Even with its table rendering problems and its sometimes-weird sidebars, it's still one of the nicest Drupal themes, as well as the only theme with a tableless layout that is a candidate for inclusion in core. And it's native to PHPTemplate. Someone pointed out that tableless layouts do actually validate as XHTML. This is true, but is no excuse for using such layouts when you don't have to. We all know that they're bad for accessibility (screen readers), portability (browsers in phones), etc. There are a lot of sites out there that are using Drupal in its simplest form: as a pure blogging tool. FriendsElectric might not be the best theme for sites that are 'pushing the limits' of Drupal (e.g. E-Commerce platform, media hub), but I think that Drupal bloggers would benefit greatly from having it as a theme in core. As for maintenance... well, I can see how that alone would stop FriendsElectric from going into core. Jaza. On 5/3/05, Steven Wittens <steven@acko.net> wrote:
The only big issue with this is that FriendsElectric does not render pages with wide tables correctly. This is because of the tableless layout. There is also a problem when the left sidebar is longer than the rest. I've been unable to come up with a good solution for this, as something in the theme triggers a weird Mozilla fieldset stretching bug when I try the conventional way to fix it.
Typically, overflow: auto; is used to make scrollbars appear on wide content, but this doesn't really work for big tables like we have in Drupal.
Really, tableless CSS simply does not mesh with a complicated system like Drupal. Sure, it's doable for a limited site with a limited amount of options. But as a generic theme for a CMS? I have my doubts. It is trendy, and a very viable option for blogs and other simple sites, but the fact that 99% of all tableless designs can't even handle clears inside them says enough about the robustness of the whole thing.
The world would be a much better place without IE: then you could actually use the table-layout model through CSS. Every other browser that matters supports it as far as I know.
Finally: if FriendsElectric goes into core, who will maintain it? Putting the theme into core gives it a much higher exposure, but are any of you willing to handle the CSS that tableless layout requires? Or will it just mean more support requests to handle?
Steven Wittens
Jeremy Epstein said: [...]
Someone pointed out that tableless layouts do actually validate as XHTML. This is true, but is no excuse for using such layouts when you don't have to. We all know that they're bad for accessibility (screen readers), portability (browsers in phones), etc.
I'm not sure who the "we" in the above sentence is, but that's certainly not been my experience. It's much easier to make @media handheld or voice stylesheets when you're not using TABLE tags, but semantically-correct tags. So, not only are tableless layouts good for accessibility, but they reduce page load time and page size. The only reason *not* to use them, AFAIAC, is because of buggy or missing CSS support among browsers. -- Tim Altman
While I _do_ have too agree that FriendsElectric is indeed a very, very good theme I don't think it is very easy to customize. There is a lot of PHP-code inside the template.php file which is there to insert more divs using regular expressions. But I think it'll reflect what is currently possible using drupals theming engine and themes.. So, afterall I would like to +1 for having FriendsElectric in core.. And i would like to rid of all the other themes... :-) Stefan. Op 2-mei-2005, om 3:29 heeft Jeremy Epstein het volgende geschreven:
The (PHPTemplate-based) theme that I would like to see in core more than any other is FriendsElectric.
This is the only Drupal theme, that I know of, that uses a tableless CSS layout, and that fully validates as XHTML. All of the themes currently in core use a table-based layout, and I don't think that this helps at all, if we're trying to give Drupal an image of being a modern and standards-compliant web platform.
FriendsElectric also looks really good - better than most of the current core themes, IMO. It does use a 'bazillion' of small images to do this, but they're all part of the CSS, rather than the XHTML, so this is not a huge problem.
Jaza.
On 5/2/05, Dries Buytaert <dries@buytaert.net> wrote:
- What PHPTemplate-based theme should we ship with core? Should we port either Bluemarine or Pushbutton to PHPTemplate or should we go with fresh themes? My requirements for such theme would be: 1. The theme must validate as XHTML. 2. The theme's CSS classes/IDs must comply Drupal's naming conventions. 3. The theme should work on all browsers without hacks. 4. The theme should be simple and easy to customize. No themes with a bazillion of small images that no one will ever change.
-- Dries Buytaert :: http://www.buytaert.net/
--- Stefan Nagtegaal http://www.istyledthis.nl/
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 02 May 2005, at 10:54 AM, Stefan Nagtegaal wrote:
So, afterall I would like to +1 for having FriendsElectric in core.. And i would like to rid of all the other themes... :-) Bluemarine needs to be laid to rest =)
I for one have seen enough bluemarine based sites to last a lifetime. =P - -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) iD8DBQFCdhHhgegMqdGlkasRAi+fAKCovUvsgpJIhUv/UaRSzlg/PkvTEACg3A+2 LRjPWKp2oN/7yIOz3BRAO+Q= =MmEK -----END PGP SIGNATURE-----
On 2-May-05, at 4:41 AM, Adrian Rossouw wrote:
On 02 May 2005, at 10:54 AM, Stefan Nagtegaal wrote:
So, afterall I would like to +1 for having FriendsElectric in core.. And i would like to rid of all the other themes... :-) Bluemarine needs to be laid to rest =)
Except for many designers that I have talked to that use Bluemarine as their "base", since it has the cleanest code and most complete theming of all elements (the PHPTemplate version). I would rather see a different *default* theme, but still keep a PHPTemplate version of Bluemarine in. So...how about a theme competition? Or do we want to use something existing? -- Boris Mann http://www.bryght.com Vancouver 778-896-2747 / San Francisco 415-367-3595 SKYPE borismann
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
So...how about a theme competition? Or do we want to use something existing?
EXCELLENT suggestion. I think the time is finally ripe for this =) - -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) iD8DBQFCdlTugegMqdGlkasRAkmrAKCxYl0un7NRHs5R/9mu3KtgNW7VbwCfUP+P Ztx/gPMObLDrF3jTgKpv4tk= =6MJ4 -----END PGP SIGNATURE-----
Op maandag 02 mei 2005 18:27, schreef Adrian Rossouw:
So...how about a theme competition? Or do we want to use something existing?
EXCELLENT suggestion.
I think the time is finally ripe for this =)
While i was in the computer store this afternoon ( yes, i still shop analogue) I had a look at possible prices for such a contest. Great minds think alike, they say ;). I think we could come up with some nice things like a wacom tablet, ipod or so. I think we need to get some donations special for this contest though. I believe that once this contest gets going we might actually get a lot of attention from designers. And that means a lot of exposure in designer forums, blogospheres and channels. Which is all we really need. Regards, Bèr -- [ Bèr Kessels | Drupal services www.webschuur.com ]
On 1 May 2005, at 16:49, Dries Buytaert wrote:
- What PHPTemplate-based theme should we ship with core? Should we port either Bluemarine or Pushbutton to PHPTemplate or should we go with fresh themes? My requirements for such theme would be: 1. The theme must validate as XHTML. 2. The theme's CSS classes/IDs must comply Drupal's naming conventions. 3. The theme should work on all browsers without hacks. 4. The theme should be simple and easy to customize. No themes with a bazillion of small images that no one will ever change.
I would add to that: 5. The theme must be accessible - at minimum Section 508 and WCAG Priority 1 compliant. Pushbutton has already been ported to PHPTemplate, and meets all of the above requirements. Note: Tables are perfectly valid XHTML, using them for page structure is discouraged - but won't invalidate a page. There are a lot of Drupal sites which have based their custom themes on Pushbutton, including it in core will give them a good starting point to transition to PHPTemplate. Best regards, Robert Castelo [MegaGrunt]
Hi! a) bluemarine should stay. It has a phptemplate version, nice and good. b) pushbutton is very popular, also has a phptemplate version, so it could stay, too. c) chameleon as a .theme example is also a good thing. d) Let Drupal be the leader -- let's include a nice, non-IE compliant theme. There are community sites already which only display a splash screen with a message and a link to firefox if you visit them with IE. Regards NK
I especially like this idea! The only problem would be if IE7 comes along and actually *works*. Karoly Negyesi wrote:
Hi!
a) bluemarine should stay. It has a phptemplate version, nice and good. b) pushbutton is very popular, also has a phptemplate version, so it could stay, too. c) chameleon as a .theme example is also a good thing. d) Let Drupal be the leader -- let's include a nice, non-IE compliant theme. There are community sites already which only display a splash screen with a message and a link to firefox if you visit them with IE.
Regards
NK
Karoly Negyesi wrote:
d) Let Drupal be the leader -- let's include a nice, non-IE compliant theme. There are community sites already which only display a splash screen with a message and a link to firefox if you visit them with IE.
I understand that sentiment (and I use Firefox almost all of the time), but I think sites that do this will lose a lot of their potential visitors. -Eric
d) Let Drupal be the leader -- let's include a nice, non-IE compliant theme. There are community sites already which only display a splash screen with a message and a link to firefox if you visit them with IE.
Drupal is a content management system, not a design engine or a client controller. Let's focus on the content, eh? First rule of content? Make it usable by everyone. -- Morbus Iff ( you are nothing without your robot car, NOTHING! ) Culture: http://www.disobey.com/ and http://www.gamegrene.com/ Spidering Hacks: http://amazon.com/exec/obidos/ASIN/0596005776/disobeycom icq: 2927491 / aim: akaMorbus / yahoo: morbus_iff / jabber.org: morbus
+1. We're not in the business of dictating which browsers people must use to access content. The browser market is going to continue to be volatile for some time and the best we can do is design for the standards that exist and support whatever is in the best interest of our audiences, which of course vary per site. IE7 will certainly have an impact on web development -- though I'm not sure it will be for the best. In any case, let's not daddle over which browsers to support in core; we need something that works out of the box; we can define what that means later. The truth of the matter is Drupal is severely showing its age post-install and this needs to change if we're going to continue to grow Drupal's following. Appearance, flexibility and experience are ways to approach this issue.Getting PHPTemplate (or whatever we call it...) into core will be a step in the right direction. Getting a theme *like* FriendsElectric into core as the new default theme is another good step. Next steps: let's talk about what needs to be done for each of these steps to happen and who can do what to get it done. I'm working on themes and UI issues... specifically, SpreadFirefox, Democratica and Lincoln's Revenge are all being rewritten, hopefully to deal with the issues that Steven raised. Additionally, I'm going to try to standardize classes and IDs as much as possible -- per Dries' request. I could certainly use some help with that -- and I think we'd be better off discussing those issues now that it seems that we have some consensus that these things need to happen! Chris On 5/2/05, Morbus Iff <morbus@disobey.com> wrote:
d) Let Drupal be the leader -- let's include a nice, non-IE compliant theme. There are community sites already which only display a splash screen with a message and a link to firefox if you visit them with IE.
Drupal is a content management system, not a design engine or a client controller. Let's focus on the content, eh? First rule of content? Make it usable by everyone.
-- Morbus Iff ( you are nothing without your robot car, NOTHING! ) Culture: http://www.disobey.com/ and http://www.gamegrene.com/ Spidering Hacks: http://amazon.com/exec/obidos/ASIN/0596005776/disobeycom icq: 2927491 / aim: akaMorbus / yahoo: morbus_iff / jabber.org: morbus
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Here's the phptemplate patch. http://drupal.org/node/21855 - -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) iD8DBQFCdpzqgegMqdGlkasRAtUXAJ4zjR/WGJL3uRLrre6YqpWLAdjWlgCgw4fj qDOHVSzlbeXQwXhzWLWAEBc= =jri3 -----END PGP SIGNATURE-----
Op maandag 02 mei 2005 21:45, schreef Karoly Negyesi:
d) Let Drupal be the leader -- let's include a nice, non-IE compliant theme. There are community sites already which only display a splash screen with a message and a link to firefox if you visit them with IE.
hmmm; i very much dislike this idea. a Firefox only theme, using XULwould make more sense, for intranets and such. But forcing people to make your choise is always a bad choice. Isn't Gnu about freedom. and isn' t freedom about choices? Regards, Bèr -- [ Bèr Kessels | Drupal services www.webschuur.com ]
participants (21)
-
Adrian Rossouw -
Boris Mann -
Bèr Kessels -
Chris Messina -
Dries Buytaert -
Eric Scouten -
Gabor Hojtsy -
Gerhard Killesreiter -
Gordon Heydon -
James Walker -
Jeremy Epstein -
K B -
Karoly Negyesi -
Matt Westgate -
Morbus Iff -
Robert Castelo -
Robert Douglass -
Stefan Nagtegaal -
Steven Wittens -
Tim Altman -
Tom Dobes