Words from a noob Drupaler, please don't get angry! :)
Hi all,
We've started working with Drupal a month or two a go. After some discussion we've decided to go open source and abandon our own cms. Doing quite a bit of research resulted in chosing Drupal over the rest. We were all excited!!! The possibilities were endless and the list of websites using Drupal (http://buytaert.net/tag/drupal-sites) is very impressive to say the least!
Now after some time, trying to port a simple website to Drupal my excitement has dropped to an all time low!! And am beginning to think we've made the wrong decision! Some of the annoyances I've encountered so far;
- Drupal and it's modules add a lot of useless mark-up to it's output. Overrides are needed to filter the $content in order to produce more semantic correct code, if possible at all? As an example I'll take the views module. When it outputs a list-view it surrounds the list with tons of useless divs. Well useless... probably not for those who only use css to style/theme a website. But to me (and from what I read a lot of others) it's useless. I believe it would be better if the output would be as raw as possible... no divs, no uls, no lis... let's spit out arrays/objects of raw content as the user put it in the DB in the first place and let the theme handle the adding of markup. Why add this nonsense in order to filter it to raw code and add your own markup to it again??
- A very huge annoyance I've encountered is the theme switching between the default and administrator theme. A lot of times when you save a setting as an admin within the admin theme you'll get thrown back into the default theme, which ofcourse a lot of times isn't meant for this and lacks the space to fit all the stuff the back end spits out like forms, admin menu's and other features. So it results in a very messy page... not nice for me... a nightmare for clients who'll think they've ruined their website drop everything they're doing and will call you in tears at 4am. Leaving you to explain to your girlfriend why you're getting strange phonecalls at this time of night.... Blocks even do this on purpose?? Why? In most CMS systems you have a back end and a front end. You change something in the back end and look at the front end to see if it worked out, the better ones have a preview function for this....
- Multilingual support... well we've looked at both localizer and i18n. And altho possible to have multilingual content it gives a severe case of insomnia to say the least. One doesn't support translation based on domainname, the other doesn't support pathauto or view translations... etc etc, all and all not what you'd expect from it.
And the list continues...
I'm not trying to bash Drupal here, just writing down my experiences to get it of my chest. I could have done this on a piece of paper to spare all of you from my whining. Yet this way I hope to get your feedback! How was your first Drupal experience?? Was it similar? And what did you do to get around these problems... Have the clouds cleared and how long did it take. If it wasn't similar and the problem probably lies with me (as I suspect), maybe I've stepped into the world of Drupal with the wrong way of thinking? Or is everything I'm saying all wrong and very possible indeed but am I missing the picture here...
I started building websites a decade a go and always have worked to create solutions to problems, with Drupal I get the feeling I'm working around problems instead and let them be, hoping they will go away by themselves as I do with my mother in-law. Which just doesn't give me the satisfaction...
Can't wait for your responses, as I said, I'm not here to bash Drupal... just looking for a bit of mental coaching :)
Cheers
All CMSs have there way of
All CMSs have there way of doing things. As individuals some of those approaches work better for us, they "feel" more comfortable.
I will address one of you points, the question of what outputs the 'html'. You state "and let the theme handle the adding of markup" and with Drupal it does something close. With Drupal 5 most(all) of html is produced by theme functions and as you might expect there are a lot of default theme functions. This has some advantages over making the theme always generate the html, these includes it makes Drupal more friendly to people who just want to produce a website, it also means themes do not need to worry about every possible module. For people who want more control they have the option of overriding as many of the default theme functions as they want. Views does a good job of this providing the ability to override both high level theme functions so you can change the output for all views to the ability to overriding the look of a particular view.
Drupal and it's modules add
I have been complaining about everything in your list for years. I still like Drupal regardless but this stuff but it is nice to know that it is not my imagination.
The consensus is that inorder to fix this you would have to write a 5mb patch. So rather than do this I am working on a fork of Drupal 4.7 which was the cleanest version I think. You have reminded me also to get off my ass and do some work on the project ;)
Hiveminds Magazine | Drupal.st | Code browser | Drupal.se
...
Yes, you've been been consistently misstating and misrepresenting your complaints like this as well for years now as well.
-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide -|- Black Mountain
yes, And you are still a
yes,
And you are still a pompus ass! get off my foot!
Hiveminds Magazine | Drupal.st | Code browser | Drupal.se
...
I didn't call you any name so play nice. You know how to contribute.
-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide -|- Black Mountain
Obviously you do not! You
Obviously you do not! You come in with your personal statements and acquisations directly without provocation.
I really can not believe that anyone actually allows you to be a moderator or represent Drupal.org in any capacity. You are a troll!! and If I have to be one in order to make my point the I will do so at every opportunity. Now get rid of the attitude and delete any of your statements that have nothing to do with Drupal and I will do the same.
Hiveminds Magazine | Drupal.st | Code browser | Drupal.se
Thanx all for the replies...
Thanx all for the replies...
@ Hiveminds: Good to hear I'm not the only one who found it was hard to start out with Drupal so it's not all just my view of things. Even better to hear you're still using Drupal after those setbacks.... I should just hang in there then ey :)
Hope we can idd drop the namecalling and if so let them be aimed at me... I'm the one who started this 'controversial' topic...
@ Nevets: I did use theme functions but still am stuck with a lot of extra markup. I do understand it makes it easier for people 'who just want to produce a website'. Yet from what I've encountered those people are more likely to download a prebuild theme and maybe change some css. So it would be no difference to them. But I reckon it's just my way of thinking that I need to change. I'm more of a minimalist, if there might be a reason to override a function/output then don't build it into something, just add another layer that has this function/ouput (theme). That way if you take the layer away you're back to basics and you don't need to build a layer that changes what the layer beneath did without asking... This way you basically only have to look forward and not backwards... like i said, it's a way of thinking I guess!
@ Sepeck: Sorry for stepping on your toes mate...
Cheers
...
You didn't step on my toes. Hivemindz is a known for his complaints, anger and inaction.
Recognizable Drupal themes are somewhat easy to spot, but there are thousands of sites that are not easily spotted as Drupal because their implementers were able to leverage the tools. Yes, it makes things more complicated for some but it gives that flexibility and power to the rest. It's a balancing act between various groups needs. Where that balance is changes each release as the community grows.
-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide -|- Black Mountain
If you think I am just going
If you think I am just going to sit here and let you slander me with off hand comments without reaction you are mistaken. Take your pathetic self and find something else to do because I am not going to let this go without a fight. I am sick and tired of you. Mostly sickened. So shut up or be willing to take this convo and delete it and any others that I find you trying to discredit me with your venemous attitude and unsubstanciated statements.
As for the name calling. This is going to get ugly really fast if I see another passive aggresive post directed at me.
Hiveminds Magazine | Drupal.st | Code browser | Drupal.se
...
Let's do without the threats all right? I'm the one who said not to ban you last time.
-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide -|- Black Mountain
I've been using Drupal for a
I've been using Drupal for a couple of months now too.
> A very huge annoyance I've encountered is the theme switching between the default and administrator theme. A lot of times when you save a setting as an admin within the admin theme you'll get thrown back into the default theme
I haven't seen that at all. My admin theme is garland, and I use a modified 3rd party theme for browsing and editing content. The only time I see garland is when I go to the admin backend. The only time I see the 3rd party theme is in admin > blocks.
Are you sure you don't have the 'use admin theme for editing content' checkbox selected in:
admin > site config > administration theme
That's the only thing I can think of which would switch you back and fourth.
> Multilingual support... well we've looked at both localizer and i18n
Its early days yet. Multi-language implementation is still very buggy and doesn't work properly, even with help from the contributed modules. But that's a reflection of a) how hard it is to implement this feature and b) the fact that only 10% of sites use more than one language.
> Overrides are needed to filter the $content in order to produce more semantic correct code
What do you mean by 'correct'? Drupal core validates, doesn't it?
Maybe you just mean 'bloated'? But really, does anyone care about 100kb of bloated html anymore, when we have so much flash, graphics and media in our sites these days, and 95% of users use ADSL or faster? What about all the javascript/jquery that needs to be loaded for web2.0 featues?
The bbc.co.uk website costs 1.2 million pounds per year to maintain and they use their own custom-built CMS - take a look at it's source and see if it is much better than Drupal's (it isn't). Interesting to note also that, whilst the layout of the source is neat, my YT account page takes 600 lines of script, yet my average Drupal page (with a similar amount of textual content) is between 200-300 lines.
> Now after some time, trying to port a simple website to Drupal my excitement has dropped to
> an all time low!! And am beginning to think we've made the wrong decision!
What was the alternative? Why do you think you wouldn't have had as many problems with it?
> with Drupal I get the feeling I'm working around problems instead and let them be
But there is a difference between a) features that are plain buggy and don't work, and b) having a plan that is unrealistic because you don't know what the limitations of the software are yet. If the latter, then you perhaps need to change the plan rather than fight the software? Over-time, your plans will become more tuned in to the capabilites of the software, and you'll naturally be fighting it less.
> How was your first Drupal experience? Was it similar? And what did you do to get around these problems
Experience with the software has been very good over-all. Usually I begin to implement an idea thinking it's going to be difficult, but I've been constantly surprised at how easy it is and how smartly the modules behave. The people on the forums and project pages have been another very good experience.
The key things that will make or break my current Drupal project are the permission system, multi-language and ease of adding text and media; if I can't make those things work properly then the project is more-or-less over. My first Drupal site is, unfortunately, a large, important one. I would have preferred a small personal site to cut my teeth on, but there you go. However, if the project doesn't float, it isn't time completely wasted, because I'll have a fairly good knowledge of Drupal for future sites (and I wasn't naive enough to tell anyone I was building a new website, until I was sure Drupal can do it; so if it fails they can continue using the old website and be none-the-wiser!).
Cheers.
Hi Anti, Thanx for the
Hi Anti,
Thanx for the reply!
About the theme switching, I thought it was just me. But then I found out in forums that other ppl experienced this as well. For blocks it's common knowledge that Drupal switches between themes and I hope to find a solution to it...
With semantically correct I mean what you call bloated... semantics has nothing to do with xhtml/css validation. Yes the following markup will validate:
<div class="view view-key-features-auto"><div class="view-content view-content-key-features-auto">
<div class="item-list">
<ul><li> <a href="link">Link to my node</a>
</li><li> <a href="link">Link to my node</a>
</li><li> <a href="link">Link to my node</a>
</li><li> <a href="link">Link to my node</a>
</li><li> <a href="link">Link to my node</a>
</li><li> <a href="link">Link to my node</a>
</li><li> <a href="link">Link to my node</a>
</li>
</ul>
</div>
</div>
</div>
But so will this:
<ul><li> <a href="link">Link to my node</a>
</li><li> <a href="link">Link to my node</a>
</li><li> <a href="link">Link to my node</a>
</li><li> <a href="link">Link to my node</a>
</li><li> <a href="link">Link to my node</a>
</li><li> <a href="link">Link to my node</a>
</li><li> <a href="link">Link to my node</a>
</li>
</ul>
And I can style both codes exactly the same with css... see what I mean. And yes people care about 100Kb html files. 1) not the entire world has ADSL
2) 10.000 pageviews at 10Kb or at 100Kb... bandwidth doesn't come for free and servers have a hard time as it is
If you go out hiking for the weekend, do you cramp your whole wardrobe into your backpack to carry around when all you need is a clean pair of socks and briefs???
Well the alternative was Typo3 or continueing with our own CMS. Typo3 is just too much for the average website and our own CMS still remains an option.
Limitations of the software. From what I've read during my research that led up to deciding to go for Drupal there basically were no limitations. Overriding and theming were keywords here. But not everything that is being outputted is themeable or overridable unless you hack into core.
All and all I'm not unimpressed with Drupal, don't get me wrong. But all the articles I've read online have builded my expectations to a level which I don't see Drupal reach yet... it might with more experience with the software! And I hope it will!
Cheers
It's not Drupal's fault with
It's not Drupal's fault with the bloated HTML output- its the module developers.
But you could just as easily dive into the .module to affect what is being returned. I do that from time to time. The joy of open source no?
==============
delaware web design
delaware website design
Hi gh0st25, Thanx for the
Hi gh0st25,
Thanx for the reply! Ofcourse you could dive into the .module and hack it a bit. But from what I've gathered it's carved in blue Drupal stone tablets that this is bad practice. Overriding and theming are the way to go... yet not all output is themeable/overridable... I beginning to see a crack in that Drupal stone tablet... :p
Cheers
Not entirely accurate
There is Drupal core, which is as flexible as possible. People take great pains to make things can be overridden. Are there things in core that could be done better? Sure, patches welcome. The issue queue is open to anyone to contribute to and over a thousand people have done so. People are strongly discouraged from modifying core. The major reason is that most things people want to do in core can be done through over rides. Those who know how to do so correctly though will still do it, but they know when and when not to and how to maintain their changes and contribute them back and deal with conflicting updates. The vast majority of people new to Drupal do not know how to do this so really, people are strongly discouraged from doing it.
We also have contributed modules. Contributed modules are just that, contributed by people. They are not blessed by some authority, they are something someone has done and it's fairly easy to get a CVS account to contribute. This person who has shared how they have solved their needs could be a neophyte with Drupal, they could be a neophyte with PHP (many are). They make decisions that solve their needs, not yours but they share them. As a result, you may very well benefit.
Some contributed modules are of a very narrow design and as a result can be difficult to use in a more complex or generic situation. Other modules are designed as generic tools. These tools have often been given great thought and matured over time to provide as great an audience with the tools that audience needs to more easily and effectively use them. So before one goes off on random complaints, it's best if you spend some time looking through the modules issue queue and any other documentation. It may well be that there is an excellent reason for any additional markup and it may well also provide the tools to avoid that generation.
However, if there is an issue with a given contributed module, then that does not indicate a 'Drupal' problem, that is a problem with the module. You have several options here. You can fix this for yourself and not share, or you can get involved with that module and contribute a patch to fix it. Many maintainers welcome this while others don't always play well with others, this too is Open Source. We even have a handbook page on this. Join forces with others. On the modules download page we have this link as well.
So, the question then is, where do you see yourself helping? Is it a contributed module that needs improvement? Is it core? Can you supply solid feedback and even perhaps patches in the right issue queue? This is all helpful. This is the point of the Drupal community, to make things better by solving your own needs. In the Developing for Drupal documentation we have a section on contributing to development. People contributing positively is always welcome and many people build their reputation in the community in this manner. Other ways to contribute can be found on the contribute tab.
-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide -|- Black Mountain
Yes! Us evil, terrible and
Yes! Us evil, terrible and thoughtless module developers should be taken out of the equation.
-- Merlin
[Point the finger: Assign Blame!]
[Read my writing: ehalseymiles.com]
[Read my Coding blog: Angry Donuts]
Drupal and it's modules add
Translation: My use case, which by the way is probably .1% of Views users out there, is more important than the normal use case, which is the one that is okay with some extra divs.
Your self-importance is astounding.
-- Merlin
[Point the finger: Assign Blame!]
[Read my writing: ehalseymiles.com]
[Read my Coding blog: Angry Donuts]
By the way, I've created a
By the way, I've created a concise explanation for all of Views' markup in the past. I'd do so again, but you've already identified the gist of it: Views' markup is intended to be as CSS friendly as possible.
See, here's the difference:
In your use case, it doesn't *matter* what markup Views puts in. You'd change it anyway, because you're very particular about your markup. See, that's why we have a theming layer. So you can.
But the vast majority of users don't need to touch the theming layer just to make some minor adjustments. It's very easy to pick out individual pieces of a view and CSS it up. I've thought long and hard about this, and it's much easier for the average user to come up with a little CSS to make their changes than it is for users to figure out what markup they would need. If it's completely raw output, it's useless to most users.
The worst part is, your particular complaint bothers me, because you've already identified exactly why it's done, and you obviously don't care!
There are two solutions:
1) Override the views theming functions, put the markup the way you like it, put these theming functions in a file named views.inc and include this into all your themes. Now, it's fire and forget. Your markup the way you like it. And no other poor user who isn't as capable with markup as you (which let me assure you is far, far more than you want it to be) will not be harmed and can go on to deal with a thousand other reasons that Drupal or Views can be hard to use.
2) Don't use Views, create your own lists and your own markup.
But really, that basic complaint is just ridiculous. I don't understand how you can possibly expect to use a generic tool and not get generic markup.
-- Merlin
[Point the finger: Assign Blame!]
[Read my writing: ehalseymiles.com]
[Read my Coding blog: Angry Donuts]
Sorry, one other thing: no
Sorry, one other thing:
If it didn't have ul/li it wouldn't be a list view, now would it?
-- Merlin
[Point the finger: Assign Blame!]
[Read my writing: ehalseymiles.com]
[Read my Coding blog: Angry Donuts]
Boy, open source community
Boy, open source community isn't well receptive of criticism, despite mostly everyone in the office who has worked with Drupal groan about the excessive HTML output of some modules. Calm down.
==============
delaware web design
delaware website design
Call it entertainment
I do volunteer work for a non-profit, and they spend so much time thanking me it's embarrassing! But they know how to make people feel appreciated. Now picture someone who spends countless hours creating code to give away, just to have people flame him. Probably not too happy about it.
Criticism does no good if it's not heard, and it's hard to hear when it's presented as an attack rather than part of a constructive process. Sometimes what we need to do is lighten up.
I'd like to take this opportunity to thank all the contributors to Drupal, including the ones who sometimes get a bit cranky, for creating this solid piece of software. It's not perfect, but it does its job well, and perhaps some day I'll be adept enough to help improve it.
I know the feeling all too
I know the feeling all too well, it comes with being a developer. You just develop a thick skin after awhile. No need to get up in arms about it because its not like what I said is untrue. I've always thought Drupal needs a 'pro' mode that doesn't do any HTML markup, it lets you determine that for yourself.
==============
delaware web design
delaware website design
Markup
Perhaps each module could have a setting for the amount of container blocks. Just a thought.
Drupal does have a 'pro'
Drupal does have a 'pro' mode; Module development. If one wants a list that doesn't have miles of extra div tags... they're really quite easy to build with a small amount of php. Views being a simple example here.
People like merlin are quite amazing. They've taken their skills and made a versatile tool, which outputs html formatted lists in a manner that is useful to 99% of people who just want to prototype a view of their database. Individually simple tasks, but overall a pain in the arse to do many of them.
I love Drupal and especially Contributed Modules
Big thanks to all the module developers out there, none mentioned, none forgotten.
I share your concern though, about extra markup, otoh, the one module you mentioned, Views, are a very generic module supposed to do everything for everybody (almost). It is also one of the most active projects, and most used modules out there.
It has a lot of ways to add theming support, so I'm sure it can be fitted to your use.
As for multilingual features, I agree. They are not what I need, but I'm not the one developing it, nor have I tried to finance some development, thus I can just guess that those modules solve the problems for those who developed them, and I've been lucky enough to have issues fixed with the i18n module in the past.
The easiest way to get things fixed is either reporting a bug or a feature request. You could also offer a bounty, or donate to some of the modules if what you need is particularly specific.
Since you say you have ditched an internal CMS, it seems that you might have some resources for fixing/creating those things you need fixed.
I would try with the theming functions first. Also, if you use any modules which don't have theming functions, they aren't that hard to implement, and if you send the patch to the module maintainer, I think the maintainer would appreciate the fact that you are using his module and like it enough to fix those things that annoys you.
I wish you luck with further work on your site.
Paul K Egell-Johnsen
Ok, maybe I started this
Ok, maybe I started this post the wrong way. Yes I'm thankful of Drupal and all it's developers. And like I did say in my post I didn't mean to bash Drupal nor it's developers hence the sarcasm and cynism used in the post. I have to agree with gh0st; "open source community isn't well receptive of criticism". I should have chosen different words and be more political about my post. Yet on various Drupal related forums I see people with critisism being attacked. Isn't critisism supposed to help making better things?? In some projects groups I worked in before we often planned 10 minutes in which one could say anything about another one's work without anyone getting pissed off as long as it wasn't something like; I think it should be blue! - Why? - Because! These 10-minutes helped opening eyes, seeying things differently and making things better! There weren't any replies like; "Do it yourself if you think you can do better". These meetings led to a positive discussion and usually a better project! Again, maybe I've provoked reactions like this due to my choice of words.... for which I again appologize!
Cheers
Criticism
There is a huge difference between constructive criticism and "I don't mean to bash you, but...". Let's take this paragraph for example: (bolding mine)
"- Drupal and it's modules add a lot of useless mark-up to it's output. Overrides are needed to filter the $content in order to produce more semantic correct code, if possible at all? As an example I'll take the views module. When it outputs a list-view it surrounds the list with tons of useless divs. Well useless... probably not for those who only use css to style/theme a website. But to me (and from what I read a lot of others) it's useless. I believe it would be better if the output would be as raw as possible... no divs, no uls, no lis... let's spit out arrays/objects of raw content as the user put it in the DB in the first place and let the theme handle the adding of markup. Why add this nonsense in order to filter it to raw code and add your own markup to it again??"
merlinofchaos took the time to make markup that would be easy to theme to the masses and you call it "useless" and "nonsense". But of course you didn't mean to bash him so that makes it all ok, right? How is that constructive? Do you really think he could write a module with the scope of views and yet put in a bunch of markup because he doesn't know better? Please.
How about this?
"I notice that there is a lot of markup with views. I assume this is there to help people theme their views with just CSS. But, for my needs, a more raw version without the markup would work better. Is there any way I can do this?"
That's what you're really asking after all. Doesn't that sound a lot nicer? Notice no where in there are the words "useless" or "nonsense". It's straight and to the point and doesn't offend anyone.
This community does just fine with constructive and original criticism. Bashing or rehashing the same issues over and over does no one any good and just irritates. If you want to see change in Drupal, there are plenty of ways to go about it without pissing anyone off.
Michelle
--------------------------------------
See my Drupal articles and tutorials or come check out life in the Coulee Region.
Hi Michelle, Well I was
Hi Michelle,
Well I was hoping to give this one a rest but I just have to comment here. I should have used the word redundant.... but unlike you English is not my first language and to me they both mean exactly the same thing. I once was thought the difference between cheap and inexpensive I guess that's the same. They both mean exactly the same but it depends on the receiver's perception and standpoint how the message comes accross. One can be offended even with the 'softest' of words... it's all in the perception/interpretation.
And like I said in a post before the next code can be styled exactly the same:
<div class="view view-key-features-auto">
<div class="view-content view-content-key-features-auto">
<div class="item-list">
<ul><li> <a href="link">Link to my node</a>
</li><li> <a href="link">Link to my node</a>
</li><li> <a href="link">Link to my node</a>
</li><li> <a href="link">Link to my node</a>
</li><li> <a href="link">Link to my node</a>
</li><li> <a href="link">Link to my node</a>
</li><li> <a href="link">Link to my node</a>
</li>
</ul>
</div>
</div>
</div>
as this:
<ul>
<li> <a href="link">Link to my node</a>
</li><li> <a href="link">Link to my node</a>
</li><li> <a href="link">Link to my node</a>
</li><li> <a href="link">Link to my node</a>
</li><li> <a href="link">Link to my node</a>
</li><li> <a href="link">Link to my node</a>
</li><li> <a href="link">Link to my node</a>
</li>
</ul>
so to me there is no use for the divs, not even for those who are pure css themers... no use.... useless....
so to me the divs make no sense, not even for those who are pure css themers... no sense.... nonsense....
rehashing the same issues over and over does no one any good
Like others in this topic said, and in forums and blogs all over the web, it is indeed a well known issue...
I reckon I was rehasing because it still is an issue...
Bartezz
They can only be styled the
They can only be styled the same if you want all unordered lists to look the same, if you want different unordered list to look different you need some class and/or id to differentiate the lists
<ul id="I can have an unique
<ul id="I can have an unique id" class="an ul can have a class too">
</ul>
Or am I missing something here?
Classes vs ID's
Classes allow you to tweak a bunch of similar things at once. ID's allow each thing to be tweaked individually. If both weren't available, someone, somewhere, would feel put out.
Hi David, I know... so this
Hi David,
I know... so this basically does the same thing tho? "if you want different unordered list to look different you need some class and/or id to differentiate the lists"
Not sure I get your point
It seems like now you're asking for more markup to allow styling. Well, I thought my idea of adding a setting for how much markup you get was good, but so far nobody else has expressed an opinion. 0=bare output, 1=enclose in a div or two, 2=class & id's for each element.
Nested divs are sometimes used because of IE versions that don't do padding right, so you use a margin on the inner div instead. Although your example code snippet probably uses them so you can talk to the list by itself, or talk to similar items throughout your pages. Also the different divs might make it easier to pick something out using descendant selectors, but I think this is the wrong way to do things. It's better to talk directly to an item.
Hey David,Thanx for the
Hey David,
Thanx for the reply. Wasn't asking for more markup really. But what I meant to say was, if the divs are there to make sure one can style the uls individually then why not give the uls an id and a class and skip the divs altogether. I understand now that they're there because of IE versions not doing padding right. Yet I believe a better solution would be to work around these IE css bugs by using IE specific css and conditional statements instead of using extra markup.
I like your idea about adding a setting for markup preferences a lot. And I've seen this opted in a few forums. That way everyone is happy!! I've tried using the themable functions (even before starting this post) to alter the views output yet somehow I'm not able to remove ALL divs this way.
"Also the different divs might make it easier to pick something out using descendant selectors" I get what you mean. But with some css and theming knowledge you don't need the divs for this. The uls are already decendants of the region in which the view is outputted. Or maybe I'm missing a bigger p[icture here as well :)
Thanx for your feedback!
Right is right
and I'm a bit put off by having to kludge up my work to satisfy people who use microsoft's viruses. If the Zen themers hadn't included an IE stylesheet I wouldn't do anything to help people who aren't willing to download a compliant browser. I might nag them a bit, however. Although I do believe that IE is ABSOLUTELY THE BEST TOOL to use to download Firefox.
.
See, the trouble is that you are, as you say, a noob, and so apparantly don't realize that those two sets of markups are most definitely not equivalent. As pointed out in the other post, the second would only work if you want all lists on the site to be the same. Views gives more specific markup so you can target things individually.
It's only an issue to you because you don't understand. And it's fine to be new, fine to not understand how things work. But when you are new and don't understand how things work, posting that said things are useless is just going to bite you in the behind.
Michelle
--------------------------------------
See my Drupal articles and tutorials or come check out life in the Coulee Region.
Markup
I use the Zen theme, which has a lot of markup. I've learned to ignore what I see as excess until I understand it. Eventually I've figured out the reason some things exist, and for the rest, well, they must have had someone else in mind. The difficulty for me is doing something, then discovering the better way, and then having to go back and clean up everything.
I still think that a verbosity setting on modules might be useful. And yes, the two markup examples might be made functionally similar by the use of selectors, but the divs provide flexibility in the box model, etc.
First let me say that Views
First let me say that Views is such a useful and excellent module that it could produce three times the markup and I'd still use it. How's that for sucking up?
I don't consider myself a total 'noob', having been involved in web design off and on for over 10 years, and still have to echo Bartezz. If you added a unique ID and a class to the ul tag, I can't see how it wouldn't cover a themer's needs 99% of the time - and for the occasion that it isn't enough one could then resort to the function overrides. I base this purely on my own experience and admittedly from a design perspective.
But does anyone have a live example of Drupal website that takes advantage of all the nested divs and their classes that Views provides? I think a real world example would shed some light on the matter for people like myself who could easily be missing the big picture. My thoughts are that if it's far less common to use them then not to use them, they're extraneous.
And now having said that I'm sure tomorrow I'll come across a design that I can't do any other way.
I use the div's all the time
I use the div's all the time :) One thing to note is that views does not always produce a list (in the html) sense.
Hi Nevets, So what do the
Hi Nevets,
So what do the divs do for you that an ul with an unique id and classname wouldn't be able to do? I'm just still trying to grasp the concept behiond all the divs.
Ofcourse views is not just there to produce lists. It does other cool stuff too. Yet haven't used all of the output possibillities so I can't really comment on those.
Cheers
It's funny - looking back
It's funny - looking back over some of my own projects I now see where I've unconsciously used some of the classes and divs that Views outputs without making note of it. But I still see where Bartezz is coming from. For example, in lists, Views seems to call two classes in each nested div - why not just select the div itself using the classes they're contained in? i.e.:
.view-example-view-list li div {
color: #eee;
}
Part of my problem is that I come from that CSS school of thought where one of the goals for web design is to make things as slim and elegant as possible, and so dozens of unused classes in the markup make my eyelids twitch.
....
I watched a presentation from a themer and her favorite thing was to add a function in template.php and 'poof' most of the markup went away.
No real time to search for you but found this: http://drupal.org/node/136136
-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide -|- Black Mountain
Well, here's some
Well, here's some resources...
http://groups.drupal.org/node/4161
http://groups.drupal.org/node/6355
http://drupalworx.com/node/6
I'd reiterate a comment of Merlins, it's a generic system, with generic output, that also happens to be remarkably flexible. For example - take Drupal, add Views, CCK and Panels - wrap it all up in the Zen theme and you have a framework from which you could build a million sites and they could all be unique - and all without knowing a single line of PHP or HTML. To me, that's what Drupal is all about.
Add +1 competent developer prepared to learn and leverage the full power of the theme layer (and beyond) and the skies the limit.