[HTML/PHP] Preserving tabs/indentation when echoing multiple lines

[EliteGM]

Say I have:

$string = "Hello, user!\n".
        = "How are you today?\n".
        = "Here's today's news:";

And in the same file, somewhere in the body (location is unimportant).

        <div class="foo">
            <p><?=nl2br($string);?></p>
        </div>

The generated HTML code will look like this:

        <div class="foo">
            <p>Hello, user!<br />
How are you today?<br />
Here's today's news:</p>
        </div>

I hate how this looks. Is there any ("clean") way in which to preserve the whitespace in front of the different senteces in the paragraph, so as to make it look like this:

        <div class="foo">
            <p>Hello, user!<br />
            How are you today?<br />
            Here's today's news:</p>
        </div>

I know I can do this:

$string = "Hello, user!\n".
        = "            How are you today?\n".
        = "            Here's today's news:";

But that looks ugly as ****. Suggestions?

Note that this is just about sematics/looks; not functionality - there is virtually no visible difference in the code until you start reading the page's source. I just want my source code to be easily legible - proper indentation and such.

Thanks!

 

[danse]

Well if you are using \n to break your code you may as well use \t for tab indentation.

 

[שเ๒єtгเ๒є]

there is no provided easy way as i kno of.

back in my php days built a class to output html ordered, with front spaces and such, but it will just calc more of things u dont need to.

in fact, u should try to prevent \n in your html at all. having all your html code in one line without empty areas will decrease your loading time, cuz of the reduced file size. who cares its not readable in source. for looking your html output u rather use any tool that formats your one line html into a nice printed and ordered html, other things are just wastes for the client in usual usage.

 

[danse]

there is no provided easy way as i kno of.

back in my php days built a class to output html ordered, with front spaces and such, but it will just calc more of things u dont need to.

in fact, u should try to prevent \n in your html at all. having all your html code in one line without empty areas will decrease your loading time, cuz of the reduced file size. who cares its not readable in source. for looking your html output u rather use any tool that formats your one line html into a nice printed and ordered html, other things are just wastes for the client in usual usage.

... will cause most browsers to get fucked-up, which is weird because technically it's still proper XHTML / XML. I've recently encoutered that problem. Removing all whitespaces just before output to browser with ob function, causes browser to fail on proper loading the website, sympoms are: it displays the page properly but keeps loading almost endlessly like it tries to load some more code, js or something else - confirmed on latest Firefox, Chrome

 

[שเ๒єtгเ๒є]

... will cause most browsers to get fucked-up, which is weird because technically it's still proper XHTML / XML. I've recently encoutered that problem. Removing all whitespaces just before output to browser with ob function, causes browser to fail on proper loading the website, sympoms are: it displays the page properly but keeps loading almost endlessly like it tries to load some more code, js or something else - confirmed on latest Firefox, Chrome

in fact, such errors need to have reasons. i rather bet your script wasnt working clean, because technically spaces, new lines, tabulators that are NOT between > and < in the deepest level as well as between " or ' in javascript/css there should be any problem. its still valid. however, u might break one line after doctype and xml tag itself, cuz im not sure how browsers parse those specific lines.
anything else has no validation problems by removing spaces, \n and \t at all.

if any browser parses the markup the wrong way just cuz all is in one line, its a browser specific problem. i would try it out, and try to reproduce this problem in a more detailed way. (so what exactly requires \n in the markup to be read correctly)
better than fully ignoring this load-improve-possibility.