">"

[Warren Oates]

Re: ">&quot ;

In article <f6b5rv0entotpg rqtqrhu7p9lqlg3 quj54@4ax.com>,
Andy Hassall <andy@andyh.co. uk> wrote:

: Odds are you have HTML elements being output in loops etc.; so even the
:sections that are literal HTML may not validate without the actual output of
:executing the PHP.

Indeed. A blank form page might validate, but one should really check
the output of a submitted form. Copy/paste "view source" works for me,
saved as a text file, uploaded to The Validator.

The w3c validator ignores php anyway, it seems. I validate for strict
xhtml, using PHP in all sorts of strange and untutored ways, and I get
good results. PHP also has all sorts of obscure functions for stripping
and adding and escaping and unescaping HTML entities.
--
Looks like more of Texas to me.
.... Arizona, where the nights are warm and the roads are straight.

[Matthias Esken]

Re: &quot;&gt;&quot ;

Hi!

Tim Tyler <tim@tt1lock.or g> schrieb:
[color=blue][color=green]
>> Only the output of the script has to conform to HTML.[/color]
>
> It prevents users from using existing HTML tools to handle PHP - files -
> such as:
>
> Web browsers;
> Syntax highlighting;
> Parsers;
> Formatters;
> Lint tools;[/color]

It's PHP, not HTML! So why do you mix up PHP and HTML. It's PHP, not
HTML! Use a template system and all is well. It's PHP, not HTML!
[color=blue]
> Were using ">=" and "->" really important enough to justify
> violating the HTML specifications?[/color]

Yes. It's PHP, not HTML! You can output HTML with PHP. It's PHP, not
HTML! If you know what you're doing, the resulting page will validate.
It's PHP, not HTML!
[color=blue][color=green]
>> Actually that's not even true; nobody is limiting you to outputting
>> just HTML or XHTML with PHP; you can output whatever you like.[/color]
>
> Well yes - but what does the "H" in "PHP" stand for? ;-)[/color]

"H" means Hypertext, not HTML. It's PHP, not HTML!

Regards,
Matthias

P.S.: It's PHP, not HTML! :-)

[Ian.H]

Re: &quot;&gt;&quot ;

On Thu, 13 Nov 2003 17:45:04 +0100, Matthias Esken wrote:
[color=blue]
> P.S.: It's PHP, not HTML! :-)[/color]


LOL!

Is that your final answer? 50 / 50? phone a friend? =)



Regards,

Ian

--
Ian.H [Design & Development]
digiServ Network - Web solutions
www.digiserv.net | irc.digiserv.ne t | forum.digiserv. net
Programming, Web design, development & hosting.

[Terence]

Re: &quot;&gt;&quot ;

John Dunlop wrote:[color=blue]
> Terence wrote:
>
>[color=green]
>>consequentl y, the "<?php" notation would/does conform perfectly to the
>>XML notation for a processing instruction.[/color]
>
>
> Hmm. A Processing Instruction (PI) in XML (XML1.0 sec. 2.6,
> especially production 16), and so XHTML too, begins at "<?" and ends
> at the first occurrence of "?>". If the string "?>" appeared within
> the PHP code, the processing instruction would be (prematurely)
> closed, and the remaining text wouldn't be part of the processing
> instruction.
>[/color]

hmmm, I suppose you're right.
one could have for instance
<?php echo '?>'; ?>
[color=blue]
> Trying to validate PHP files against an HTML DTD is equally
> problematic. Processing Instruction Close (PIC) in HTML is simply
> ">". So any occurrence of ">" closes the processing instruction. No
> amount of hiding or commenting-out changes that fact. Thus the absurd
> notion that ">" shouldn't be allowed within PHP code is akin to
> arguing that PHP shouldn't allow strings.
>[/color]

Lucky for us, no one anywhere has ever argued that ">" should not be
allowed.

;)
[color=blue][color=green]
>>Instead we have the short_open_tag mess >:([/color]
>
>
> Unfortunately.
>[/color]

The inability for embedded PHP to conform to a PI is still no reason to
have other PI's and the XML declaration break the PHP scanner. It is for
this reason that short_open_tag should be banned -- PI conformity aside.
Part of the problem is that this php.ini directive cannot be set at
runtime for obvious reason. Hence it blocks open-source app developers
from using the templating ability of PHP to produce XML without
destroying XML compliance in the process.
ie.
<?php // nasty hack to get around ISPs with short_open_tag on
echo "<"."?xml version=\"1.0\" ?".">";
// this code block MUST begin on line 1 ?>

The above hack means that there is no possibility for the document to be
procssed by an XML parser prior to the PHP parser -- even if the
developer gave up the ability to use "?>" in a string literal.

IMO, this unnecesary feature deparavation is counter to the idea that
PHP is a great "enabler" allowing developers to do more.

I think part of the problem is that XML is relatively new compared to
PHP even though XML is mature and well-established now. They changed the
behaviour of register_global s because it needed to be done even though
it caused inconvenience. In my opinion, having to do a search/replace on
"<?"/"<?php" for OLD SCRIPTS is much less of an inconvenience. People
will have no issues getting used to using "<?php" because it doesn't
actually deprive them of any features as short_open_tags does in the
case of XML.

It's just completely uneccessary.

[Terence]

Re: &quot;&gt;&quot ;

Tim Tyler wrote:[color=blue]
> Should PHP have allowed ">" to be used within PHP tags?
>
> e.g. in:
>
> if (a > b) { ... };
>
> ...and...
>
> $object -> member;
>
> The use of ">" stops PHP pages being valid HTML/XML - by ending
> the current HTML tag - which prevents page validation and the
> use of conventional formatting tools or parsers.[/color]

It might break HTML, but it doesn't break XML because if you use
"<?php", then the entire PHP block can be a valid processing instruction
(provided you don't use the character sequence "?>" in any string
LITERAL). Now this only works if short_open_tags is disabled (see my
rant on abolishing short_open_tag) .

As for HTML and HTML validators -- who cares? -- really...
hardly worth breaking from convention.

(did I mention that that character sequence would have to be in a string
LITERAL as opposed to a variable?)

[Juha Suni]

Re: &quot;&gt;&quot ;

>>> The use of ">" stops PHP pages being valid HTML/XML - by ending[color=blue][color=green][color=darkred]
>>> the current HTML tag - which prevents page validation and the
>>> use of conventional formatting tools or parsers.[/color]
>>
>> Only the output of the script has to conform to HTML.[/color]
>
> It prevents users from using existing HTML tools to handle PHP -
> files - such as:
>
> Web browsers;
> Syntax highlighting;
> Parsers;
> Formatters;
> Lint tools;
>[/color]

Hmm not to my experience. My Macromedia Dreamweaver is handling it all
perfectly, even using PHP-specific syntax highlighting for the
php-parts, and the WYSIWYG works too, I can go drag and dropping the
php-script parts. Only problems occur if I would want to (I really dont)
to use wysiwyg when hassling around with some more complicated scripts
containing partial html-elements with conditional output. Even this
could be avoided with good separation of code and visual layout.

Besides its server-side stuff, your web-browser should not even ever see
the php-code, as shouldnt any validators or other such software.

--
Suni