Drupal 7 was propelled, in part, by two major initiatives: improving user experience and developer experience. UX improvements made Drupal easier to use, better organized, and more elegant. DX improvements resulted in a more granular API that allows developers to hook into Drupal to add, remove, or override functionality and output at virtually any step while rendering a page.
But what about TX: themer experience? While Drupal 7 made huge leaps towards improving TX -- a more granular templating system, the Stark theme, support for hooks in the theme layer, the enormously powerful hook_page_alter() -- we still have a ways to go. Work is well under way to add HTML5 support to D7, while many of us are simultaneously brainstorm ways to eliminate all markup from core.
Here are some ideas to improve Drupal TX:
- Creating a library of reusable design patterns (guidelines, UI assets) in core that can be invoked by modules and overridden in specific instances or contexts. This approach would allow for a standard yet robust collection of UI components that developers can draw from. For example, the "spinner" or "throbber" associated with AJAX lookups should be a reusable asset in core. theme_progress_bar() is an interesting example of a semi-standardized UI asset in core. Imagine a world in which modules don't have to re-implement spinners and themes don't have to override them, piling CSS upon CSS, JS upon JS -- all to implement multiple versions of essentially the same thing!
- Implementing this library as a design pattern API. Just like the forms API and fields API abstracts form elements and data fields into hooks, a module could invoke UI components instead of rolling its own markup, CSS, and JS -- all of which would inevitably be overridden by a themer in an unwieldy template.php file.
- From dvessel: Separating the markup from theme hooks, which should focus on manipulating and preparing data. Instead, move markup and CSS to libraries.
- Module-style dependencies listed in a theme's .info file. Some themes require base themes or modules to display properly. This will be critical for implementing design pattern APIs or separating markup and CSS into libraries.
Identifying and reusing UI components in Drupal isn't a new idea. Bojhan Somers and Roy Scholten presented a session on Drupal 7 interface patterns at DrupalCon Chicago, and Jeff Eaton highlighted the need to document design patterns in a post called Drupal 8: The Road Ahead:
Drupal's toolbox of UI elements conventions has been growing since the day it was first released: we need to document it and expand it. In the 1980s, Apple demonstrated the value of providing clear guidelines to developers on solving common UX problems. Module developers need to know when to use Vertical Tabs instead of collapsed fieldsets, why they should utilize drag and drop tables, and how to hide unnecessary information from novice users. In addition, UX tools that are unnecessarily tied to specific use cases, like Color module's color picker, need to be broken out for cleaner reuse. Enhancing and documenting UX Pattern Library for Drupal will pay off in greater consistency throughout core and contrib.
What do YOU think? What else can we do to improve themer experience?
Please show your support on the Twitters with the #DTX hashtag.
Postscript: Why "themer experience" instead of "designer experience"?
Designers, in the strict sense, don't necessarily work with markup, CSS, JS, or even Drupal. Themers are unique: We must be comfortable with all of the above, plus a little bit of PHP. We're really front-end developers who may work on the design component of a site but must also translate those pixels into code.
Also... "DX" (developer experience) was already taken.
Working list of ways to improve themer experience (updated 2011-06-27)
- Create a library of reusable UI components that can be invoked via theme hooks. This would begin as a contrib module and, hopefully, work its way into Drupal 8 core. Examples include AJAX lookup indicators ("throbbers" or "spinners").
- Identifying and documenting reuseable UI components that already exist in core. Examples include draggable table rows, the progress bar, and the check boxes and X's used in the password validation interface.
- Base themes: Identify and document major base themes and their major improvements. Examples include Zen, Omega, NineSixty, etc.
- Dependency support in themes.
- Leverage CSS3/HTML5 for better form validation. (HTML5 form element work is well underway.)
- Standardizing or documenting the recommended use of vertical tabs.
- Audit the dumping ground know as /misc and see what can be added to a proper, documented UI library.
Comments
What is a themer?
Honestly, that's the question that's never been answered. Above, you describe it as, effectively, "jack of all trades, king of none". In a previous post, I said it doesn't actually exist as an audience.
As a module developer I've been begging for richer UI gadgets (widgets was also already taken) and written specifications for when to use them for years, so I am extremely +1 on that.
I am also fully supportive of cleaning up our markup to make it cleaner, slimmer, and more modern.
As far as "removing all markup from core", I honestly have to say no. My reasons here are multi-fold:
1) Abstraction. As I said at my own DrupalCon Chicago presentation, "There is no problem that cannot be solved by adding another layer of abstraction, except abstraction". I fear that we are already at the point where Drupal is too abstract in some areas for anyone who is not a core developer to comprehend. Hell, I am a core developer and I don't comprehend large parts of it. :-) chx has noted this as well.
2) Rapid development. Not everyone is an HTML purist who wants to control every single div in existence. I don't. I just want "stock Drupal" plus a few customizations. Core should have sane defaults. Overridable, sure, but I should be able to just install core, tweak one template file, and run with it.
Sometimes, "using Drupal" means your site will have trade elements of Drupal in it. That's not a downside.
3) DX. No HTML in theme functions? Really? With hook_theme, single-parameter theme functions, preprocess functions, and render API, simply generating a default chunk of output in a module is already more trouble than it's worth. We're almost at the point of encouraging people to bypass it entirely and go back to returning strings, or throwing everything into a #markup render element to avoid having to deal with that complexity. And that was in order to make Drupal "more themable!"
If the work needed to make a module "themeable" is too high, then module developers simply won't bother. DX and TX are intricately linked, in part because Themers are a brand of developer.
I agree about improving life for themers. We absolutely need to. But not at the cost of adding epicycles of complexity to a system that is already, I would argue, too difficult to work with not just for themers but for everyone else, too.
A themer is...
A themer as a distinct role is somewhat unique to the Drupal ecosystem. They work with HTML, CSS, JS, and PHP to build markup, style it, make it do interesting or dynamic stuff, and override Drupal's behavior using theme and preprocess hooks. A themer works with the entirety of Drupal's presentation (i.e., theme) layer. In the broader world, a Drupal themer is largely a "front-end developer," though not at the exclusion of being a "designer."
This is different from a "designer" in that a themer may not necessarily be involved in creating the look/feel of a site, its IA, or UX concerns. They are often handed a design and IA from someone else and expected to know enough about Drupal's rather complicated and technical presentation layer to turn it into a real site.
I expect others to disagree with this definition, mainly because we tend to define roles based on our processes. If a Drupal shop has people that do both look/feel/IA/UX as well as building a Drupal theme, then they're simply "designers"; if a firm divides responsibilities between look/feel and implementation in all its forms, then the theming responsibilities fall to developers who, I think it's fair to assume, would rather not be dealing with HTML and CSS.
Drupal's presentation layer is sufficiently complex that it requires clusters of skills ofter associated with both designers and developers.
I offered this definition to several people at Drupal Design Camp Boston this week, and the response was pretty clear: There are people who identify as "themers" as opposed to strictly designers or developers. To fully describe their abilities, they called themselves both designers and themers or themers and developers.
The point here, however, is not to file people away into categories. Rather, Drupal's theme layer could be a better experience -- for everyone. "Themer experience" simply means a better experience for everyone working with the theme. This means documented, repeatable design patterns, as well as a library of elements that can be invoked by developers and themers. Can we agree, for example, that rebuilding AJAX lookup indicators for each module is duplicated effort that yields inconsistent results?
Does this overlap with design and UX? Sure. Module development? Absolutely. Writing a Drupal theme requires a broad skill set. A themer experience initiative, therefore, will require working with all the other Drupal initiatives to create a better platform.
Todd Ross Nienkerk
Digital Strategist and Partner
Four Kitchens: Big ideas for the web
IRC: toddross
Hooks
Todd,
I like your definition. Although I am fairly new to Drupal, themer is the closest tag I would hang on myself. The areas that I need to become more acquainted with are the ability to "override Drupal's behavior using theme and preprocess hooks".
Is there a good source to educate myself in how to take on these themer tasks?
Thanks,
Dan
The point here, however, is
Thank you! Exactly my thoughts. I never liked the label but I've only used it because it's easier than the person who happens to be working with themes. It's a process and we must improve it on all levels. It might be more productive if each DTX problem is labeled with an experience level and make sure themers of all levels are accounted for.
Right on
Yes, that sounds like a very good idea, and pretty much exactly the type of thing I was driving at. Thank-you.
DTX FTW
Huge +1, Todd. I've been thinking about this a lot lately, am very interested to contribute.
Sorry I missed d4d this year, but will stay tuned. :)
1) This might be a
1) This might be a perspective thing or not, I don't have a computer science background so take this for whatever its worth. I don't care how many layers of abstractions there are as long as it's predictable and the complexity is properly managed. Most will not have to know of the details, only the rules. What kills me is when those rules have holes and exceptions forcing me to read through the underlying code so I don't fall into those holes.
2) This would help rapid development more than anything. This isn't about HTML purist, it's about consistency. Doing less with potential for greater change.
3) I think it's too early to say if it'll be more difficult for module dev. It depends on how it's implemented. Who knows, we may end up making it easier but it's too early to know but an important consideration.
Although this focuses on CSS,
Although this focuses on CSS, there's something that can be taken here when applying a design library in Drupal.
Drupal never really had an ideal "best practice" in terms of output/styles but even if we did, the outcome would still be the same, "a spaghetti tangle of duplication and unpredictability". There are simply too many parties involved so when you leave the markup and CSS open ended leaving it up to each module implementing some "theming hook" duplication and unpredictability will be the rule. There's no way around this.
Think about how many implementations we have in displaying each chunk of a theming hook. The intent and how it's being displayed is far less than the number of the hook implementations. What I'd love to have is the ability to modify a few and have it apply across many iterations. Form API had the right idea as Todd mentioned.
This is what got me thinking about it. Never did anything about it. Only thinking on and off of its practicality in the Drupal echo system. (Object Oriented CSS video on YDN)
Again, Nicole Sullivan (@stubbornells) focuses on CSS but it makes sense when applying it to theming hooks and creating some abstractions.
A few things to think about, (a few of these fall inline with what Todd already posted):
My problems with the
My problems with the experience of being a themer is not that I feel frustrated that I can't do more stuff. Don't get me wrong I like the having things like hook_page_alter and I like being able to do more things. These things do improve my experience. They don't, however, address my biggest frustration (which dvessel outlined above) which is that I often feel powerless to prevent themes becoming "a spaghetti tangle of duplication and unpredictability".
The idea of overriding data that comes from modules does sound appealing but I worry that it would just result in an even great fudge where you have js and css being overridden in something like template.php. I would want to hear more about what a 'library' (as in 'move markup and CSS to libraries') might look like as I can not picture how this would work in practice.
I like a lot of the small (small not in the sense of inconsequential but in the sense of tweaks) things that dvessel has done in Hexagon (). Things like, for example, having vars.inc files where you are linking preprocess functions to relevant template files make it a lot easier to navigate around and figure out how things work.
@eoriordan, I'd like to post
@eoriordan, I'd like to post a clear example but to be honest there are still gaps and possible problems that's been mentioned. I'll try to provide a clear example of how theming would be affected as it becomes more clear to me.
...
Just a quick shout out for Themes should support dependencies.
...
If we are talking about DTX and in the same breath talk about hooks in the theme layer, hook_page_alter() and, to an extent, granular theming then IMO we are not talking about DTX, we are talking about programming and the DX (developer experience). I think this is an enormously important distinction to make - Crell is really hitting the nail on the head when he separates out the CSS and HTML designers and programmers.
I need to absorb and think more about the things being presented here before making comments, but I wanted to reiterate what Crell is saying because its very important to stop relying on this "themer" persona. We need to break it down and think about CSS and HTML designers, and programmers as separate personae.
Themers and arrays
chx's blog post, I think, touched on this as well. As of D7, we've defined "themer" as "an HTML/CSS guru who lives in render arrays." All six people in the world that applies to probably love it, but for everyone else it just makes life harder. :-)
I think this particular topic
I think this particular topic goes even further than just a distinction of "roles" and what people can do with specific experience/knowledge.
It's one thing to introduce what is quite possibly a massively improved theming system, it's another to expect people to be able use it. The biggest factor I can see wrong with the D7 theming system is that there is very little by way of understanding 1) what has changed, 2) how to use the new features 3) where to find more info...
It's weird that usability was a high priority during D7 development yet the end result is more complicated. Sure you can do more... IF you can find out how.
I wrote a rambling ponderous blog post earlier today (which I won't post here cos it would look spammy), but it touches on this topic and more. If you want to track it down it's on my site.
Dreamleaf Media
+1
I'd like to +1 dreamleaf's reminder that this topic is not about the definition of roles. Rather, the idea is to improve the experience of working with the theme layer.
Todd Ross Nienkerk
Digital Strategist and Partner
Four Kitchens: Big ideas for the web
IRC: toddross
...
Please see my reply above regarding the "themer" role.
IMO, lumping people into "HTML/CSS" and "everything else" camps doesn't reflect reality. People who work with Drupal themes use HTML, CSS, JS, and PHP. I've never built a Drupal theme without having to deal with hooks, custom modules to handle output before it's locked down and unchangeable in the theme layer, and other stuff typically associated with the "programmer" role.
Todd Ross Nienkerk
Digital Strategist and Partner
Four Kitchens: Big ideas for the web
IRC: toddross
Omega.
The Omega Theme + dynamic Theming. Based on the 960gs. + HTML5 seems like the biggest D7 leap forwards.
At the end of the day, these templates all have their pros and cons.
But consider Theming with the economics in mind.
If a base theme gives you a more efficient Theming process, why re-invent the wheel. However, as with the spirit of most features of Drupal, it tries not close doors.
Check out the development of the D5 + 6 Theme templates and you can see the evolution.
Contrib. themes usually address a group of needs and can be re purposed to serve others. Bare bones themes give you an efficiency by presenting a range of ready made components that are easily moulded to fit your purposes, whereas there are more specific themes for more specific needs.
Have a look at OpenPublish for an example.
I really think that the ecology of contrib. themes can show you the diversity of demand for different designs and methodologies. At which point a lot of these arguments become moot. Documentation varies equally along with demand for it and the end user of each Theme. If you're looking for something documented down to the very last minutiae then you will have to compromise on use.
If youre looking for something that can be bent to fit a specific need, more knowledge and understanding will be required.
In the wider Drupal Ecosystem, this is what Drupal Gardens represents, or in the world of Wordpress what .wordpress sites address.
The current overhaul of the Drupal Documentation has been a mamoth task and KUDOS! to all who have undertaken it. But it can never serve all of the interests that rely upon it. The best it can (and to some extent has done) is address the different levels of knowledge. E.g. Here's an overview, here's an explanation of the code, here's an explanation of the install and here's an example of its operation.
What I suppose I'm trying to say is that Drupal is a Free Market. Supply is dictated by demand and the benefit delivered by each component. Its not a command economy, where one niche group can demand an action and expect it to be put into effect. Finally Drupal, like wikipedia is on the face of it open and hugely collaborative, but ultimately relies on a small and semi-hierarchical (although with some non-hegemonic structure within the tiers) to ensure that it operates.
For instance the people who design one theme may not be aware of another Team developing a similar Theme. There is no requirement that one body ceases work on their Theme or collaborate (although this happens a lot) e.g. the WYSIWYG module covering all the WYSISWYG formats.
So shown your demand. Download these theses, Contribute back and you can help steer this giant sprawling market that is Drupal. There is wisdom in the crowd as it responds to market information and demand.
The other aspect to consider is what the market leaders do, and what they give back. What direction they push Drupal in. So watch the Aquia stuff, Phase 2, etc. Their size and the scope of their work, their investment and stake in Drupal's overall success means they are much more prone to contribute and as much react to Drupal Development as they are to try to steer Drupal towards a better product.
I hope this isn't too off topic. But a lot of what has been said seems not to take account of the open marketplace that is Drupal. There are some good valid points in this thread, but in this context, I hope I have been able to touch upon some the reasoning behind why some of these issues exist.
http://www.alltooeasy.co.uk
...
I agree that base themes can improve themer experience by reducing workload and providing a common starting point, much like frameworks (960.gs, jQuery, etc.) do. Thank you for identifying base themes as an agenda item.
However, I don't really understand the rest of your post. If it relates directly to improving themer experience -- i.e., making it easier to handle markup/UI in modules and build themes in Drupal -- please clarify.
Todd Ross Nienkerk
Digital Strategist and Partner
Four Kitchens: Big ideas for the web
IRC: toddross
The state of the Drupal Theme Ecosystem.
Basically my point is that the Drupal Market and Community isn't governed.
Its a common issue of Free Markets in any number of other contexts, including the wider design world. Think about Apple, Microsoft, Google Android, etc.
This intersection of Technology and Design in an Open Source community is an issue to do with a lack of overall direction. Its it's strength and weakness.
So what happens is we get multiple Themes and Base Themes. Each with a different approach and increasingly tied to certain modules and certain coding practices. Each promises a different efficiency.
But there is no overall guidance for this. Its a competitive market. Each Theme designed for use as a contrib. Theme has an agenda and the developers behind it want it to succeed. So its a competitive space. They want to convert you to their way (maybe so you can contibute, etc - the incentives and motivations vary hugely).
My point I suppose, is that the market is competitive and adoption and uptake then swings the community in a certain direction. Its a bit like picking a horse in a race, its a punt. We've used plenty of Themes that died a quiet death, aren't/won't be updated to 7 and or have evolved but perhaps not in direction that suits us.
Each requires a different approach, simply because the Theme layer is very rarely treated in the same way. Or its use is done differently. Just look at the range of modules, let alone methodologies for theme development.
This has evolved out of "the market". A demand was there to do it in one way and that demand was met. E.g. Views? Is this not a principle tool/consideration of Theming and UX? (Which is not to say a D7 site can be made without it, but it addresses a need and therefore makes some other approaches/modules/methodologies redundant IMHO).
I think my point is that Theming is a very artificial term. Its not just design. Its not backend coding? It sits somewhere accross discplines. So the pursuit of "one" Theme to address all needs, so Jquery, 960.gs, HTML 5 features, won't emerge without engagement and demand from the market and if they do, they will be made for a specific purpose e.g. A Theme Template or Base Theme that addresses a demand, that by releasing as Contrib will then be pushed forward by the community.
However these changes won't be packaged back into Core or possibly into a module or theme unless the demand can justify the costs of time in doing so. IMHO unless one of the key stakeholders (*E.g. Aquia's core team contributions towards the new D7 UI. or a development house needs a better Theming Template) wants it to.
So each build is seperate, but there are common elements. I think trying to get people to pick a horse/Theme and stick with it helps to drive forwards these sets of development. E.g. a good set of themes, and a good set of installation profiles emerge, with a range of methodologies.
But this will only happen in the way that your discussing if there is enough demand (so downloads and use of a particular Theme, Module, etc). At which point you get a sub-group of people on Drupal who have a vested interest in making their Theme/Installation profile as good as it can be. So I believe that in encouraging this, your ideas for better themer experience are more likely to come about.
Support your module and Theme developers in the market and you will see a better ROI for your time as a Themer, have a higher probability of influencing the direction of development and ultimately reap the benefits of a more efficient Theme development experience.
Sorry its long, I hope that explains it better?
John
http://www.alltooeasy.co.uk
However these changes won't
I disagree. Changes are made to core (and contrib) when people do the work, submit the patches, and those patches are accepted by the maintainers. It's not simply a cost-benefit analysis. Those who contribute work to open-source projects are motivated by a mix of market forces, the need to self-promote and advertise skill, and a deep desire to contribute to something larger than anything they alone could accomplish.
I think we're getting off-topic here. This isn't a discussion about the economics of theme development -- it's about how to make theming a better experience for everyone. Those who want to contribute to this effort will do so according to whatever mix of motivations propel them.
Todd Ross Nienkerk
Digital Strategist and Partner
Four Kitchens: Big ideas for the web
IRC: toddross
"key stakeholders"
This is open source. There is no "they" there is only "us."
The fact that you assume there is a group of illuminati-eqsue "key stakeholders" and there's nothing you can do about it is a sad circumstance. You're basically saying "demand works...except in core." I'd like to remark that you are as potentially as much a part of contributing Drupal core as anyone else.
Additionally, your posts seem to claim contrib will save us and it doesn't matter what core does. Suppose core theme layer gets more abstract while we don't participate and sit on the sidelines. Do you want more layers upon the already confusing maze of render(), overrides, preprocess, and alter hooks?
While it has been shown in the past that good ideas from contrib will eventually find their way to Drupal core, the current discussion is a much deeper level than simply features and functionality contrib can provide, since we're talking about the underlying way we approach theming in Drupal.
It's not about redesigining the wheel. We need to redesign the car. Each of us has the potential to do so.
The tempest
I've been following this feedback, and decided to jump right in.
I think the term "themer" has been over-used (and abused) that clients/workers no longer tend to care. With designing and coding put into the equation, it's tough to define what a themer really does.
Quite frankly in my recent projects people hire me to "theme" a site... and then somewhere in the middle I (often) find myself being asked to execute tasks that doesn't really fall into the "theming" category. — which is okay and is a valid burden to carry for your average Drupal guy.
HTML / CSS / JS? — Fine, find a themer.
UI / User-experience? — I tell clients to hire a "front-end developer" to work alongside their themers, site-builders, and designers.
So I guess I'm just wondering... how does the founder (and active committers) of Drupal call it these days? Somehow this discussion reminds me of Steven Wittens during the long lost Garland era. Did day have the term 'themer' back in the day?
Again pardon me if my thoughts are irrelevant (troll alert!). I needed to put my ramblings about DTX / D4D in a safe spot.
Marckee for Short
...
I agree with you marcobinsone, and with comment http://groups.drupal.org/node/157999#comment-530944
Being a Drupal themer for most projects involves a broad range of skills - html, css, js and php for sure. On most projects, custom modules are often required to "theme" output and the interface in one way or the other. In most cases when hired as a drupal "themer" I end up having to be a "developer" as well, but I think it's unavoidable.
Let's not forget the context of this whole conversation. Drupal sites are dynamic and complex. I don't think there is a way to get around a themer wearing many hats and needing a broad range of skills. There may be ways to make the theming "experience" more friendly, but it's never going to be able to erase the need for a themer to know php and javascript as well as html/css. Even with modules like contemplate, one is most likely still going to have to create some php logic sooner or later.
I have heard Dries speak to the fact Drupal has no intention of being backwards compatible with major releases, but I really do feel like keeping the theme system backwards compatible moving forward would be a major improvement. As has been mentioned, D7 seems to have made theming even more complicated, and has required D6 themers to spend a good amount of hours pouring over changes. Not being backwards compatible may allow Drupal to "rewrite the book" so to speak, and improve performance and code, but do the new features outweigh having themers take a few steps backwards every major release? Sometimes consistency goes a long way in building a strong community.
Working list added
I've added a working list of tasks/improvements to the bottom of the original post.
Todd Ross Nienkerk
Digital Strategist and Partner
Four Kitchens: Big ideas for the web
IRC: toddross
Great post. I'm happy to see
Great post. I'm happy to see it and most of the replies. We have some big and hard problems we need to solve here, and there are some really good points and ideas being put forth in this post. Of course there is no way to remove markup from core, but I don't think that's what's really being pushed for here.
I think we are all a little burnt out and fed up with all the inconsistencies and spaghetti code, and are crying out for help. Personally, I think the single biggest problem is the lack of consistency that exists for every single task a themer has to perform over the course of creating a theme. Who knew it was possible, but D7 brought even more ways to accomplish the same thing. This is the wrong direction to move in, and I think we all know it.
I agree completely with this. Lots of people that work with Drupal themes complain about the markup. We've all heard this for years. Of course this is a justified complaint, and it's definitely worth making Drupal's markup and CSS the best it possibly can be. However, even if we succeed at making the markup and CSS pristine, we're still left with some major problems, some of which have been outlined by Todd and dvessel in this post.
I don't know if the proposed approach is the best way to go about this or not. It sounds good, but a UI component library will likely not work for all cases, so there is definitely a risk of adding more complexity/inconsistency. I agree that we definitely need to be sure whatever we do is a win for developers and themers, or we'll shoot ourselves in the foot.
@dvessel's example about how it's a common occurrence to have a title and body, but sometimes it will simply be an image, is what I worry about most with this. What will the data structure will look like? How much PHP will we need to know to change it? It strikes me that it will be more like what developers do now in pre render functions, and that is way harder for most people to work with than what we generally have now. The only way I'd feel good about this is if it's available via a fully featured, extensible UI, and there's no reason that I'll ever have to go back to code to manipulate data structure because it's something the UI doesn't allow or do well enough. If something like this were to be done half ass, we'd be in trouble.
I do know that we need to do something and I completely agree with the "Working list of ways to improve themer experience (updated 2011-06-27)" in the OP. We did some work along these lines in Drupal 7. theme_exposed_filters() was created to replaced some horrendous code in a couple of places, and we really tried to do an epic CSS clean up that completely separated the CSS for autocomplete, collapsible fieldsets, progress bars, tabledrag and resizable textareas. The idea was to move the JS files too and effectively make these all standalone libraries, but it was too late. The point is that there's a decent amount of things we can do without radical changes to the theme system, and this is one of them.
This is easily the best definition of what a "themer" is that I've seen to date. Is there a handbook page for this? LOL. Maybe it would be a good idea to create one and let it evolve, since we are constantly having this discussion.
Themer Hogwarts
I agree to @jacine especially the last paragraph. Now if only we can (drum roll please)
... queue the Themer's wishlist.
I'm pretty sure 'Drupal theming for Dummies' will be in the TOP 10. Mine would be: re-usable theming kit.
What's #1 in your themer's wishlist?
Marckee for Short
Two Sense
I been lending an ear to this conversation and would like to offer up some thoughts:
That is a great definition of a Themer. Personally, I have dropped the use of "Themer" in favor of Front-End Developer because I really am manipulating the information design.
In terms os Spaghetti code, I love drupal_render ... and would like to see that extended. However, instead of a theme_wrapper or a prefix / suffix solution, it would be beneficial for drupal_render to look for a #attributes and process them accordingly. Or a #formatter like "html5" or "mobile" that would process the data accordingly.
I often find myself (in Drupal 7) being frustrated at the inconsistencies - if I do this like this, why is it like that here, this makes no sense.
Having values in their raw state until late as possible is a great thing ... except when a developer replaces that value with a markup.
The structure are already in place - I think that we just have to narrow it down to a unified solution. As William Gibson said, "The future is here; it's just unevenly distributed."
Love is a general term for a broad range of emotions :)
Seems to me you are saying you like the idea of render(), but in practice you think it should have a better implementation. If so, I agree. Abstraction isn't necessarily Wrong™ but at some point we must implement these abstractions in a sensible way.
The structure are already in
Indeed! I really, really dislike the way the theme function does the same thing in multiple ways. Render element vs. variables? Hook suggestion from a theme call vs. setting in preprocess? All the possible combinations and predicting the outcome == PITA!
I didn't make this connection earlier but look at hook_element_info(). The docs only mention forms but it applies to all render arrays. What if a simple type change automatically guarantees the data is valid for the UI element. Not sure how ATM. heh. Thinking it's possible for some reason. Need to look into all the API's to get the whole picture.
Yep
I think it's possible too and it could be really awesome. I definitely don't want to worry about massaging data in arrays to use one UI element over another, whether it's in a theme function or whatever else.
Issue tag
I just marked the first issue with d8dtx!
http://drupal.org/node/474004
http://drupal.org/project/issues/search/drupal?issue_tags=d8dtx
Cool
Any reason not to simply use "dtx" instead of "d8dtx" since Drupal 8 is implied in the version field and the tag could lose meaning if issues are backported? Just a thought.
Same kind of discussion is
Same kind of discussion is going on in http://drupal.org/node/1499460. Round up the themer voices! We need your input there!