4 Replies Latest reply on Jun 19, 2009 6:07 AM by Nick Belaevski

    RichFaces and XHTML Strict

    Jeff Faath Newbie

      Is there a way to get RichFaces to render in XHTML Strict?

      I'm using a couple tags and they don't validate but the errors are simple. As an example, the "alt" attribute is missing on spacer images.

      Is this fixable or am I going to have to live with Strict?

      Thanks,

      JF

        • 1. Re: RichFaces and XHTML Strict
          Ilya Shaikovsky Master

          Which version used? I could highly recommend you to check the latest one if you using some older release.

          • 2. Re: RichFaces and XHTML Strict
            Jeff Faath Newbie

            Good question. I'm using 3.2.1.GA. I see there are newer versions so I'll give the latest one a shot.

            Thanks.

            • 3. Re: RichFaces and XHTML Strict
              Jeff Faath Newbie

              Looks like the latest version (3.3.1.GA) cleared up the missing "alt" attributes. However, there are still other issues.

              For example, the Tree control actually outputs its own attributes to HTML tags which doesn't fly with XHTML strict. Addtionally, the tab panel outputs a form tag with a "name" attribute and a hidden field that isn't properly wrapped, both illegal in strict.

              The latter can easily be fixed by removing the name attribute and wrapping the hidden input field in a . I've done that by creating a custom renderer for the standard JSF form tag. The other issue, probably not easily fixed. And those are the only two controls I've worked with so far.

              Looks like RichFaces is not currently compatible with XHTML Strict.

              • 4. Re: RichFaces and XHTML Strict
                Nick Belaevski Master

                Hi,

                Unfortunately, XHTML specification is not compatible with extensions namespaces used in tree components (XHTML guys provides special DTDs for those who want to be conformant with the spec.). The good news are that these custom namespaces are well supported by all browsers we declare as the supported ones; so it's really not a problem. We're doing renderers optimization for 3.3.2 version; this will address the problem of simple AJAX-based tree to be conformant to XHTML strict, but switching on some features like built-in D'n'D will cause these attributes to appear in the generated HTML again.