Do you think controlling wrapper markup in the UI would be a good idea for Drupal 8 core?

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

Some people believe that wrapper markup should be controlled via UI so that those configuring the site can choose the proper element to wrap blocks of content in, down to fields. This question is about Drupal core itself. Contrib has been and will continue to be able to solve this problem. See Display Suite, Views, Fences, etc.

I ask this because there has been a lot of discussion about improving the theme layer, and somehow this issue always comes up, and Drupalcon Denver as no exception. I can recall 3 separate sessions where it was asked if this was going into Drupal core, and in JohnAlbin's responsive techniques session he deferred it to me and the HTML5 Initiative and said he wouldn't be against it.

I think this would be better in contrib, personally, and I also think it’s out of the scope of the HTML5 Initiative, because it would have far reaching consequences, some good, some bad. I think it’s within the scope of the HTML5 Initiative to provide better default templates and that’s what we’ve been concentrating on (which BTW is no small task). Aside from the obvious bloat this would add to core, these are the reasons why I think it would be a bad idea in Drupal core:

  • It wont work seamlessly with templates. The UI cannot always know if a template override is in place, which means if you decide to handle something via template, you end up with a broken UI. In some cases we’d also have to worry about others making markup changes where they weren’t wanted.
  • It turns the job of a Drupal themer into that of a Site Builder who writes CSS. There are a lot of big changes coming to Drupal 8, including layouts like Panels and possibly a move to abandon PHP Template for something else like using Twig or Tokens in templates. If we go the route of allowing markup to be selected in the UI, we would have to use variables to print tags in templates, which make them more complicated to approach and lessen the HTML in them period, which is not a good thing.
  • It has implications for contributed themes. Drupal already has a bad name for lack of nice looking themes, and this could make it worse. If all of this is editable via the UI, a theme has no real foundation to style CSS against. Classes will get you halfway there, but sometimes you need more specificity, and that means using the tag in the selector, except you wont really be able to rely on that.
  • It expects the Site Builder to know HTML. They won’t have to actually code it, no, but they’ll need to understand the semantics of their content and the meaning of the tags. This also complicates the UI rather than simplifying it, which is problematic IMO.

But, what do you think?

Comments

Define "controlling wrapper markup"

gkatsanos's picture

Hi Jacine,

Could you please explain a bit more in detail what is the proposal? How will the markup be "controlled" ? Through settings and menus? Through variables/functions available to use in template.php? Could you present some examples before we start the arguments for or against it?

Thank you.

Controlling wrapper markup means...

Jacine's picture

Instead of overriding templates for blocks, nodes, fields, etc. some people want a UI option to choose the proper HTML element that each piece would be wrapped with at the top level. It's not a proposal (and will never be one coming from me) but more of a question to consider. Hope that clarifies things a bit.

and layout?

theborg's picture

I think that it depends on the kind of user/working habits. Lets see:

  • a) as a power user I like to do everything in code, even with a simple text editor, I like to have the control and I don't want to move around an UI that sometimes it has a learning curve.
  • b) as a new user or site-builder having the ability to touch some bits of a pre-made theme to adapt it to my need would be a nice addition.

On the other hand, this evolution means an improvement to selling Drupal as a whole package/product, but I think is a similar case as, for example, Dreamweaver.

And,

  • are we going to expose core theme_ functions to the UI? why not do the same with css related to that markup?
  • and the layout? is structural html going to be controlled by the UI?

Right now, even with the

heather's picture

Right now, even with the benefits of "semantic views" in Views 3, most people still don't know it's possible. I have seen clients put JQuery in headers of Views to re-write the DOM to change elements on a page(!!!!) where there is a will there is a way!

While all the jazz of Drupal's middle man seems like a revolutionary way to "kill the developer" (as one man put it) - it makes Drupal one powerful but confusing piece of software. I say "kill the trainer"! I am basically relegated to training to poorly designed software. Where users need to touch 4-5 different UIs to get one thing done (configure comments, compare that to the same in other systems). It's also a poorly designed UI because of the variety of interaction models. I heard a trainer just yesterday declare a jihad against context's UI.

More and more, I think HTML knowledge is becoming more essential. It's better we leave this to the templates. Let people bring what they already know (markup) and meet them half way with a legible theming system. Let's not direct them to a frustratingly confusing experience.

Before giving a final answer it would be good to observe or speak to people who are not enmeshed in Drupal, but use it everyday- and find out what level of configuration they need and expect.

In fact I think layout configuration is more needed (get this x thing over there!) more than messing w markup in the UI.

Mostly I think the awesome work of Semantic Views and so on was always a work around the issue of bloated markup in the first place. And the bloated markup was there because developers thought designers wanted more and more classes. The answer to that is dividers, and more of em!

How about a "CLASSY/NOT CLASSY" toggle? ;)

nicl's picture

As Jacine points out, making all markup configurable via a UI is going to be a lot of work, and quite complicated too. I am not sure whether a friendly UI could be made for this kind of functionality either.

For me, we should prioritise improving the theming system to make it easier to alter and remove markup using templates/theme functions. A move to Twig and rationlizing the tpl files (one per HTML element) would help here.

Against removal of php template

berenddeboer's picture

PHP is a template language. Let's not write yet another template language. So please don't remove PHPTemplate.

I still recall that when I started building stuff with Drupal I did everything through the template system. Yes bad, but it got me started. For many people playing with templates and adding php is how they start customising Drupal.

Please don't turn Drupal in yet another overengineered solution. I like it the way it is, and I like the way it was moving. But keep the learning curve accessible.

I understand the question, as

julien's picture

I understand the question, as there is more and more jquery added to each theme. Jquery needs a markup selector (often id or class) to do his magic.
Even the Drupal Ajax Framework api like ajax_command needs a jQuery selector string as parameter, so as soon as you have customisable markup in custom theme templates, it's difficult to make a generic module that will use those api functions, without a configuration form somewhere.

Contrib

yoroy's picture

I'm not quite sure what this would look like. In general though, I'd be very wary to build 'themer tools' into core. I'd worry most about the third point Jacine makes: it makes core an unreliable moving target for contributed themes.

I'm interested to hear some strong arguments in favor of adding this to core. I haven't seen one yet. (Not sure julien explanation above here means he's in favor of adding this to core :-)

Agree

theborg's picture

Agree with you and Heather, if we have to choose between easy to use versus reliable, the answer is clear.
I say one step at a time, let's build first a better theme system and leave the fancy UI to contrib.

Related to Jacine's point 2:

We have a powerful framework that has enabled the creation of a growing market behind, meaning trainers, themers, module developers, site builders, etc. Yes, sometimes is hard understanding the insights of it but take a look at the big ERPs. Is the tendency to eliminate people from the Drupal equation?

Markup Config: The

danielnolde's picture

Markup Config:
The possibility of configuring wrapper markup through the interface and therefore taming and tailoring Drupals verbose and multipurpose markup would be thrilling! For many Drupal users, it's a blessing to have this possibility in Views or Display Suite. Having this in Core 8 would be amazing. The side effects on templates have to be mitigated, true, but they seem manageable, given the fact that Views+DS are solving the same problem already.

PHPtemplate:
Yes, we have to make the theming layer with its template/themefct usage and data structures much more consistent, concise, predictable and learnable. We should however try hard to keep PHPtemplate the templating language for Drupal – it's one language less a novice has to learn (very important when we think of the whole steep Drupal learning curve!).

The answer is in the question

philippejadin's picture

The answer is in the question imho. You present mostly negative arguments about this, and I agree completely.

Choosing the wrapper trough the UI won't help to separate cleanly content and presentation. Wrapper html is presentation and belong to the theme layer. Let's not mix this up more than it is already.

I would focus more on providing first class/lean/sematic html in core, to provide themeres the ability to create "mostly css" themes.

If the html provided by core is clean, we'll see more and more css only themes, à la zen garden. Stark based themes are a good example of where we should head.

I don't think we'll ever get

karschsp's picture

I don't think we'll ever get to a point where you can customize all markup through the UI (certainly not for Drupal 8), but with the "everything is a block / page manager in core" movement, perhaps there's room for some semantic blocks functionality.

If every block has, at minimum, wrapper, subject and contents, maybe we could provide the ability in the UI to choose the HTML elements for those items and perhaps add classes so they are easier to style without having to dig into template files.

Semantic Blocks

ericgsmith's picture

Funny you should say that - that I what I do for my drupal projects. The main aim was to provide a more semantic wrapper for my blocks. A lot of "HTML5" themes output blocks as a section tag if it has a title. This frustrates me as it isn't semantic for a lot of cases.

I use the block class module for classes and my own module for altering the block template. Currently being reviewed but if you want to have a look http://drupal.org/node/1421888

best of both worlds

Edith Illyés's picture

I love the UI options in Views/Semantic Views and I would like to see something like that in core for fields. In the best possible world I should have both the UI and the option to override in a config file:

<?php
$overrides
= array(
 
'my_field_1' => array(
   
'tag' => 'h2',
   
'class' => 'class-1',
  );
 
'my_field_2' => array(
   
'tag' => 'div',
   
'class' => 'class-2'
 
);
);
?>

If all of this is editable via the UI, a theme has no real foundation to style CSS against.

I think the problem with Drupal themes is conceptual. We have a modular CMS and most theme stylesheets are non-modular. Themers think in entire pages, when the natural way to theme a modular CMS would be to have predefined sets of styles that are not dependent on markup, except having to correctly choose a block or inline tag for the CSS to work.

For example I have a .syle-1 class that looks like this:

.style-1 {
  padding: 1em;
  background: url('fancy-bg-image.png') no-repeat 50% 0;
}
.style-1 a {
  color: blue;
}

The sitebuilder can examine the CSS, and simply assign this .style-1 class to whatever container/element as he wishes. Yes, some of these assignments won't work, e.g. when trying to assign a block level style to an inline element. But who said people should be able to build sites without a minimal understanding of CSS?

IMHO themes should be, by and large, collections of predefined, isolated, and markup-agnostic styles identified by classes. That requires a change in thinking on both the designer and themer level. But unless we make this shift in our way of thinking, we'll always be stuck with the antagonism between a modular CMS and non-modular CSS.

Some remarks

gkatsanos's picture

Actually,

  • CSS is not a modular language, by nature. (maybe scope will change that)
  • CSS writing best practices are still under discussion: Location based, one id per page, multiple classes, etc

What is the out of the box

gkatsanos's picture

What is the out of the box HTML wrapper rendered on a Drupal 7 installation?

<body> with a bunch of classes?

That's what we're talking about? Please clarify what do you mean "wrapper markup".

A no from me

rooby's picture

Seeing as how drupal is the ultimate do anything CMS, I think there is a place for this like there is everything else anyone wants to do.

However I don't think that place is core.

Core, being a base to build on, needs awesome default templates and modules that don't interfere with the theme (that is the job of the theme). So I think what limited time everyone has should be spent making drupal output the best base markup it can.

This would add complexity that isn't necessary or desired in core.
It's yet another different place that markup could be being changed.

With a clean core it will make it much nicer for contrib to do something like this.

Config in the UI is great, but things generally start to get messier when you have code in the UI.

Plus, call me a jerk but I don't really think people who have no web experience to the point where they can't code HTML into a template themselves should be allowed to modify HTML markup via the UI.
You're asking for trouble.

If end users can't do absolutely everything themselves so what.
Not everyone can build their own house, not everyone can build their own custom car, not everyone can build their own custom website.
I know people do DIY houses, cars etc. but you can do the same with drupal, just have to spend some time learning.

If this is all done to please the most people and get the most market share, then make core as flexible, usable and cleanly coded as possible and let contrib build all the awesome extras.
That covers the people who want it and the people who don't.

"Kill the developers" will never happen regardless.
You still have all the clients who want a professional job done, clients who don't have spare time to DIY and clients who need you to fix shoddy DIY work :)
Plus you need developers to build wonderful automation.

Also, to keep ranting :)
I don't see the point in moving away from PHP Template. So newbies and some designer folk don't like coding PHP. So we get rid of the PHP and we force our entire current developer/themer/designer/everyone who templates now to learn a new system. My guess is that would irritate a greater number of people.
Plus, from what I have seen of a lot of alternatives, they are pretty much the same thing exactly, with ifs and foreaches etc., just in a different syntax. So why bother making more work for everyone by switching. Some people just seem to be scared of the PHP acronym.
A different syntax is still a syntax you have to learn.

Replacing crazy array structures with tokens but keeping PHP might keep the most people happy and keep things more consistent.
And we have a theme engine system that can handle contrib adding their own templating systems later if they want.

Quick thought

Graeme Blackwood's picture

The issue I have with wrappers is when they don't group anything. For example this div is completely pointless: < div id="logo">< a href="#" class="logo">Logo< /a>< /div>

Outputting wrapper divs around other wrapper divs is just pointless, so I am all for reducing this in core.

I do think HTML is a pretty basic requirement, but its all relative. I know a lot more about HTML/CSS than I did 2 years ago, and I have been coding for the web for over 10 years.

So we do need to provide improved basics but make it easier to rework the markup – contrib modules are making this a lot easier so it's becoming less of a problem. The bigger problem is communicating that these tools exist and where to find them.

Seems to me then that core

yoroy's picture

Seems to me then that core should focus on providing the cleaner starting point. Let contrib add the additional bells and whistles. Sounds like the general Drupal philosophy of doing things :)

Don't understand the cons

fmizzell's picture

So, the layout initiative is already planning on having a UI for placing blocks on a layout. If I understand correctly, they way to display anything in D8 will be through a block (entities, fields, etc), and any block can have a layout (I am no 100% sure that this is true). From what I heard a layout will be a way to group a template (layout markup), and some other things like js and css. The info for these layouts will be stored in the xml format provided by CMI. I am not only a themer, I play all roles for each site I have built, but from my theming experience, the templates that I have built were serving 2 purposes: layout and providing classes and ids for my css and js. I guess what I am trying to get to is that the layout initiative is taking care of the first thing that I currently use the theming system for. If I could easily add classes to any of block markup from the UI given by the layout initiative, my themes would be pure css and js, and the only templates would be defining layouts, unless core gets a UI for building layouts also. From my experience, I don't see how adding classes through the UI would be a bad thing. Defining classes from the UI is not adding much more complexity after the layout initiative get done and since we are getting CMI, any of this classes should be easily changed without using the UI, by modifying the config file. Just my 2 cents.

Fmizzel reasoning makes sense

dodorama's picture

Fmizzel reasoning makes sense but at the same time I think that the idea of themers that just edit CSS is a myth. Especially if we're going to introduce a template system that should make easier for front end developers to manipulate templates I think we should keep markup in code.
I think we should clearly define what are the kind of users of a Drupal installation and I think in D8 we're going toward a clear separation between developers, themers, and content editors.
Developers will mostly use config files and modules and work mostly in code. Themers will use templates, CSS and JS. Content editors will use the UI.
In this sense if we keep to clutter the UI with functionalities geared toward all of these users we will never be able to make it work for any of them. It will never be enough for a themer or a developer and it will always be too complex for a content editor.

Configuration vs. Complication

JohnAlbin's picture

If we go the route of allowing markup to be selected in the UI, we would have to use variables to print tags in templates, which make them more complicated to approach and lessen the HTML in them period, which is not a good thing.

I am STRONGLY opposed to having variables used to print HTML tags in the wrapper element of the templates. NO. NO. NO. That's why Palantir rejected several existing "semantic wrappers around fields"-type modules. (That, and their UI was too complicated.) Using PHP vars for wrappers is a performance hit. And it obfuscates the template file making it unreadable.

If you look at how the Fences module actually implements a HTML5 configuration for fields, you'll see that there is a single drop-down in a field's configuration with almost every possible HTML5 element (categorized and sorted). From a UI perspective, you don't have to type anything, just pick the single wrapping HTML5 element you want from the list. If you don't pick anything, it defaults to "div". ( Boo! divs! ;-) )

On the back-end, it uses theme hook suggestions to map the selected element to a specific template file. Yes, Fences.module includes one template per HTML5 element. And, yes, that's its down-side. Boatloads of template files. It is, however, its only down-side that I can see. Each template file is totally readable with no crazy PHP variables for the markup element.

The theme hook suggestions that Fences.module sets for a field also have very low priority. Any theme hook suggestion that a themer might want to use for a particular field overrides the suggestion that Fences makes.

It wont work seamlessly with templates. The UI cannot always know if a template override is in place, which means if you decide to handle something via template, you end up with a broken UI.

So, I hope you see… in the case of Fences and field wrappers, this is not true. If you use a theme hook suggestion, you should understand you are overriding the configuration. That shouldn't be a surprise. Actually, you should copy the specific Fences field template for the HTML5 element and make your changes for your suggestion. Anyways…

But I've only worked on fields, there are other things it might make sense to have a configurable UI for. And if core has a configuration for field markup, it might be confusing why it doesn't have configuration for other types of wrappers.

Also, fences templates currently don't wrap the title and the field values in a single wrapper. The selected wrapper is placed just around the field values. 95% of the time that's what you want. And fences has an open issue about how to deal with the 5%.

So, given that, I'd say Fences has great potential as a way that Core could do it. But Fences hasn't totally figured things out. I'm not opposed to having this remain in contrib land until it is 100% fleshed out.

(BTW, I'd love help working to make Fences a better solution to the HTML5 configuration problem space. See http://drupal.org/project/issues/fences for how you can jump in.)

  - John (JohnAlbin)

I've seen fences. Took a

Jacine's picture

I've seen fences. Took a look after watching your session. It's great, and also noted at the top of this post as a solution that currently lives in contrib. Generally, I think the concept is good, but it don't agree that the settings should ONLY be global per field. When dealing with different view modes, for things like headings, and things that can have similar HTML and be semantically correct, the HTML can be different per view mode and I wouldn't call that an edge case. An H2 might be appropriate when viewing a full node and an h3 might be appropriate when viewing a list of nodes, at which point I'd need to go into templates. Why not go all the way?

It's great that you've solved the problem for providing defaults to fields, but what about everything else? IMO none of what is in fences should be specific to just fields. There should just be a generic wrapper, and formats to deal with common implementations in core. Core doesn't need to provide UI access, just doing this in code would go a long way.

Regarding this point:

It wont work seamlessly with templates. The UI cannot always know if a template override is in place, which means if you decide to handle something via template, you end up with a broken UI.

Crell was the one who brought up this concern. If I override a template and remove a label, yet you still are able to configure that label, I'd call that broken. If I override a template and remove the wrapper, yet you are still able to configure that wrapper, I'd call that broken too. Maybe it can be resolved, though I don't see know, but it would definitely complicate the UI, and in my opinion that is a fail.

I think the other issues that I brought up in the original post are important to consider, but regardless of what I think, if you or anyone else want to propose that Fences be in core, why haven't you proposed it? No one needs me to propose any patch to core. I resent the fact that things like this are thrown solely on my shoulders as if I have (or want) any power to make a decision like this anyway.

Fences looks great

Edith Illyés's picture

Oh, so there's a module for that...:) I just inspected Fences and it looks great. Many thanks.

Also +1 for Jacine's comments above. Just to summarize:

  • Fences in core
  • + view modes
  • + generic wrappers
  • no need to provide UI access, non-themers wouldn't want to touch this anyway

I think she's saying Fences

RobW's picture

I think she's saying Fences should not be in core.

Clarification

JohnAlbin's picture

I guess I didn't make myself totally clear. Let me italicize the operative words in what I said previously.

So, given that, I'd say Fences has great potential as a way that Core could do it. But Fences hasn't totally figured things out.

I haven't written a patch for "fences in core" because, as I said, it's not ready yet. And, IMO, it should remain in contrib until those issues have been worked out. It is actually easier to figure this stuff out in contrib because we can commit code early and often, a luxury we don't have in Core. Could it be in time for D8? I don't know. I wouldn't be able to work on it with the other things on my plate.

I resent the fact that things like this are thrown solely on my shoulders as if I have (or want) any power to make a decision like this anyway.

Jacine, I would hope you know that I understand what it means to be an initiative lead.

Everyone: An intiative lead's power is only in having a big megaphone. Core gets changed when consensus is reached and someone writes a patch. An initiative lead's role is to try to foster consensus and cheer on the patch writers and reviewers. Notice how "deciding" and "doing the work" isn't in my description? That's left to everyone else. :-)

  - John (JohnAlbin)

Does WSCCI have an impact on theming?

bstoppel's picture

This is such a complex issue that effects the productivity of a lot of people. I really appreciate the work that everyone has contributed.

After DrupalCon and even leading up to it, it is obvious that Drupal is about to zag when it has been zigging. A lot of fundamental changes are occurring under the hood. Drupal8 will depart from the notion of simply serving pages of HTML. Instead Drupal8 will be serving responses based on the http request, which may include the mimetype specific responses. This is all part of the WSCCI initiative unless I am misunderstanding what I've been reading.

Now may be the right time for a shift in theming to complement the shift toward mimetype agnostic paths in Drupal core. To do this, I think the theming layer primarily needs to be concerned with delivering clean data and secondarily with manipulating the clean data for final delivery. Drupal already goes along way to providing us with what we need: hooks, (pre/post)process functions, tokens, tpls. It needs to be modernized a tad and cleaned up a bit. But I think the foundation is good.

Personally, I'd like the template files to be as basic as possible and very readable. I like tokens and html or whatever the output format is... xml, json, rss. Let's leave the UI to contrib for Drupal8 and focus on cleaning up the theme layer to be rock solid and understandable.

A quick more practical note: If a UI is provided for tag manipulation, could a hook system be implemented to allow hard-coded themes to inform the UI that it cannot be overridden?

Brett

HTML only

fmizzell's picture

If I understand correctly, all of the infrastructure that we call the theme system in Drupal is only relevant to HTML. XML and JSON will be handle by their own controllers

Correct

Crell's picture

Yes. For theming purposes just consider HTML. Other data formats we'll deal with separately.

And, yes, that's its

swentel's picture

And, yes, that's its down-side. Boatloads of template files. It is, however, its only down-side that I can see

Actually, there is another one, and important: they are template files by default. That's actually where core is doing the right thing on the field level. Functions are always faster then template files, no exceptions. Printing 'div' or 'address' or $wrapper in a template file doesn't really matter, except for readability - which imo is rather linked to the knowledge of the system and/or experience of the person controlling markup.

Views, Semantic fields, the field templates feature in Display Suite also have the ability to control field level elements, but they all use theme functions by default. People are allowed to copy template files, and while we can't forbid them to copy, we need to make sure the default has no potential performance implications on a site.

Configurable in theme settings only

rohnjeynolds's picture

Drupal does a great job of keeping the module and theme layers separate by being honest about where they collide. Modules define default, suggested markup via hook_theme() and cordially invite any theme to override it. Fences seems to extend this idea into the field-definition GUI, which is cool, as long as the theme is allowed to win any arguments. But if we're talking about GUI-controlled markup in core, the only way it makes sense at all is if it's in the Appearance section (or whatever theme settings are called in D8). Maybe you could have global wrapper tags for common elements defined for all themes, and theme-specific ones to override, just as you can define global and theme-specific site name, logo, slogan, etc.?

shawn.sh's picture

I personally would like to see us give more control to the experience front-end developer. Lets give them a simple theming system with files that they intuitively understand and manipulate. If required to learn a UI and use it for some things while using template files for others, in the quest to achieve total control, it adds too much complexity.

I think the UI markup tools belong in contrib. Core should be a lean framework, not site building tool out of the box. If we focus on simplifying the theming system and center around template files at the core (phptemplate/twig/token what have you...) I think we'll see larger adoption because we'll be speaking the universal language of markup.

tldr: Less clicky more typie in my humble opinion.

-sg shalo

Let's keep the power and

pixelmord's picture

Let's keep the power and flexibility, but add some configurable choices.

There are always several templates and theme functions where I want to have full control and flexibility regarding the output for some fields for example. I would not want to loose that by some solution that is based to much on configuration. I want to have the power of preprocessing, renderAPI and templates.

But on the other hand there are a lot of fields, where I either just want no wrapping markup or I want something specific like headlines or lists with a really standard output.
What I can do now is write some helper functions that can be called from the field specific theme functions, but I would have to implement theme functions for every field (also the fields that will be put in later, what we tend to forget ;) ).

Here it would be nice to have a system in place, where some predefined templates could be selected by the site builder after adding new fields, and I as front-end developer could focus on the tricky stuff.

Yes, I could see this functionality provided by a contrib module like Fences or Display Suite, but sometimes I don't want all the functionality that comes with a contrib module like DS for every project.

Wrapping a bunch of new text fields in a H3 tag seems such a basic operation, that writing a theme function or activating a module to take care oft that just feels like a bit to much...

****************
wunderkraut - Da wächst etwas..... www.wunderkraut.com

Enlightning

fmizzell's picture

This conversation has been very enlightening, and the only conclusion that I can come up with, is that we need to make sure that a lot of themers are paying attention to the layout initiative for D8. If I am seeing things clearly, there could be a major conflict between what themers want, and what the layout initiative is trying to do.
Just by using the functionality proposed by the layout initiative, I will be able to choose a layout for a page, add some blocks to that layout (where blocks can be entities, fields, etc), and if desired, I can even choose a layout for each of the blocks on the page (for example a node block, will contain multiple blocks (fields, properties, etc) and I can layout those too). So pretty much we will have these hierarchies of layouts and blocks.

In my mind that sounds pretty awesome, but that is where I see the conflict. If I use the layout functionality on a node, the system will have a template file defining the layout, but I am assuming that where the blocks (fields, properties, and other parts of the node) are placed withing that layout, will all be saved somewhere as configuration, not in a template file that a themer can go an hack at with full freedom.

So, it seems to me that if a themer wants full freedom, they might use the layout functionality for a page, but not for individual blocks, and I think that completely waters down the capabilities of the layout stuff (to much work for the relatively small benefit).
Am I missing something, can we have a useful layout UI, and full control through templates at the same time? The only solution I can think of is for the layout initiative to save their configuration as hackable templates, but I have not thought through the kind of difficulties that that might present.
I know this is a little off topic, but it was inspired by all the comments from this thread.

UI is only for choosing which layout + putting content in

Edith Illyés's picture

Am I missing something, can we have a useful layout UI, and full control through templates at the same time?

If the new layout system works like Panels, then the UI is for:

  • choosing a layout from a predefined selection, e.g. use layout X for nodes of type Y,
  • and putting pieces of content in the various slots that are available in the chosen layout.

The system provides a couple of predefined layouts, e.g. two-column, three-column, etc. and themers can create new layouts easily by writing simple config and template files. These are recognized by the system and after rebuilding the theme registry they show up in the list of available layouts on the UI.

Right..

fmizzell's picture

I believe that is right.. do you see the conflict? creating a layout template, and using the UI to place the content within that layout, is not the same than what you get when you override node.tpl.php in a theme. They are different ways of doing things, and from this thread it seem like themers do not want to lose the power and flexibility of the node.tpl.php override approach. So, once again, can we have power and flexibility, and the proposal from the layout initiative working together?

Power & Flexibility

shawn.sh's picture

From my perspective, we want control over all HTML being printed out to the page. ideally in some file.

If we're working to put layout building into an interface of some sort to make it easy for anyone to build, while removing the flexibility/power of overrides people familiar with writing their own code will simply go elsewhere. Clean, simple, and overridable is what's valued by the professional theme developer IMO.

Clean, simple, and overridable also makes Drupal flexible enough to adapt to any front-end developer's style, thus reducing the learning curve and paving the way for higher adoption by the best front-end developers out there.

So we need both, and if not both, Power & Flexibility first, then layer tools on top in contrib.

-sg shalo

For whom?

Crell's picture

Power and Flexibility, sure, but for whom?

For an HTML guru, P&F means "here's a template file, have your way with it and ignore the UI crap".

For a clicky site-builder (who has to date been Drupal's primary target audience), P&F means "here's a GUI, push some buttons and ignore the markup crap."

Those two constituencies are directly at odds, because as others in this thread have noted the templates that make the GUI powerful and flexible make them godawful for HTML-editing-types while the templates that HTML-editing-types sing about have no hooks at all to allow a GUI to muck with it. That's an inherent tug of war that we need to decide how to resolve.

Personally I don't much care which way we go with it. I'm a backend developer so I don't deal with it either way. :-) I just care that whatever decision we make and whatever trade-off we go with is a conscious, explicit, consistent decision.

It's when we try to please everyone all the time in an ad-hoc manner that we end up with the mess of spaghetti we have now.

Agreed

shawn.sh's picture

I agree with you. I'm a professional theme developer so that's who I care most about. I'm not opposed to the GUI but I don't want to fight with it, or to be forced to use it to shape the markup of my sites. If Drupal aims to be the point and click CMS vs the lean/clean front-end machine then that's ok also. It just means that it won't be the ideal solution for those types of developers and they'll go elsewhere.

What i hear most about and what I see at the Cons are Drupal shops who develop sites for small and large clients, Freelancers, Universities, and large Corporations, all of whom are or have front-end developers.

I gathered from the Keynote that we were aiming to grow our marketshare. We do that by attracting the best IMO (like wordpress does), and by keeping things simple and intuitive for them. We do have a mess of spaghetti (starting to get hungry) and that's the main complaint for new professionals wanting to give Drupal a shot. Drupal's power is in it's awesome tools (thanks developers) and it's flexibility. We'll never be able to be totally flexible in the GUI.

Just trying to make this not true: http://twitpic.com/3pvrmw/full

-sg shalo

it depends on the template engine

Edith Illyés's picture

In Panels we have the same flexibility in a layout template as in node.tpl.php. But we don't have to fish in huge arrays and load this and that in template.php just to get to the value that we want to print. All available or potentially loadable stuff is offered to us in a nice point-and-click UI. You can of course manipulate your stuff in template.php or even the layout template, it's just a PHP file like any other.

This would of course change if we drop PHPTemplate and start using a "safe" templating engine. Then we'll no longer be able to put SQL queries in our templates. That would be sad. I'm against it. ;)

I had a look at the fences

dodorama's picture

I had a look at the fences module (very cool, indeed) that made me think about semantic. One of the problem that makes this issue complicated is that markup (html5 markup in particular) is not about presentation and so, somehow, not necessarily a themer problem but a site builder issue. In this sense markup selection makes sense in the field UI where I'm deciding what that piece of content means.
So for example if I'm adding a field that will contain quotes it make sense to choose blockquote as the wrapper when I create the field. How the block quote looks IS a themer issue but you don't need to mess with the template to do that. CSS is enough.

This makes me lean toward having markup control in the UI. But if we decide so it means it should be consistent and be available for blocks as well (as defined by the layout initiative) and when I create fields and content types programmatically I should be able to define the markup in code. So the markup becomes part of the configuration of the field.
Essentially I believe that if it happens in the markup it shouldn't be possible in the template.
This means to me using variables for tags rather than different template for each html tag like the fences module does. Because if I set a specific field to be an unordered list I don't want a themer to be able to override the unordered list and make it print something else. That would be totally confusing and the usual spaghetti mess Crell was talking about.

I am having strange visions

Jon Pugh's picture

I am having strange visions arising from this and config management...

we are generating valid XML there. How much of a leap would it be to leverage that to generate valid HMTL5?


Jon Pugh
Founder & CEO
THINKDROP
open source consulting
http://thinkdrop.net

As a site builder ... I would

Dustin@PI's picture

As a site builder ... I would say having the ability to layout fields in UI is pretty essential.

My ideal scenario:

  • Enable a professionally created theme
  • Create content types/entities
  • Layout content types according to the layouts that come with the theme (theme should come with multiple tiers of layouts: page layouts, entity layouts (container), etc.
  • For each field (in a display) either:
    (1) except the default html tag template,
    (2) select an alternative html/template that is associated with that field type (with an optional class id),
    (3) override the Twig template for that field right in the UI
    or (4) get my themer to dig into the files and create a template for the fields including any additional css, js and pre-process functions that are necessary.

I can do this more or less now using Display Suite, but there's a lot of room to streamline. Having it in core and compatible with the work regarding layouts would be very powerful.

as an FYI ... I have 3 developers on my team, one of whom specializes in theme'ing but I want them concentrating on truly custom work. I want it so that our database guy and myself can setup the content types (and views) and place the fields etc. where they belong in the pre-defined template/layouts.

None or very limited options in D8 core

effulgentsia's picture

Thanks for starting this discussion, Jacine, and thanks to everyone for your insightful comments. I'm a PHP-side developer, not a themer or site builder, so my perspective is limited by that, but here's my thoughts.

In general, I lean towards only attempting to put into core stuff that meets at least one of the following conditions:

  • What has already been sufficiently well worked out in contrib.
  • What has been identified (usually by Dries) as strategically important to the Drupal project and not well solvable in contrib without significant core changes.
  • What helps solve a problem that already exists in core and needs solving.
  • What helps solve a new problem created by other work currently happening in core.

That's just my guideline. People are free to disagree with it. If you humor me on it though, here's how I view configurable wrapper markup through this lens:

  • According to the Fences maintainer, it hasn't yet been well worked out in contrib, and is more likely to be worked out better by staying in contrib a bit longer.
  • Dries has not identified this as a strategically important initiative. People are free to use this thread and others to build up grassroots momentum for it, but at least currently, it's not being pushed by the project lead.
  • A problem that a lot of people have identified as needing fixing is Drupal core outputting themer-unfriendly default markup and themes being burdened by too many functions/templates to override to correct for this. If exposing tag name selection or other things in the UI would help address this problem (for example, by removing the need for several dozen of our current templates), I'd be very in favor of it, but in chatting with Jacine and some other themers, I don't think it's possible. Back when we had to support IE6 and other old browsers, clearly a template editor had many more choices to make than the tag name to use for a wrapping tag: without CSS3, you often needed a whole bunch of divs and other craziness. Now with IE8 as our most legacy browser, I've heard some people expressing hope that choosing the appropriate HTML5 wrapper tag and some class names (along with adding the needed CSS and JS files) is all you need to do to achieve any desired presentation effect. But I think this hope is a bit premature. Let's consider a title. Seems like besides deciding whether it should be an <h1>, <h2>, or <h3>, you also have situations where you don't want a wrapper tag at all, and sometimes you have situations where you want an <hgroup> in addition to the appropriate-level heading tag. And that's just the case for something as simple as a title. I'm guessing there's other kinds of content quite a bit more involved than that. So I don't think UI configuration lets us remove the need for templates: we need to get our templates modernized, organized, and simplified regardless.
  • Finally, we have the question of whether the HTML5 initiative and/or the Layouts initiative, either independently or jointly, create a need for UI-configuration of wrapper markup. I don't think we'll have full clarity on this until after we've cleaned up our templates, and made more headway with the Layouts work. Conceptually, I can see some problems surfacing, like needing to identify whether a particular configuration of a particular block needs an <article> tag based on information known only to the site builder / content editor, and not when the theme is created, so I'm definitely open to exposing some limited amount of UI configuration for addressing this once the Layouts work is far enough along for us to evaluate this. But I see this, if necessary at all, as being very limited in scope, so as to avoid the problems listed at the top of this thread.

To be clear, what I'm refering to above is the question asked of this thread title only: controlling wrapper markup in UI of D8 core. There's a lot of UI-configuration that the Layouts initiative is working on making possible, like picking which template to use for which layout/block, into what regions and in what order to insert which blocks, which things within the block to make visible, etc. So a lot of what's being asked for in some of the above comments will be possible, even if the answer to this thread title is "no".

Can we have a useful layout UI, and full control through templates at the same time?

This question can be asked of D7 themes currently. We have a "Manage Display" UI where the admin can control the vertical order of fields. Meanwhile, a theme can implement a node.tpl.php or node--article.tpl.php that renders fields in a different order than the administrator configured. We try to provide variables to templates that make it easy for the template to implement the requested configuration, but the template does have the ability to deviate from that. As we build more configurable layout tools for D8, we'll need to keep making it easy for the templates to implement the requested configuration, and trust template editors to know what they're doing when they override configuration choices.

From my experience, I don't see how adding classes through the UI would be a bad thing.

I agree with this. Adding classes is a small subset of "controlling wrapper markup", and we already have a mechanism by which modules can add classes to the $classes variable of any template. Once we have an initial Layouts initiative block configuration UI in core, we can certainly open an issue for adding UI for specifying additional CSS classes to add to the block. Even if that issue is rejected for D8 core for some reason, it would be very easy for a contrib module to add this.

As a designer (themer is a

Jon Betts's picture

As a designer (themer is a term that really shouldn't need to exist) I want to design using my favorite tools, HTML, CSS and whatever else comes down the road. My main issue with Drupal is not knowing how to refer to a particular field I need to use in a template. This is the "problem" that is solved for me with pointy-clicky. I don't need to worry about it. I select an h2 for a title field and I don't need to worry about render arrays or plain text whatever's, etc.

It is however, a very tedious process compared to adding a few variables to a template file and currently a nightmare when it comes to source control. I just need to know, consistently, how to add those variables and without needing a deep understanding of PHP or the many layers of potential places the variable can be changed. This is the aspect of Drupal theming that I think needs to be addressed. I just want to be able to do my job without the need of a developer in order to do visual design and communications.

That said, I can see how certain demanding clients may wish to have a lot of control over the formatting and I would not want them to have access to the source files. For them, a pointy-clicky interface would be desired. But as mentioned by others, I don't think this is necessarily something that should be included in core. At least not at this time.

analytics

btopro's picture

It might be interesting to mine data from reporting drupal sites to d.o. for things like using modules that help provide this functionality or things like it already like semantic views. It might also be interesting (and I doubt that the update.php thing sends this) to see on sites using fields how many actually use custom formatters per field for rendering and how many have template / advanced template.php style enhancements for field theming. That way we could have some kind of numbers to justify a move in this direction. I know I try and avoid writing template files as much as possible in favor of formatters on things like views, yet content types do wacky stuff with block configurations and arguments to get things to render more appropriately.

Let me be a front end developer, not a themer.

RobW's picture

The idea of a themer exists only in the Drupal world -- it's the product of the platform specific skills you need to do front end development in the Drupal system. Front end development is an industry, defined by near universal web technologies: html, css, and javascript.

I want to see the theme system move towards the way most front end devs work, not an esoteric Drupal-only workflow. Design and front end development are necessary for first class web products, and if we want Drupal to live in that space we have to start supporting the way those teams work. This doesn't mean abandoning the often mentioned amateur sitebuilder (who I'm not sure is as large a part of Drupal as some think) that downloads, points, and clicks their way to a fully functioning site, but it does mean that we need to understand both audiences, what they need to do with the CMS, and what tools we need to give them.

Point and click users need to be able to easily build a default site without getting their hands dirty. Give them an install profile and links to the top ready made contrib themes for that profile, let them tap away and enjoy (see tumblr, re: massive success). Front end developers need fine grained control over template code and behavior, the ability to completely custom and fine tune user experiences while working alongside the rest of their design and development team. We are professionals. We write code.

And honestly, if you care about the semantics of your wrapping element, it's time to start learning how to write code too.

I love Drupal because of the beautiful way it handles content management, and I want to build every project that comes my way on it. It does so much right. But as things stand it doesn't make things easy for the front end developer, especially those who are future facing, mobile ready, and skilled in modern techniques and best practices. I want to see a Drupal that's friendly to them (myself included), with light default markup controlled as much as possible in one place: through template files, not in ui.

To sum up, Less clicky more typie. Drupal themers Front end developers need to put that on a flag.

(I'd also like to say thank you to Jacine and all the rest who are doing the hard work of collecting our community's opinions and helping to fold them into a roadmap for the future/Drupal 8.)

A novice 'themer'(?)

dOwen's picture

Having built a single Drupal site and created a special content type with CCK, Views and Image, I was especially impressed with Drupal as a powerful CMS. I looked forward to more Drupal projects.

Then I worked on (non-Drupal) sites with my own custom responsive/adaptive designs and jQuery UI elements styled with jQuery's Themeroller. Am I missing something or is it even possible to use a Themeroller CSS file in Drupal? Can I use jQuery accordion menus, tabs, buttonsets, dialog boxes, timelines, etc.?

Can I create custom responsive/adaptive themes? (If I use Adaptive or Omega themes, do I have full control over all elements?)

These seem like must haves as Drupal looks forward, especially fully supporting the jQuery UI.

Like I say, maybe I'm missing the obvious. If so, sorry.

Graeme Blackwood's picture

One of the things we discussed at Frontend United was the need for the same control in the GUI as we will be getting in code. A chap called Thijs has blogged about his concept for how best to approach the Drupal theme layer through the GUI: http://thijs.drupalgardens.com/content/markup-styles

It's a short post and very worth a skim.

Good GUI

peterx's picture

The more things you move out of code into the database, the more options you give people to change things. GUIs can then be add on modules with several fitting different requirements. Performance is easily solved by compiling the result into a usable system, technology known and used back in the 1970s, now adopted by Google for their faster version of Java.

Ok, themes already do it with colours, compiling a CSS file from your colour selection and a CSS template. That can be done to a .tpl file or a twig. Code already exists in several applications to do exactly that. I did it in a Drupal 5 theme then switched to XSL to generate XHTML instead of HTML.

All we have to do is decide exactly what we want to change so we can define what is in the database. Classes? Ids? Divs? Do you want the flexibility to replace one div with three when you want to create a fancy position option? This is the difficult bit and many of the programmers working on Drupal have a hard time thinking about what could be changed.

When we have the change list in a database, the change can be programmed in through PHP, Cel, Twig, Smarty, any of the template programming languages. Twig appears to have already won the political battle to be the magic solution. Twig compiles templates to PHP code. The Twig templates can be built from the database. The build process can start with other sorts of templates. You could go from XML through XSLT to a Twig then let Twig compile to PHP.

The process of generating the code to be used by Drupal is not a problem because we already do that. Placing Twig in the middle is no more difficult than using XSL or anything else. The problem is deciding what level of change you want to allow.

My vote is to have the option to make divs optional around empty spaces, to add classes and ids, to define colours once by name then have the RGB string inserted where needed. The definition of colours should be on the site configuration page then used everywhere by all themes. I should be able to define purple as whatever I want then tell the themes where to use purple and have one place to change purple to a different RGB value.

Do we want users to change things? If we do have everything in the database and some users are allergic to purple, they could change the RGB value in their profile and see the site in another colour. The system would generate a modified version of the CSS for that user when that user requests the change.

How do you copy something like this from test through Q&A to production? You do not have to export code, you just export the data the same as the current dozen export modules export vocabularies and other things.

Given more than 30 years history of moving things into the database, and Drupal being a leading example, it is time to move themes into the database, allow any sort of GUI to change the database, and generate the final processing code from the database.

Code in database met a challenge

dozymoe's picture

Having theme configuration(??) in the database met a strong argument at [meta] New theme system about development and testing workflow. No one answered the challenge yet, and that thread was closed.

peterx's picture

@dozymoe, I followed the meta discussion, and contributed my 2.2 cents worth (GST included). The discussion did move toward storing stuff in the database and the discussion was shut down. The original database related discussion was about storing the template, the input to Twig, in the database so we could edit online. Some programmers confused the input template with the output code and said no to storing the input in the database.

The whole point of Twig is to separate the template from the code to a greater degree than the current theming system. Both Twig and the current theme .tpl files can be separated from the underlying data processing in the template.tpl.

You can lock up the Twig code files in Git, or anything else, without locking up the theme settings, which makes many of the suggestions neutral in that respect.

The current Git lockup does not lock up colours, images, or many other theme settings, only code. Moving to one of the several "template in database" suggestions from the meta issue would not change the degree to which you prevent changes through Git.

Code in Git? Yes, that is one of the few reasons for changing to Twig. Template in Git? No, it is not related and will be made obsolete by all the other "theme components in database" changes proposed for Drupal 8 outside of and cooperating with Twig.

Is twig safe?

peterx's picture

I keep seeing references to Twig being 'safe' but all I can find in the Twig manual is a reference to automatic escaping and you can easily bypass that, in fact they provide a shortcut to the unescaped value.

If we open up theming with a GUI to the point where people can make data appear or disappear, we need to implement real security. The twiglet can display data not meant to be displayed, exactly the same as a .tpl file. We need security to stop the themer seeing stuff we do not want them to see. At the same time, we need to let them see the data the way the user will see it.

When we display the themed page/block/blob for the themer in preview, we need to let them see it as displayed for anonymous, authenticated, and any other role that might have a special display, except for the data we do not want the themer seeing. I suggest hooking the masquerade module in the theme UI.

Thijs is good

peterx's picture

I like the suggestions by Thijs. Fits in with the idea of defining colours in one place for all themes. I would like to see something like an xx profile then a xx-front profile inheriting from xx.

Also needs to fit it in with variations by screen size. xx-htc-tinyphone, xx-htc-tinyphone-front. The Thijs suggestion with the option to select a parent would work.

variations by screen size

dOwen's picture

I think the lists of mobile devices is already prohibitively large. That is why adaptive or responsive themes provide the only practical means of universal device support. The theme can be easily tweaked to support greater granularity (numbers of breakpoints) without specifying individual device. For every device that you provide an individual 'profile' you will have ignored twenty others.

Variations by size, not pixel count

peterx's picture

I find themes adapt to the number of pixels, not the screen size. Given the highest resolution display occupies half the screen length of the lower resolution devices, you need a way of relating your display to the screen size, not the number of pixels. If there is a trick to getting the screen size without knowing something about the device, I am happy to use it.

Example

dOwen's picture

The new iPad has a 2k display but 'tells' the browser it is 1k. Don't know how.

Your point is very well taken. Still, it seems like an issue the device manufacturers will have to solve. Either that or Google or somebody will maintain the list.

A very complex task

laura s's picture

and I feel too complex for core, especially if you consider that, really, any such UI would best be targeted per theme. Semantics aside, these kinds of things create temptations to add classes particular to a given framework or js library, which means that theme changes could end up requiring hours of configuration as well.

I also feel that since HTML5 is still becoming what it will be, any implementation would need to be agile enough to keep up, and that means it's more ideally suited for a contrib implementation.

And when you consider that Drupal is becoming more platform agnostic, so that it can serve as a logic handler, content manager for more of a services-based serving of content (see WSSCI), quite a number of projects would have no use for such handling.

I'm generally against the idea of trying to shoehorn this into core. Let contrib handle it. Those who want to tinker with things in the UI can work on such an implementation. There might be many approaches. Let them be explored in D8 (and D7) contrib.

Related: The issue to allow themes to require modules. http://drupal.org/node/474684

Laura Scott
PINGV | Strategy • Design • Drupal Development

Theme development

Group organizers

Group notifications

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