New function drupal_element() to complement drupal_attributes()?

I do think this could fit into the Butler project from what I know of it - http://groups.drupal.org/wscci

Certainly worth mentioning there. This level of abstraction could possibly allow substitutions that would be useful.

What would be the performance cost of introducing this new function & running thousands and thousands of lines through it? There must be a pretty simple way to test this with enough randomized sets of data that we could determine this with some accuracy.

I don't know if with the use of SimpleTest that there are that many errors produced. I think I'd prefer the 3rd of your options. Just seems shorter & more concise.

I do wonder how this would constrain the development process. Also, we'd have to think about how this fits with the nesting of html.

There is no way to organize spacing or produce more readable HTML at least not easily.

I'm not at all opposed to doing this but also see that it would be hundreds of hours of work to complete. If it fits into the Butler project or gives us enhancements in performance however it may well be worth doing.

This is a really good idea.

I find myself missing this in PHP from time to time -- it's been in Perl for years: http://cpansearch.perl.org/src/LDS/CGI.pm-3.29/cgi_docs.html#functionvsoo

+++ b/includes/common.inc
@@ -2269,6 +2269,35 @@ function drupal_attributes(array $attributes = array()) {
+ * @param $name
+ *   The string tag name.
+ *
+ * @param $attributes

No blank line between parameters.

+++ b/includes/common.inc
@@ -2269,6 +2269,35 @@ function drupal_attributes(array $attributes = array()) {
+ * @param $close
+ *   If boolean false (default), generate only the open tag.
+ *   If boolean true, generate an XML-shorthand empty element.
+ *   If a string, use that as the contents of the element and generate the close tag.

I don't really like the reuse of this parameter. What if you wanted the contents of the element to be the TRUE boolean?

Could the function not actually know which elements are empty? (Are there any HTML elements that can be both empty and non-empty?)

+++ b/includes/common.inc
@@ -2269,6 +2269,35 @@ function drupal_attributes(array $attributes = array()) {
+  if ($close === true) {

Booleans should be in capitals: TRUE.

+++ b/includes/common.inc
@@ -2269,6 +2269,35 @@ function drupal_attributes(array $attributes = array()) {
+  return $ret;

Use $output to be consistent with Drupal.

Powered by Dreditor.

Another niggle... I'm not sure about the best order of parameters.

How often would you want a DIV with contents and no attributes, vs how often would you want an element with attributes and either empty or just the opener?

In other words, should $content go before $attributes?

Hmm and the other thing is that while I think this would be hugely useful for themers and module developers, when it comes to its use in core theme functions I think we should get some benchmarking to see how much function calls slows things down by compared to raw strings.

Can we get some performance tests with the patch applied to some sample code?

Is there an automated way to replace 90% of the lines of code used here?

How would this be tagged to bring it to a more specific group of developers to review?

Can we get some performance tests with the patch applied to some sample code?

Is there an automated way to replace 90% of the lines of code used here?

How would this be tagged to bring it to a more specific group of developers to review?

That patch gives us a good idea of what the code will look like. Seems shorter & easier to read through in many instances. Nice to have cleaned out the html from many places in the code too!

The implementation here seems to behave different from the code inlined in format_xml_elements() which probably means that this one needs work, because both implementations should probably be exactly the same and then it should be possible to reuse the new function in format_xml_elements().

Subscribe, switching component to get maintainer feedback.

I'm not sure this is a good idea. Do people who write HTML for a living, really want another function to call that will do it for them? This is the kind of thing that will make Drupal harder to learn, and increase the barrier to entry even more. I think we really need to weigh the pros and cons of this one, it should not go in without heavy consideration.

Totally agree with @jenlampton. This is an absolute no-go for me until there is a discussion about this on a much higher level about where we want to go with the theme layer in Drupal 8.

Whoops. Wrong tag.

tagging for learnability too

It's also a duplicate of theme('html_tag'); which was only committed to core on the promise that no-one would use it, and would be great to remove if we can.

> I'm not sure this is a good idea. Do people who write HTML for a living, really want another function to call that will do it for them?

I understand that point completely.

And yet every time I fiddle with getting my typo-prone fingers to properly close yet another tag, I think fondly of this from the days of perl:

print header(),
      start_html(-title=>'Wow!'),
      h1('Wow!'),
      'Look Ma, no hands!',
      end_html();

(from http://cpansearch.perl.org/src/LDS/CGI.pm-3.29/cgi_docs.html)

And yet every time I fiddle with getting my typo-prone fingers to properly close yet another tag, I think fondly of this from the days of perl.

Just because one has difficulty writing HTML doesn't justify reimplementing an abstraction of HTML in Drupal. I also would like to suggest that referencing a Perl library implementation isn't exactly something I would consider forward-thinking or cutting-edge.

Abstract idealism is the enemy of adoption. HTML5 vs XHTML was a good example of this.

If we are going to have drupal_attributes(), then it is a very small step for learnability to add the tag name to create drupal_element().

So because there exists a counterargument against this feature request, which in your opinion is also a counterargument against an existing feature, the latter's existence justifies the addition of the new feature? Let's not attack a straw man.

I agree that they shouldn't both need to exist...

IMHO, Drupal needs neither more new APIs nor more API inconsistency. I recommend closing this as Won't fix or status Postponed.

Agreed. This really makes no sense. The cost is just too high.

Historically, I believe, drupal_attributes() stems from Form API as a D.R.Y. accessory for imploding $element['#attributes'] arrays.

So, I see drupal_attributes() as an accessory to $element['#attributes'] whereas I don't see how drupal_element() is anything more than syntactic sugar. Outside of Form API, I personally don't use drupal_attributes() much when theming, and I dread the thought of tpl files turning into a bunch of print drupal_element('div', $attributes, $content)

Were I a new developer learning Drupal looking at a theme function for the first time, I would wonder "Where is the HTML?"

Not to pile on a won't fixed issue, but just pointing out that drupal_attributes() is important and necessary for a couple of reasons:

a) It allows modules (such as RDF) to dynamically inject additional attributes into tags. This wouldn't be possible by hand-writing these attributes out one by one like we did in D5 and D6; you'd need to change the templates to manually check for additional variables being present.

b) It also deals with the sanitization of these dynamic values, which are coming from who knows where, which eliminates the risk of XSS vulnerabilities and other nasty things.

Contrast this with writing HTML in a template. In addition to the abstraction argument, there's no chance you introduce XSS vulnerabilities into your own hand-written code, and it wouldn't make sense for modules to dynamically insert more <h2>s in your template without your prior authorization.

Hope that helps.