Administration Survey: Theme improvements, theme help system, theme mailing list
As part of the Drupal administration user experience survey we identified Drupal theme issues as the most difficult administration issues( http://www.surveymonkey.com/DisplaySummary.asp? SID=1425065&U=142506581557). There was some confusion about the results so Trae McCombs, from CivicSpace Labs, conducted six additional theme development interviews. Trae identified some common goals of theme developers, basic theme tasks, and difficult theme tasks. I have created a documentation page, http://drupal.org/node/39451, which outlines all this. I also spoke with Dries yesterday and requested that a theme developers mailing list be started to focus on helping with Drupal's most difficult administration task. In summary here are the actions we are taking to improve administration specifically focused on Drupale theme development. 1) Identified Drupal theming as the most difficult Drupal administration task. 2) Improved the project module to allow for categorization so that themes can be categorized to help themers pick a solid base theme. Designed by Dries and implemented by Nedjo Rogers for CivicSpace Labs. This is coming in the next few weeks on Drupal.org. 3) Provided a "Manage inconsistency in themes" documentation page with best practices. http://drupal.org/node/37156 4) Created a support channel #cstheme to support development of the CivicSpace theme. This may lead to a dedicated Drupal theme channel. 5) Added a link to theme help from the theme admin interface using the CivicSpace theme. Added several base layouts to the CS theme for theme developers to customize with styles. 6) Created a theme help documentation page to focus on basic and difficult theme tasks. http://drupal.org/node/39451 7) Requested a themers mailing list to focus specifically on the tasks of Drupal theme development Please help us to develop theme help documentation(http://drupal.org/ node/39451). Understanding basic and difficult theme tasks, and how to solve them, will allow us to attract more themers to the platform and make it easier for all of us to theme our sites. I'll leave you with a quote: Dries_:it's the reason I didn't convert buytaert.net yet -- it takes too f*****g long to make a theme Cheers, Kieran Development Manager CivicSpace Labs
On Wed, 30 Nov 2005 12:10:46 -0800, Kieran Lal <kieran@civicspacelabs.org> wrote:
As part of the Drupal administration user experience survey we identified Drupal theme issues as the most difficult administration issues( http://www.surveymonkey.com/DisplaySummary.asp? SID=1425065&U=142506581557). There was some confusion about the results so Trae McCombs, from CivicSpace Labs, conducted six additional theme development interviews.
Trae identified some common goals of theme developers, basic theme tasks, and difficult theme tasks. I have created a documentation page, http://drupal.org/node/39451, which outlines all this. I also spoke with Dries yesterday and requested that a theme developers mailing list be started to focus on helping with Drupal's most difficult administration task.
In summary here are the actions we are taking to improve administration specifically focused on Drupale theme development. 1) Identified Drupal theming as the most difficult Drupal administration task. Agreed, but IMO we can fix this by making it at least consistent, so it's easier to use.
2) Improved the project module to allow for categorization so that themes can be categorized to help themers pick a solid base theme. Designed by Dries and implemented by Nedjo Rogers for CivicSpace Labs. This is coming in the next few weeks on Drupal.org. Would be a great improvement.
3) Provided a "Manage inconsistency in themes" documentation page with best practices. http://drupal.org/node/37156 Indeed..
4) Created a support channel #cstheme to support development of the CivicSpace theme. This may lead to a dedicated Drupal theme channel. I vote for using drupal-theme, which is consistent with drupal-support.
[...]
7) Requested a themers mailing list to focus specifically on the tasks of Drupal theme development I will be definatly a members of that!
Please help us to develop theme help documentation(http://drupal.org/ node/39451). Understanding basic and difficult theme tasks, and how to solve them, will allow us to attract more themers to the platform and make it easier for all of us to theme our sites. I will, trust me... I will...
I'll leave you with a quote: Dries_:it's the reason I didn't convert buytaert.net yet -- it takes too f*****g long to make a theme Dries, If you need a fancy theme for free, you can contact me..
Don't forget we need to finally get the drupal theme functions to be consistent for usage. Some functions return HTML, some don't. It would be nice if we can convert (or make wrappers for these) all functions used inside the themes to drupal_get_*(), like we currently have for drupal_get_title(). It would make life much nicer and easier to use. This would lead to drupal_get_page_title(), drupal_get_page_help(), drupal_get_page_breadcrumbs(), drupal_get_local_tasks(), drupal_get_page_content(), drupal_get_node_title(), drupal_get_node_teaser(), drupal_get_node_body(), drupal_get_node_author(), drupal_get_node_submission_date() drupal_get_node_modified_date(), drupal_get_node_links(), etc, etc... There are several things which I would like to see changed and willing to cooperate with any of you guys to accomplish this goal. I think it would make sense remove all the PHP-logic from themes. Checking if there is output is IMO unacecptable, this should be done in the function which calls the desired theme function. Things like check_plain() should also be removed from the theme functions itself. Also removing most of the divs which are by default in the theme functions would make sense IMO. So it's more consistent from function to function. Stefan
Kieran Lal wrote:
3) Provided a "Manage inconsistency in themes" documentation page with best practices. http://drupal.org/node/37156 A bit off topic - but i'll keep it short May I suggest updating the validation best practice text to say - validate XHTML1.1 Strict. I mean if we urge people to do it right - urge them to really do it right - it really does solve more problems for developers than it causes.
andre
On Thursday 01 December 2005 12:20 am, Andre Molnar wrote:
Kieran Lal wrote:
3) Provided a "Manage inconsistency in themes" documentation page with best practices. http://drupal.org/node/37156
A bit off topic - but i'll keep it short May I suggest updating the validation best practice text to say - validate XHTML1.1 Strict. I mean if we urge people to do it right - urge them to really do it right - it really does solve more problems for developers than it causes.
andre
Except that sending XHTML 1.0 Strict as text/html is valid, but sending XHTML 1.1 Strict as text/html is not right, according to the W3C. Since we can't send things as text/xml+html because IE is a broken ancient piece of popular crap, that means XHTML 1.0 is as up to date as we can support and still be "right". -- Larry Garfield AIM: LOLG42 larry@garfieldtech.com ICQ: 6817012 "If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson
On Thu, 01 Dec 2005 08:17:38 +0100, Larry Garfield <larry@garfieldtech.com> wrote:
On Thursday 01 December 2005 12:20 am, Andre Molnar wrote:
Kieran Lal wrote:
3) Provided a "Manage inconsistency in themes" documentation page with best practices. http://drupal.org/node/37156
A bit off topic - but i'll keep it short May I suggest updating the validation best practice text to say - validate XHTML1.1 Strict. I mean if we urge people to do it right - urge them to really do it right - it really does solve more problems for developers than it causes.
Except that sending XHTML 1.0 Strict as text/html is valid, but sending XHTML 1.1 Strict as text/html is not right, according to the W3C. Since we can't send things as text/xml+html because IE is a broken ancient piece of popular crap, that means XHTML 1.0 is as up to date as we can support and still be "right".
Using XHTML without application/xhtml+xml is pretty pointless. I'd prefer a theme based on HTML 4.01. -- Tim Altman
Except that sending XHTML 1.0 Strict as text/html is valid, but sending XHTML 1.1 Strict as text/html is not right, according to the W3C. Since we can't send things as text/xml+html because IE is a broken ancient piece of popular crap, that means XHTML 1.0 is as up to date as we can support and still be "right".
Using XHTML without application/xhtml+xml is pretty pointless. I'd prefer a theme based on HTML 4.01.
Actually doing all the Drupal core theme functions with XHTML in mind is quite a good idea IMHO. Any theme can do the fancy magic of detecting capable user agents, and send proper Content-type to them. Goba
On Thu, 01 Dec 2005 22:19:56 +0100, Gabor Hojtsy <gabor@hojtsy.hu> wrote:
Except that sending XHTML 1.0 Strict as text/html is valid, but sending XHTML 1.1 Strict as text/html is not right, according to the W3C. Since we can't send things as text/xml+html because IE is a broken ancient piece of popular crap, that means XHTML 1.0 is as up to date as we can support and still be "right".
Using XHTML without application/xhtml+xml is pretty pointless. I'd prefer a theme based on HTML 4.01.
Actually doing all the Drupal core theme functions with XHTML in mind is quite a good idea IMHO. Any theme can do the fancy magic of detecting capable user agents, and send proper Content-type to them.
Certainly. I've been thinking about making a theme that used XHTML 1.0 for UAs supporting application/xhtml+xml and HTML 4.01 for other UAs, but never got around to looking into the implementation details. That would be the best of both worlds, IMHO. -- Tim Altman
Op donderdag 01 december 2005 22:27, schreef Tim Altman:
Certainly. I've been thinking about making a theme that used XHTML 1.0 for UAs supporting application/xhtml+xml and HTML 4.01 for other UAs, but never got around to looking into the implementation details. That would be the best of both worlds, IMHO.
Before we can do any proper X(h)TML theming, or XUL or SVG themes, we first need to unclutter the theme spaghetti. On all sorts of levels in the theme, sometimes even outside of a theme funtion, do we inject HTML. I started a proof of concept for a pure svg theme. It very quickly became a failure of concept. Not possible with the current state of Drupals MVC. 1 we need a clean transparant and consistent theme layer. Not spaghetti, but layers 2 we need to weed out any (mostly in contribs) hardcoded HTML 3 we need to weed out HTML in help texts and strings. 4 we need to make sure that all theme functions receive only structured data and not htmlified strings. (aka that clean layered theme from 1) Or else this remains an uphill battle and will Drupal never be able to output anything else then HTML or XHTML. Ber
0 we need some guidelines for how to write a good theme functions, some examples of well written theme functions, and some examples of badly written ones. Bèr Kessels wrote:
1 we need a clean transparant and consistent theme layer. Not spaghetti, but layers 2 we need to weed out any (mostly in contribs) hardcoded HTML 3 we need to weed out HTML in help texts and strings. 4 we need to make sure that all theme functions receive only structured data and not htmlified strings. (aka that clean layered theme from 1)
-- Neil Drumm http://delocalizedham.com/
I volunteer mine for the bad examples... On 12/2/05, Neil Drumm <drumm@delocalizedham.com> wrote:
0 we need some guidelines for how to write a good theme functions, some examples of well written theme functions, and some examples of badly written ones.
Bèr Kessels wrote:
1 we need a clean transparant and consistent theme layer. Not spaghetti, but layers 2 we need to weed out any (mostly in contribs) hardcoded HTML 3 we need to weed out HTML in help texts and strings. 4 we need to make sure that all theme functions receive only structured data and not htmlified strings. (aka that clean layered theme from 1)
-- Neil Drumm http://delocalizedham.com/
Larry Garfield wrote:
On Thursday 01 December 2005 12:20 am, Andre Molnar wrote:
Kieran Lal wrote:
3) Provided a "Manage inconsistency in themes" documentation page with best practices. http://drupal.org/node/37156
A bit off topic - but i'll keep it short May I suggest updating the validation best practice text to say - validate XHTML1.1 Strict. I mean if we urge people to do it right - urge them to really do it right - it really does solve more problems for developers than it causes.
Except that sending XHTML 1.0 Strict as text/html is valid, but sending XHTML 1.1 Strict as text/html is not right, according to the W3C. Since we can't send things as text/xml+html because IE is a broken ancient piece of popular crap, that means XHTML 1.0 is as up to date as we can support and still be "right".
How right you are - XHTML 1.0 Strict it is. Notwithstanding the 'potential' problems with sending xhtml as text/html - see: http://www.hixie.ch/advocacy/xhtml (or google for similar documents) - the idea is to encourage the creation of valid markup - and have all markup passed through a validator first (which eliminates the 'real' problems). On that note - it might be a good idea to include links to pages like: http://www.hixie.ch/advocacy/xhtml part of the best practices documentation. andre ___________________________________________________________ To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com
On Dec 1, 2005, at 7:40 AM, andre wrote:
Notwithstanding the 'potential' problems with sending xhtml as text/ html - see: http://www.hixie.ch/advocacy/xhtml (or google for similar documents) - the idea is to encourage the creation of valid markup - and have all markup passed through a validator first (which eliminates the 'real' problems).
On that note - it might be a good idea to include links to pages like: http://www.hixie.ch/advocacy/xhtml part of the best practices documentation.
Can we resolve these issues and make solid recommendations I can include in the documentation? thanks, Kieran
Kieran Lal wrote:
On Dec 1, 2005, at 7:40 AM, andre wrote:
Notwithstanding the 'potential' problems with sending xhtml as text/html - see: http://www.hixie.ch/advocacy/xhtml (or google for similar documents) - the idea is to encourage the creation of valid markup - and have all markup passed through a validator first (which eliminates the 'real' problems).
On that note - it might be a good idea to include links to pages like: http://www.hixie.ch/advocacy/xhtml part of the best practices documentation.
Can we resolve these issues and make solid recommendations I can include in the documentation?
IMHO the solid recommendation is - Make sure to include a doc type declaration in your theme. VALIDATE no matter what - both your (x)html and your css. Which standard the developer uses to validate is up to the developer - BUT - best practice suggestion is to validate XHTML 1.0 Strict. Include links to http://www.w3.org/QA/Tools/#validators and optionally information about XHTML so theme developers can make an informed decision when choosing their doc type. andre
On Dec 1, 2005, at 8:05 AM, Andre Molnar wrote:
Kieran Lal wrote:
On Dec 1, 2005, at 7:40 AM, andre wrote:
Notwithstanding the 'potential' problems with sending xhtml as text/html - see: http://www.hixie.ch/advocacy/xhtml (or google for similar documents) - the idea is to encourage the creation of valid markup - and have all markup passed through a validator first (which eliminates the 'real' problems).
On that note - it might be a good idea to include links to pages like: http://www.hixie.ch/advocacy/xhtml part of the best practices documentation.
Can we resolve these issues and make solid recommendations I can include in the documentation?
IMHO the solid recommendation is -
Make sure to include a doc type declaration in your theme.
Can you give a basic explanation of doc types, with appropriate link, and where this is defined in the theme?
VALIDATE no matter what - both your (x)html and your css.
Which standard the developer uses to validate is up to the developer - BUT - best practice suggestion is to validate XHTML 1.0 Strict.
I update the title to indicate XHTML 1.0 Strict.
Include links to http://www.w3.org/QA/Tools/#validators and optionally information about XHTML so theme developers can make an informed decision when choosing their doc type.
I have these two. I think that is enough. What do you think? # Before you start modifying your CSS to fix your bugs it is important to ensure you are styling valid HTML or XHTML. There is a web validator is built into the Firefox Web Developer toolbar. # A more advanced tool for analyzing HTML pages for looking over code, spotting errors is the Watchfire WebXACT tool. Thanks for all your help. Kieran
andre
On Thu, 01 Dec 2005 17:44:52 +0100, Kieran Lal <kieran@civicspacelabs.org> wrote:
On Dec 1, 2005, at 8:05 AM, Andre Molnar wrote:
Kieran Lal wrote:
On Dec 1, 2005, at 7:40 AM, andre wrote:
Notwithstanding the 'potential' problems with sending xhtml as text/html - see: http://www.hixie.ch/advocacy/xhtml (or google for similar documents) - the idea is to encourage the creation of valid markup - and have all markup passed through a validator first (which eliminates the 'real' problems).
On that note - it might be a good idea to include links to pages like: http://www.hixie.ch/advocacy/xhtml part of the best practices documentation.
Can we resolve these issues and make solid recommendations I can include in the documentation?
IMHO the solid recommendation is -
Make sure to include a doc type declaration in your theme.
Can you give a basic explanation of doc types, with appropriate link, and where this is defined in the theme?
http://www.htmlhelp.org/tools/validator/doctype.html and http://www.w3.org/QA/2002/04/valid-dtd-list.html should help. [...]
Include links to http://www.w3.org/QA/Tools/#validators and optionally information about XHTML so theme developers can make an informed decision when choosing their doc type.
I have these two. I think that is enough. What do you think? # Before you start modifying your CSS to fix your bugs it is important to ensure you are styling valid HTML or XHTML. There is a web validator is built into the Firefox Web Developer toolbar.
Opera also has validation built in without needing an extension. Just press Ctrl+Alt+V. -- Tim Altman
On Dec 1, 2005, at 9:02 AM, Tim Altman wrote: Added both.
http://www.htmlhelp.org/tools/validator/doctype.html and http:// www.w3.org/QA/2002/04/valid-dtd-list.html should help.
Opera also has validation built in without needing an extension. Just press Ctrl+Alt+V.
Assuming folks do not want to read about doctypes and DTDs what should we recommend as defaults? DocType: application/xhtml+xml I assume. What DTDs ? <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Frameset//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-frameset.dtd"> Anything else? Kieran
On Thu, 01 Dec 2005 18:24:47 +0100, Kieran Lal <kieran@civicspacelabs.org> wrote: [...]
Assuming folks do not want to read about doctypes and DTDs what should we recommend as defaults?
DocType: application/xhtml+xml I assume. What DTDs ?
application/xhtml+xml is a MIME type. We should recommend the use of text/html (even with XHTML).
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Frameset//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-frameset.dtd">
Anything else?
For HTML: <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"> <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN" "http://www.w3.org/TR/html4/frameset.dtd"> One other interesting piece of information may be doctype switching. I don't know any good documents about it off the top of my head, though. -- Tim Altman
I would stick with the XHTML 1.0 strict as mentioned, with text/html. See www.stopdesign.com ... one of the top CSS guys in the world, he's doing it right :-) It follows what the W3 is saying too, although the xml decleration at the top could be buggy too. Yeah it's just a mess, make that note somewhere ;-)
On Thu, 1 Dec 2005 12:47:36 -0500, Theodore Serbinski <tss24@cornell.edu> wrote:
I would stick with the XHTML 1.0 strict as mentioned, with text/html. See www.stopdesign.com ... one of the top CSS guys in the world, he's doing it right :-) Indeed that guy is doing it right!
But something I feel pretty ancient about is why we would stick to XHTML 1.0 Strict when drupal isn't even XHTML 1.0 Strict... I would like to elobarate on this if you guys have the same feeling. Steef
Kieran Lal wrote:
Can you give a basic explanation of doc types, with appropriate link, and where this is defined in the theme?
Document Type Declarations (aka doctypes or DTDs) tell user agents what version of (x)HTML your document is written in. This is a pretty good start: "Fix Your Site With the Right DOCTYPE!" http://www.alistapart.com/stories/doctype/ Further Reading: http://www.w3.org/TR/REC-html40/struct/global.html#h-7.2 http://www.w3.org/TR/xhtml1/#docconf andre
On Thursday 01 December 2005 09:40 am, andre wrote:
On that note - it might be a good idea to include links to pages like: http://www.hixie.ch/advocacy/xhtml part of the best practices documentation.
andre
I don't know why people insist on passing that page around, since it's spreading FUD. - The scenario right up at the top applies only to dumb developers, because it does not include validation. If you're not validating your code against your specified doctype, then you're doing it wrong in the first place. - <script> and <style> with funky comments to hide from old browsers: I don't recall the last time I saw someone actually use the comments, now that Netscape 3 is no longer used. And if you're putting Javascript or CSS directly into the page in the first place rather than linking to it, then you're doing it wrong in the first place. - CSS stylesheet differences: Of course it's case-sensitive, XML is case sensitive. Duh. - DOM scripts work differently: This is the only one with any validity, but again being careful in what you write takes care of most of it. You'll need to rewrite the Javascript anyway whenever you do actually upgrade to XHTML, so you may as well get a jump on it. - document.write() breaks in XHTML: document.write() belongs in the same place as the <font> tag. Even if you're just writing for HTML, you should be using DOM methods. - Some UAs get confused: I have never once seen a UA that when given valid XHTML sent as text/html 'show[s] ">" characters all over the page.' So it's not XHTML that is considered harmful, it's people assuming that throwing a few />'s into their code makes it XHTML. Read: XHTML doesn't break browsers, web developers break bad browsers. :-) Don't blame XHTML for the fact that most web developers are morons and most web surfers use the POS that is IE. Let's leave the old FUD links out of the handbook. -- Larry Garfield AIM: LOLG42 larry@garfieldtech.com ICQ: 6817012 "If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson
On Fri, 02 Dec 2005 02:02:04 +0100, Larry Garfield <larry@garfieldtech.com> wrote:
On Thursday 01 December 2005 09:40 am, andre wrote:
On that note - it might be a good idea to include links to pages like: http://www.hixie.ch/advocacy/xhtml part of the best practices documentation.
I don't know why people insist on passing that page around, since it's spreading FUD.
It is informative and accurate, and quite useful when used in context: if developers are considering the use of Drupal with the application/xhtml+xml MIME type. Most things can be considered FUD when used out of context.
- The scenario right up at the top applies only to dumb developers, because it does not include validation. If you're not validating your code against your specified doctype, then you're doing it wrong in the first place.
Validating your own code isn't the only issue: http://diveintomark.org/archives/2004/01/14/thought_experiment. Drupal.org doesn't validate, FWIW.
- <script> and <style> with funky comments to hide from old browsers: I don't recall the last time I saw someone actually use the comments, now that Netscape 3 is no longer used.
9 out of the top 10 sites on the Web[1] have comments at the beginning of SCRIPT tags. There is a caveat about this point, too. [...]
So it's not XHTML that is considered harmful,
No, sending XHTML as text/html is. What benefits does sending XHTML as text/html have over semantic HTML 4.01? [...]
Read: XHTML doesn't break browsers, web developers break bad browsers. :-)
This sentence doesn't make sense. Neither XHTML nor Web developers can break browsers unless they trigger a bug. XHTML sent as application/xhtml+xml breaks the Web: http://annevankesteren.nl/2005/11/draconian. What benefit is there to Drupal developers and implementors in using HTML 4.01 vs. sending XHTML as text/html vs. sending XHTML as application/xhtml? That's the kind of question the handbook should answer. The suggested page provides such information. [1] http://www.alexa.com/site/ds/top_500 -- Tim Altman
We might want to move this thread to themes@drupal.org Trae PS. in case you missed it, we have a #drupal-themes channel now too. Tim Altman wrote:
On Fri, 02 Dec 2005 02:02:04 +0100, Larry Garfield <larry@garfieldtech.com> wrote:
On Thursday 01 December 2005 09:40 am, andre wrote:
On that note - it might be a good idea to include links to pages like: http://www.hixie.ch/advocacy/xhtml part of the best practices documentation.
I don't know why people insist on passing that page around, since it's spreading FUD.
It is informative and accurate, and quite useful when used in context: if developers are considering the use of Drupal with the application/xhtml+xml MIME type. Most things can be considered FUD when used out of context.
- The scenario right up at the top applies only to dumb developers, because it does not include validation. If you're not validating your code against your specified doctype, then you're doing it wrong in the first place.
Validating your own code isn't the only issue: http://diveintomark.org/archives/2004/01/14/thought_experiment. Drupal.org doesn't validate, FWIW.
- <script> and <style> with funky comments to hide from old browsers: I don't recall the last time I saw someone actually use the comments, now that Netscape 3 is no longer used.
9 out of the top 10 sites on the Web[1] have comments at the beginning of SCRIPT tags. There is a caveat about this point, too.
[...]
So it's not XHTML that is considered harmful,
No, sending XHTML as text/html is. What benefits does sending XHTML as text/html have over semantic HTML 4.01?
[...]
Read: XHTML doesn't break browsers, web developers break bad browsers. :-)
This sentence doesn't make sense. Neither XHTML nor Web developers can break browsers unless they trigger a bug. XHTML sent as application/xhtml+xml breaks the Web: http://annevankesteren.nl/2005/11/draconian.
What benefit is there to Drupal developers and implementors in using HTML 4.01 vs. sending XHTML as text/html vs. sending XHTML as application/xhtml? That's the kind of question the handbook should answer. The suggested page provides such information.
-- Trae "occy" McCombs || http://occy.net/ Founder - Themes.org // Linux.com CivicSpaceLabs - http://civicspacelabs.org/
Andre Molnar wrote:
May I suggest updating the validation best practice text to say - validate XHTML1.1 Strict. I mean if we urge people to do it right - urge them to really do it right - it really does solve more problems for developers than it causes.
On the topic of XHTML1.1 Strict, I ran into some problems with getting included CSS and Javascript to work when in Strict mode. I didn't have time to completely resolve it, and dropped back to Transitional to make my site work. I did do some research trying to find the problem and in the process found a good article on why XHTML1.1 Strict may not really be all that great a thing -- or least, what a lot of the potential problems are. So just as a For Your Information on that topic, see this article *and* the follow-up comments: http://www.456bereastreet.com/archive/200501/the_perils_of_using_xhtml_prope... ..chrisxj
Chris Johnson wrote:
I did do some research trying to find the problem and in the process found a good article on why XHTML1.1 Strict may not really be all that great a thing -- or least, what a lot of the potential problems are.
Wow. I did not need to post that. You all are very on top of the problem and the references posted were great. Nothing like working with brilliant people to keep one humble and build great software! :-) ..chrisxj
On 30 Nov 2005, at 21:10, Kieran Lal wrote:
As part of the Drupal administration user experience survey we identified Drupal theme issues as the most difficult administration issues( http://www.surveymonkey.com/DisplaySummary.asp? SID=1425065&U=142506581557). There was some confusion about the results so Trae McCombs, from CivicSpace Labs, conducted six additional theme development interviews.
2) Improved the project module to allow for categorization so that themes can be categorized to help themers pick a solid base theme. Designed by Dries and implemented by Nedjo Rogers for CivicSpace Labs. This is coming in the next few weeks on Drupal.org.
Nedjo setup a demo site, so if you have some time, please help us test and review this functionality. The project module improvements are a high-priority task. Check out the issue tracker of the project module for details, or Nedjo's recent call for help on the mailing list.
4) Created a support channel #cstheme to support development of the CivicSpace theme. This may lead to a dedicated Drupal theme channel.
occy started a #drupal-themes on FreeNode.
7) Requested a themers mailing list to focus specifically on the tasks of Drupal theme development
I created this mailing list.
I'll leave you with a quote: Dries_:it's the reason I didn't convert buytaert.net yet -- it takes too f*****g long to make a theme
Unfortunately, it's the true. Think about it. Drupal's strength is that you can setup and deploy a site in a couple hours ... if you go with one of the few existing themes, that is. I converted buytaert.net's content (including the photo galleries) to Drupal CVS in about two hours. Now it will take me ten times as much time to create a good looking theme. Having to create a Drupal theme really turns me off. Making it easier to create a unique, good-looking theme in a matter of hours is a key challenge for the Drupal community. Glad to see CSL is taking steps to grow the number of quality themes. And thank God we have visionaries like Adrian, who will hopefully continue to stun us with sweeping theme system improvements. -- Dries Buytaert :: http://www.buytaert.net/
Sorry for the cross post - but I thought I would move this discussion to the theme list. Dries Buytaert wrote:
Having to create a Drupal theme really turns me off.
Making it easier to create a unique, good-looking theme in a matter of hours is a key challenge for the Drupal community.
Well - the 90-10 rule applies. I get get 90% of a theme done very rapidly and have a pretty good looking site at the end of a short session (i.e. matter of hours). But, its that last 10% that takes 90% of the time. All the special cases - all the different forms - different node types - different 'sections' of a site that require a different look etc. All the tiny annoying little bumps that require ironing. That's what's a pain in the ass. But, most of this is unavoidable. This time consuming stuff isn't the fault of the themeing engine or the templates... its the natural result of people wanting to modify things because they don't want a 'stock' vanilla looking elements. They want to mod almost every detail - and that kind of modification takes time. And also keep in mind that some of these mods that make a site look 'unique' aren't just simple theme overrides - they are hacked and modified modules - that become completely new modules and/or new functionality contributed back to core modules. andre ___________________________________________________________ To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com
andre wrote:
Well - the 90-10 rule applies. I get get 90% of a theme done very rapidly and have a pretty good looking site at the end of a short session (i.e. matter of hours). But, its that last 10% that takes 90% of the time. All the special cases - all the different forms - different node types - different 'sections' of a site that require a different look etc. All the tiny annoying little bumps that require ironing. That's what's a pain in the ass.
I think half of the problems I encounter themeing different drupal sites is with the different modules. Every single developer out there wants to code something in one way or another. And they all want to use page breaks (<br /> [yes, that is the proper way you print out a "<br>" people!) in places where you, the themer, might not necessarily want them. So if you are themeing all the different form elements, you are constantly scrambling for different classes and ID's to try and theme a particular form to look a certain way. I honestly don't understand why there isn't, and wasn't, a common set of practices decided on long ago for people to use when building modules. I am thinking that's what this new "forms.api" stuff I keep hearing about is for... I'm not sure. The biggest bulk of a Drupal themers problem is, you typically can't just theme, all generic selects, inputs, etc. You have to specifiy certain elements and my gosh, there can be tons and tons and tons of them. Ending up with a nasty huge giant amount of CSS. Dries is right, it shouldn't be this hard to theme. I should be able to theme the header, sidebars, footer, content area, select, input, and a few other things and be done. But that is not the case. Before anyone goes asking me to patch something, I do graphics, and know CSS. I don't code. So, no, I can't "submit a patch"[tm] Trae
But, most of this is unavoidable. This time consuming stuff isn't the fault of the themeing engine or the templates... its the natural result of people wanting to modify things because they don't want a 'stock' vanilla looking elements. They want to mod almost every detail - and that kind of modification takes time.
And also keep in mind that some of these mods that make a site look 'unique' aren't just simple theme overrides - they are hacked and modified modules - that become completely new modules and/or new functionality contributed back to core modules.
andre
___________________________________________________________ To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com
-- Trae "occy" McCombs || http://occy.net/ Founder - Themes.org // Linux.com CivicSpaceLabs - http://civicspacelabs.org/
another. And they all want to use page breaks (<br /> [yes, that is the proper way you print out a "<br>" people!)
Mmm... it just depends on the DOCTYPE you are using. I use HTML 4.01 in many sites, so a <br /> would be wrong for those cases. álvaro -- http://www.popmadrid.com http://furilo.com
The point is... you shouldn't be using page breaks to format the output of your module or form. That's why God created CSS. Trae Álvaro Ortiz wrote:
another. And they all want to use page breaks (<br /> [yes, that is the proper way you print out a "<br>" people!)
Mmm... it just depends on the DOCTYPE you are using. I use HTML 4.01 in many sites, so a <br /> would be wrong for those cases.
álvaro
-- Trae "occy" McCombs || http://occy.net/ Founder - Themes.org // Linux.com CivicSpaceLabs - http://civicspacelabs.org/
I am fairly certain I can make a large amount of improvements on the current process of building a theme, and I will be looking into them in the drupal 4.8 cycle. The biggest boost however is the phptal theme engine I have been planning since time immemorial. The first theme I ever wrote for drupal was a system that used phptal templates, and allowed for template switching. I called it Chameleon. Dries later stole my name for the theme we have in core now (although i don't think it should be called chameleon. it's nowhere near flexible enough). The benefit of the phptal system, is that your html mockup, IS your final template. You can open it up in dreamweaver, and change it however you see fit. You just add the right xml tags in the blocks you want to either define as theme functions or replace with variables. When i think about it, I could probably write an ajax tool to turn any static html mock up into a template, although practically .. you obviously need to have enough blocks in your page for all the elements. I stopped developing the engine, as phptal was incredibly slow with php4. The php5 version is a lot faster though, probably the same speed as phptemplate. On 13 Dec 2005, at 4:52 PM, Trae McCombs wrote:
The point is... you shouldn't be using page breaks to format the output of your module or form. That's why God created CSS.
Trae
Álvaro Ortiz wrote:
another. And they all want to use page breaks (<br /> [yes, that is the proper way you print out a "<br>" people!) Mmm... it just depends on the DOCTYPE you are using. I use HTML 4.01 in many sites, so a <br /> would be wrong for those cases. álvaro -- http://www.popmadrid.com http://furilo.com
-- Trae "occy" McCombs || http://occy.net/ Founder - Themes.org // Linux.com CivicSpaceLabs - http://civicspacelabs.org/
-- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com
On 12/13/05, Trae McCombs <occy@occy.net> wrote:
I think half of the problems I encounter themeing different drupal sites is with the different modules. Every single developer out there wants to code something in one way or another. And they all want to use page breaks (<br /> [yes, that is the proper way you print out a "<br>" people!) in places where you, the themer, might not necessarily want them. So if you are themeing all the different form elements, you are constantly scrambling for different classes and ID's to try and theme a particular form to look a certain way.
Have you filed bugs against modules that use <br /> and/or suggested alternate approaches? If a module is outputting hard-coded HTML where it shouldn't, it's a bug.
The biggest bulk of a Drupal themers problem is, you typically can't just theme, all generic selects, inputs, etc. You have to specifiy certain elements and my gosh, there can be tons and tons and tons of them. Ending up with a nasty huge giant amount of CSS.
Dries is right, it shouldn't be this hard to theme. I should be able to theme the header, sidebars, footer, content area, select, input, and a few other things and be done. But that is not the case.
Umm....sorry, but *why* can't you just theme those areas if that is all you want to do? I'm really not too sympathetic to theming complaints, seeing as how I've seen something like 60+ sites launched in the past year with custom themes -- see http://www.aeropod.ca/ or http://www.netsquared.org for two examples off the top of my head. *Design* is hard. A completely custom look and feel for your website is hard. Cross browser CSS is hard. Designing individual pages in HTML and uploading them via FTP is hard. None of these things have anything to do with Drupal. -- Boris Mann http://www.bryght.com Vancouver 778-896-2747 / San Francisco 415-367-3595 IM boris_mann@jabber.org / SKYPE borismann
*Design* is hard. A completely custom look and feel for your website is hard. Cross browser CSS is hard. Designing individual pages in HTML
and uploading them via FTP is hard. None of these things have anything to do with Drupal.
I concur. I wrote a mini-essay a while back on the nature of this problem. In a fit of narcissism, I will copy-and-paste a relevant portion. In the world of Movable Type and WordPress, it's a foregone conclusion that connecting your blog to your de.licio.us favorites or adding a 'quote of the day' in the sidebar will involve wading deep into templating languages and perhaps Perl or PHP. One of the snappier WordPress themes, K2, boasts features like "compatability with multiple authors" and "Showing the latest comments." A lot of work has gone into making K2 flexible enough to deal with more than one or two configuration scenerios, and the work shows. What really struck me was that any Drupal theme released without that sort of flexibility would be sent back to the drawing board as broken. New modules are released almost daily, shoving new content types and new presentation paradigms and new tools and options into the Drupal framework. The Drupal themes one can download from the main site take them in stride thanks to the tremendously flexible templating system. I've thrown together quickie themes for Drupal that make all sorts of assumptions (we'll never had sidebars, we don't need to display comments, only Module X and Module Y will ever be installed...) and it's as easy as any other system. Easier, in some cases. In about twenty minutes , I whipped up a very rough 'compatability theme' that lets a Drupal site use CSS skins originally designed for Movable Type blogs. But making a theme that's visually stunning, cleanly designed, AND flexible enough to handle anything J. Random User installs into their Drupal build can be a pretty daunting task. That's a DESIGN problem, not a DRUPAL problem. It's certainly something we can try to take a stab at improving. It's certainly an opportunity for some highly-skilled designers to step in and create some great (and highly flexible) themes... But the only way to make theming 'brain dead simple' is to dramtically reduce the number of scenerios themes have to deal with. That means admitting that your 'easy' theme will only work with a small subset of Drupal's features. --Jeff
Op dinsdag 13 december 2005 18:07, schreef Boris Mann:
-- see http://www.aeropod.ca/ or http://www.netsquared.org for two examples off the top of my head.
Great examples. Also to stress Occys point. Just look at the next-prev witget. yup. standard. core. Yes its themable, but no, its not easy. Not at all. So, yes, Drupal is extremely powerfull for themeing, but, its not transparant enough, nor is it consistent in that flexibility. Another example is /aggregator I have never come across a drupal site that made something nice looking out of that, something that fits into the rest of the site better then the default pages. Same for search. http://www.newsphoto.nl/search/node/Lennon was a very hard one to do. Its a theme function of over 100 lines! and it performs horrible. Ber -- | Bèr Kessels | webschuur.com | website development | | Jabber & Google Talk: ber@jabber.webschuur.com | http://bler.webschuur.com | http://www.webschuur.com |
participants (18)
-
Adrian Rossouw -
andre -
Andre Molnar
-
Boris Mann -
Bèr Kessels -
Chris Johnson -
Dries Buytaert -
drupal-devel＠istyledthis.nl -
Earl Dunovant -
Gabor Hojtsy -
Jeff Eaton -
Kieran Lal -
Larry Garfield -
Neil Drumm -
Theodore Serbinski -
Tim Altman -
Trae McCombs -
Álvaro Ortiz