why would an inline XMLNS change the entire tag structure? JSF

1
votes

My apologies in advance, i don't do a lot of front end development. But in short xmlns attributes are removing tags and moving them around in the rendered document. This is probably a JSF issue as it even happens in view source. This svg tag works and does not alter the structure:

<svg id="Layer_1"  x="0px" y="0px" width="150px" height="150px" viewBox="0 0 150 150" enable-background="new 0 0 150 150">

But as soon as an xml namespace is declared, all the code on the page is altered. It moves my span tags, a tags, heading tags, removes closing div tags, and orders them in a way that just breaks everything. here is an example of the original xhtml, and rendered xhtml along with the html's xmlns

pre-jsf xhtml:

 <a href="?service=all" class="#{servicesAllClass}">
                      <span>
                          <svg **xmlns="http://www.w3.org/2000/svg"**  id="Layer_1"  x="0px" y="0px"
                               width="150px" height="150px" viewBox="0 0 150 150" enable-background="new 0 0 150 150">
                            <path fill="#3A3838" d="M126.83,8.875H22.169c-7.116,0-12.884,5.768-12.884,12.884v102.482c0,7.115,5.768,12.884,16.884,12.884
                                H130.83c3.116,0,8.884-5.769,8.884-12.884V21.759C139.714,14.643,133.946,8.875,126.83,8.875z M38.643,118.505
                                c-5.93,0-10.737-4.807-10.737-10.737c0-5.93,4.807-10.736,10.737-10.736s10.736,4.807,10.736,10.736
                                C49.379,113.698,44.573,118.505,38.643,118.505z M38.643,83.736c-5.93,0-10.737-4.806-10.737-10.736
                                c0-5.93,4.807-10.737,10.737-10.737S49.379,67.07,49.379,73C49.379,78.931,44.573,83.736,38.643,83.736z M38.643,48.969
                                c-5.93,0-10.737-4.807-10.737-10.737s4.807-10.736,10.737-10.736s10.736,4.806,10.736,10.736S44.573,48.969,38.643,48.969z
                                 M112.834,45.167H68.166c-4.418,0-8-3.582-8-8s3.582-8,8-8h44.668c4.418,0,8,3.582,8,8S117.252,45.167,112.834,45.167z
                                 M112.834,80.167H68.166c-4.418,0-8-3.581-8-8c0-4.418,3.582-8,8-8h44.668c4.418,0,8,3.582,8,8
                                C120.834,76.586,117.252,80.167,112.834,80.167z M112.834,115.167H68.166c-4.418,0-8-3.581-8-8s3.582-8,8-8h44.668
                                c4.418,0,8,3.581,8,8S117.252,115.167,112.834,115.167z"></path>
                            </svg>
                         </span>
                      <h5>All</h5>
                  </a>

This is the code after JSF when xmlns is in the tag, notice the lack of a closing anchor tag, that was not left out, its just not there. When xmlns is removed however, it is displayed exactly the same as the original (above) script, so i have opted to not include it.

DOM when pulled in any browser (note the missing anchor tag, it was moved down like 30 lines)

<a href="?service=all-services" class="disabled">
                      <span><svg xmlns="http://www.w3.org/2000/svg" id="Layer_1" x="0px" y="0px" width="150px" height="150px" viewBox="0 0 150 150" enable-background="new 0 0 150 150">
                            <path fill="#3A3838" d="M126.83,8.875H22.169c-7.116,0-12.884,5.768-12.884,12.884v102.482c0,7.115,5.768,12.884,16.884,12.884                                     H130.83c3.116,0,8.884-5.769,8.884-12.884V21.759C139.714,14.643,133.946,8.875,126.83,8.875z M38.643,118.505                                     c-5.93,0-10.737-4.807-10.737-10.737c0-5.93,4.807-10.736,10.737-10.736s10.736,4.807,10.736,10.736                                     C49.379,113.698,44.573,118.505,38.643,118.505z M38.643,83.736c-5.93,0-10.737-4.806-10.737-10.736                                     c0-5.93,4.807-10.737,10.737-10.737S49.379,67.07,49.379,73C49.379,78.931,44.573,83.736,38.643,83.736z M38.643,48.969                                     c-5.93,0-10.737-4.807-10.737-10.737s4.807-10.736,10.737-10.736s10.736,4.806,10.736,10.736S44.573,48.969,38.643,48.969z                                      M112.834,45.167H68.166c-4.418,0-8-3.582-8-8s3.582-8,8-8h44.668c4.418,0,8,3.582,8,8S117.252,45.167,112.834,45.167z                                      M112.834,80.167H68.166c-4.418,0-8-3.581-8-8c0-4.418,3.582-8,8-8h44.668c4.418,0,8,3.582,8,8                                     C120.834,76.586,117.252,80.167,112.834,80.167z M112.834,115.167H68.166c-4.418,0-8-3.581-8-8s3.582-8,8-8h44.668                                     c4.418,0,8,3.581,8,8S117.252,115.167,112.834,115.167z"></path>
                            </svg>

                      <h5>All</h5>
                  </span>

complete document that was requested:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns:jsp="http://java.sun.com/JSP/Page"   xmlns:fn="http://java.sun.com/jsp/jstl/functions" xmlns:c="http://xmlns.jcp.org/jsp/jstl/core" xmlns:f="http://java.sun.com/jsf/core" xmlns:h="http://java.sun.com/jsf/html" xmlns:ui="http://java.sun.com/jsf/facelets">
<head></head>
<body>
<ui:composition>
<div style="display:grid;">
 <a href="?service=all" class=".test">
                      <span>
                          <svg xmlns="http://www.w3.org/2000/svg"  id="Layer_1"  x="0px" y="0px"
                               width="150px" height="150px" viewBox="0 0 150 150" enable-background="new 0 0 150 150">
                            <path fill="#3A3838" d="M126.83,8.875H22.169c-7.116,0-12.884,5.768-12.884,12.884v102.482c0,7.115,5.768,12.884,16.884,12.884
                                H130.83c3.116,0,8.884-5.769,8.884-12.884V21.759C139.714,14.643,133.946,8.875,126.83,8.875z M38.643,118.505
                                c-5.93,0-10.737-4.807-10.737-10.737c0-5.93,4.807-10.736,10.737-10.736s10.736,4.807,10.736,10.736
                                C49.379,113.698,44.573,118.505,38.643,118.505z M38.643,83.736c-5.93,0-10.737-4.806-10.737-10.736
                                c0-5.93,4.807-10.737,10.737-10.737S49.379,67.07,49.379,73C49.379,78.931,44.573,83.736,38.643,83.736z M38.643,48.969
                                c-5.93,0-10.737-4.807-10.737-10.737s4.807-10.736,10.737-10.736s10.736,4.806,10.736,10.736S44.573,48.969,38.643,48.969z
                                 M112.834,45.167H68.166c-4.418,0-8-3.582-8-8s3.582-8,8-8h44.668c4.418,0,8,3.582,8,8S117.252,45.167,112.834,45.167z
                                 M112.834,80.167H68.166c-4.418,0-8-3.581-8-8c0-4.418,3.582-8,8-8h44.668c4.418,0,8,3.582,8,8
                                C120.834,76.586,117.252,80.167,112.834,80.167z M112.834,115.167H68.166c-4.418,0-8-3.581-8-8s3.582-8,8-8h44.668
                                c4.418,0,8,3.581,8,8S117.252,115.167,112.834,115.167z"></path>
                            </svg>
                         </span>
                      <h5>All</h5>
                  </a>
</div>
</ui:composition>
</body>
</html>

Details:

My clear question: "What could possibly cause the dom to be changed when an XML namespace attribute is added to an element?"

application server + IDE: Glassfish 5.0 - Java EE 8 - JSF 2.3.2 - SCSS css pre-proccessor only processing .scss files - intellij IDEA Ultimate (Latest)

all files are .xhtml, there are currently no managed beans, code, or javascript that in any way effect this.

When html is put in tomcat without JSF this does not happen. This is why i am pointing at JSF but i may be incorrect.

1
jsfsvgxml-namespaces
Thomas you should remove your downvote if you feel your last comment is no longer valid and was justifiably deleted. Please note however, i'm more than happy to alter my question in any way that would actually make it easier to understand/answer. However people who just come in to mini-mod as a power play are just hurting the community far more than they help it. My question is well structured, not asked before, has code samples, question right in the title, how does that deserve a downvote? – Nathan H
I'd have liked to try to help out, but the sort of complaining and me not being able to see the other comments and the question not being an minimal reproducible example, you pointing fingers to JSF while at the same time stating you have little knowledge of front end development makes me sort of reluctant. Since JSF works on xml (and validates it), I doubt JSF does this since it would result in a xml dom error. Start by makeing sure your jsf namespaces are all from the same version. Then make it a real minimal reproducible example, provide version info (JSF and 'jsp' is prehistoric but you do partly have very modern jsf namespaces) – Kukeltje
So effectively a lot is missing in your question and if for all sort of not to good (often bad) questions, I get €10,-, I could go on a great holiday on a tropical island. And yes, then often simple modding by downvoting happens. Keep in mind we all do this in our spare, free, unpaid time!!! – Kukeltje
Hey thanks for the comment. I did not say i have little frontend knowledge, ive developed frontends for many major websites, its just not my focus. JSF is by no means prehistoric so ofcourse i have modern namespaces, i have reasons for using JSF i wont get in to. It does not result in a dom error because it is moving the xml tags allowing it to validate, the missing anchor in my post was moved down very far. I can not release the source to my site so this is what i am able to post. – Nathan H
I am happy to add more if it does not disclose all of my source, but from what i have experienced the info i have added should be sufficient enough to get somebodies opinion on where to even start looking. As you stated i will start looking through versions. And i do agree with you, this may not be JSF but when ran in tomcat without EE it does not do this. Thank you for the help, i will edit my post accordingly. It could be a glassfish thing too, or CDI, ill research that too. – Nathan H

1 Answers

1
votes

I debugged a bit and found this must be happening in JSF SAXCompiler routines. While the com.sun.faces.facelets.compiler.SAXCompiler.CompilationHandler gets its' startElement and endElement methods invoked in correct order as per the XHTML source code, the result of

FaceletHandler h = this.compiler.compile(url, alias);

at line 475 of com.sun.faces.facelets.impl.DefaultFaceletFactory Mojarra 2.3.8, is a FaceletHandler representing the observed wrong element tree structure.

This has been reported as bug #4555.

There has also been a very similar question before which was then reported as a bug to Mojarra. As that bug is resolved, I'd consider this to be a new one. So I'd suggest you to report that bug using a minified reproducable example. For your application you should consider to emebed SVGs using <ui:include src="/resources/svg/one.svg" /> as BalusC suggest in response to the other question.