php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Request #41223 PHP should output better HTML for the .phps (highlight source) view
Submitted: 2007-04-29 09:22 UTC Modified: 2021-07-30 11:53 UTC
Votes:3
Avg. Score:3.7 ± 0.5
Reproduced:3 of 3 (100.0%)
Same Version:2 (66.7%)
Same OS:2 (66.7%)
From: jeremy dot visser at gmail dot com Assigned: cmb (profile)
Status: Wont fix Package: *General Issues
PHP Version: 5.2.1 OS: Ubuntu 7.04
Private report: No CVE-ID: None
View Add Comment Developer Edit
Anyone can comment on a bug. Have a simpler test case? Does it work for you on a different platform? Let us know!
Just going to say 'Me too!'? Don't clutter the database with that please — but make sure to vote on the bug!
Your email address:
MUST BE VALID
Solve the problem:
6 + 8 = ?
Subscribe to this entry?

 
 [2007-04-29 09:22 UTC] jeremy dot visser at gmail dot com 
Description:
------------
When PHP outputs highlighted source, the HTML it outputs is ugly. It looks pretty when viewed in a browser, but the actual HTML is bad.

For starters, it doesn't use a DOCTYPE, and includes no <html>, <head>, or <body> elements like you'd expect.

Even worse, it preformats the text not with a <pre> tag like should be used, but with several &nbsp;'s to space text out. What is wrong with using <pre>?

Expected result:
----------------
Should be using proper HTML headers:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
    <title>test.phps</title>
</head>
<body>
<pre class="php">
&lt;?php
    /* This is some PHP */
?&gt;
</pre>
</body>
</html>

You see, when you use a <pre>, you don't need all these &nbsp;&nbsp;'s to space things out.


Actual result:
--------------
Example of ugly code:

<span style="color: #0000BB">&lt;?php<br />&nbsp;&nbsp;&nbsp;&nbsp;</span><span style="color: #FF8000">/*<br />&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Test<br />&nbsp;&nbsp;&nbsp;&nbsp;*/<br />?&gt;

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2007-04-29 14:39 UTC] iliaa@php.net 
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php

The reason there are no headers is because the expectation is that the 
output will be embed in an existing page. Presence of the requested 
headers and elements would then cause the page to break.
 [2007-04-30 01:16 UTC] jeremy dot visser at gmail dot com 
OK, I see what you mean about the headers. However, I'm not talking about the highlight_file() or highlight_string() functions. Obviously, they should not return HTML or HTTP headers.

The issue is when viewing a .phps file, where PHP does everything itself, without any script having to output the headers for it. When viewing a standalone .phps file, PHP should output the proper headers.

Of course this is a bug. PHP is not returning standards-compliant or semantic markup. This has accessibility problems. That part of my report _is_ a bug.

I'm reopening the bug, but if you close it again, I will not bother to try and argue.
 [2010-12-31 20:40 UTC] jani@php.net
-Package: Feature/Change Request +Package: *General Issues
 [2021-07-30 11:53 UTC] cmb@php.net
-Status: Open +Status: Wont fix -Assigned To: +Assigned To: cmb
 [2021-07-30 11:53 UTC] cmb@php.net 
I'd rather get rid of this "feature" than improving it.

If you still feel that highlighting of PHP sources is important
enought to be supported by php-src (instead of some library, maybe
not even running on the server), and that the generated HTML
should be improved, please pursue the RFC process[1].

[1] <https://wiki.php.net/rfc/howto>
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Fri Apr 19 21:01:30 2024 UTC