field with multiple values, not marking itself properly as block level element for views integration?

Fields that have block elements need to set 'element type' to 'div' so that they won't get enclosed in spans.

see views_handler_field::element_type()

Experiencing this problem as well with a node reference field. Subscribing.

Did you check with latest CCK -dev (fairly stable, a 2.2 release is imminent). Some fixes around this area went in #392476

OK just found this and it looks like this may be the problem.
The following code is from /cck/includes/views/handlers/content_handler_field.inc
This is from the latest version of CCK 6.x-2.2

  /**
   * 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'];
    }
    // TODO Figure out exactly when to return a div or a <span>. Any field
    // that ever needs to be shown inline in Views UI. It needs to return
    // a div for textareas to prevent wrapping a <span> around a <p>.
    // Earl says we need to be sure that other fields we don't know
    // about won't end up wrapping a span around a block-level element.
    if ($this->content_field['widget']['type'] == 'text_textarea') {
      return 'div';
    }
    else {
      return 'span';
    }
  }

It would appear that unless the content type is a textarea is is being inclosed inside of a <span> the comments also would appear to support this:

    // Earl says we need to be sure that other fields we don't know
    // about won't end up wrapping a span around a block-level element.

So now I am not sure how to proceed from here does anyone know how I can change this without touching the core files for CCK?

This is a real problem as this is the one issue that is keeping the site from validating and the project must by contract validate.
Thanks.

I am having the same issue (span class="field-content") on a non cck field (node_title).
My view has a block display with style = unformatted, row style = fields(inline not checked). Fields are node title and 2 cck fields. Because I wanted to create h2 tags around my titles, I created a views-view-field--myviewname--title.tpl.php file and wrapped the h2 around $output.
It was then that I noticed the span tag when I attempted to validate my page. I could remove the h2 tags but then my Headlines would be wrapped in a span tag - not good for seo.
Earl says:

Fields that have block elements need to set 'element type' to 'div' so that they won't get enclosed in spans.

How is this done? If this is a template override could someone post an example?

(update: I just ran a validation on the much heralded drupalcon dc2009 website. 10 errors all because of this issue. For now, I guess I'll let it slide)

Yes it is a problem and I consider a big one because our clients expect and pay us to write valid code and in this we do not have the luxury of letting it slide. Is there no solution to this issue? I am not trying to denigrate the people that work on and created this module. Just the opposite it is a god-send but I am still left with a client that wants to know when we (the company I work for) are going to resolve this issue. At this point I will even accept a hack of core files if necessary though I so do not wish to go that route.

Can any one shed any light on this?

I committed the attached patch, which should fix the problem.

I did not try the patch yet, but i would second TheresaB's opinion. This should be fixed.

Its one thing with the XHTML, but I Safari refuses to show the image field, wrapped in that span tag. Firefox is not sure, sometimes it does show it, and sometimes it does not.

Anyways, I will try the patch and hopefully it will solve this. Cross fingers.

Which version of CCK should be patched? I am working with 6.2.2 while this issue is for 6.2.1. Can i still apply the patch though?

I am using 6.x-2.2 and it has the problem for me. Is the patch going to be rolled into a new release or dev release anytime soon?

See #10 : the patch has been committed to -dev already.

yched, thanks so much for you work and for doing this but... I am still getting the following code output;

<div class="views-field-title">
<span class="field-content"><h2 class="pageTitle"><a href="/events/Recycle-For-Reuse.html">Recycle For Reuse</a></h2>
</div>

As you can see I am still getting a span wrapping my <h2>.

In my field. I have not defined it as inline in views and there is setting in CCK Title field for configuration. What information can I provide to help in this matter?

The problem Theresa is having may be less CCK and more Views, so probably deserves its own issue in the Views queue.

Theresa, for now I think you may be forced to actually use a theme template to do what you want to do; Views doesn't scan the HTML you're adding via rewriting to see if you're adding block elements, and there's no way to tell it you're adding those. Ordinarily title *is* an inline element, so it adds a span tag, but you're turning into a block element.

I first ran at this as it was Views but it seems to be from the code in post 6 that is causing the problem. I say this because Views is not writing the <span class="field-content"></span> but it does seem to be coming directly from the code I cited.

I could be wrong but from I was told over on the Views side that is the cause because the Title field in CCK is not considered a text_textarea. Am I wrong in this?

I am using the following code to wrap an <h2> tag around the anchor from views in my template.php

function kslb_views_view_field__event_listing_upcoming__block_1__title($view, $field, $row) {
  return '<h2 class="pageTitle">'.$field->advanced_render($row).'</h2><!-- this code is in template.php -->';
}

I can also include the temple file if that would help.

Theresa: I think the problem may be that we are adding h2 tags downstream from where the decision on what the fields element type is. I believe you added the h2 in the template.php and I added it in a views-view-field--my_view--title.tpl.php file. Neither views nor cck has that info when making the decision as to whether this should be treated as inline or block.

I think what we need is an override switch in views for cases such as this. I thought the "inline fields" checkboxes in views(views row style fields settings) would do this, but in my case they only turn blocks into inline elements, not the other way around.

Yes, that's it exactly!

You can correct for it in the next template up (views-view-fields if you're just using the 'fields' row style) as a workaround. That's a fix you can implement now to get your HTML to validate.

Got it working. That was so easy I feel, well, stupid.

Thanks.!

I shall look again into that and see if I can figure out how to do that in the code and then check to make sure it does not mess up my other non-row views. and post back my findings.

Thanks Merlin.

Dogboy what exactly did you change to get it to work?

I still find that this is the line of code that that is problematic for me in views-view-fields.tpl.php

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

My problem is the variable element_type in that I do not see how it is being set to be a span. If I understand it right the variable element_type is being set in CCK and I am not sure how to over ride it with out "hard coding" a div there.

Am I looking at this wrong?

First, it would be best to create a template just for the particular view(s) your using/having the problem with. (i.e. views-view-fields--my_view_name.tpl.php) Then, if you're good at php, (I'm not) you can write some logic that will change all fields that you need to be blocks (node titles for me) and set element_type to "div'. I did something, shall we say, more sledgehammer like:

<?php
      // Set the fields in this view to be treated as blocks
	    $my_element_type = 'div';
      ?>
      <<?php print $my_element_type; ?> class="field-content"><?php print $field->content; ?></<?php print $my_element_type; ?>>

Anyway, I'm sure someone else here can produce a more elegant solution. Good luck!

dogboy, and to all the others that have replied thank you. That worked as a fix and though I still would like to know more how the CCK assigns the element_type as it is a pain to to do that for all the views.

So that anyone coming behind will know what dogboy did and how to do it for their own site;

First copy views-view-fields.tpl.php from the Views module [views/theme/views-view-fields.tpl.php] into your theme folder.

change the name to views-view-fields--my_view_name.tpl.php and them look for the following line of code:

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

Then to make it easy just highlight that line of code and copy the following code;

<?php
      // Set the fields in this view to be treated as blocks
        $my_element_type = 'div';
      ?>
      <<?php print $my_element_type; ?> class="field-content"><?php print $field->content; ?></<?php print $my_element_type; ?>>
      <!--<<?php //print $field->element_type; ?> class="field-content"><?php //print $field_content; ?></<?php //print $field->element_type; ?>>-->

You will see that I included the original line but commented it out so that at a later time, if a more eloqunet solution is found, it can be changed back easily.

Once more I want to thank everyone here for all their help in this mater and I shall also post this solution in the issue I had open in the Views module.

Now everyone go and have a great weekend!

The genaral issue here is that its really hard for CCK to know whether the output of a field value will contain block-level elements.
In the end, what is displayed is entirely left to field 'formatters', which themselves are theme functions that can be overriden in the site's specific theme.

For instance, an image field displayed with the 'display as link' format produces no block-level element (<a> tag), while the same field displayed with the 'display as image' format produces img tags.

It's really a combination of field type + formatter.

I don't think this qualifies as critical per se, BTW.

yched, apologies then on the critical and I understand the difficulties of programatically trying to do this. Perhaps I should make a suggestion to the Views team to provide a override selection, just as one can now define for the element to be inline perhaps they can offer a toggle to define as block or such.

As for the critical I personally believe it is was as valid code is very important not just to me but is a requirement in all of our projects. Yes, this problem could have handled through theme formatting, which is wonderful, but for the person that is coming into Drupal it can be over whelming and honestly trying to find an answer with the search feature here is daunting and many times useless. I actually find more answers through google's results of drupal posts.

Anyway, so many thanks to you and all here for the help and for such wonderful module that has literally cut my development time by as much as 50% at times.

Theresa, please understand that it's been explained that the reason it turned into a block element is because you added an H2 tag to something that is ordinarily inline. That doesn't even qualify as 'normal', that's actually quite minor. If you want it to validate, take out the H2 tag, Yes, I realize that's not what you want, but there are clear workarounds to the issue. You're being surprisingly inflexible about something that ultimately amounts to a problem caused 100% by *user input* doing something unexpected.

At this point I am comfortable in stating that this is absolutely not a CCK bug, and that you have a workaround solution.

Merlin,

I am not trying to be inflexible here and I apologize if I came across as such. Yes I did place the h2 tag because the field is a title field and I am only trying to write semantically correct code. Yes I could remove the h2 but then the code is no longer semantically correct. You are correct, I do have a "workaround" but is a "workaround" the proper solution? I understand that I have done something "unexpected" but is it really unexpected to place a title field in a title tag?

As I said I am not trying to be inflexible, I merely pointed out a problem with getting my code to validate and to be semantically correct is all. If you wish to consider this matter closed, I understand and will no longer comment, but please do not confuse a desire to be helpful with inflexibility.

Thanks.

As it happens, yes, I never actually expected that when I implemented the field rewriting. This is primarily because if you're placing tags, I believe you really should be doing it at the theme layer. So you're using a feature for something that it really wasn't *intended* for, but you happen to be able to use it to do that. The output rewriting is meant to allow you to add some decoration to the fields, but if you are going to change the semantic value of the field, I do believe you need to do that at the theme layer.

To be fair, you're in an area of Views that's still very new -- this feature was only introduced as of Views 2.3 and the full extent of what people are going to do with it hasn't been really seen yet, either.

I have just hit the same issue, and whilst I do understand why you say that the issue is caused by using a feature for something that it wasn't intended for, I actually dissagree. My reason for doing so is that in Views, underneath the 'rewrite the output of this field' check box (which I have done for Node : Title in my case) is says quite clearly

The text to display for this field. You may include HTML. You may enter data from this view as per the "Replacement patterns" below.

Note, You may include HTML!

So, I set mine to:
<h3><a href="node/[nid]">[title]</a></h3>

I haven't done anything that I wasn't supposed to do, I have rewritten then output of the field using valid html, just like it said I could... So, either this is a bug that needs fixing, or, the description in Views needs rewording to make it clear what you can and cant include.

Personally, I think thing Views should do some scanning of the rewritten out put and decide again weather the output really should be wrapped in a span, of if it would be better in a div.

I'm having the same issue with headings in my node titles. The span prevents my view from validating as XHTML.

Honestly, it doesn't make sense that there should be any span tag there.

If someone is going to rewrite the output of the field, I don't see that fancifying divs or spans are needed, since those can be added manually.

Seems to me you can change textfield to textarea then change the number of rows to 1 to make it look like a text field. I did this for my "display date" the date needed to be styled and behave like block elements, and did not validate because I had a div inside a span.

None of the fixes worked for me. But this is a simple work around for the people getting their titles wrapped in spans then add headers or other block level items.

Like #30, I want to add h3 to the row titles.
Subscribing.

Subscribing.

Sometimes you may want to inject extra elements at the theme layer for a field.
However, this means you *always* have to overwrite another template to return a div instead of a span.

Subscribing and agree with #30

create a template like #18 @merlinofchaos said...

use rowstyle template then do this to your fields:

<div class="views-field-field-title-value"><?php print $fields['field_title_value']->content; ?></div>

['field_title_value'] - is the ID of the field

this eliminates the <span class="field-content">

This is the second time in a week that I've come back to this node. So I thought it was about time I wrote about my experience.

The first time was because I had a field which sometimes got wrapped in a div and other times it got wrapped in a span.
I noticed this since I had more than one view basically showing the same data.
Initially the behaviour appeared random... but I determined it was probably something to do with having a multi-value field (allowing two items) ... where only one of the fields was populated.

My particular circumstances were: Style: unformatted, Row style: panel fields, Field: email CCK
Where I wanted the label and field values to appear on the same line e.g.
email: herb@bobbingwide.com
I actually ended up with a div tag, therefore getting
email:
herb@bobbingwide.com

I fixed the problem by ensuring that 'Group multiple values' was unchecked.
But this meant that only ONE of the values was shown, not a problem in this particular instance.

Now I'm here again, but this time with the SEO related heading problem on my title fields.
I now note that if I create a template file to wrap the title in h3 tags
e.g. views-view-field--title.tpl.php containing

print '<h3>'.$output.'</h3>';

it still gets wrapped in span class="field-content"
Which causes XHTML validation to fail.

The simplest solution appears to be to forget about the div and span stuff altogether.
So in my views-view-fields.tpl.php file I have replaced

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

by
print $field->content;

My question(s) are simple, possibly naive

Short term:
Can I get away with my workaround or will it come back to bite me?

Long term:
Why does it have to be so complicated?
Do we really need all these automatically generated div and span tags with generated class names?
Can't we have a couple of options to tick when we need them?

Hi herb_miller, altering the template code as you have done seems perfectly reasonable to me, I wouldn't even go as far as calling it a workaround. If you want to take it even farther, you should check out the Semantic Views module, which helps produce very clean markup without having to muck around with template files.

Been plagued by a very similar situation, and reading this discussion really helped. I think I found a reasonable "solution".

Looking at views-view-fields.tpl.php, the line TeresaB and dogboy72 are editing reads:

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

Instead of forcing $field->element_type to "div", I changed the line to read:

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

Now, the nested element is the same as the containing element, so if you have an inline element, you get a containing span and a nested span. If you have a containing div, you get a nested div.

It's not pretty, but it validates. At least on my site :) It does seem really redundant to have 2 containing elements for each piece of content, regardless.

I looked at Semantic Views, and it looks promising, maybe I will try it on my next site.

Double thanks for everyone who posted here.

#39 worked wonderfully, thanks a lot for this!