Core template conversion methodology - cart before the horse?

We encourage users to post events happening in the community to the community events group on https://www.drupal.org.
Jeff Burnz's picture

The way we have been approaching changes to core templates has, at least afaict, been a piecemeal affair - we change one or two templates at a time working through the various markup issues until such time as we have some broad consensus and ta da, here's our new template.

This bottom-up-esque methodology seems reasonable because we we are not overhauling the entire system at any one time and are just looking to adjust or tweak parts of it.

I think this has worked OK in the past, however I tend to think this methodology has a few drawbacks.

  1. It makes systems thinking harder. While we are always looking over our shoulder at the entire markup system, this gets very hard when in the thick of the day to day grind of getting shit done in the issue queues.

  2. It suffers from bikesheditis, and not just once, but often repeatedly. Building consensus is hard and tiring. You know the deal, right?

  3. Enter HTML5 - now we really are overhauling the entire system - time for a rethink?

HTML5 ushers in a whole raft of new semantic elements, not least of which are the new sectioning elements and a new way of using heading levels. It is critical to think at the system level when introducing new sections and headings - no one template outputs the entire document, so we must consider the template stack and how they affect the outline and overall structure of the document.

I recently created a whole bunch of issues to deal with converting our core markup to HTML5. I've actually done this myself at least 3 times already, and to my mind this bottom-up approach is going to be a long winded affair that may not yield us optimal results. Tbh I am not 100% happy with any of my previous attempts and here's why:

  1. There are too many templates.
  2. There are many inconsistencies.
  3. Building from the bottom up can obfuscate breakages in the grand scheme.

Let me explain this third point a little more - its very easy to build one template, iterate it until you consider it perfect and consider it done. In XHTML this approach sort of worked because we only had to think about a few heading levels. In HTML5 we have think about what each section means and on top of that apply a whole new set of rules to our heading levels, and of course wrangle implicit sections.

OK, so before this becomes an essay/brain-dump I have a few ideas on how we might be able to do a better job of this whole HTML5 conversion thing.

  • First I want to propose that we hold off on the tpl conversions and in the first instance build our ideal document structures in HTML only. No Drupal, no templates, no theme functions - just strait out HTML wireframes. We'll need to build a lot of these because there is no one structure, however many of us will have a pretty good idea of what these will look like most of the time.

  • Once we have our "ideal structures" in place we start breaking them down into their component parts and actually rethink what these are. I'm not saying we should tear the entire system apart, just rethink how and why we are doing things - maybe there are better ways.

  • Never iterate a component in isolation from the overall structure.

  • Look for ways to ensure the structure always matches our ideal notions of a good outline.

  • entity.tpl.php

At the end of the day what I am hoping to do is streamline our markup conversion process, to avoid as many bikesheds as possible and end up with a more robust set of templates. Thoughts?

Comments

I was wondering how we would

psynaptic's picture

I was wondering how we would solve this problem and, like you alude to in your post, we're not really solving it, rather trying to wrangle what we have to fit what we need (do we even know clearly what we need yet?)

We could get a few quick wins towards this that wouldn't get in the way:

  • Remove hardcoded titles from all template files and put them in hook_*_view functions instead, with their own theme_heading theme hook.
  • Move everything into the main $content render array.
  • Standardize the templates as much as possible which IMO will result in a vast reduction in template files.

Then we need to figure out the way to control the heading levels and dynamic tags in the render arrays for particular displays.

Thoughts?

Right on - pretty much in my

Jeff Burnz's picture

Right on - pretty much in my vein of thinking. What I am toying about with atm is an entity.tpl.php, so no more node, comment, user profile and block templates (assuming some sort of block entity in D8) - so yes, this really demands an "everything is a field" idea and pushing everything out through $content. Love to hear some feedback on this particular concept.

Can you elaborate on the

dreamleaf's picture

Can you elaborate on the practicality of how this would help? Not saying it's a wrong idea, more that I don't understand what it is - but I want to :D

One thing from the D7 changes that annoys me is having to unset something from the content variable to then output it elsewhere, if that's the theory behind putting everything in $content then there could be a lot of unsetting to get a non-standard layout. The other thing about this is when you want to include something "elsewhere" you also have to have another line of code to break it free, rather than just printing it out.

Well, you would still have

Jeff Burnz's picture

Well, you would still have full access to the data structure in $content, so it would really be no different to how it is now.

In terms of what could be good about it - lets say we have a UI for setting the wrapper element, we'd need to do that in each entity template, but if we only have one... think that this template will probably look something like this:

<<?php print $element; ?> class="<?php print $classes; ?>"<?php print $attributes; ?>>
  <?php print render($content); ?>
</<?php print $element; ?>>

So, you're probably going to be theming at the field template level more, or breaking up $content to move around bits of content and/or bits of fields. The UI and options for display of fields could get a lot better in D8 also.

Consistency and

c4rl's picture

Consistency and standardization are worthy goals, but I am concerned about abstraction. Drupal 7 upped the learning curve for theming rather significantly for newcomers in this regard.

Your template code example above actually doesn't contain any tags. Will newcomers to Drupal (and possibly PHP) look at the above code in entity.tpl.php and know what to do with it? Or know what the implications are of changing "$element" to "div?"

Is this simply an issue with having proper documentation? I'm honestly not certain. And Drupal historically hasn't been a treasure chest of documentation.

The remark about "systems thinking" is applicable. I would hope that better solutions are also clearer solutions.

I've just been silently

scotwith1t's picture

I've just been silently following this discussion as a relative newcomer to HTML5 (while not new to Drupal theming)...I think you're on to something with starting with plain HTML wireframes. I even thought, while reading your post, that making a full page layout, not broken into page, node, block, etc. might make the overall structure needed for each piece more evident. Again, I'm new to this whole process, especially in how it relates to/affects core development, new theme functions, etc., but would like to contribute and learn more about HTML5 in the process. Thanks for all you're doing!

would it make sense

jessebeach's picture

Would it make sense to work exclusively in the theming layer to start, as a means to produce the ideal HTML output? Then we could port the repeatable bits back to core and remove the responsibility of rendering from the theme.

I think we need a core theme sandbox where we can work through what it means to build an HTML5 theme in Drupal now. There's a lot of good work already in the pipeline to draw from e.g. html5_base and boron.

I started a sandbox theme for this purpose. http://drupal.org/sandbox/jessebeach/1208838

I think it's a really good

dodorama's picture

I think it's a really good idea to start from the HTML and then go back to templates. And I believe it would be helpful to come out with a tentative html structure ASAP (taking into considerations all drupal elements) that could evebtually be used as a base for the design submissions (http://drupal.org/node/1205044#comment-4721906)

Jeff, I think this is a

Sheldon_Parnes's picture

Jeff, I think this is a really important discussion to have right at the beginning. It looks jensimmons has been very actively working the HTML5 issues. It might be good just to take a look at the issues they are facing and classify them as trivial (replace this string with that), minor (affects only one function or file), structural (affects multiple files), deadly (functionality is incompatible with current architecture). If you've got anything in the deadly category you might as well start thinking about what the new architecture needs to look like. Otherwise, you might want to get a hold of the current structural issues and decide whether any additional complexity will finally push the current architecture over the edge and make it to unwieldy to function.

I was going to write a post

Jacine's picture

I was going to write a post about what I'd like to see during this process, but there are already 3 similar posts including this one, all working towards the same goals, so I'll just comment here with my 2 cents, instead of fracturing the discussion more.

It makes systems thinking harder. While we are always looking over our shoulder at the entire markup system, this gets very hard when in the thick of the day to day grind of getting shit done in the issue queues.

This comes with the territory. It not easy, but it's not rocket science either. It's very much the nature of the theming system, and probably Drupal in general, that small changes can have big consequences both negative and positive.

This is something I'm convinced we can teach people as part of the patching and reviewing process, but that shouldn't be an overarching concern for the average contributor when trying to figure out what markup is the best for a given piece of output. On some level, I think we are really overcomplicating what needs to happen, and that will cause us to loose otherwise perfectly willing and able contributors. I don't want to see that happen.

It suffers from bikesheditis, and not just once, but often repeatedly. Building consensus is hard and tiring. You know the deal, right?

I fail to see how creating a pure HTML version of a template first is going to solve/lessen the bikeshedding problem. At some point it will enter the normal review process and the bikeshedding risks are exactly the same. Bikeshedding is, unfortunately, part of the process sometimes. I think the best way to combat this is to do things in smaller, focused issues.

First I want to propose that we hold off on the tpl conversions and in the first instance build our ideal document structures in HTML only. No Drupal, no templates, no theme functions - just strait out HTML wireframes. We'll need to build a lot of these because there is no one structure, however many of us will have a pretty good idea of what these will look like most of the time.

I'm not convinced that creating static HTML templates will be helpful in practice as part of the process. If it helps some people to do this while working on a patch, then by all means they should do whatever works for them, but generally I think this is unnecessary and in some cases it could end up being a complete and utter waste of time. The last thing we need is for people to become more frustrated with the process. I'm also not at all convinced that we have the time or resources to even attempt something like this.

  1. There are too many templates.
  2. There are many inconsistencies.

These are 2 huge problems areas that I'm confident that we can make great strides towards improving. I think that we'd be better off taking inventory of what we have in the theme system and determining what we want to concentrate on for analyzation and improvement. Some of the things I think we should concentrate on include:

<ol>
  <li><h4>Major templates for entities</h4>
    <p>The most commonly edited template files like node.tpl.php, block.tpl.php, and comment.tpl.php share a lot of common characteristics. Their markup  is very similar, and so are their variables.  We can do better standardizing the variables, i.e. $title instead of $block-&gt;title and things like that. And yes, it's quite possible that they'll all be combined into one entity.tpl.php, like you mentioned.</p>
  </li>
  <li><h4>Generic theme functions</h4>
    <p>We have a good deal of generic theme functions for lists, pagers, more links, usernames, feed icons, etc.  However, they need work in order to be more useful across the board and we also need some more of them. There are some great ideas that are related to this <a href="http://groups.drupal.org/node/157999">here</a>. Some of them need to be made more generic, some of them need better documentation and others are fine &mdash; their use needs to be encouraged instead of always creating new random theme functions or variables, which brings me to...</li>
  <li><h4>Totally useless theme functions and templates</h4>
    <p>As much as I appreciate the thought behind making them, they are just not needed in so many cases.  All they do is promote inconsistency and add clutter to an already complicated theme system. The process of throwing these out will help us achieve progress with #2.  Here's a few examples that illustrate why I think this:</p>
    <dl>
      <dt><a href="http://api.drupal.org/api/function/theme_book_title_link/7">theme_book_title_link()</a></dt>
      <dd>Seriously?  Yep.  We have a theme function that makes a block title a link. Clearly this indicates a lack of functionality in block.tpl.php that's needed and should be addressed.</dd>
      <dt><a href="http://api.drupal.org/api/function/theme_task_list/7">theme_task_list()</a></dt>
      <dd>Clearly a task for theme_item_list(). If for whatever reason what's happening here isn't possible with theme_item_list(), then it should be extended or fixed.</dd>
      <dt><a href="http://api.drupal.org/api/function/theme_task_list/7">theme_filter_tips_more_info()</a></dt>
      <dd>Yep. Another theme function for a simple &amp;lt;p&amp;gt; with a link inside.</dd>
      <dt><a href="http://api.drupal.org/api/drupal/modules--forum--forum-submitted.tpl.php/7/source">forum-submitted.tpl.php</a></dt>
      <dd>There's no reason at all to add another layer of complexity here. There's a <a href="http://api.drupal.org/api/drupal/modules--forum--forum.module/function/template_preprocess_forum_list/7">preprocess function</a> that could just add this one liner in place instead of calling another theme function to do it.</dd>
    </dl>
    <p>I could go on... but you get the gist. There is zero reason that any of these should stick around IMO, and it's things like this that we should be looking for to stop the bleeding. We can supply theme hook suggestion variations and that will allow the exact same level of functionality, and a much cleaner implementation.  If we were to just do straight HTML versions of templates, we could easily miss this sort of thing.</p>
    </li>
    <li><h4>Some templates are broken down too far</h4>
      <p>The aggregator, profile and forum modules contain prime examples of this. No one cares about just one piece of the user profile like that, and having it all split up makes it 10 times harder to grok. The prospect of fixing those make me want to cry. These need to be brought up to date and back to reality in as few templates as humanly possible.</p>
   </li>
</ol>
  1. Building from the bottom up can obfuscate breakages in the grand scheme.

I see what you're saying to a point, but we can never really rely on a "grand scheme." We can't guarantee how content will be structured, or how it will be used for the most part. We can make educated guesses and try to develop for the majority of uses cases, which I think we try to do. I don't mean to sound like a broken record here, but I just don't see how starting with static HTML versions will help solve this either. We will need to do some work in order to ensure content is properly sectioned, but we may not be able to get it 100% perfect for all use cases, and I think that's okay.

I think there's also a lot of uncertainty and also some misunderstanding of how other initiatives like the WSCCI will affect the HTML5 Initiative. While the work being done there will have an effect on what we do, it will mostly be at the wrapper level. It's not going to change how we structure what's inside these templates a whole lot, if at all, and IMO we simply cannot just wait around for what's coming on that front. If we do, we'll be in deep trouble. We've already got 98 issues tagged HTML5 and there will be plenty more to come. In short, if we don't get moving soon, there's a very real possibility that we won't accomplish our goals.

Having all the templates and CSS files as issues for people to get started is great, but we need to provide people with more direction than "Convert X.tpl.php to HTML5" and "Clean up X CSS" because that's not ALL we are looking to accomplish here. Luckily issues summaries have rolled out, so it doesn't matter what the OP says - we can build on it.

nice!

catch's picture

I don't have much stake in the actual markup, but just a massive +1 to these:

  • small focused issues that don't lend themselves to huge over-arching bikesheds, this doesn't stop there being an overall game plan, but trying to discuss overall game plans in abstract tends to just prolong the agony. "It's easier to ask forgiveness than it is to get permission."

  • Nuking theme_book_title_link() and other stupid crap that was added in 2005 and never looked at again, that'd be so nice. Also related to http://drupal.org/node/679112

  • entity.tpl.php that would be great.

Very long and good post

Jeff Burnz's picture

Very long and good post Jacine, I've taken it all onboard.

IMO we simply cannot just wait around for what's coming on that front. If we do, we'll be in deep trouble.

After some long thinking over the past few days I came to the same conclusion last night, we can't wait - which is what I have kind of been doing, sitting on the fence and waiting, especially in regards to entity API and if it will be possible to have an entity.tpl.php (contrib Entity API module has one).

I think for now a better approach is as you outlined, which pretty much says to me worry less about the wrappers and concentrate on whats on the inside, which I think is a good approach for now, wrappers are easy to change and if we end up with configurable or dynamic wrappers well that's a whole other issue really.

For entity stuff, the more we

catch's picture

For entity stuff, the more we can centralize in the entity system to remove duplicate code from the individual entity-providing modules like node/comment/user the better. entity.tpl.php would fit great with the plans for entity_view() and similar.

There's a new 'entity system' component so best to post issues there:

http://drupal.org/project/issues/search/drupal?component%5B%5D=entity+sy...

I'm hoping this will be the first D8 entity patch - http://drupal.org/node/1018602. Once that's in we'll have a proper target to post issues against.

Jacine's 4 Part Plan.

Sheldon_Parnes's picture

A brilliant plan of attack. It looks like everything in your 4 items needs to be done regardless of what any other group is doing. What's more, there is important work to be done from the start, from the point of view of general use cases, architecture, main stream development and bug fixing. Thumbs up for Jacine. Just brilliant.

There was some discussion in

Jeff Burnz's picture

There was some discussion in IRC last night, which I mostly missed but caught up on, regarding wrappers for entity templates etc. I think there are a couple of points worth discussing here further:

  1. Abstraction and obfuscation of markup is bad for designers.
  2. Which templates should have dynamic wrappers (if any).

Abstraction and obfuscation

Lets say we have an entity template similar to what I proposed earlier which has no markup - $content is still going to hold the entire data structure, so we could have entity-[type] templates that expose that data structure in much the same was as we do now.

For example entity--node.tpl.php:

<?php
  hide
($content['picture']);
 
hide($content['title']);
 
hide($content['submitted']);
 
hide($content['comments']);
 
hide($content['links']);
?>

<article<?php print $attributes; ?>>
  <?php print render($content['picture']);; ?>
  <?php print render($content['title']);); ?>
  <?php print render($content['submitted']);); ?>
  <?php print render($content); ?>
  <?php print render($content['links']); ?>
  <?php print render($content['comments']); ?>
</div>

Sure, this still hides the markup, but its also very simple and easy to read, and power themers that want to get further inside the data structure to alter markup can do so, or we can shift paradigm and theme at the field level much more so - so variables become a way of moving things around, but to alter the markup you get into the field templates to do so.

These are possibilities, so just thinking out loud here, no need to stymy ideas right now, we're actually a bit behind in this department and need to get moving if we're thinking about rethinking these things.

An alternative approach is for theme_field to output very little markup (and be configurable from within the UI - that means label, row and top level wrapper elements) - and instead expose some markup in the entity type templates, in this case tings could look something more like this:

<?php
  hide
($content['picture']);
 
hide($content['title']);
 
hide($content['submitted']);
 
hide($content['comments']);
 
hide($content['links']);
?>

<article id="node-<?php print $node->nid; ?>" class="<?php print $classes; ?> clearfix"<?php print $attributes; ?>>

  <?php print render($content['picture']);; ?>
 
  <?php print render($title_prefix); ?>
  <?php if ($display_title): ?>
    <h1<?php print render($content['title_attributes']); ?>>
      <a href="<?php render($content['node_url']); ?>"><?php print render($content['title']); ?></a>
    </h1>
  <?php endif; ?>
  <?php print render($title_suffix); ?>
 
  <?php if ($display_submitted): ?
    <
p class="submitted"><?php print render($content['submitted']);); ?>
</p>
  <?php endif; ?>

  <div class="content"<?php print render($content_attributes); ?>>
    <?php print render($content); ?>
  </div>

  <?php print render($content['links']); ?>

  <?php print render($content['comments']); ?>

</article>

This second example is a mess, hard to read and horribly inconsistent - frankly I hate it and think we should not expose markup in this fashion, it needs more thought and a more consistent approach.

Which templates should have dynamic wrappers

Really I think we're only looking at two, maybe three templates that really would benefit from dynamic wrappers (set via the UI, with a sensible default such as DIV), and they are blocks and fields. If we had an entity.tpl.php file this could possibly have it as well.

Will blocks be entitles or just some blocks (such as "node blocks")?
theme_field - I would say its not just the wrapper in theme field but label, row and wrapper elements that needs to be dynamic.
Should we allow a template to have no wrapper (I think this could be useful), i.e. via the UI select NONE.

All other templates could have hard coded wrappers - node, comment, terms, user can have a sensible default hard coded - not really a great need here for setting this via the UI.

So, throwing some ideas out there, that is, if we want to overhaul this stuff and start rethinking things at this level - I know we have a lot of other things to cover - merging templates and cleaning up theme functions, but we could and I think should start moving to a new paradigm because the old one is not optimal.

I came here this morning to

tim.plunkett's picture

I came here this morning to post my idea from IRC last night, but I guess I don't need to anymore, as you've typed it all up for me.

Really I am just building on

Jeff Burnz's picture

Really I am just building on and clarifying http://groups.drupal.org/node/159734#comment-539984, I've expanded on this further again. I think they're all interesting ideas, how feasible they are I am not sure as yet. I certainly want to see changes in D8, the way I see it the traditional approaches are reaching an end of life.

Regarding the first

c4rl's picture

Regarding the first example:

power themers that want to get further inside the data structure to alter markup can do so

I would argue that this task of altering markup not simply relegated to the audience of power themers--on my very first Drupal site, I needed to change markup. Furthermore, this task demands knowledge of PHP data structures and knowing where to interact with the render arrays (whether in a preprocess, process, alter, or override function).

There are still a lot of moving parts. What is the template actually doing at this point? Not much (and this might be okay). What about use cases where logic needs to exist in the template--where certain markup will be affected by the presence of other variables? I don't see how render() solves this issue simply.

Regarding the second example:

This second example is a mess, hard to read and horribly inconsistent - frankly I hate it and think we should not expose markup in this fashion, it needs more thought and a more consistent approach.

I agree that this example is "a mess, hard to read, and horribly inconsistent" mostly because it convolves usage of

<?php
print render($var)
?>
with traditional
<?php
print $var
?>
. For a newcomer, however, this second example may be more approachable than the first. The newcomer can probably identify the markup as it translates to the page source. There are (slightly) less moving parts than the first example.

Practically, I'm not declaring the second example is correct by any means -- both examples need work. But the second example has less abstraction, and (in general) less abstraction is better for newcomers than more abstraction.

I think we need to be careful with "more thought and a more consistent approach" in that the thought needs to consider not simply theoretical purity and elegance but also approachability.

To use an analogy outside of Drupal itself: I'd argue that XHTML 2 was influenced standpoint of theoretical purity whereas HTML5 was influenced by approachability and practicality. We see who won that battle.

I have a blog post in the works regarding this issue that I'll share in the next week.

I think the overall question

Jeff Burnz's picture

I think the overall question I am asking here is this - will the current paradigm (theming in node, comment, block templates) continue to the "best fit" paradigm in Drupal 8.

Anyway you look at this (first vs second) the reality is that only a small amount of markup is actually being added by the entity template - that is really the problem here - that combined with the fact that its not feasible to do the complex logic required entirely within the entity template (thus expose all the markup in one place). What I am saying is - why bother? Shift paradigm, change thinking, don't rehash this debate again - lets find a better way.

A couple of very grand ideas have been proposed...

  1. UI for markup changes - this gives very easy and powerful control to designers and other low-php-skill themers.
  2. Entity templates that do nothing but output $content

Now - what if we could had a UI for breaking up the data structure? Worth thinking about - kind of like Contemplate but with drag and drop - e.g. drag bits of the structure into "entity regions" and wrap them in markup, right there, in the UI.

Afaict is that we have this huge step between CSS theming and power themers ripping apart the data structure - there is no middle ground, so I think what I am asking is how to bridge this middle ground - and probably looking for an entirely new paradigm.

The way I see it now is that our current node & comment templates attempt to be the middle ground, but are not doing a really great job at it.

I'm not being very empathic about a direction here because right now I just don't know, its early days, lets brainstorm on this a bit more.

I'm not being very empathic

c4rl's picture

I'm not being very empathic about a direction here because right now I just don't know, its early days, lets brainstorm on this a bit more.

Likewise. :)

I'm also guessing that there's not a one-size-fits-all solution here either. I'm hesitant to give any sort of validity to Contemplate. Markup doesn't belong in the DB, imho, as I've commented elsewhere.

Yeah but you're getting stuck

Jeff Burnz's picture

Yeah but you're getting stuck on this idea of saving config in the database, there will be file based config in D8 and we could write templates to the file system.

Ok, sorry about that

c4rl's picture

@Jeff Burnz I see. I haven't been following that with regard to theming, so I apologize if I made an irrelevant point. I'm a bit of a newcomer so my participation in this thread comes from a fear of the general direction of theming evolution evoked by D7. Looks like I have some catching up to do. :)

If an aim is to make this

dreamleaf's picture

If an aim is to make this simpler for the non "power themer", then the markup within templates should be limited to printing out a variable that displays something.

In my thinking...

<?php
  hide
($content['picture']);
 
hide($content['title']);
 
hide($content['submitted']);
 
hide($content['comments']);
 
hide($content['links']);
?>

...is pointless for the person theming. Sure I know what it is doing and why, but if there is a way to avoid even having it there and just focussing on output, then all the better. D6 development seemed to focus on stripping stuff out of tpls, D7 appears to be putting it back... I'd be happy if D8 says "roll it your own way".

My thought based on the mention of having a UI for this...
Just as we can now "manage fields" and "manage display" from a UI, have a variant of this system that passes the choice of splitting items out (and maybe even allowing the variables to be named) which are then recognised at a tpl level.
This could provide a really powerful user-led decision of what things are, and how they recongise them.

If you've themed a views tpl then you've already played with this granularity, same with Contemplate etc. Basicaly, if we can see each variable (ie. devel) then we should be able to dictate where it comes out.

The big plus I would see from this sort of UI, is that right from within the Drupal backend, a themer/designer/powermonger would get total control without having to touch a line of code. If the UI could also recognise new variables as they are created in the system (say when new content type is created), then all the better.

Remember, if you don't have

Jeff Burnz's picture

Remember, if you don't have those hide()'s then you're left with this (potentially in D8):

<<?php print $element; ?> class="<?php print $classes; ?>"<?php print $attributes; ?>>
  <?php print render($content); ?>
</<?php print $element; ?>>

So using hide() and render() in this way is "being nice" to new themers by exposing some of the data structure, a sort of breadcrumb trail or "easy on-ramp".

Not saying I like it, but its an idea, but then again pretty much what we are doing now, not really that much different.

That was what I meant by

dreamleaf's picture

That was what I meant by having that part handled by the UI, I can see it in my head but having a hard time finding the terminology for it!

Essentially, if from the UI you were to tell it to strip out for display everything that is in the hide array, then Drupal would process the hide statements before the tpl gets rendered. That way the variables that would then be output in the tpl are set on a page level rather than tpl level. As a thought springing from this, that may also go some way into making variables global rather than block/comment/node/page specific.

Obviously, I have no idea how to do this, but I'm confident there are people that could do it :D

Additional thought: I think what's springing all this is the thought of D8 shipping with the same stuff, just done in a different way (again). If we're gonna be radical and really say "it's easy for designers/new entrants" then it really has to be, and the current systems isn't, and I don't think an altered current system will be either.

netwarrior007's picture

Makes sense, i understood it too.

OT: Why do we still have

psynaptic's picture

OT: Why do we still have attributes hardcoded like that? We should put everything in $attributes_array.

I think the tag for the wrapper element of all templates should be dynamic. Why limit the scope?

<<?php print $tag; ?> <?php print $attributes; ?>>
  ...
</<?php print $tag; ?>>

This is not pretty but it functions the way I want all templates to function.

If we go down this route, why do we even need to have the wrappers within the templates? They could be set from the UI or in build functions in the render array. I think everything should be in the render array. Let's get rid of the odd variables we have floating around.

I like that theme_links now supports grouping of links, each having its own theme hook. Elements within the render array should be much more interchangeable. It should be possible to render an individual link from node links anywhere else in the template without having to reassign to cope with differently named properties!

I have to go now but would love to hear your thoughts on all of this.

Everything in the render

Jeff Burnz's picture

Everything in the render array is my first example above, how it gets there I am not sure - everything a field?

I'm not sure what you mean by Elements within the render array should be much more interchangeable, care to elaborate on that?

I also would like templates to be like you propose, the challenge is how to make theming easier at the same time.

Configurable UI

jessebeach's picture

I'm beginning to believe that no amount of fancy template authoring is going to make the .tpl files both simple for new Drupal themers and satisfying for power Drupal themers.

We need to bubble up common actions like defining wrapper elements, adding classes and configuring attributes to the UI level. Then we'd be able to remove tags and hard-coded elements from the template files...perhaps we could jettison most of them altogether.

I can't quite fathom yet what this UI would look like. It feels like a hulking mass lurking in deep shadows.

More UI == Simple for whom?

c4rl's picture

I believe the issue we've been circling around is audience.

The theme layer in Drupal must be leveraged by many different audiences including new themers (who may just have an HTML/CSS background and are learning PHP), developers (who don't really want to write HTML may find renderable arrays the easiest method), site builders (who just want to click buttons like they do in Views and Field UI), and experienced themers (who are familiar with HTML and preprocessors and PHP).

I think we need clearer waypoints for newcomers as well as for experienced themers. We have a one-size-fits-all system now and present waypoints are unclear since there are many different methods of achieving the same result.

You said:

We need to bubble up common actions like defining wrapper elements, adding classes and configuring attributes to the UI level. Then we'd be able to remove tags and hard-coded elements from the template files...perhaps we could jettison most of them altogether.

The idea of keeping markup in the database and pushing attributes to the UI scares me away for the following reasons:

  1. It poses some performance bottlenecks since now we'd have to query the database to get markup.
  2. It is yet another layer of abstraction (in an extremely strong sense -- no longer are we writing templates, we're clicking buttons in a UI?)
  3. As a corollary of #2, it is a crutch and devalues the skills of themers, namely writing HTML and CSS by hand.
  4. It will potentially have limitations as themes get more complicated, and themers will at some point be having to fight against the system in the same way they have to abide Field UI.
  5. For newcomers to Drupal who are familiar with traditional template building (e.g. Smarty) it will be a drastic change.
  6. Viewing source and grep'ing around to find markup will potentially become impossible.

Agreed. I've been waiting to

Jacine's picture

Agreed. I've been waiting to see what others come up with because I know this something that quite a few themers want and have asked for numerous times. However, I'm not convinced that this is the right way to go – in core – because of the following concerns, which I'll try to keep as short as possible:

How will this affect our templates?

There is markup in our templates now. What's being proposed contains no markup at all, just the shell of it. There's no question that something like this will make templates harder to grok and work with:

<<?php print $element; ?><?php print $attributes; ?>>
  <?php print render($content); ?>
</<?php print $element; ?>>

Let's think about what we do when we override templates in the first place. Being able to choose a tag isn't enough. We'll need to group content and apply classes to those groups for this to be efficient. We also get pretty granular with the content of fields, which goes way beyond a simple print render in many cases. I seriously doubt that we'd be able to get to a point where we wont need to edit templates, and exposing this to a newbie that does HTML/CSS isn't exactly ideal.

What kind of impact will this have on contrib/core themes?

If users can throw pieces of content around and alter data structure at will, then themes will have very little control. I think this will force themes into coding more general designs, and contributed themes already suffer enough in this area. Themes that try to push the envelope could literally be punished in the issue queues by users expecting things to just work, no matter what sort of configuration they apply. This could also put a huge burden on site administrators. Based on on some of the similar feedback I've gotten for Skinr, I also think the need will also arise for themes being able to ship with configuration to do the work for end users instead of saying "here's 20+ steps you need to do in order to configure your site's markup to match our demo." This is a disaster waiting to happen IMO.

How will this affect everyday configuration management?

If we do all of the markup tweaks in the DB, I have serious concerns about how this will effect our day to day tasks when working on Drupal themes. Most of the sites I work on these days do the bulk of the configuration in code. It used to be fairly easy, because it was just a quick view export here and there toward the end of the process, but now with features/context it's a lot more work. Every time a view is modified to alter the markup or change the position of a field, or a block is moved to a region or something, that change needs to be exported to code and put into version control.

It ends up doubling the time it normally would to accomplish a simple task and it's very tedious and borderline miserable when there are lots to configure. When you spend more time doing configuration crap and all you want to do is write HTML/CSS/PHP, it becomes a serious problem to say the least. I don't know how many other themers deal with this regular basis, but it's one of the things I am growing to hate more and more. Don't get me wrong, there are many benefits to having configuration in code, but the thought of having to do this for HTML tags all over the place makes me want to throw up.

How do we prevent introducing even more inconsistency?

This may seem like a no brainer for entities but what about the contents of page.tpl.php. Are we proposing to do that the same way? What about forms? There is no UI to modify regions or forms, and what about all the other random pages? Maybe WSCCI will help with this and there will be a more unified UI that this sort of change could plug into... I don't know. What I'm trying to say here is unless we do this Drupal-wide, we will no doubt be adding to the consistency and WTF problems. We'd probably also introducing new usability problems at the same time because there are different interfaces and patterns used to configure different parts of the system.

The bottom line here is that there will absolutely be trade-offs and there could be some really negative consequences here. We'd really have to take all of this into account and weigh our options carefully.

We're already to the point

Jeff Burnz's picture

We're already to the point where you cannot build highly use-case-specific themes for contrib - this does not change any of that - what is being proposed here is nothing you cannot already do in templates directly. Well, you can, but you better be ready for support requests and be a very advanced themer to account for permutations - or ship a distro underneath it, or a Drush make file.

Config management is file based in D8 (or will be), and we could write templates to the file system - is/would there be a problem doing that? I'm not sure.

The normal template override system would not go away - any UI based configuration simply layers on the existing system - just like Views, you can override any template. You would not be forced to use this, its an option - it would be a big fail if you could not.

The consistency problems need to be solved, one way or the other, agreed.

I suspect that what I am really saying is that forcing users to write code just to modify what is printed out and where is the primary mistake we are making. For example we don't ask site builders to rewrite color.inc to change their sites color scheme - we have a UI for that. So why do we ask site builders to learn advanced theming just to change what is printed out? Why do we ask them to edit PHP code at all?

The bottom line is that we have made tradeoffs already (there are always tradeoffs), and we ended up with something very hard to use, so we need to solve the very real problem that the 80% are not being catered for (and I would argue have never been catered for).

Configuration in files means

catch's picture

Configuration in files means it'd be JSON or YAML.

So markup in configuration would likely end up being something like HTML embedded in JSON or YAML (or the HTML tag name or whatever, not really sure what's being proposed).

So - you will no longer necessarily have to go to the UI, make a change, then export it - lots of people are sick of doing that so there is a strong desire to make this possible via drush and text editors. How friendly it will be to edit the files directly depends on the format chosen and how complex the specific configuration would be.

It'd be worth putting some of these ideas in the CMI group just as a potential use case for the new system.

Thanks catch!

Jacine's picture

You just cleared up a lot of confusion I had about CMI. :)

This is along the lines of

Jeff Burnz's picture

This is along the lines of what is in my head right now http://picplz.com/kRTR

I've not really stopped to think about how this would work although I appreciate that is very important to do that at some stage, right now I'm just letting the idea bubble away. Maybe its a terrible idea, I am not sure.

I just thought of a scenario that might explain this better.

Say you have an image field with 5 images in it. You could format each image with a different imagecache preset and drag them anywhere you wanted. You could potentially build a lightbox type gallery with one big image and 4 thumbnails. Like I said, I'm not really thinking about the "how would or even if this could work", just thinking out loud and banging ideas around.

Sorry for spamming this thread :)

For entities specifically,

catch's picture

For entities specifically, the latest version of display suite for 7.x has integration with panels. I haven't tried this at all, and couldn't find a link that explains it, but it adds it's own tab like manage fields and gives you drag and drop control over layouts per build-mode. swentel did that work I think.

This also ties in with the Butler phase 4 stuff that Bojhan and yoroy have been working on (configurable layouts for all pages on the site, down to individual entity level). One thing that has been nagging me with this is how that would conflict with current methods of doing that kind of thing in templates, but if there's a genuine reason not to do that in templates, then maybe that starts to be answered.

I disagree. Yes, it's

Jacine's picture

I disagree. Yes, it's challenging to build themes for contrib now, but IMO this will make the situation way worse than it is now. We are not just talking about moving fields around. We are talking about changing tags and structure all over the place, which will have a massive affect on how CSS needs to be written. Also, as I mentioned with regard to configuration, I think it will mean that themes will need to be able to ship with configuration capabilities, which seems like a nightmare, even if your are modifying files in the UI. What happens when you start tweaking your markup in one theme and then install another? Will the new themes "configuration" take over, will your changes be lost, or will this system attempt to merge things?

I suspect that what I am really saying is that forcing users to write code just to modify what is printed out and where is the primary mistake we are making. For example we don't ask site builders to rewrite color.inc to change their sites color scheme - we have a UI for that. So why do we ask site builders to learn advanced theming just to change what is printed out? Why do we ask them to edit PHP code at all?

Because this is how template systems work. A default is provided and you can decide to stick with that default or modify it. Many people don't modify anything. They'll use a core or contrib theme slap it on and call it a day. They could care less. What problem are we solving for them? Forget Drush make, and stuff along those lines. I'm talking about people new to Drupal that pick up a theme want to enable it, or make slight tweaks to it. I can't think of any system that doesn't do this, down to Tumblr. If we are trying to throw that out, let's just call it what it is. I see no point in even having PHP templates if this is how things are going to work.

From my standpoint, as initiative owner, I'd argue that this is way beyond the scope of what the HTML5 Initiative has set out to do. I realize that we are throwing out ideas here, but I don't like the state of limbo this leaves us in. I'd highly recommend those of you that are serious about pulling something like this off, post in the WSCCI and CMI groups and figure out how something like this could work and what the advantages vs. disadvantages are. I sure I can't even comprehend most of them, so I will go back to working on what I can for now. :)

jessebeach's picture

I love the conversation here. It's exactly the kind of fundmentals discussion we need to be having.

I have to agree with Jacine. This discussion shouldn't blow up the scope of the HTML5 initiative. We can complete the initiative with a bow and not touch these fundamental aspects of configurizing the theming layer.

I think dynamic tags are core

psynaptic's picture

I think dynamic tags are core to the HTML5 initiative. We need to be able to allow users to specify which tags to use for containing certain content e.g., section/article/aside/div. The context of each changes depending on the site. Having to override a ton of templates to achieve this is something I hope we can avoid for Drupal 8.

See my comments below :)

johnvsc's picture

This is why I was talking about functions / structures and build tags -> we have so many "

<

div>" declarations in core , the only way to approach no markup in core is to have a structure that allows for dynamically generating tags.

This is the precise reason I brought up the (now infamous) theme_html_tag <- which can be used to generate dynamic tags.

However flawed the potential is for nameoftheme_html_tag is -> we already have a structure that supports this option ... but it is rarely used (except in head ... correct?)

if drupal_render searched for the tag (it might, i don't know), then we might be able to use this without re-inventing the wheel.

Only a thought - as there are many ways to do this ....

I'm with you, I <3

linclark.research's picture

I'm with you, I <3 theme_html_tag for it's flexibility. However, catch isn't the only person who has brought up the performance implications. I had a discussion with Crell about it at DrupalCon Chicago and he also shivered at the performance implications of using theme_html_tag. He explained why it affects performance well but I can't remember enough of it to reiterate it coherently. It's a shame late night party conversations aren't uploaded to archive.org... something to work on for DrupalCon London ;)

While it would be cool for flexibility's sake, I don't know that we'd be able to counter the performance issues enough to make it fly.

I use a mixture of

psynaptic's picture

I use a mixture of theme_html_tag and #prefix/#suffix to move markup out of template files and into PHP code. The main problem with theme_html_tag seems to be performance. I'm using this on examiner.com and we don't even have page caching and don't see any negative performance impact. I'll need to profile this to be sure.

Maybe we can ship Drupal core with hardcoded tags and have the ability from the UI to export template files with necessary variables included. Hmm..

This conversation and what

Jacine's picture

This conversation and what has been proposed goes WAY beyond having the option to choose between 4 tags on "certain content." As far I'm concerned the only thing this remotely has to do with the HTML5 initiative is with regard to choose the wrapper markup for blocks, and still that is a not a requirement of the HTML5 initiative. It's a "nice to have."

It's core's job to provide sane defaults and allow people to customize from there. We already allow templates to be customized, and there's nothing stopping any of us from implementing HTML5 in Drupal 7, except for one issue that has to do with filter_xss_admin(), and which unfortunately no one has stepped up lately to help decide which tags should be allowed. Sure it would be nice to be able to choose these tags in the UI, but it is not, by any means a requirement for core. Getting these issues taken care of is what's within the scope of the HTML5 Initiative.

Those issues are just

psynaptic's picture

Those issues are just piecemeal tasks for changing X template to HTML. What we need in an overarching plan to solve the underlying problems. If we keep shuffling stuff around in small chunks I think we're going to miss issues in the bigger picture.

I outlined the big picture

Jacine's picture

I outlined the big picture earlier in this post. It's not just piecemeal tasks, it's a lot of changes broken up into smaller issues so that we can get it done.

I'm not telling anyone not to attempt this. I'm saying that it IS beyond the scope of what we are planning to do in the HTML5 Initiative. The changes that'd be required to pull something like this off are monumental, and frankly are beyond what the current HTML5 Initiative team are capable of (a) deciding upon and (b) implementing because these would be huge architectural issues that affect all areas of Drupal beyond templates and UI.

I re-read your post that you

psynaptic's picture

I re-read your post that you linked to (thoroughly this time) and I must say it's certainly well articulated.

I thought we were going to change Drupal's whole output layer so it could output any type of content (HTML, XML, JSON, YAML, etc.) but I suppose we don't need to as one can already do that (at least for JSON, not sure about the others) with page callbacks.

Anyway, I guess the scope of changes we're expecting to make for D8 is going to me more limited than I was expecting.

There will definitely be

Jacine's picture

There will definitely be changes. You might want to look into the WSCCI. What you're describing is outlined in Phase 3 of what they are planning on doing.

It's a little confusing, but as far as we're concerned, we've already got HTML, so we don't have to jump through any hoops in that respect. We've got to concentrate on moving what we've got to HTML5 and refactoring as much as possible during the process.

Oh yes, absolutely most of

Jeff Burnz's picture

Oh yes, absolutely most of this is way beyond the scope of HTML5 Initiative, maybe configurable wrappers are within the scope, or some sort of "smart dynamic wrapper", but as for the UI sketch I posted - that is way beyond the scope, even beyond Drupal 8, maybe Drupal 9 after some time in contrib (need to look at Display Suite way more and see what it can do). I am very much enjoying all the feedback and discussion, some really interesting stuff is flowing out.

I'm right with you

Jeff Burnz's picture

@jessebeach, I'm right with you here. I'd even go one step further and have the ability to drill into the data structure and lift bits out - imagine a Krumo like UI that allowed you to drag bits of the array into a text field - or perhaps into defined entity regions (maybe "source view" is expert mode). These "templates" would then be saved to the file system. BTW this would absolutely kick WP in the pants which has had a similar feature (edit templates in the UI) for as long as I can recall.

Interchangeable elements

psynaptic's picture

I'm not sure what you mean by Elements within the render array should be much more interchangeable, care to elaborate on that?

Say you have a link in a theme_links array. You should be able to pull out this one link and render it elsewhere in the node without having to reassign the keys. I'm talking about path vs href, text vs title, and other such inconsistent naming conventions we currently have.

Extending the Drupal Abstraction Layer

johnvsc's picture

There is a ton of great thoughts above and I have been following this thread with major happiness.

There are three ways that we can ensure that what we do in the presentation layer for Drupal 8 can set the stage for 9, 10, n

  1. Organize the $variables / render array so that it is economical and historical. The content array is the most valuable tool that we have -> because once the ordered information makes it to the theme layer -> we can do anything with it. However, much of the problems that the FEDs (Front End Developers) have is finding the information they need / can use in that array. This is all jacked up if a Dev replaces a value with markup. Even though Node object is there (recursively unavailable, Krumo always reminds you) how certain are you that you can use it / alter it. So, maybe in the $variables array there are three nested arrays "State", "Current", "Legacy": State give vital information about the present state of this array -> is it a page?, is it a node? is it something else? "Current" is the information that the drupal_render will use to actually render the content values. "Legacy" is where you put a copy of "current" if you alter it -> nested with your module name ... maybe, we can add a delta to this so that we can see a history of the values. This way, the original values are always available -> and we can see a progress of data as it was pass though the system. Also, this will give us our own "run time version control (rtvc)" so that we can pick and choose what values we can use. Remember this idea assumes that there is no markup in core :)
  2. I love the entity.tpl.php -> actually, I think that we should get down to one tpl as the base template and use a library of snippets for specific use cases. However, i have always found
    <<?php print $element; ?><?php print $attributes; ?>>
      <?php print render($content); ?>
    </<?php print $element; ?>>
    to be really sloppy. The reason is purely grammatical -> the one reason that it might be difficult for web designers to use Drupal is because how thing are done seem to make no sense. For me, I abhor the devilish " if(test_something): " because, quite honestly, my brain can't keep track of the open / closed patterns. It is not the fact that I can't write PHP or understand code ... it is because parsing logic in markup gives me a migraine, literally. Therefore I use preprocessing functions and never tpls. Still, tpls are very powerful in their flexibility ...
  3. Pre-processing power: To continue with above, I often wonder why it is so difficult for people to understand preprocessing -> and the benefits of it. I think that has to do with the abstract nature of it as well as the "kind of mind" that can actually parse the devilish " if(test_something): " I have tried time and time again to leverage theme_html_tag as a powerhouse to build all forms of html elements -> however, what stops me dead in my tracks is the complexity of the attributes array -> to which I wonder ... well, why the hell is this so verbose, nested and hard to use? So I created my own powerhouse that suits the themers needs and run everything through that: http://pastebin.com/xATvLKZW which is what i was really hoping theme_html_tag would look like :(

So, my point is this -> The umbrella idea is this -> create simple, elegant structures (functions, arrays or tpls) that are abstract and can be used for any purpose: Then use those structure to build EVERYTHING that the theme / presentation layer needs. Once once understand that simple structure, then extending it is easy peasy. But here -> consistency is the key ... if the logic isn't reliable, if there are more exceptions to the rules (which is the case right now) then we will have added to the mess.

Oh, one last thing -> I always like to provide a solution to a problem, rather than just state a problem -> so the markup about would be this:

<?php
// define the variables
$input['content']          = $content;
$input['tag']               = 'h1';
$input['id']                 = null;
$input['classes']          = array('title','node-title');
$input['wrapper']         = null;
$input['attributes']       = null;
print
drupal_markup($input);
?>

or
<?php
// define the variables
$title = drupal_markup( array(  'content' => $content,   'classes' => array('title','node-title'),   'tag' => 'h1' ,    ) );
// somewhere in the document
print $title.$pre_content.$content.$post_content.$comments;
?>

That could be used in a tpl. If we defined that in a preprocessing, it would be the same structure. When i think of drupal_render -> i expect that this functionality to happen -> and, for the most part it does ... but building it and using it for myself isn't something that is easy -> hence the hard learning curve.

Does this make any sense?

hmmm after all that

johnvsc's picture

then hell can't we use theme_html_tag alot more? http://api.drupal.org/api/drupal/includes--theme.inc/function/theme_html...

If we did that, PHP

catch's picture

If we did that, PHP performance could plummet even further than it already has. Function calls to generate every HTML tag are the sort of horror story Rasmus brings up in conference presentations.

I disagree :)

johnvsc's picture

Because we are already doing that with every drupal_render .... what I am proposing is to simplify it.

Besides, i have build huge portals like this and they very fast - tpl take some serious time.

Still, this precludes the fact that we wait until the very last moment to render markup -> that way, the amount of effort to produce a HTML tag is reduced because we process the markup just once... not over and over and over and over and over and over

Simplification does not connote abstraction

c4rl's picture

I'm sorry to hear that parsing logic in markup gives you a "migraine." Personally, it gives me euphoric, lilting dreams of unicorns and ponies. ;)

With all due respect, your examples may seem simple to you, but I can honestly say that if I had to use drupal_markup() every time I wanted to write an HTML tag, I would be extremely annoyed. It also risks severely marginalizing themers who are new to PHP.

You remark:

consistency is the key ... if the logic isn't reliable, if there are more exceptions to the rules (which is the case right now) then we will have added to the mess.

I think this has high potential for "mess." As history has shown, Drupal has a very hard time being consistent. Just look at "people" vs "users."

If Drupal is to endure it needs to be easier to learn; abstraction does not help this cause.

True, true

johnvsc's picture

which is why i really never participate in these sort of adventures | collaborative endeavours.

So, I will head back to the way that i like to do things and then all of you sort it out for your selves:

take care :)

The input is definitely

c4rl's picture

The input is definitely appreciated -- the clash of ideas is healthy. I am suggesting we need to think about the consequences for all of the audiences, and (as a themer) I fear the effects of abstracting things like HTML too much.

Maybe your idea could work as a contrib theme or theme engine?

Not every HTML tag goes

catch's picture

Not every HTML tag goes through drupal_render() individually, there are some cases where it's very granular but not to the level of each tag.

Templates are indeed not fast, we discovered this at cost during the D7 cycle (although some improvements were also made to improve this too).

So I would not rule this out if it's accompanied by other changes, but adding theme_html_tag() calls where they don't currently exist scares me.

theme_html_tag() = bad idea

donquixote's picture

What do I read there, theme_html_tag() ?
I never heard of this before, and it sounds very wrong to me.
Why would a theme want to intercept all (*) html tags? Unless that theme wants to invent a new html language, I see no point in this.
In the usual case we will probably see a lot of if/else going on. Similar to (or, worse than) theme_menu_item() being used to target only a few very specific menu items - what a waste.

The solution is not a theme function, but a jQuery-like object to wrap html attributes, with some convenience methods like addClass, removeClass, etc for alter operations. (I make this a new comment so it can have its own replies)

(*) "all html tags" = all that are themed with theme_html_tag(), obviously. Still, this is so totally arbitrary and generic that there is probably no situation where you really want to override the output of this for all possible html tags.
The if/else you need to pull off needs a lot of information from outside (in Drupal world, this means: global state) to find out about the context of a tag to be rendered.

Ok soooooo

johnvsc's picture

First of all: http://api.drupal.org/api/drupal/includes--theme.inc/function/theme_html...

Second of all, my post was not to say "Hey, let's send every thing through a function", my post was to say -> let's simplify how all the markup gets created. I never use theme_html_tag and would never override it in the theme layer... In fact, I was very surprised to find it -> and how "not often" it was used.

The reason being was that there were theme_item_list and theme_table (and others) that I use everywhere because of the added benefits (odd / even being one). I thought, hmmm, ok, then there must exist a generic type of function for generic markup. That old OOP idea of children extending the parents methods and properties is what lead me down THAT rabbit hole........

The "migraine" that i experience doesn't come when I author a tpl -> but rather when I try to change / alter something. I often think, man there has got to be a better way ... this is so, well, clumsy -> even though it is semantic.

Creating an Object (with awesome methods) as suggested above is supercool esp if it would allow for the altering of attributes easily and effectively. To this point (and jeffs point above) that for the non-php themer, a graphical interface would be key to make that work for them.

Consistency in my frame of mind is being able to think like this " Hmmm, well, I did it like this over there ... then that means that over here I can do it the same way ..." throughout the course of a theme. Once you learn that pattern, if the system is designed well, then you can alter and change anything. That is good Dev UX ... a topic that has been coming up more and more recently.

So, the idea here is this ... maybe this type of thing it too high level. maybe we are so far down our path that reworking things (like Jacine said) will be more of a headache. The idea to bring up theme_html_tag was due to the fact that, well, this already exists in core ... what else is there that we might be able to use that was not in the mind of the original authors.

get it?

I think my little rant was a

donquixote's picture

I think my little rant was a bit out of place there. I have no issue with you bringing this up. It just happens to be the first time I notice the existence of this theme hook, in a thread I was following with only half of my brain, and it made me nervous. My thought is, why is something a theme hook that you never want to override with mytheme_html_tag(). Obviously this is not your fault, and there might be a better place for this rant (where this thing was invented).

Thinking about this again, probably the reason is that theme hooks is the first thing that drupal_render will look for to render something.

jQuery-like html tag engine.

donquixote's picture

A much better idea is to have a jQuery-like object to wrap html attributes, with some convenience methods like addClass, removeClass etc.
This thing can be passed around in alter hooks.

I have an example implementation in dqx_adminmenu,
http://drupalcode.org/project/dqx_adminmenu.git/blob/b4a8275aba09e4bcd51...
see class dqx_adminmenu_HtmlTagAttributes on line 199

Something special about this implementation:
The object does store all html attribute values, but it does not store the tag name or the html content.
This allows to work on the attributes array at a time when you don't know yet if it will be rendered as a table row or a list item, and when the html content is not yet available.

There are two ways to render this thing:

<?php
$attr
->addClass('some-class');
return <<<EOT
  <a $attr>bla bla bla</a>
EOT;
?>

to render only the attribute string. Or
<?php
return $attr->A('bla bla bla');
?>

to render a tag (where "A" is the uppercased tag name). (there is a more verbose option without magic method)

I consider making this a contrib module..

"Flat" "nested" arrays

donquixote's picture

Probably somewhat related and somewhat useful in this discussion.

One issue I have with nested rendering arrays is that I never know where to find a specific piece I want to alter.
Typical example (on D6), I want to use hook_form_alter() to change a label of a component in a node edit form. So I go and hardcode $form['submit']['#title'] = t(...).
But now another module interferes and puts the submit button into a field group. Duh. My simple hardcoded code works no longer. I would need a jQuery-like selector logic to find the thing that I want to alter.

An alternative would be to put all the items at the top level of the array, and specify the nested position with a "#parent" attribute. Or maintain a structure array in addition to the items array.
(if you want an example, dqx_adminmenu works this way)
This looks like quite a radical change, but maybe we could go a small step in this direction, by providing an option to postpone the "move into a deeper level" to a late-firing preprocess function.

Again, I agree :)

johnvsc's picture

Look at http://groups.drupal.org/node/159734#comment-545334 Item 1 in my list -> that is exactly the same this -> albeit a different solution, though similar.

That drives me freaking crazy.

IMO, this is an example of

moshe weitzman's picture

IMO, this is an example of "the cure is worse than the disease".

Tag much more rich

AndrzejG's picture

I am almost complete ignorant in PHP, and all the stuff like "hidden" or "render" instructions within the tags etc. Nevertheless, please take into account that in near future, while HTML5 is growing rapidly, the tag probably should carry, and respond, much more than id, css class, and attributes, because it itself should carry the meaning to be processed in some way (we don't even now how!).

This seems to break the rule of strictly dividing presentation and content "layers", and probably could have significant impact on future theming.

Related to this are new trends in mobile theming, which without doubt will have been transfered to traditional desktops and notebooks. I can imagine the content scrolling up and down (or in the other directions?, 3D?) in part of the screen, like in Apple gadgets... without such things as a header or footer in today's sense.

Example

AndrzejG's picture

Please look at the example of the layout inspired by mobile theming: http://cargocollective.com/

Great example

jessebeach's picture

Mobile theming is definitely something that should happen in the theming layer, not the core layer. Our current efforts to clean up core for HTML and sparser CSS will make output agnostic (e.g. mobile theming) easier to accomplish.

Also see the Web Services and Context Core initiative. This is one I'm really excited for. It brings Drupal into the space of web app platforms.

Theme development

Group organizers

Group notifications

This group offers an RSS feed. Or subscribe to these personalized, sitewide feeds: