4 ms·

It would be impossible to maintain backward compatibility if they made the language HTML context aware. It would make it more difficult to output any non-HTML c

by shawnz 6y ago

It would be impossible to maintain backward compatibility if they made the language HTML context aware. It would make it more difficult to output any non-HTML content type from a PHP script. It would require many new syntaxes (e.g. for outputting variable data in the attribute values of elements, selectively outputting elements or attributes, looping through them, etc). It would also mean the language is tied to specific HTML versions and it would not be able to be forgiving of HTML syntax errors, defeating much of its ease of use. I am not sure it would have been practical to turn PHP into a strongly HTML aware template language like Thymeleaf for example, while still having it be useful as a general purpose programming language. IMO, the dream of PHP/CFML/JSP/ASP mixing code with templates just isn't realistically possible.

tannhaeuser 6y ago
Backward-compat and syntax doesn't have to be a problem. The `<?php ...>` processing instruction can stay as it is, only to be augmented with a new opt-in mechanism based on entity expansion (the fully context-aware templating mechanism built-in to SGML/XML). Eg roughly <title>bla</> <?php let x = "<p>whatever</p>"?> &x <div class="debug"> <![ RCDATA [ &x ]]> </div> where x is bound to markup checked against permissible elements in the first context (eg rejecting <script>) and escaped into <p>whatever<p> in the second. Rejecting script elements in user or other dynamic content as well as escaping comes for free with regular SGML parsing.
- shawnz 6y ago
  There are many cases that doesn't solve, for example, how can I conditionally decide to either inject an attribute or not inject it using this technique? How do I mix user-controlled text which should be escaped with dynamically generated HTML in PHP strings that I don't want to be escaped? How will scope be managed and can those constants be redefined (not normally a concern in SGML)? Plus, what makes you expect this opt-in syntax would catch on if people already don't care enough to use HTML-aware template engines? EDIT: Also, what happens if the static parts of the document aren't syntactically correct SGML? How can you even know if the final output will be syntactically correct SGML until you run all the legacy parts of the PHP code that output directly in the document stream?
  - tannhaeuser 6y ago
    Good points, some of which can be addressed: Re: conditionals SGML allows marked sections to have parameter entities as keywords, and recognizes INCLUDE/IGNORE in their expansions: <!entity % e "include"> ... <![ %e [ will only be included if e expands to INCLUDE ]]> Re: mixed user/system text SGML supports quite restrictive content model exclusions, eg the "-(script)" part below makes SGML reject script elements in main's content anywhere: <!element main - - ANY -(script)> Moreover, you can declare an entity as a so-called data text entity, special chars in which are preserved Re: running legacy parts There's no difference to what PHP does now eg just running through the page/template doc until the end, erring out on validation errors?

by shawnz 6y ago

tannhaeuser 6y ago

Backward-compat and syntax doesn't have to be a problem. The `<?php ...>` processing instruction can stay as it is, only to be augmented with a new opt-in mechanism based on entity expansion (the fully context-aware templating mechanism built-in to SGML/XML). Eg roughly <title>bla</> <?php let x = "<p>whatever</p>"?> &x <div class="debug"> <![ RCDATA [ &x ]]> </div> where x is bound to markup checked against permissible elements in the first context (eg rejecting <script>) and escaped into <p>whatever<p> in the second. Rejecting script elements in user or other dynamic content as well as escaping comes for free with regular SGML parsing.

shawnz 6y ago
There are many cases that doesn't solve, for example, how can I conditionally decide to either inject an attribute or not inject it using this technique? How do I mix user-controlled text which should be escaped with dynamically generated HTML in PHP strings that I don't want to be escaped? How will scope be managed and can those constants be redefined (not normally a concern in SGML)? Plus, what makes you expect this opt-in syntax would catch on if people already don't care enough to use HTML-aware template engines? EDIT: Also, what happens if the static parts of the document aren't syntactically correct SGML? How can you even know if the final output will be syntactically correct SGML until you run all the legacy parts of the PHP code that output directly in the document stream?
- tannhaeuser 6y ago
  Good points, some of which can be addressed: Re: conditionals SGML allows marked sections to have parameter entities as keywords, and recognizes INCLUDE/IGNORE in their expansions: <!entity % e "include"> ... <![ %e [ will only be included if e expands to INCLUDE ]]> Re: mixed user/system text SGML supports quite restrictive content model exclusions, eg the "-(script)" part below makes SGML reject script elements in main's content anywhere: <!element main - - ANY -(script)> Moreover, you can declare an entity as a so-called data text entity, special chars in which are preserved Re: running legacy parts There's no difference to what PHP does now eg just running through the page/template doc until the end, erring out on validation errors?