W3C home > Mailing lists > Public > public-html-bugzilla@w3.org > October 2013

[Bug 23587] Provide rationale for content restrictions for script tag

From: <bugzilla@jessica.w3.org>
Date: Tue, 22 Oct 2013 14:48:59 +0000
To: public-html-bugzilla@w3.org
Message-ID: <bug-23587-2486-ybfSAVYDeQ@http.www.w3.org/Bugs/Public/>
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

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 16:31:45 UTC