- From: <bugzilla@jessica.w3.org>
- Date: Tue, 22 Oct 2013 14:48:59 +0000
- To: public-html-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23587 --- Comment #5 from Jakub Łopuszański <qbolec@gmail.com> --- If I may add my two cents from a developer's perspective: times when a webmaster created the HTML in a texteditor and therefore had control over every aspect of the shape of HTML are a bit distant to me. I don't think it would be of much value to suggest to authors of dynamically genrated mashups to even consider any actions which would require "manual" treatment of the HTML. And this is how I perceived the suggestion to escape occurrences of "<script>" inside comments in the scripts. I am not even sure how to perform this correctly (using simple tools like PHP) in an automated way and I am affraid many developers would use something like Regular Expressions to try to match something like "<!--.*<script", and will obviously fail, as HTML is not a regular language. Anyway, the solution we finally chosen in our company is to replace all "<" with "\u003C", which in PHP can be conviniently achieved by json_encode($data, JSON_HEX_TAG|JSON_HEX_APOS|JSON_HEX_QUOT|JSON_HEX_AMP). I still do not understand why the rules for the parser are so complicated. In my opinion it would be sufficient to define them as follows: state INSIDE_SCRIPT: if you see "<!--" go to state INSIDE_COMMENT_INSIDE_SCRIPT if you see "</script>" go to state OUTSIDE otherwise sit here state INSIDE_COMMENT_INSIDE_SCRIPT: if you see "-->" go to state INSIDE_SCRIPT otherwise sit here Could you provide some real world scenario in which the rules above would be contrary to authors intention? -- You are receiving this mail because: You are the QA Contact for the bug.
Received on Tuesday, 22 October 2013 14:49:01 UTC