When we started to use XXE v9.1, one of the first things that happened
was that my college contacted me and asked what to do with the new error
message that she saw once she started to edit a document that worked
just fine in v9.0.
Full story:
For HTML 5 documents (or "HTML living standard" documents) XXE 9.1’s
implementation of the "conformance requirements for authors specified in
the HTML Living Standard", does not permit the use of the @type
attribute on the style element. This change, from v9.0, is not described
in the "About the XHTML 5 XML Schema and Schematron developed by
XMLmind" section of
https://xmlmind.com/xmleditor/_distrib/doc/xhtml/create.html#xmlmind_xhtml5_schema,
but is experienced by anyone using XXE v9.1.
If a style element has a @type attribute, XXE v9.1’s conformance
checker reports that the element has no "type" attribute and this error
message is displayed in deep red color, and also the XXE renderer
switches from "strict mode" to "lenient mode".
However, I think this is not in conformance with HTML Living Standard.
(But perhaps it is meant as an "willful violation" of the HTML Living
Standard?)
Because, while it - to my (but not very great) surprise - is correct
that the HTML Living Standard’s section dedicated to the style element
(https://html.spec.whatwg.org/multipage/semantics.html#the-style-element)
does not define @type as one of the attributes it is permitted to take,
another section
(https://html.spec.whatwg.org/multipage/obsolete.html#obsolete-but-conforming-features)
defines type="text/css" (<style type="text/css">) as an obsolete but
conforming feature.
Therefore, allthough the feature is obsolete, the @type attribute for
the style element is possible to use, if it is used in a way similar to
the @charset of the meta element, namely, only a single value is
conforming: For @charset, only "UTF-8" is permitted, while for @type of
style elements, only "text/css" is conforming.
Thus, the reason XXE’s current reaction to <style type="text/css" is
not conforming, is that the HTML Living standard requires a
(pedagogical) warning - and not an error message - when obsolete but
conrforming features are found.
I think I see a dilemma here: XXE really should not allow authors to add
type="text/css" since, doing so, would result in a document which
triggers a warning to be created. And as creators of an authoring tool
you do not want that. From that angle, the current behavior might seem
fair enough. However, while it should not (easily) permit user to add
this conforming but obsolete feature to their documents, I really think
that XXE should treat documents that allready contain the
type="text/css" feature according to what HTML Living Standard says!
One possible solution: What I would suggest is that @type is added back
as one of the attributes style elements can have. However, instead of
making the @type attribute available - by default - in the attribute
edititing tool, it ought to be hidden by default. For instance, it could
be hidden as a "scripting" attribute - meaning that users must activate
"Show 'scripting" attribute" in order to see the "type" attribute. Or
even better: Instead of simply adding type to the "scripting" categroy,
add a new category "obsolete but conforming" attrributes.
Given the fact that you permit @border on the table element (something I
think is a smart decision[*]), I think you should definitelely find some
way to add back type="text/css" as well, given the fact that it actually
is a conforming feature.
[*] Fun fact: But then again, table@border was one of the features I -
dare I say: successfully! - bike-shedded about when I was active (in the
HTML Working Group as well as in the WHATwg). In fact I authored a
change decission which was formally voted over and put to scrutiny by
the chairs, and which "won". But since the editor did not respect the
outcome of that decisiom procoss, this became one of the features where
the W3C spec and the Living spec differed.
Leif Halvard Silli
--
XMLmind XML Editor Support List
xmleditor-support@xmlmind.com
https://www.xmlmind.com/mailman/listinfo/xmleditor-support
