Inline fields separator gets spaces before and after it

You might be getting whitespace due to formatting in the template, though that's kind of unusual.

Ok, I've confirmed these spaces are coming from whitespace in the formatting of views-view-fields.tpl.php -- and taking out this formatting would really harm the editability of this template. Since not having spaces there is a fairly rare event, you're going to have to override this template yourself and remove the whitespace. It's not ideal, I understand, but the alternative is to make a template that is basically unusable to anyone else.

The whitespace is coming from the fact that the browser translates a carriage return around a tag as a space. It means that you pretty much have to edit the template and put everything on just one line.

And I'm simply unwilling to publish a template in that state.

Which template to edit?

I'm having the same problem, where if I say use ", " as a separator, I get " , ". I read the above, and I believe I understood the developer's point, but when I used the theme URL to generate a "Row style output" tpl.php override, (which seems to me to be correct) I was able to modify output in some fashion, but if I changed the entire file into a single, non-carriage returned string, I still got the extra space before the comma.

I love views 2, FWIW.

Update: Fixed

Update I was in the right file -- I ended up taking out all whitespace characters that were between tags, and I took out an 'extra' span element:
<?php foreach ($fields as $id => $field): ?><?php if (!empty($field->separator)): ?><?php print $field->separator; ?><?php endif; ?><<?php print $field->inline_html;?> class="views-field-<?php print $field->class; ?>"><?php if ($field->label): ?><label class="views-label-<?php print $field->class; ?>"><?php print $field->label; ?>: </label><?php endif; ?><?php print $field->content; ?></<?php print $field->inline_html;?>><?php endforeach; ?>

AS stated in #3, views-view-fields.tpl.php

There is a third option, which eliminates whitespace while still retaining code readability:

Abandon "template style" PHP coding for this one template (or alternatively, implement it using a theme function), and use "regular style" PHP with print statements for total control of all output. Here is my version of views-view-fields.tpl.php:

foreach ($fields as $id => $field){
	if (!empty($field->separator)){
		print $field->separator;
	}
	print '<' . $field->inline_html . ' class="views-field-' . $field->class . '">';
	if( $field->label ){
		print '<label class="views-label-' . $field->class . '">' . $field->label . ':</label> ';
	}
	print '<' . $field->element_type . ' class="field-content">' . $field->content . '</' . $field->element_type . '>';
	print '</' . $field->inline_html . '>';
}

Should execute faster too, which can't be a bad thing for a low-level template like this.

Since not having spaces there is a fairly rare event

Sorry but I have to agree with petiar in #4... commas are extremely common delimiters (if not THE most common), and should never be preceded by a space.

Sorry, I'm not turning a template into a bunch of code for this.

That is your prerogative, of course, but mind if I ask why?

Even the theme coding conventions (http://drupal.org/node/1965) only states to prefer "tag style" PHP in templates.

Surely exceptions can be made where warranted? Conventions shouldn't be shackles that prevent real problems from being addressed, IMHO.

Or, how about putting it into a function then, instead of a template, if coding style is the issue?

Sure, it will address your real problem.

And create a different real problem for more people. You can address your problem by refactoring your template. Therefore, there is a workaround. If we make the template difficult for normal people to navigate, then more people will have more problems.

Fair enough, hopefully this thread will help anyone else with the same issue. Cheers.

RE-activated because I agree with petiar in: http://drupal.org/node/315360#comment-1041029

Re: the rest: I can't really agree that not having whitespaces is fairly rare event - consider comma - this is actually my problem as usually there is no space before comma but there is one after it. Wouldn't be easier to get rid out those whitespaces completely and carry this feature over to configuration? So the separator would not be ",", but ", ". Hope you understand what I mean.

I disagree with merlinofchaos that:

not having spaces there is a fairly rare event

I do not see why anybody would usually, by default, want unspecified (as displayed) space before a specified separator (whether introduced by Views alone or as a side-effect of the carriage return on every browser I've tried: Firefox, Opera, Chrome, Safari).

Please see attached image which illustrates the problem exactly.
It shows how, in the live Firebug editor, I have removed the newline from before the comma and after a company name 'Automatisering og Utvikling av Rutiner', so that only it correctly displays with the comma immediately after it, without unwanted white space:

Automatisering og Utvikling av Rutiner, Boks 1091 , 4391 Sandnes , Norway
Sentralbord: +47 52 76 16 00 , Fax: +47 52 76 16 11

Note how all other inline fields have ' , '. While, I understand the workaround solution, I invite the Views maintainer(s) to again consider a solution in Views that does not have this undesirable side-effect, which I keep running up against over and over.

@merlinofchaos
I have adapted a theme-specific views-view-fields.tpl.php template as recommend. That is one ugly template, and I can understand why you don't want to adopt that as a general, distributed solution (and anybody wishing to is free to as recommended here).

However, from a software engineering and requirements specification perspective, the entire chain of components together (completely irrespective of implementation elegance and appeal), has an undocumented, unexpected, and undesirable side-effect, namely resulting in white space appearing mystically before a separator.

And it undermines the entire notion of a separator.

I think this issue should remain (if at very low priority) at least active in some sense, and "won't fix" is not appropriate. It can be fixed, even if the solution is not aesthetically appealing.

BTW with all "unspecified" white space removed from my template, I now use as separator , , which reflects the complete control over final formatting of inline fields that I consider a basic requirement one should impose on the Views module.

And for the record the result as desired with adapted template is attached:

Automatisering og Utvikling av Rutiner, Boks 1091, 4391 Sandnes, Norway
Sentralbord: +47 52 76 16 00, Fax: +47 52 76 16 11
Org. nr.: 955 634 497

(BTW This in fact combines 2 mini-views.)

Also of possible interest is the fact that I needed a special field_postcode_city to get the Norwegian format 4391 Sandnes instead of with a separating comma 4391, Sandnes as achieved with field_postcode and field_city next to each other with comma separator, because there is no way it seems to specify no inline separator following a given inline field (on a per field basis).

Suggestion: could you please at least document this undesired behaviour in the Views UI near the Separator: input field for the Row style: Fields, perhaps even with a link to this issue, or with a remark concerning the template solution, with something like:

Undesired white space before and/or after a separator may be removed by editing views-view-fields.tpl.php to remove newlines in the template.

I have data that conclusively shows it's a fairly rare event:

In 2 years, only 5 people have posted about this.

That is rare enough that I am willing to say "use the work around as given."

Have read. I have implemented the solution per template. Thanks for your input.

Good UI design means that it should be difficult to have comma separators with spaces in front of them, not the other way around.

Please add this to your list of statistics requesting that this be fixed.

Good UI design means that it should be difficult to have comma separators with spaces in front of them, not the other way around.

You're right, of course. Good UI design means inconveniencing HUNDREDS and possibly THOUSANDS of users to placate DOZENS.

Oh wait, I mean the other one.

This is a genuine question not picking an argument: Can you explain why it will "make the template more difficult for normal people to navigate"?

That implies that some people can understand and interpret a template file but not php code as given in reply #10, which I find surprising - though of course I don't ever deal with people trying to interpret templates. Thanks.

I certainly can't say what is the "right" thing to do, but I searched briefly for this on one project, didn't find this thread, and just suffered the " , " formatting.

I "found" the issue again on my current project, and am glad I found at least a workaround.

I will say that the wording "Inline fields will be displayed next to each other rather than one after another." and "The separator may be placed between inline fields to keep them from squishing up next to each other. You can use HTML in this field." suggest a different result than what actually happens.

Perhaps rewording and mentioning that extra whitespace is a side effect of "tag style" PHP in templates and to check help for more information, then leading to this thread or where ever appropriate.

I'm just getting on converting a CMS I made myself ten years ago to Drupal. Drupal obviously saves a lot of time compared to writing all of my code from scratch, but it feels like it's full of little gotchas like this one that I have to hammer out to make it do what I want, namely, not insert spaces before commas.

I've inserted brian_c's code and so far it seems to take care of the problem. Thanks everyone, especially brian_c.

I just encountered this issue in D7. Though I kind of disagree with the "won't fix", I found it easy enough to put a theme-specific copy of views-view-fields.tpl.php into the templates directory in my Omega subtheme. I don't have to change the original copy in the views module.

Stackoverflow.com has some suggestions for removing the whitespace from the template function but still keeping it readable. Here's the original template:

<?php foreach ($fields as $id => $field): ?>
  <?php if (!empty($field->separator)): ?>
    <?php print $field->separator; ?>
  <?php endif; ?>

  <?php print $field->wrapper_prefix; ?>
    <?php print $field->label_html; ?>
    <?php print $field->content; ?>
  <?php print $field->wrapper_suffix; ?>
<?php endforeach; ?>

You can move the ending ?> onto the next line to close up the white space(I like this best):

<?php foreach ($fields as $id => $field):
   ?><?php if (!empty($field->separator)):
     ?><?php print $field->separator;
     ?><?php endif;

     ?><?php print $field->wrapper_prefix;
     ?><?php print $field->label_html;
     ?><?php print $field->content;
     ?><?php print $field->wrapper_suffix;
 ?><?php endforeach; ?>

Or you can wrap the whitespace in comments:

<?php foreach ($fields as $id => $field): ?><!--
  --><?php if (!empty($field->separator)): ?><!--
  --><?php print $field->separator; ?><!--
  --><?php endif; ?><!--

  --><?php print $field->wrapper_prefix; ?><!--
  --><?php print $field->label_html; ?><!--
  --><?php print $field->content; ?><!--
  --><?php print $field->wrapper_suffix; ?><!--
  --><?php endforeach; ?>

There is a CSS3 proposal for a collapsing white space property, text-space-collapse, but it's still being discussed.

Templates get cached. Isn't it possible somehow to strip those carriage returns just before they get cached? Thus, the templates stay as readable as they are, but this problem is solved.

reopening, because this possible sollution hasn't come up yet ..

Templates do not get cached.

Seriously, if this is a problem for you: Put an overridden template of your choice in your theme, and eliminate the spaces. You suffer a small inconvenience so that the 99% of users who don't care about this don't.

It's not that difficult.

In modern Views, another solution is to use tokens, where you can set a bunch of fields to 'exclude' and use a token to write them together, putting the separators in as you prefer.

It's also entirely possible that telling Views to not put any markup in at all would also address this problem.

You can also rewrite your fields to include the separator right in the field.

There are lots of solutions.

I do agree with all these per-case sollutions, I really do. I just think (and I don't seem to be the only one) that ideally, an out-of-the-box sollution should be sought after. In order to be able to work on it, at least we need one of the issues concerning this problem to remain open. Changing this into a feature request ... and status to Active (duh).

I really doubt that anyone will work on this issue, or commit a patch which makes theming ugly as hell.

Earl gave a lot of solutions which works all.

Unfortunately, the only "out of the box" solution involves eliminating or destroying the template; we can't just magically make the extra whitespace the template generates disappear, and we can't just eliminate the template.

Can we add some warning about the extra spaces that will be added (due to the way browsers deal with whitespace)? Now the description says

The separator may be placed between inline fields to keep them from squishing up next to each other. You can use HTML in this field.

Can we change this to

The separator may be placed between inline fields to keep them from squishing up next to each other. You can use HTML in this field. You may have to override views-view-fields.tpl.php to get rid of unwanted whitespace, displayed in most browsers.

Do we need to add extra information in the advanced help pages?

This issue still exists in the latest views incarnation.

I really like the solution zilverdistel proposes in #37 to make it clearer what is happening, maybe even linking to this thread for more information as well.

I used the solution in #28 to solve this and a template override works fine...but really moving the ending php tags to the next line solves it and doesn't ruin the look or have potential to cause problems for other users like other solutions that cannot be added to the module. This seems like a great permanent solution to actually include in the module.

<?php foreach ($fields as $id => $field):
   ?><?php if (!empty($field->separator)):
     ?><?php print $field->separator;
     ?><?php endif;

     ?><?php print $field->wrapper_prefix;
     ?><?php print $field->label_html;
     ?><?php print $field->content;
     ?><?php print $field->wrapper_suffix;
 ?><?php endforeach; ?>

I actually even wrapped the separator in a span and things were amazing! :D

<?php foreach ($fields as $id => $field):
  ?><?php if (!empty($field->separator)):
  ?><?php print '<span class="separator">' . $field->separator . '</span>';
  ?><?php endif;

  ?><?php print $field->wrapper_prefix;
  ?><?php print $field->label_html;
  ?><?php print $field->content;
  ?><?php print $field->wrapper_suffix;
?><?php endforeach; ?>

I suggest making a copy of the templates to your theme, and removing the sitespaces your self.

Annoying, but a solution.