Removing blank lines for txp tags that don't output anything

Bloke · 2025-04-02 08:56:45

This is something that’s way way waaaay down the list, but it’s always kinda bugged me that any tags that don’t output anything (e.g. conditionals, <txp:variable>, <txp:if_variable>, <txp:evaluate>, <txp:output_form> etc) still generate a blank line per tag in the outputted HTML.

Quite often, I have a ‘variables’ form that sets up a bunch of things, with many lines in it, and that leaves a huge blank space near the top of the generated page.

Another thing I do is put conditionals inside headings or divs so it constructs a title or adds class names based on whether an article contains custom fields. e.g:

<h1><txp::art_title />
<if::custom_field name="serial">
   (<custom::field name="serial" />)
</if::custom_field>
<if::custom_field name="features">
   with <custom::field name="features" />
</if::custom_field>
</h1>

which renders:

<h1>Super mega widget

   (123456)


   with muffler

</h1>

Sure, the browser doesn’t care but it’s extra bytes sent for no reason, and they add up.

I know I can condense my code into one line or use a plugin to gobble whitespace. But sometimes, especially when doing complex nested conditionals to output schema.org metadata based on whether something or other is set in the article, that becomes unwieldy to read and manage if it’s all modged into a single line in the form. It’s nice to separate it out for readability.

Is there anything we can do to prevent conditionals etc taking up ‘space’ in the rendered HTML? I suspect the answer is no because the act of me pressing enter in the source document renders a blank line and there’s probably nothing the parser can do about that. But I thought I’d ask.

phiw13 · 2025-04-02 09:42:02

Gzip does an excellent job at squashing all bytes, so the transfer of the page over the wire is not affected.

Readability is a little problematic. Doesn’t the trim attribute help esp. on <txp:if_something> type tags?

jakob · 2025-04-02 09:42:33

Same here. I do similar things. In past more-OCD days* I used to bunch together code to get cleaner output but after the browser dev tools started rendering source code more cleanly I relaxed.

You can, of course, enclose those sections in <txp:hide process>…<txp:hide> but that’s not the point. For some details that are so frequently used that they might as well exist on every page, I make a page_vars form that is inserted in the head area and completely surrounded in txp:hide process. There are advantages and disadvantages to that approach: one the one hand they are grouped together, on the other separated from where they are used.

*in my defence, blank spaces in old-style float & display:inline column layouts were previously a problem.

etc · 2025-04-02 10:10:07

If wrapping is not an option, trim can only help partially, rendering

<h1>Super mega widget
(123456)
with muffler
</h1>

Technically, it shouldn’t be difficult nor expensive for the parser to ‘normalize’ the between-tags space, but do we want it by default? Certainly not in scripts, pre etc.

etc · 2025-04-02 11:07:09

Bloke wrote #339423:

that becomes unwieldy to read and manage if it’s all modged into a single line in the form.

If you call the form directly, this might help:

<txp::my_form escape="tidy, trim" />

Bloke · 2025-04-02 20:08:43

Hadn’t thought of wrapping in <txp:hide process>. Great tip for the variables form I inject into the page head. Thank you.

With regards calling forms directly, I wasn’t clear, sorry. I meant stuff inside the form, like multiple complex conditional blocks I might use (if-else-if-else). I suppose I could put those into a sub-form and call them like you suggest but there’s only so many times I can do that before it starts to smear the logic between more forms than necessary, which makes it perhaps harder to chase through and understand how things hang together.

For the record, I’m fine with the stuff appearing on new lines if they’re together, it’s the extra blank lines in between that sometimes bugs me. Not enough to do anything about, haha, and as you say, we’d need to be careful as some content might be intentionally laid out that way. And <txp:variable /> can take output so we’d not know if it was being used for assignment only. But even if just the conditional tags always took up ‘no space’ (besides perhaps a line break) it’d condense the rendered page a bit.

Dunno. Not a huge issue and it doesn’t affect my enjoyment at all. l just wondered if it might be possible to tidy a few blank lines. But if it’s tricky or could lead to corner cases and difficulties, I’m fine leaving it be.

etc · 2025-04-02 20:35:38

Bloke wrote #339428:

I’m fine with the stuff appearing on new lines if they’re together

Then phiw13 tip should work: <if::custom_field name="serial" trim>...? This will remove ‘inside’ line breaks/spaces after the opening and before the closing if tags. Should we trim tags output by default? Maybe, opinions welcome.

even if just the conditional tags always took up ‘no space’ (besides perhaps a line break) it’d condense the rendered page a bit.

Dunno. What is a ‘conditional’ tag? Starting with if? But <txp:evaluate /> can act as conditional too. Accepting <txp:else />? But sometimes we use it, sometimes not, and core has no idea of tags internals.

jakob · 2025-04-02 20:54:33

Bloke wrote #339428:

Hadn’t thought of wrapping in <txp:hide process>. Great tip for the variables form I inject into the page head. Thank you.

Because only the tags are processed but nothing is output, you can also afford to write your comments as plain text in amongst your variables, e.g.

<txp:hide process>

    ++++ environment variables ++++
    <txp:variable name="nonce_token"><txp:php>echo Txp::get('\Textpattern\Password\Random')->generate(32);</txp:php></txp:variable>

    ++++ asset variables ++++
    <txp:variable name="assets_url"><txp:page_url type="theme_path" />/assets/</txp:variable>
    <txp:variable name="assets_path">/themes/<txp:page_url type="theme" />/assets/</txp:variable>

    …

</txp:hide>

I also do the page-context dependent stuff for the head block that Phil does here and here in the standard theme as part of these head_vars, setting some page_context vars for later use in the process. It makes your html_head form so much more readable.

colak · Yesterday 04:18:31

I use pat_speeder as it trims everything:)

Vienuolis · Yesterday 08:18:44

I remove blank lines and spaces (or add them for clarity) by hand, such as

	<figure<if::yield name="class"> class="<txp:yield name='class' />"</if::yield>>
<txp:image yield="id" loading="lazy" /> <txp:if_yield>
<figcaption><txp:yield escape="tidy,textile" /></figcaption> <txp:else />
<txp:image_info yield="id" escape="tidy,textile" wraptag="figcaption" /> </txp:if_yield>
	</figure>

This way it’s not quite visual on forms and pages, although it’s really clean and pretty as HTML (source view), e. g. az.on.lt/dvibalsiai.

But thanks to Oleg for the escape="tidy, trim" tip in a whole form.

phiw13 · Yesterday 08:34:57

Vienuolis wrote #339432:

I remove blank lines and spaces (or add them for clarity) by hand, such as

[…]

This way it’s not quite visual on forms and pages, although it’s really clean and pretty as HTML

I do something similar when the code is not overly complicated or long. Or when dealing with a JSON snippet.

Bloke · Yesterday 09:14:16

jakob wrote #339430:

Because only the tags are processed but nothing is output, you can also afford to write your comments as plain text in amongst your variables

That’s another boon! I’ll take this approach, thank you.

etc wrote #339429:

<if::custom_field name="serial" trim>...? This will remove ‘inside’ line breaks/spaces after the opening and before the closing if tags.

Good to know, if I remember and it starts to bug me too much in the rendered HTML.

Should we trim tags output by default? Maybe, opinions welcome.

My gut feeling says yes, simply for improved readability, but I’m not sure if it might have ramifications in edge cases. And how does that affect escape="trim"? What if you don’t want it trimmed? Would we have to introduce escape="untrim"? ;)

Textpattern CMS

Textpattern CMS support forum

#1 2025-04-02 08:56:45