[ICE-10026] HTML5 DocType styling issues (was: WildFly8 specific styling issues) - ICEsoft JIRA Issue Tracker

Carmen Cristurean created issue - 15/May/14 10:53 AM

Carmen Cristurean made changes - 15/May/14 10:54 AM

Field	Original Value	New Value
Attachment		Capture.PNG [ 17188 ]

Carmen Cristurean made changes - 15/May/14 10:55 AM

Component/s

Sample Apps [ 10010 ]

Carmen Cristurean made changes - 15/May/14 10:58 AM

Description

showcase > ace:selectMenu > all demos:
Component renders as in attached screen shot.

showcase > ace:selectMenu > all demos:
Component renders as in attached screen shot.

This issue can be reproduced also with QA test application for selectMenu, if installed on WildFly8.

Ken Fyten made changes - 15/May/14 11:01 AM

Assignee		Arturo Zambrano [ artzambrano ]
Fix Version/s		EE-3.3.0.GA_P02 [ 11371 ]
Priority	Major [ 3 ]	Minor [ 4 ]
Assignee Priority		P2 [ 10011 ]

Carmen Cristurean made changes - 15/May/14 11:31 AM

Description

showcase > ace:selectMenu > all demos:
Component renders as in attached screen shot.

This issue can be reproduced also with QA test application for selectMenu, if installed on WildFly8.

WildFly8 testing found the next styling issues:

1) showcase > ace:selectMenu > all demos:
Component renders as in attached screen shot (capture.PNG).
This issue can be reproduced also with QA test application for selectMenu, if installed on WildFly8.

2) Ace:selectMenu inside ice:panelTabSet (tabSet.PNG).

Carmen Cristurean made changes - 15/May/14 11:32 AM

Attachment

tabSet.PNG [ 17189 ]

Carmen Cristurean made changes - 15/May/14 11:32 AM

Summary

ace:selectMenu styling issue (WildFly8)

WildFly8 specific styling issues

Hide

Permalink

Carmen Cristurean added a comment - 15/May/14 3:04 PM

These issues are not dependent on the icefaces-ee-ext.jar being included or not in showcase.war file.

Show

Carmen Cristurean added a comment - 15/May/14 3:04 PM These issues are not dependent on the icefaces-ee-ext.jar being included or not in showcase.war file.

Hide

Permalink

Arturo Zambrano added a comment - 20/May/14 2:47 PM - edited

After a lot of investigation, the only likely cause of this behaviour is the document type declaration in WildFly8. In tomcat, the document type declaration that gets rendered in the pages tested is this:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

Which is the same doctype declaration specified in all the xhtml pages tested. In contrast, in WildFly8, the doctype declaration that gets rendered is always this:

<!DOCTYPE HTML>

There doesn't seem to be any other cause/difference but this one. The rest of the rendered HTML is identical between tomcat and WildFly8. I verified all the applied CSS styles of several elements that compose the ace:selectMenu and ice:panelTabSet components, and all of them are exactly the same. The only difference is seen in the computed style.

I also tried removing CSS class names from the elements that compose these components as well as removing entire CSS style sheets and specific definitions, and none of that improved the issue.

Custom application CSS styles don't have anything to do either. The issue was still seen using a simple test page like the following:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
        "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"
      xmlns:h="http://java.sun.com/jsf/html"
      xmlns:f="http://java.sun.com/jsf/core"
      xmlns:ace="http://www.icefaces.org/icefaces/components">

<h:head>
    <title></title>
</h:head>

<h:body>
		<h:form>
				<ace:selectMenu>
					<f:selectItem itemValue="test" itemLabel="test" />
				</ace:selectMenu>
		</h:form>
</h:body>
</html>

Moreover, the ace:selectMenu component doesn't have a CSS file of it's own, and the issue with ice:panelTabset also failed when using a different componen such as ace:comboBox or a simple h:outputText, instead.

It seems that the issue doesn't have to do with CSS, but with the way that elements are arranged, while being under the effects of certain doctype declaration.

I could come up with a simple fix for the ace:selectMenu component, which consists in specifically setting the height of the container to that of the down arrow button. This works well on Tomcat as well. It hasn't been committed yet.

Show

Arturo Zambrano added a comment - 20/May/14 2:47 PM - edited After a lot of investigation, the only likely cause of this behaviour is the document type declaration in WildFly8. In tomcat, the document type declaration that gets rendered in the pages tested is this: <!DOCTYPE HTML PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> Which is the same doctype declaration specified in all the xhtml pages tested. In contrast, in WildFly8, the doctype declaration that gets rendered is always this: <!DOCTYPE HTML> There doesn't seem to be any other cause/difference but this one. The rest of the rendered HTML is identical between tomcat and WildFly8. I verified all the applied CSS styles of several elements that compose the ace:selectMenu and ice:panelTabSet components, and all of them are exactly the same. The only difference is seen in the computed style. I also tried removing CSS class names from the elements that compose these components as well as removing entire CSS style sheets and specific definitions, and none of that improved the issue. Custom application CSS styles don't have anything to do either. The issue was still seen using a simple test page like the following: <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd" > <html xmlns= "http://www.w3.org/1999/xhtml" xmlns:h = "http://java.sun.com/jsf/html" xmlns:f = "http://java.sun.com/jsf/core" xmlns:ace = "http://www.icefaces.org/icefaces/components" > <h:head> <title> </title> </h:head> <h:body> <h:form> <ace:selectMenu> <f:selectItem itemValue= "test" itemLabel= "test" /> </ace:selectMenu> </h:form> </h:body> </html> Moreover, the ace:selectMenu component doesn't have a CSS file of it's own, and the issue with ice:panelTabset also failed when using a different componen such as ace:comboBox or a simple h:outputText, instead. It seems that the issue doesn't have to do with CSS, but with the way that elements are arranged, while being under the effects of certain doctype declaration. I could come up with a simple fix for the ace:selectMenu component, which consists in specifically setting the height of the container to that of the down arrow button. This works well on Tomcat as well. It hasn't been committed yet.

Hide

Permalink

Ted Goddard added a comment - 20/May/14 3:52 PM

Try a simple non-ICEfaces application with a facelet page with custom doctype.

Show

Ted Goddard added a comment - 20/May/14 3:52 PM Try a simple non-ICEfaces application with a facelet page with custom doctype.

Hide

Permalink

Arturo Zambrano added a comment - 20/May/14 4:07 PM

Using the test page above and changing the doctype declaration to <!DOCTYPE HTML> and deploying on Tomcat reproduced the same issue seen on WildFly8. So, we can confirm that the doctype declaration has something to do with this issue.

The code used was the following:

<!DOCTYPE HTML>
<html xmlns="http://www.w3.org/1999/xhtml"
      xmlns:h="http://java.sun.com/jsf/html"
      xmlns:f="http://java.sun.com/jsf/core"
      xmlns:ace="http://www.icefaces.org/icefaces/components">

<h:head>
    <title></title>
</h:head>

<h:body>
		<h:form>
				<ace:selectMenu>
					<f:selectItem itemValue="test" itemLabel="test" />
				</ace:selectMenu>
		</h:form>
</h:body>
</html>

Show

Arturo Zambrano added a comment - 20/May/14 4:07 PM Using the test page above and changing the doctype declaration to <!DOCTYPE HTML> and deploying on Tomcat reproduced the same issue seen on WildFly8. So, we can confirm that the doctype declaration has something to do with this issue. The code used was the following: <!DOCTYPE HTML> <html xmlns= "http://www.w3.org/1999/xhtml" xmlns:h = "http://java.sun.com/jsf/html" xmlns:f = "http://java.sun.com/jsf/core" xmlns:ace = "http://www.icefaces.org/icefaces/components" > <h:head> <title> </title> </h:head> <h:body> <h:form> <ace:selectMenu> <f:selectItem itemValue= "test" itemLabel= "test" /> </ace:selectMenu> </h:form> </h:body> </html>

Hide

Permalink

Arturo Zambrano added a comment - 20/May/14 4:24 PM

I made another test with plain HTML markup. I copied the HTML markup rendered by the component, removed the scripts, and removed everything else that ICEfaces renders. The end result was this:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"><head>
    <title></title>
</head>
<body>
<div class="ui-selectmenu " id="j_idt5:_t6">
	<span class="ui-widget ui-corner-all ui-state-default ui-selectmenu-value " role="select" style="display: inline-block; width: 200px;" tabindex="0">
		<span class="ui-inputfield ui-state-default ui-corner-left  ui-state-optional" style="; display: inline-block; overflow: hidden; border-top:0;border-bottom:0;border-left:0;"></span>
		<div class="ui-state-default ui-corner-right" style="float:right; width:17px; border:0;">
			<div></div>
			<div class="ui-icon ui-icon-triangle-1-s"></div>
		</div>
	</span>
	<input autocomplete="off" name="j_idt5:_t6_input" type="hidden" />
	<div class="ui-widget ui-widget-content ui-corner-all ui-selectmenu-list" id="j_idt5:_t6_div" style="display:none;z-index:500;"></div>
</div>
</body>
</html>

Since all the CSS stylesheets are not included, the page looks blank. However, you can still inspect the elements in the Chrome developer tools window and notice that the height of the first span (that with class ui-selectmenu-value, corresponding to the area that displays the value of the component) is 0, when using the transitional doctype declaration, which is normal. Then, after changing the doctype declaration to <!DOCTYPE HTML>, if you inspect that same span element, it will show a height of 18 pixels in Chrome. So, the doctype declaration definitely plays a role in how components look to the user.

Show

Arturo Zambrano added a comment - 20/May/14 4:24 PM I made another test with plain HTML markup. I copied the HTML markup rendered by the component, removed the scripts, and removed everything else that ICEfaces renders. The end result was this: <!DOCTYPE HTML PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd" > <html xmlns= "http://www.w3.org/1999/xhtml" > <head> <title> </title> </head> <body> <div class= "ui-selectmenu " id= "j_idt5:_t6" > <span class= "ui-widget ui-corner-all ui-state-default ui-selectmenu-value " role= "select" style= "display: inline-block; width: 200px;" tabindex= "0" > <span class= "ui-inputfield ui-state-default ui-corner-left ui-state-optional" style= "; display: inline-block; overflow: hidden; border-top:0;border-bottom:0;border-left:0;" > </span> <div class= "ui-state-default ui-corner-right" style= "float:right; width:17px; border:0;" > <div> </div> <div class= "ui-icon ui-icon-triangle-1-s" > </div> </div> </span> <input autocomplete= "off" name= "j_idt5:_t6_input" type= "hidden" /> <div class= "ui-widget ui-widget-content ui-corner-all ui-selectmenu-list" id= "j_idt5:_t6_div" style= "display:none;z-index:500;" > </div> </div> </body> </html> Since all the CSS stylesheets are not included, the page looks blank. However, you can still inspect the elements in the Chrome developer tools window and notice that the height of the first span (that with class ui-selectmenu-value, corresponding to the area that displays the value of the component) is 0, when using the transitional doctype declaration, which is normal. Then, after changing the doctype declaration to <!DOCTYPE HTML> , if you inspect that same span element, it will show a height of 18 pixels in Chrome. So, the doctype declaration definitely plays a role in how components look to the user.

Arturo Zambrano made changes - 20/May/14 4:25 PM

Assignee

Arturo Zambrano [ artzambrano ]

Ted Goddard [ ted.goddard ]

Hide

Permalink

Ted Goddard added a comment - 22/May/14 9:15 AM

Please also try a non-ICEfaces test with the Transitional doctype and an h:outputText to see if WildFly mangles the doctype even when ICEfaces is not present.

Show

Ted Goddard added a comment - 22/May/14 9:15 AM Please also try a non-ICEfaces test with the Transitional doctype and an h:outputText to see if WildFly mangles the doctype even when ICEfaces is not present.

Ken Fyten made changes - 23/May/14 9:54 AM

Assignee

Ted Goddard [ ted.goddard ]

Arturo Zambrano [ artzambrano ]

Hide

Permalink

Arturo Zambrano added a comment - 26/May/14 7:01 PM

After creating a plain JSF application, and using the following facelet...

<!DOCTYPE HTML PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<HTML xmlns="http://www.w3.org/1999/xhtml"
      xmlns:h="http://java.sun.com/jsf/html"
      xmlns:f="http://java.sun.com/jsf/core"
      xmlns:ui="http://java.sun.com/jsf/facelets">
    <h:head>
        <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"/>
        <title></title>
    </h:head>
    <h:body>
        <h:outputText id="test" value="test"/>
    </h:body>
</HTML>

...WildFly 8 still used <!DOCTYPE HTML> as the doctype declaration. The whole HTML rendered was this:

<!DOCTYPE HTML>
<HTML xmlns="http://www.w3.org/1999/xhtml"><head id="j_idt2">
        <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
        <title></title></head><body><span id="test">test</span></body>
</HTML>

Show

Arturo Zambrano added a comment - 26/May/14 7:01 PM After creating a plain JSF application, and using the following facelet... <!DOCTYPE HTML PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd" > <HTML xmlns= "http://www.w3.org/1999/xhtml" xmlns:h = "http://java.sun.com/jsf/html" xmlns:f = "http://java.sun.com/jsf/core" xmlns:ui = "http://java.sun.com/jsf/facelets" > <h:head> <meta http-equiv= "Content-Type" content= "text/html; charset=iso-8859-1" /> <title> </title> </h:head> <h:body> <h:outputText id= "test" value= "test" /> </h:body> </HTML> ...WildFly 8 still used <!DOCTYPE HTML> as the doctype declaration. The whole HTML rendered was this: <!DOCTYPE HTML> <HTML xmlns= "http://www.w3.org/1999/xhtml" > <head id= "j_idt2" > <meta http-equiv= "Content-Type" content= "text/html; charset=iso-8859-1" /> <title> </title> </head> <body> <span id= "test" > test </span> </body> </HTML>

Hide

Permalink

Ted Goddard added a comment - 27/May/14 9:26 AM - edited

This apparently is a JSF 2.2 feature:

http://jsflive.wordpress.com/2013/08/08/jsf22-html5/

By default, JSF 2.2 always renders the HTML5 doctype <!DOCTYPE html> regardless of what is set in the source xhtml file. If you need the old JSF 2.1 behavior (passing through the doctype from the source) you have to change the way xhtml files are processed in the faces-config.xml like this (the complete list of processing modes can be found in the spec):

<faces-config-extension>
<facelets-processing>
<file-extension>.xhtml</file-extension>
<process-as>xhtml</process-as>
</facelets-processing>
</faces-config-extension>

Or use the h:doctype tag:

http://docs.oracle.com/javaee/7/javaserverfaces/2.2/vdldocs/facelets/h/doctype.html

Covered by JSF 2.2 Specification:
1.1.1.1 The facelets-processing element

http://download.oracle.com/otndocs/jcp/jsf-2_2-fr-eval-spec/index.html

When JSF 2.2 is used on Tomcat, does the same behaviour occur?

The most important outcome of this issue is for ICEfaces to generate HTML5-compliant markup.

Show

Ted Goddard added a comment - 27/May/14 9:26 AM - edited This apparently is a JSF 2.2 feature: http://jsflive.wordpress.com/2013/08/08/jsf22-html5/ By default, JSF 2.2 always renders the HTML5 doctype <!DOCTYPE html> regardless of what is set in the source xhtml file. If you need the old JSF 2.1 behavior (passing through the doctype from the source) you have to change the way xhtml files are processed in the faces-config.xml like this (the complete list of processing modes can be found in the spec): <faces-config-extension> <facelets-processing> <file-extension>.xhtml</file-extension> <process-as>xhtml</process-as> </facelets-processing> </faces-config-extension> Or use the h:doctype tag: http://docs.oracle.com/javaee/7/javaserverfaces/2.2/vdldocs/facelets/h/doctype.html Covered by JSF 2.2 Specification: 1.1.1.1 The facelets-processing element http://download.oracle.com/otndocs/jcp/jsf-2_2-fr-eval-spec/index.html When JSF 2.2 is used on Tomcat, does the same behaviour occur? The most important outcome of this issue is for ICEfaces to generate HTML5-compliant markup.

Hide

Permalink

Ken Fyten added a comment - 27/May/14 11:09 AM

This makes sense, except that this issue is being reported against EE 3.3 P02 which should be using JSF 2.1, not JSF 2.2?

Show

Ken Fyten added a comment - 27/May/14 11:09 AM This makes sense, except that this issue is being reported against EE 3.3 P02 which should be using JSF 2.1, not JSF 2.2?

Hide

Permalink

Carmen Cristurean added a comment - 27/May/14 11:32 AM

For this test, the JSF version used was WildFly8 server's default v. 2.1.2.

Show

Carmen Cristurean added a comment - 27/May/14 11:32 AM For this test, the JSF version used was WildFly8 server's default v. 2.1.2.

Hide

Permalink

Arturo Zambrano added a comment - 29/May/14 3:43 PM

This extra spacing is a known issue with HTML5. There are a number of possible solutions described on various sites...

http://www.emailonacid.com/blog/details/C13/12_fixes_for_the_image_spacing_in_html_emails
http://www.andymatthews.net/read/2011/01/02/Resolving-gaps-and-spaces-in-table-cells-when-using-the-HTML-5-doctype
http://bytes.com/topic/html-css/answers/943492-background-leaksbelow-image-table-cell-html5

As for the ice:panelTabSet issue. The extra spacing is simply caused by having an <img> element inside a <td> element, even if the <img> element has no source image. This can be fixed by adding line-height:0; to the <td> element. This fix doesn't break things with HTML4.

As for the ace:selectMenu issue, the fix seems more complex because of some other markup involved. So the fix could be the one reported above, done with Javascript.

Show

Arturo Zambrano added a comment - 29/May/14 3:43 PM This extra spacing is a known issue with HTML5. There are a number of possible solutions described on various sites... http://www.emailonacid.com/blog/details/C13/12_fixes_for_the_image_spacing_in_html_emails http://www.andymatthews.net/read/2011/01/02/Resolving-gaps-and-spaces-in-table-cells-when-using-the-HTML-5-doctype http://bytes.com/topic/html-css/answers/943492-background-leaksbelow-image-table-cell-html5 As for the ice:panelTabSet issue. The extra spacing is simply caused by having an <img> element inside a <td> element, even if the <img> element has no source image. This can be fixed by adding line-height:0; to the <td> element. This fix doesn't break things with HTML4. As for the ace:selectMenu issue, the fix seems more complex because of some other markup involved. So the fix could be the one reported above, done with Javascript.

Ken Fyten made changes - 29/May/14 3:56 PM

Summary

WildFly8 specific styling issues

HTML5 DocType styling issues (was: WildFly8 specific styling issues)

Ken Fyten made changes - 29/May/14 3:56 PM

Security

Private [ 10001 ]

Ken Fyten made changes - 29/May/14 3:56 PM

Affects Version/s		EE-3.3.0.GA_P01 [ 11174 ]
Affects Version/s	EE-3.3.0.GA_P02 [ 11371 ]

Ken Fyten made changes - 29/May/14 3:56 PM

Fix Version/s

4.0 [ 11382 ]

Hide

Permalink

Arturo Zambrano added a comment - 30/May/14 3:19 PM

Committed fixes to 3.3 EE maintenance branch at revision 41258 and to the P02 tag at revision 41260. Added specific fixes for the spacing issues in ice:panelTabSet and ace:selectMenu. The fixes for ice:panelTabSet involve using style="line-height:0;" on the <td> elements that compose the tab and also adding align="left" on the spacer <img> elements. The fix for ace:selectMenu consists in adjusting the height of the value field, as it is routinely done for the down arrow button.

Show

Arturo Zambrano added a comment - 30/May/14 3:19 PM Committed fixes to 3.3 EE maintenance branch at revision 41258 and to the P02 tag at revision 41260. Added specific fixes for the spacing issues in ice:panelTabSet and ace:selectMenu. The fixes for ice:panelTabSet involve using style="line-height:0;" on the <td> elements that compose the tab and also adding align="left" on the spacer <img> elements. The fix for ace:selectMenu consists in adjusting the height of the value field, as it is routinely done for the down arrow button.

Arturo Zambrano made changes - 30/May/14 3:19 PM

Status	Open [ 1 ]	Resolved [ 5 ]
Resolution		Fixed [ 1 ]

Hide

Permalink

Carmen Cristurean added a comment - 03/Jun/14 3:51 PM

Fix confirmed with EE 3.3.0_P02 Build9 / EE-3.3.0-maintenance branch rev. 41277 in showcase and selectMenu QA test app in IE10, Chrome35 and FF 29 on WildFly 8/ with Mojarra 2.1.28.

Show

Carmen Cristurean added a comment - 03/Jun/14 3:51 PM Fix confirmed with EE 3.3.0_P02 Build9 / EE-3.3.0-maintenance branch rev. 41277 in showcase and selectMenu QA test app in IE10, Chrome35 and FF 29 on WildFly 8/ with Mojarra 2.1.28.

Ken Fyten made changes - 14/Nov/14 5:21 PM

Status

Resolved [ 5 ]

Closed [ 6 ]

HTML5 DocType styling issues (was: WildFly8 specific styling issues)

Details

Description

Attachments

Activity

People

Dates