<div dir="ltr"><div dir="auto"><div>Hi Don,<div dir="auto"><br></div><div dir="auto">let me respond below.<br><br></div><div class="gmail_quote"><div dir="ltr">On Mon, Jun 3, 2019, 12:18 AM Brutzman, Donald (Don) (CIV) <<a href="mailto:brutzman@nps.edu" target="_blank">brutzman@nps.edu</a> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Thanks for in-depth study analysis and implementation efforts Andreas (and Holger).<br>
<br>
Your getting proper capitalization to be accepted is important since that was the major munging going on that made content into invalid XML.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Translating attributes from arbitrary case into x3d case was the easiest way to make the x_ite parser work.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
Avoiding singleton self-closing tags such as <Material/> by using <Material></Material> is something we can live with since the resulting X3D content is still valid XML.  Also I believe that it is the same DOM.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Yes, it results in the same DOM.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
Wondering if there is a path to getting X3D handled similarly to SVG or MathML (perhaps as a Foreign Element) so that singleton elements are allowed and self-closing flags are defined?<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto"> X3D as Foreign Element would be probably the path for WWW standardization.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
It is curious that HTML syntax allows closing elements to be omitted, but apparently doesn't handle a singleton element as equivalent to an open element that is not followed by a closing element.  It seems like a flaw or omission in HTML5 if XHTML content can't be read as HTML.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">These are called void elements. I think they were around from the first HTML and were intentional. I am sure there were hard discussions around deviating from xml.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
(Also wondering about a special case, if the X3D <meta/> tag would seem to work according to the HTML parsing rules since it matches the HTML5 meta element.)<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Yes, I think it may.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
If no path is available, then this might be feedback that we provide to W3C HTML5 working group, since it seems like HTML parsers are being over-assertive.  The note about SGML seems to be overshadowing XML.  Perhaps we should comment in the forum you indicate below.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">If you read through the discussion there is little appetite to change the HTML parser, mostly for security reasons. The discussion is about custom elements, used in web components, so a comment on X3D is a bit off-topic. But perhaps mentioning A-Frame which uses custom elements and Unknown Elements often used for meta information will add support.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Even simpler HTML5 spec strategy would be to propose that X3D be treated as a Foreign Element similar to SVG and MathML.<br></blockquote><div><br></div><div>Yes, I think there the first step would be to reach out and learn how such a proposal can be crafted and delivered. Looking at SVG, the process seems to be daunting and perhaps even out of reach for X3D as an organisation.</div><div><br></div><div>In the mean time it would be great to have a way to generate X3D without self-closing tags, from DOM, from JSON, from Python, or from Java.</div><div><br></div><div>Cheers, -Andreas</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
On 6/2/2019 12:52 PM, Andreas Plesch wrote:<br>
> For anybody who is interest in how HTML parsing is defined, here are<br>
> pointers to the relevant portions in the HTML5 spec.:<br>
> <br>
> The optional tags section here is normative:<br>
> <br>
> <a href="https://www.w3.org/TR/html5/syntax.html#optional-start-and-end-tags" rel="noreferrer noreferrer" target="_blank">https://www.w3.org/TR/html5/syntax.html#optional-start-and-end-tags</a><br>
> <br>
> I can find it right now but HTML treats the /> sequence by ignoring<br>
> the / and expecting no end tag: so <input /> is equivalent to <input><br>
> <br>
> <a href="https://www.w3.org/TR/html5/syntax.html#parsing-html-documents" rel="noreferrer noreferrer" target="_blank">https://www.w3.org/TR/html5/syntax.html#parsing-html-documents</a><br>
> - points out that HTML became separated from XML and has its own rules<br>
> - during parsing there is a stack of open elements:<br>
> <a href="https://www.w3.org/TR/html5/syntax.html#the-stack-of-open-elements" rel="noreferrer noreferrer" target="_blank">https://www.w3.org/TR/html5/syntax.html#the-stack-of-open-elements</a><br>
> Elements are grouped into special, formatting and ordinary. SVG is<br>
> special, X3D elements are ordinary (anything else).<br>
> - SVG and MathML are treated explicitly throughout<br>
> There are adjustment tables for case in SVG attributes.<br>
> - HTML have a self-closing flag which is checked during parsing.<br>
> The algorithm explicitly acknowledges a set self-closing flag to be ok<br>
> for these elements:<br>
> <br>
> <a href="https://www.w3.org/TR/html5/syntax.html#the-in-head-insertion-mode" rel="noreferrer noreferrer" target="_blank">https://www.w3.org/TR/html5/syntax.html#the-in-head-insertion-mode</a> :<br>
> start tag whose tag name is one of: "base", "basefont", "bgsound", "link"<br>
> start tag whose tag name is "meta"<br>
> <br>
> <a href="https://www.w3.org/TR/html5/syntax.html#the-after-head-insertion-mode" rel="noreferrer noreferrer" target="_blank">https://www.w3.org/TR/html5/syntax.html#the-after-head-insertion-mode</a><br>
> start tag whose tag name is one of: "area", "br", "embed", "img", "wbr"<br>
> start tag whose tag name is "input"<br>
> start tag whose tag name is one of: "param", "source", "track"<br>
> start tag whose tag name is "hr"<br>
> start tag whose tag name is "math"<br>
> start tag whose tag name is "svg"<br>
> <br>
> <a href="https://www.w3.org/TR/html5/syntax.html#the-in-column-group-insertion-mode" rel="noreferrer noreferrer" target="_blank">https://www.w3.org/TR/html5/syntax.html#the-in-column-group-insertion-mode</a><br>
> start tag whose tag name is "col"<br>
> <br>
> <a href="https://www.w3.org/TR/html5/syntax.html#the-in-frameset-insertion-mode" rel="noreferrer noreferrer" target="_blank">https://www.w3.org/TR/html5/syntax.html#the-in-frameset-insertion-mode</a><br>
> start tag whose tag name is "frame"<br>
> <br>
> <a href="https://www.w3.org/TR/html5/syntax.html#the-rules-for-parsing-tokens-in-foreign-content" rel="noreferrer noreferrer" target="_blank">https://www.w3.org/TR/html5/syntax.html#the-rules-for-parsing-tokens-in-foreign-content</a><br>
> Any start tag other than a start tag whose tag name is one of: "b",<br>
> "big", "blockquote", "body", "br", "center", "code", "dd", "div",<br>
> "dl", "dt", "em", "embed", "h1", "h2", "h3", "h4", "h5", "h6", "head",<br>
> "hr", "i", "img", "li", "listing", "meta", "nobr", "ol", "p", "pre",<br>
> "ruby", "s", "small", "span", "strong", "strike", "sub", "sup",<br>
> "table", "tt", "u", "ul", "var" or A start tag whose tag name is<br>
> "font", if the token has any attributes named "color", "face", or<br>
> "size"<br>
> <br>
> Take home, I think, is that HTML parsing only allows singletons in<br>
> special cases.<br>
> <br>
> -Andreas<br>
> <br>
> On Sun, Jun 2, 2019 at 1:47 PM Andreas Plesch <<a href="mailto:andreasplesch@gmail.com" rel="noreferrer" target="_blank">andreasplesch@gmail.com</a>> wrote:<br>
>><br>
>> Hi Don,<br>
>><br>
>> let me see what I can respond to right away.<br>
>><br>
>> On Sun, Jun 2, 2019, 12:23 AM Brutzman, Donald (Don) (CIV)<br>
>> <<a href="mailto:brutzman@nps.edu" rel="noreferrer" target="_blank">brutzman@nps.edu</a> wrote:<br>
>>><br>
>>> Thanks for continuing scrutiny, this issue is quite important for X3Dv4 specification efforts.<br>
>>><br>
>>> I think an earlier version of X_ITE used regular X3D elements without problem - not sure, that was some time ago.  Hard to tell now since the online .html examples all seem to use <X3DCanvas src="somesuch"><!-- fallback --></X3DCanvas><br>
>>><br>
>>> I spot-checked a few of the examples, am seeing same X3DCanvas pattern at<br>
>>> <a href="http://create3000.de/x_ite/getting-started/#x3d-examples" rel="noreferrer noreferrer" target="_blank">http://create3000.de/x_ite/getting-started/#x3d-examples</a><br>
>><br>
>> X_ITE went back to using a X3DCanvas element because the X3D tag is<br>
>> already taken by the X3D document and because it conveys that it is<br>
>> derived from the HTML5 canvas element, and can be styled in the same<br>
>> way.<br>
>><br>
>>> Perhaps X3DOM is avoiding direct inclusion and parsing of .x3d source for same reason?<br>
>><br>
>> No, it uses the browser parsing mechanism because that allows external<br>
>> access to the scene as part of the DOM.<br>
>><br>
>>><br>
>>> Looks like you've worked on this in X_ITE already Andreas<br>
>>><br>
>>> * <a href="http://create3000.de/x_ite/getting-started/#xhtml-dom-integration" rel="noreferrer noreferrer" target="_blank">http://create3000.de/x_ite/getting-started/#xhtml-dom-integration</a><br>
>>><br>
>>> * <a href="http://create3000.de/x_ite/xhtml-dom-integration/" rel="noreferrer noreferrer" target="_blank">http://create3000.de/x_ite/xhtml-dom-integration/</a><br>
>>><br>
>>> * <a href="http://create3000.de/x_ite/xhtml-dom-integration/#example" rel="noreferrer noreferrer" target="_blank">http://create3000.de/x_ite/xhtml-dom-integration/#example</a><br>
>>><br>
>>> * <a href="http://media.create3000.de/create3000/dom-integration/dom.integration.xhtml" rel="noreferrer noreferrer" target="_blank">http://media.create3000.de/create3000/dom-integration/dom.integration.xhtml</a><br>
>>> excerpt:<br>
>>>          <body><br>
>>>                  <X3DCanvas class="browser" timings="false"><br>
>>>                          <img class="fallback" src="XHTML.png"/><br>
>>>                          <X3D xmlns="<a href="http://www.web3d.org/specifications/x3d-namespace" rel="noreferrer noreferrer" target="_blank">http://www.web3d.org/specifications/x3d-namespace</a>" id="spheres"><br>
>>>                                  <Scene DEF='scene'><br>
>>><br>
>>> Wondering if you had tried a .html version of that preceding file, and what any difficulties might have been?<br>
>><br>
>> Yes, Holger and me added a HTML compatibility layer to X_ITE. Let me<br>
>> find an example:<br>
>> <a href="https://andreasplesch.github.io/x_ite_dom/tests/html5/html5.html" rel="noreferrer noreferrer" target="_blank">https://andreasplesch.github.io/x_ite_dom/tests/html5/html5.html</a><br>
>><br>
>> The compatibility layer only addresses capitalization, but not self<br>
>> closing tags. So html with self-closing X3D tags also does not work in<br>
>> the X_ITE dom integration.<br>
>><br>
>>> Wondering why you have a DEF on the <Scene> ?  If applying HTML events, presumably it could be an id="scene" reference instead.<br>
>><br>
>> Yeah, I do not know. I do not think it is necessary.<br>
>><br>
>>> SVG recommendation allows singleton elements in fragments within HTML, also seems to sometimes use namespaces and sometimes not.  Also SVG appears to have at least 2 lowerCamelCase elements, clipPath and foreignObject, plus a large number of lowerCamelCase attributes - so not every element/attribute has to be all lower case.<br>
>>><br>
>>>          Scalable Vector Graphics (SVG) 2<br>
>>>          W3C Candidate Recommendation 04 October 2018<br>
>>><br>
>>>          Chapter 5: Document Structure<br>
>>>          <a href="https://www.w3.org/TR/SVG2/struct.html" rel="noreferrer noreferrer" target="_blank">https://www.w3.org/TR/SVG2/struct.html</a><br>
>><br>
>> I think for HTML lowercase is not required, only a defacto standard in<br>
>> the markup. The DOM standard element.nodeName property always<br>
>> normalizes the element name to UPPERCASE.<br>
>><br>
>> Singletons are ok for certain elements, but not for the X3D elements<br>
>> since they are Unknown.<br>
>><br>
>>> Also wondering if you folks think that the <X3DCanvas src=""/> pattern from X_ITE is something we should repeat for X3DOM.  Seems like a good fallback that supports multiple X3D encodings.<br>
>><br>
>> If there is a way to preserve backward compatibility that may be<br>
>> doable. I think it should already be possible in x3dom to wrap the X3D<br>
>> element in a noop X3DCanvas element.<br>
>><br>
>> But it will be harder to preserve the styling options. In x3dom to the<br>
>> idea was to follow the SVG element, in x_ite the idea is to follow<br>
>> more the old plugin <object> element, with SAI access.<br>
>><br>
>>> I recommend that we try to pursue every possibility that might allow inclusion of .x3d (XML valid) models "as is" within the HTML page.  Certainly the fact that they work when relabeled as an XHTML page shows that it is possible.  SVG also provides corrolary evidence that it is possible.  If we force a special conversion of all X3D models used in HTML, then<br>
>>> - that has a huge impact on the number of just-slightly-different scenes that get created,<br>
>>> - it greatly complicates validation, and<br>
>>> - it also is a huge negative when trying to edit/test/apply improvements to a model when the deployed version has unnecessarily different syntax from the original version.<br>
>><br>
>> The issue is that 'relabeling' may not the correct term here. xhtml is<br>
>> a different encoding and is treated very differently by browsers.<br>
>> Inclusion of XML within HTML is only possible with workarounds, eg.<br>
>> wrapping in a script tag, or from a file. The proper way to include<br>
>> XML is to use xhtml. Since the goal is to use html, we would have to<br>
>> consider non-XML for X3D.<br>
>><br>
>> SVG is special. Let's see:<br>
>><br>
>> <a href="https://www.w3.org/TR/html5/syntax.html#foreign-elements" rel="noreferrer noreferrer" target="_blank">https://www.w3.org/TR/html5/syntax.html#foreign-elements</a><br>
>><br>
>> In html, svg namespace elements are Foreign Elements.<br>
>><br>
>> And Foreign Elements can have self-closing tags:<br>
>><br>
>> <a href="https://www.w3.org/TR/html5/syntax.html#start-tags" rel="noreferrer noreferrer" target="_blank">https://www.w3.org/TR/html5/syntax.html#start-tags</a> , item 6).<br>
>><br>
>> When or if X3D elements are also designated Foreign Elements in HTML,<br>
>> they could become self-closing. But until then, they are Unknown<br>
>> Elements in HTML5 and need a start and end tag.<br>
>><br>
>> Oh, this is actually still being discussed in the context of custom<br>
>> elements for web components:<br>
>><br>
>> <a href="https://github.com/w3c/webcomponents/issues/624" rel="noreferrer noreferrer" target="_blank">https://github.com/w3c/webcomponents/issues/624</a><br>
>><br>
>> The summary of this discussion is while there is a demand for<br>
>> self-closing tags for custom elements, the changes to the html parsing<br>
>> algorithm are considered too invasive for the benefit.<br>
>><br>
>> In a way, an x3d html encoding would be parallel to the x3d json or<br>
>> java encoding. It just should be simpler to define based on the XML<br>
>> encoding. Starting with something like XML but case-insensitive and<br>
>> with explicit closing tags rather than self-closing tags.<br>
>><br>
>>> As far as jupyter goes, since that notebook supports python and a wide variety of embedded languages I expect that we will be able to align satisfactorily as this work proceeds - you've made great progress already.<br>
>><br>
>> Yes, with the goal in mind in mind to make the python encoding easy to<br>
>> use for jupyter. Perhaps a separate conda/pip python package which<br>
>> depends on a future x3dpsail and provides .toStringX3Dhtml(),<br>
>> toFileX3Dhtml<br>
>><br>
>> -Andreas<br>
>><br>
>>> On 5/31/2019 5:56 PM, Andreas Plesch wrote:<br>
>>>> Well, if it was xhtml we were talking about you would be correct.<br>
>>>><br>
>>>> But, it is html without the x which is expected by the HTML renderer<br>
>>>> in Jupyter. There is no XHTML renderer since the Jupyter notebook<br>
>>>> itself is a HTML document.<br>
>>>><br>
>>>> And html allows singleton tags only for certain tags, at least in how<br>
>>>> all browser parse the markup, and probably also as defined in the<br>
>>>> HTML5 spec. These certain tags may include all known HTML elements<br>
>>>> which do not use their text content. Unfortunately, the X3D tags are<br>
>>>> considered Unknown Elements by html and they seem to require the<br>
>>>> explicit end tag.<br>
>>>><br>
>>>> x3dom does not use any HTML parsing libraries but completely relies on<br>
>>>> the web browser to do the parsing. And the browsers get confused,<br>
>>>> because they do not understand the singleton x3d tags in a html<br>
>>>> document.<br>
>>>><br>
>>>> Alas, if the xml serializing library in X3DJSAIL does not have an<br>
>>>> option to generate full tags (they would be still legal XML, no?), we<br>
>>>> would need to settle for xhtml IFrames which can also be included in a<br>
>>>> Jupyter notebook (but not tested yet), or, as another option, wrap the<br>
>>>> xml X3D into an Inline since x3dom always uses the browser XML parser<br>
>>>> for Inlines. Would x3d.toStringX3DInline(filename) be considered too<br>
>>>> extravagant ? It would generate an xml X3D document string with a<br>
>>>> single Inline node, and also the content X3D in the file filename.<br>
>>>> x3d.toFileX3DInline(x3dFileName, inlineFileName) would generate two<br>
>>>> files.<br>
>>>><br>
>>>> Perhaps Python has an option to serialize out the full tags, perhaps<br>
>>>> as HTMLFragments. Then a x3d.toStringFullTags() could be included<br>
>>>> outside of X3DJSAIL, and with X3DPSAIL.<br>
>>>><br>
>>>> To consider X_ITE and x3dom together it would be first necessary get<br>
>>>> X_ITE to work at all with Jupyter locally generated content. It may be<br>
>>>> possible since X_ITE works with remote URLs in Jupyter.<br>
>>>><br>
>>>> -Andreas<br>
>>>><br>
>>>> ---on the phone---<br>
>>>><br>
>>>> On Fri, May 31, 2019, 5:14 PM <<a href="mailto:x3d-public-request@web3d.org" rel="noreferrer" target="_blank">x3d-public-request@web3d.org</a> wrote:<br>
>>>>><br>
>>>>> Send x3d-public mailing list submissions to<br>
>>>>>           <a href="mailto:x3d-public@web3d.org" rel="noreferrer" target="_blank">x3d-public@web3d.org</a><br>
>>>>><br>
>>>>> To subscribe or unsubscribe via the World Wide Web, visit<br>
>>>>>           <a href="http://web3d.org/mailman/listinfo/x3d-public_web3d.org" rel="noreferrer noreferrer" target="_blank">http://web3d.org/mailman/listinfo/x3d-public_web3d.org</a><br>
>>>>> or, via email, send a message with subject or body 'help' to<br>
>>>>>           <a href="mailto:x3d-public-request@web3d.org" rel="noreferrer" target="_blank">x3d-public-request@web3d.org</a><br>
>>>>><br>
>>>>> You can reach the person managing the list at<br>
>>>>>           <a href="mailto:x3d-public-owner@web3d.org" rel="noreferrer" target="_blank">x3d-public-owner@web3d.org</a><br>
>>>>><br>
>>>>> When replying, please edit your Subject line so it is more specific<br>
>>>>> than "Re: Contents of x3d-public digest..."<br>
>>>>><br>
>>>>><br>
>>>>> Today's Topics:<br>
>>>>><br>
>>>>>      1. Re: jupyter notebook; X3DOM syntax for including X3D within<br>
>>>>>         HTML/XHTML (Brutzman, Donald (Don) (CIV))<br>
>>>>><br>
>>>>><br>
>>>>> ----------------------------------------------------------------------<br>
>>>>><br>
>>>>> Message: 1<br>
>>>>> Date: Fri, 31 May 2019 10:14:05 +0000<br>
>>>>> From: "Brutzman, Donald (Don) (CIV)" <<a href="mailto:brutzman@nps.edu" rel="noreferrer" target="_blank">brutzman@nps.edu</a>><br>
>>>>> To: "<a href="mailto:x3d-public@web3d.org" rel="noreferrer" target="_blank">x3d-public@web3d.org</a>" <<a href="mailto:x3d-public@web3d.org" rel="noreferrer" target="_blank">x3d-public@web3d.org</a>><br>
>>>>> Subject: Re: [x3d-public] jupyter notebook; X3DOM syntax for including<br>
>>>>>           X3D within HTML/XHTML<br>
>>>>> Message-ID: <<a href="mailto:b6c49fa9-6afc-34fe-ee57-59f0ad5fc99d@nps.edu" rel="noreferrer" target="_blank">b6c49fa9-6afc-34fe-ee57-59f0ad5fc99d@nps.edu</a>><br>
>>>>> Content-Type: text/plain; charset="utf-8"<br>
>>>>><br>
>>>>> thanks for great progress.<br>
>>>>><br>
>>>>> On 5/28/2019 12:12 PM, Andreas Plesch wrote:<br>
>>>>>> - x3dom has a problem with generated X3D outside of an Inline because<br>
>>>>>> the serialized XML output uses self-closing tags such as <Material /><br>
>>>>>> which is not HTML compatible.<br>
>>>>><br>
>>>>> HTML allows singleton elements, i.e. self-closing tags.<br>
>>>>><br>
>>>>> Similarly, element CamelCaseElementNames are legal, so we should not have to rename <Material/> to <material></material> simply because of similarity to another language's naming patterns.<br>
>>>>><br>
>>>>> i think root of this problem likely lies in how X3DOM uses the accompanying DOM libraries - not sure of those details.<br>
>>>>><br>
>>>>> Note that I got *all* of the X_ITE and X3DOM examples to work with HTML by assigning scenes to .html and .xhtml respectively.<br>
>>>>><br>
>>>>> <a href="http://www.web3d.org/x3d/content/examples/X3dResources.html#Examples" rel="noreferrer noreferrer" target="_blank">http://www.web3d.org/x3d/content/examples/X3dResources.html#Examples</a><br>
>>>>><br>
>>>>> <a href="http://x3dgraphics.com/examples/X3dForWebAuthors/Chapter01TechnicalOverview/HelloWorldIndex.html" rel="noreferrer noreferrer" target="_blank">http://x3dgraphics.com/examples/X3dForWebAuthors/Chapter01TechnicalOverview/HelloWorldIndex.html</a><br>
>>>>> <a href="http://x3dgraphics.com/examples/X3dForWebAuthors/Chapter01TechnicalOverview/HelloWorldX3dom.xhtml" rel="noreferrer noreferrer" target="_blank">http://x3dgraphics.com/examples/X3dForWebAuthors/Chapter01TechnicalOverview/HelloWorldX3dom.xhtml</a><br>
>>>>> <a href="http://x3dgraphics.com/examples/X3dForWebAuthors/Chapter01TechnicalOverview/HelloWorldX_ITE.html" rel="noreferrer noreferrer" target="_blank">http://x3dgraphics.com/examples/X3dForWebAuthors/Chapter01TechnicalOverview/HelloWorldX_ITE.html</a><br>
>>>>><br>
>>>>>> So the suggestion would be to provide a method, say<br>
>>>>>> x3d.toStringX3DClosingTags(), which generates explicit closing tags:<br>
>>>>>> <Material></Material><br>
>>>>><br>
>>>>> I don't think it is good to propagate a side-effect fix (which encourages mysterious improper practices and hides path towards fixes).<br>
>>>>><br>
>>>>> Rather it is more desirable to isolate and fix the actual problem.  If someone can figure out why X3DOM runs differently when included within .xhtml and .html pages, that may reveal whatever idiosyncrasy is actually occurring.<br>
>>>>><br>
>>>>> Finally we want to match the same patterns in X_ITE and X3DOM so that choice of player is independent of source-model syntax when using X3D version 4.  So this is a worthy mismatch to figure out and fix.  Hopefully we can get closer to sorting things out fully.<br>
>>>>><br>
>>>>> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -<br>
>>>>><br>
>>>>> Meanwhile: found and fixed several errors in online X3DOM .xhtml examples:<br>
>>>>> - corrected url to match changed release address:<br>
>>>>>      <a href="https://x3dom.org/release/x3dom.css" rel="noreferrer noreferrer" target="_blank">https://x3dom.org/release/x3dom.css</a><br>
>>>>>      <a href="https://x3dom.org/release/x3dom-full.js" rel="noreferrer noreferrer" target="_blank">https://x3dom.org/release/x3dom-full.js</a><br>
>>>>><br>
>>>>> - fixed bug in X3dToX3dom.xslt code logic in order to include function toggleFullscreen ()<br>
>>>>><br>
>>>>> - using XHTML Transitional (vice Strict) DTD in order for anchor target attribute to pass validation<br>
>>>>>      <a href="https://stackoverflow.com/questions/4666523/xhtml-strict-1-0-target-blank-not-valid" rel="noreferrer noreferrer" target="_blank">https://stackoverflow.com/questions/4666523/xhtml-strict-1-0-target-blank-not-valid</a><br>
>>>>><br>
>>>>> X3dToX3dom.xslt stylesheet correction checked in, X3DOM example pages updated and uploaded.  Having fun with X3DOM!  8)<br>
>>>>><br>
>>>>> all the best, Don<br>
>>>>> --<br>
>>>>> Don Brutzman  Naval Postgraduate School, Code USW/Br       <a href="mailto:brutzman@nps.edu" rel="noreferrer" target="_blank">brutzman@nps.edu</a><br>
>>>>> Watkins 270,  MOVES Institute, Monterey CA 93943-5000 USA   +1.831.656.2149<br>
>>>>> X3D graphics, virtual worlds, navy robotics <a href="http://faculty.nps.edu/brutzman" rel="noreferrer noreferrer" target="_blank">http://faculty.nps.edu/brutzman</a><br>
>>>>><br>
>>>>> ------------------------------<br>
>>>>><br>
>>>>> Subject: Digest Footer<br>
>>>>><br>
>>>>> _______________________________________________<br>
>>>>> x3d-public mailing list<br>
>>>>> <a href="mailto:x3d-public@web3d.org" rel="noreferrer" target="_blank">x3d-public@web3d.org</a><br>
>>>>> <a href="http://web3d.org/mailman/listinfo/x3d-public_web3d.org" rel="noreferrer noreferrer" target="_blank">http://web3d.org/mailman/listinfo/x3d-public_web3d.org</a><br>
>>>>><br>
>>>>><br>
>>>>> ------------------------------<br>
>>>>><br>
>>>>> End of x3d-public Digest, Vol 122, Issue 137<br>
>>>>> ********************************************<br>
>>>><br>
>>>> _______________________________________________<br>
>>>> x3d-public mailing list<br>
>>>> <a href="mailto:x3d-public@web3d.org" rel="noreferrer" target="_blank">x3d-public@web3d.org</a><br>
>>>> <a href="http://web3d.org/mailman/listinfo/x3d-public_web3d.org" rel="noreferrer noreferrer" target="_blank">http://web3d.org/mailman/listinfo/x3d-public_web3d.org</a><br>
>>>><br>
>>><br>
>>><br>
>>> all the best, Don<br>
>>> --<br>
>>> Don Brutzman  Naval Postgraduate School, Code USW/Br       <a href="mailto:brutzman@nps.edu" rel="noreferrer" target="_blank">brutzman@nps.edu</a><br>
>>> Watkins 270,  MOVES Institute, Monterey CA 93943-5000 USA   +1.831.656.2149<br>
>>> X3D graphics, virtual worlds, navy robotics <a href="http://faculty.nps.edu/brutzman" rel="noreferrer noreferrer" target="_blank">http://faculty.nps.edu/brutzman</a><br>
> <br>
> <br>
> <br>
<br>
<br>
all the best, Don<br>
-- <br>
Don Brutzman  Naval Postgraduate School, Code USW/Br       <a href="mailto:brutzman@nps.edu" rel="noreferrer" target="_blank">brutzman@nps.edu</a><br>
Watkins 270,  MOVES Institute, Monterey CA 93943-5000 USA   +1.831.656.2149<br>
X3D graphics, virtual worlds, navy robotics <a href="http://faculty.nps.edu/brutzman" rel="noreferrer noreferrer" target="_blank">http://faculty.nps.edu/brutzman</a><br>
</blockquote></div></div></div>
</div>