html_element property of field handler often produces invalid markup

I don't know why views does this currently, but views sets the element type to span, if you use strip_tags. I guess you use it here, but its impossible to say, because you missed to paste the export.

That span is coming from views-view-unformatted.tpl.php (I think; would have to double check to make sure I have this right) -- you could override the style template (either globally or for that view). You might also get some mileage out of the semantic views module which might help with that as well.

(Reopening because I think there must be a more complete answer)

Actually, the span is coming from views-view-fields.tpl.php. The comments on lines 34 and 35 say this:

// $field->element_type is either SPAN or DIV depending upon whether or not
// the field is a 'block' element type or 'inline' element type.

What I'm wondering is whether that's supposed to be controlled by the checkboxes in Row Style->Fields->Settings->Inline Fields.

In theme.inc, $object->element_type is set by $object->handler->element_type();

In /handlers/views_handler_field.inc I see $this->definition['element type'] but that's where I get lost because I can't find anywhere in the views module where $[anything]->definition['element type'] is set except in views_handler_field.inc in render_trim_text(). The comments there say that external fields might override the element type.

So what I'd like to know is: is there a way to "correctly" override the element type so that it is seen as a block element rather than an inline element type?

I "fixed" this problem by adding a views-view-fields.tpl.php to my theme and adding the line

$field->element_type='div';

before the print statement that rendered the field. That seems like a bit of a hack though. Is that really the best way to approach it?

Edit to add:

Forcing $field->element_type to div in views-view-fields.tpl.php indeed made all my inline fields (specified in Row Style->Fields->Settings->Inline Fields) revert to non-inline display. It's not surprising, but it does indicate that there is an intended relationship between the settings in Row Style->Fields->Settings->Inline Fields and the value of $field->element_type, and that that relationship is not being honored.

That seems to elevate this from a support request to a bug report unless I'm wrong about Row Style->Fields->Settings->Inline Fields and $field->element_type.

wondering the same thing:

// $field->element_type is either SPAN or DIV depending upon whether or not
// the field is a 'block' element type or 'inline' element type.

What I'm wondering is whether that's supposed to be controlled by the checkboxes in Row Style->Fields->Settings->Inline Fields.

Even when there are NO fields designated as inline, I usually see <span class="field-content">

It appears that if there's a block-level element inside - p, label (is label a block element?) - then it renders as <div>, if not it seems to always render as <span>. So the checkboxes may not be the only control.

It would be helpful if $field->element_type is <div> for ANY fields not specifically checked as inline in Row Style->Fields->Settings->Inline Fields. Having divs within a span breaks validation.

EDIT: see this patch: http://drupal.org/node/740686

Also wondering the same thing -- why are there 2 variables in that template that determine if the field should be div or span?

 *   - $field->inline: Whether or not the field should be inline.
 *   - $field->inline_html: either div or span based on the above flag.

and also:

      // $field->element_type is either SPAN or DIV depending upon whether or not
      // the field is a 'block' element type or 'inline' element type.

greping element_type in the views module, it's a function in the api for the field handler:

  /**
   * Return DIV or SPAN based upon the field's element type.
   */
  function element_type() {
    if (isset($this->definition['element type'])) {
      return $this->definition['element type'];
    }

    return 'span';
  }

But it's only reimplemented in views_handler_field_markup, and views_handler_field_user_picture to return a div in core views. This creates invalid markup everywhere when rewriting output either with templates or using the UI while providing very little value. I would argue it should get removed from the default template altogether. Down side is it might break some people who've done some advanced theming that happens to use that element. You might be able to get a handle on the scope of the badness by grepping the contrib repository for the 'field-content' class.

I'm wrong actually -- there's value when there's a label present, so you can wrap both the label and the content in containers. But it's redundant when there's no label, and if there is a label it still produces invalid markup by potentially nesting block elements inside the inline span. You can break it quite easily with just using the UI, but you can't fix it without theming, which is bad.

I've added the following line before the print in views-view-fields.tpl.php to fix this problem. Well it's more a hack until the real bugs are fixed.

if (preg_match("/<(h[1-6]|p|div)[^>]*>/",$field->content)) $field->element_type = 'div';

+1 until bug got corrected

+1

subscribing

+1

Code is slightly changed after #740686: Integrate semantic views

Thanks Tekl, your line in post #9 substitutes span with div, and the page now validates with W3C Markup Validation Service.
Note to others: Enter the substitution magic at line 26 in views-view-fields.tpl.php

Thank you that worked perfectly!

closing from a lack of activity.

You may fix the inappropriate markup by using this in views-view-fileds.tpl.php:

<<?php print $field->inline_html; ?> class="field-content"><?php print $field->content; ?></<?php print $field->inline_html; ?>>

(inline_html instead of element_type)

But this doesn't fix the views-field-nothing bug!

This was actually happening in a link function on a view.tpl.php I encountered. I guess maybe a field shouldn't be used to construct a link? Or rather views was never intended for this? So i just stripped the tags, and that fixed it, this may be the same thing as checking strip tags on the field, but I didn't want to alter the view:
<h2><?php print l($title, strip_tags($fields['entity_id_3']->content), array('html' => true)); ?></h2>

This bug still exists even in 6.x-2.12. The workarounds shown may help but why is this closed when not fixed?

I used sematic views in my case to fix it, but this problem should not exist by default. As already described above there is a span even if no field is inline.

So changing the status back to give it a chance again to be fixed!

When strip tags is used the views handler assumes all markup is gone so it uses a span instead of a div, this also happens when (block) tags are preserved so this situation needs to be handled to prevent validation errors.

I fixed this by checking the fields value and only setting the element type to span if it doesn't contain any block elements. I attached a patch with the fix.

Solution in #9 works great for me.

I'm still using views 2 branch... the patch in #21 applied cleanly to 6.x-2-dev but was not effective... is there something 3.0 specific about it?

I had problem also with this bug and I solved it with the help of this module: http://drupal.org/project/semanticviews

Have you tried get into the VIEWS settings? So there are options that turn off any framed HTML tags of the field... View more. What for all of these patches?

#9 works!!!

I had a lot of validation errors using Views 6.x-2.12.

Code after change (middle line added):

  <?php endif;//***after this line*** ?>
  <?php if (preg_match("/<(h[1-6]|p|div)[^>]*>/",$field->content)) $field->element_type = 'div';?>
  <<?php print $field->inline_html;//***before this line*** ?> class="views-field-<?php print $field->class; ?>">

Regards

The Drupal 6 branch is no longer supported, please check with the D6LTS project if you need further support. For more information as to why this issue was closed, please see issue #3030347: Plan to clean process issue queue