Re: RFE: More nuanced validation of <script> with data blocks

Hussein Shafie <[email protected]> Mon, 12 Jun 2023 09:46:20 +0200
Newsgroups	gmane.editors.xxe.general
Message-ID	<[email protected]>
On 6/10/23 03:01, Leif H Silli wrote:
> Proposal:
> 
> In case of <script type="none-JavaScript-MIME-type-goes-here" >, or put 
> differently: When <script> is used for data blocks, the XXE validation 
> tool should not stamp child elements of <script> as illegal. (At least 
> not when the data block, per the particular script element’s type 
> attribute is a XML-based markup language.)
> 
> Alternatively, XXE should allow to specify in the preferences that, for 
> specific MIME types, then <script 
> type="none-JavaScript-MIME-type-goes-here" > should be ignored by the 
> validation tool. (I prefer the first variation, so as to not have to 
> fiddle with preferences.)
> 
> Description:
> 
> HTML5 defines 3 variants of HTML: DOM, XML and (text/)HTML, and points 
> out that what is possible or impossible in one of them, might be 
> possible or impossible in another. And the <script> element is one of 
> the elements whichs behaves quite differently in XML compared to 
> text/HTML. Basically, in text/HTML, the <script> cannot contain any 
> child elements (the parser simply views any code as pure text). Whereas 
> in XML it can.
> 
> Per HTML5, the default state of the <script> element (that is: the 
> omission of the type attribute) means that the content is supposed to be 
> a “classic script”. [1]  And so, this is not a “classic script”:
> 
> <script><style>/*CSS*/</style></script>
> 
> XXE’s Validator stamps the above code as invalid - and this is correct, 
> if we look at the content. (However, by contrast - and strikingly, if 
> you check the above code in an HTML5 text/HTML validation tool, the 
> above is actually considered valid, because all the content it sees is 
> just text, e.g. try https://validator.nu )
> 
> (By the way, I am not certain what happens, if the JavaScript engine 
> detects e.g. a <style> element inside the <script> element. But I guess 
> it could stop the script from running.)
> 
> HTML5 goes on to define certain keywords, such as "module" – <script 
> type="module"> , and promise that extensions to how <script> behaves, 
> will be made via such keywords.  However, the above code example would 
> be invalid for all the current keywords (and thus also are invalid also 
> per XXE's validator).
> 
> However, HTML5 says that <script> can also be used to contain “data 
> blocks": [2]
> 
> «Setting the attribute to any other value means that the script is a 
> data block, which is not processed. None of the script attributes 
> (except type itself) have any effect on data blocks. Authors must use a 
> valid MIME type string that is not a JavaScript MIME type essence match 
> to denote data blocks.»
> 
> And so we could have the following:
> 
> <script type="application/xhtml+xml"><style>/*CSS*/</style></script>
> 
> Currently, XXE Validation tool stamps that as well as invalid. However, 
> it seems to me that it is **not** invalid. A more precise feedback, if 
> feedback is necessary, would be to inform that the above content is 
> treated differently when parsed as XML compared to when parsed as 
> text/HTML. (In fact, in an XML parser, the style rules found inside the 
> child element '<style>', would in fact be applied, whereas in a 
> text/HTML parser, it would not be applied.)
> 
> Finally, I want to be so honest as to confess that the issue discussed 
> in this email, for me has several layers and motifs:
> 
> (1) I happen to think that <style> should be permitted the same places 
> that the <script> element is permitted, and not only in the <head> 
> element. Such a permission should probably be on the condition of 
> certain authoring requirements. (The condition could be that every style 
> rule only targets the current element and/or its children.) And I guess 
> I should file a bug report against the HTML5 specifcation to make this 
> happen. 

Indeed. It used to be the case a few years ago if my memory serves me well.




> But until that becomes a feature of HTML5, the above for me is a 
> way to circumvent the validation error message in XXE - because those 
> messages are annoying (if not so much for myself, then at least for 
> other XXE users).
> 
> (2) XXE already allows us to author HTML documents that does not meet 
> the (text/)HTML conditions for a HTML document. For instance, it can be 
> used to author documents that consists of only an <article> element (and 
> no <html>, <head> or <body> element). Such a document is already 
> “invalid”. But XXE’s validator does fortunately not bother to tell me 
> about it! Which is great, because I like to use XXE to author HTML 
> fragments that can be included or pasted in to ordinary web pages.

This is just a by-product of

1) XXE being an XML editor (not an HTML editor);

2) XXE being strictly schema driven;

3) Unlike RELAX NG Schemas, DTD and W3C XML schema have no concept of 
"top-level pattern" (i.e. <grammar><start>pattern</start></grammar>), 
which would limit an XHTML document to have an <html> root.

More information below.



> 
> Regardless, XXE ought to treat data blocks different from other script 
> content.
> 
> https://html.spec.whatwg.org/multipage/scripting.html#data-block
> 
> [1] https://html.spec.whatwg.org/multipage/scripting.html#attr-script-type
> [2] https://html.spec.whatwg.org/multipage/scripting.html#data-block
> 

I'm afraid that we cannot do much due to the very nature of XXE.

1) XXE is an XML editor. XXE does not support HTML.

2) It comes with DTD or W3C XML schemas for XHTML 1.0 Strict and 
Transitional, XHTML 1.1 and XHTML5. In the later case, the W3C XML 
schema is our work. Our interpretation of the spec found here: 
https://html.spec.whatwg.org/multipage/

3) XXE is strictly schema driven. It comes with the following schemas:

* XHTML 1.0 Strict and Transitional, XHTML 1.1: the DTD mandates 
<script> to contain plain text (CDATA) and has a required type attribute 
(any string is OK).

* XHTML5: our W3C XML schema mandates <script> to contain plain text and 
has an optional type attribute (any string is OK).

We do not plan to change the very nature of XXE or to implement 
"exceptions" to better support HTML. Sorry.


---
PS: If you really need <script> to contain XML elements when 
type=AN_XML_MIME_TYPE, then please consider modifying 
XXE_INSTALL_DIR/addon/config/xhtml/xsd/5/xhtml5.xsd:

---
<xs:element name="script">
   <xs:complexType mixed="true">
     <xs:attribute name="src" type="nonEmptyURI"/>
     <xs:attribute name="type"
                   type="normalizedString"/> <!--May be "", "module", etc-->
     <!-- NON-CONFORMING ATTRIBUTE: kept for compatibility with older 
5.x W3C
          recommendations. (Is it an omission in the LS?) -->
     <xs:attribute name="charset" type="charset"/>
     <xs:attribute name="nomodule" type="nomodule"/>
     <!-- LIMITATION: not enforced: Classic scripts may specify defer or
          async, but must not specify either unless the src attribute is
          present. Module scripts may specify the async attribute, but must
          not specify the defer attribute. -->
     <xs:attribute name="async" type="async"/>
     <xs:attribute name="defer" type="defer"/>
     <xs:attribute name="crossorigin" type="crossOrigin"/>
     <!-- LIMITATION: not enforced: The integrity attribute must not be
          specified when embedding a module script or when the src attribute
          is not specified. -->
     <xs:attribute name="integrity" type="string"/>
     <xs:attribute name="referrerpolicy" type="referrerPolicy"/>
     <xs:attributeGroup ref="globalAttributes"/>
   </xs:complexType>
</xs:element>
---







--
XMLmind XML Editor Support List
[email protected]
http://www.xmlmind.com/mailman/listinfo/xmleditor-support