On 04/28/2017 03:55 PM, Leif Halvard Silli wrote:
On 27 Apr 2017, at 9:58, Hussein Shafie wrote:
On 04/26/2017 11:51 PM, Leif Halvard Silli wrote:
1.
However, the parser of XMLmind XML editor does not conform to this:
I have noticed that when DOCTYPE is excluded, then the document is
rendered - within XXE - in quirks-mode.
@srcdoc is an attribute of element iframe. See
https://www.w3.org/TR/html5/embedded-content-0.html#the-iframe-element
Element iframe is rendered in the styled view by embedding a "Web
browser" (part of JavaFX, based on WebKit, I think). As such, we,
XMLmind, have very few control on this embedded "Web browser". See
http://docs.oracle.com/javase/8/javafx/api/javafx/scene/web/WebView.html
Ok. Is there an easy way to report this bug to Oracle?
There is no easy way to report a bug to Oracle. They require you to
write in Java a self-contained program allowing to reproduce the bug. If
you don't do that, your bug report will be rejected.
May be you have easy access? (Hint …)
No, not at all. Reporting a Java bug to Oracle is a lot of work and I
confess that we tend to "forget" reporting Java bugs to Oracle.
2.
Some might think (ahem - I am looking at myself ...) that a srcdoc
document would be a XHTML document when inside a XHTML document, and
a HTML document when inside a HTML document. But, actually (and of
course: my bad), a srcdoc document is always a 'text/html' HTML
document. This means, says the HTML5.x spec, that you are allowed to
skip the start and end tag of a lot of elements, including the root
element.
However, XMLmind XML editor does not implement this: Unless the
<html> start tag and end tag is included in the srcdoc attriute,
then XXe erroneously reports that the content is not HTML. By
contrast, the HTML5.x specification says that the @srcdoc does not
need to contain any code - it could simply simply be this:
|srcdoc="XMLmind must update its srcdoc HTML mind" |
The HTML parser will then, itself, insert all the lacking elements
when the srcdoc document is rendered.
Our implementation is based on this spec:
https://www.w3.org/TR/html5/embedded-content-0.html#attr-iframe-srcdoc
To be honest: I am not at all certain what the purpose of the HTML
specification’s reference to XML’s document production is.
That being said: I question your particular reading of it. See below.
[ ... snip ...]
Please tell us where to find a more authoritative spec and we'll have
no problem changing our implementation accordingly.
You quoted HTML 5.0, however HTML 5.1 became official last year. That
being said: HTML 5.1 continues to have the statement that you quoted
from HTML 5.0
https://www.w3.org/TR/html/semantics-embedded-content.html#element-attrdef-iframe-srcdoc:
]] For iframe elements in XML documents, the srcdoc attribute, if
present, must have a value that matches the production labeled document
in the XML specification. [XML] [[
But what does it mean to «have a value that matches the production
labeled document in the XML specification»?
Your interpretation of this requirement appears to be that the <html>
element must be present. However, this is not the only possible
interpreation. (Looking away from the escaping rules:) I would claim
that srcdoc="<div>blah</div>" matches the document production
(https://www.w3.org/TR/xml/#NT-document) just as well as
srcdoc="<html>blah</html>" does!
But, going with your interpreation: Because a self closed <html/>
matches XML’s document production (https://www.w3.org/TR/xml/#document),
it would be logical to assume that XXe would accept srcdoc="<html/>".
However, even then, XXe reports that the @srcdoc doesn’t contain HTML.
Only if one does "<html></html> will XXe be satisfied. This not logical.
And there are other illogical issues with your current implementation.
For example, XXe considers it entirely OK to do all kinds of weird
things, such as srcdoc="<html><p><p>blah</p></html>", which does not
match XML’s document production - but which is a valid and meaningful,
as a HTML syntax document.
Anway, just below that statement follows Example 62
https://www.w3.org/TR/html/semantics-embedded-content.html#example-add3a347,
which, in the final paragraph, states:
]] [...] only the contents of the body element need appear literally
in the syntax. The other elements are still present, but only by
implication.[[
One could, of course, be tempted to jump to the conclusion that this is
valid only for HTML syntax documents. But, at the very least, that is
not how it has been implemented in Web browsers that support the both
@srcdoc and XHTML.
I think that the purpose of the reference to XML’s document production
is twofold:
Firstly, it clarifies that a srcdoc document does NOT have to be a XHTML
document. Thus: Its purpose is to LOWER the authoring requirements
compared with the authoring requirements of XHTML syntax documents. For
eample, there does not need to be a namespace declaration (as this is
not required by the document production. And also, it does not need to
begin with the HTML root document, since this is also not required by
the document production (if you do <div>blah</div>, then <div> is the
root, as per the document production).
Secondly, the reference to the XML document production means that
elements must be well-formed, which INCREASES the authoring requirements
compared with HTML syntax documents. But given that @srcdoc documents
are supposed to rendered as text/html documents anyway, why, at all, is
that an requirement? I must confess that I am not certain. However, my
guess is that the purpose is to handle ‘pure’ XML editors/parser: XML
editors/parsers are probably able transform the content of the srcdoc
attribute into a valid XML-document, but they might not be able to
transform the document into a valid HTML document (since that would mean
that they would have to embed two parsers - an XML parser and an HTML
parser).
If I am correct about the second purpose, then, I must say, that I think
there is reason to question the spec’s requirement to conform with the
XML document production.
After reading all this, we'll almost certainly change our implementation
to stop checking the value of attribute @srcdoc. I mean, you'll be able
to type anything you want as the value of @srcdoc. This should be well
sufficient for a program like XMLmind XML Editor which don't claim to be
an (X)HTML validator.
This change will probably not happen before we officially support
(X)HTML 5.1. (For now, we don't support (X)HTML 5.1, just (X)HTML 5.0.)
--
XMLmind XML Editor Support List
xmleditor-support@xmlmind.com
http://www.xmlmind.com/mailman/listinfo/xmleditor-support
