WordPress.org

Support

Support » Themes and Templates » [Resolved] Lots of W3C HTML Validation errors

[Resolved] Lots of W3C HTML Validation errors

  • I love this theme and I am using it straight out of the box without any modifications so far. However, I noticed that this theme is generating upwards of almost 50 HTML Validation errors depending on the page. Some of the errors originated in my widgets and my postings but those have been fixed. The vast majority of errors are coming from this theme.

    I’m not here to be critical of the developer as I’m grateful for his hard work in creating something that looks this nice.

    I plan on fixing many of the validation errors with a child theme.

    However, there are a couple of validation errors that should be addressed by the developer:

    – Duplicate ID primary. <div id="primary" class="widget-area" role="complementary">

    – End tag svg did not match the name of the current open element (image). </svg>

    Thank-you!

Viewing 15 replies - 1 through 15 (of 51 total)
  • Regarding this error: End tag svg did not match the name of the current open element (image). </svg>

    In the header.php file, this can easily be fixed by “self-closing” all of the <image> tags for the social icons by adding the slash at the end, /> .

    Example: <image src="<?php echo get_template_directory_uri() ?>/images/Twitter.png" />

    However, I cannot find where <image/> is a valid HTML5 tag. I think it’s supposed to be <img/>. However, after correcting the tag to be <img/>, I get a duplicate of the corresponding image. Perhaps the developer can explain what’s happening here.

    See: http://dev.w3.org/html5/markup/img.html

    Regarding this error: Duplicate ID primary. <div id="primary" class="widget-area" role="complementary">

    In the sidebar.php file, this can easily be fixed by changing the id from primary to something else. I don’t see #primary being referenced in the CSS so I don’t believe this fix breaks anything, but I’ll let the developer be the final judge of that.

    There’s also an issue with the Social Icons. You have all of them inside of an unordered list, <ul></ul>. However, only <li></li> elements are allowed to be immediate child elements of ul.

    This can be fixed by wrapping each item within a set of <li></li> tags.

    However, this CSS is also required to preserve the inline format:


    .sociallinks ul li {
    display: inline;
    }

    With the image tags, 1) Self closing tags like <image/> are not proper.
    2) I’m using this SVG fallback technique.

    For the #primary ID, I’ll remove it in the next version. (Same with the invalid Rectangle 1, 2, etc. IDs which I’ll just remove.)

    For the header, I’m not going to bloat the social link markup more, but I might switch to using something other than <ul>.

    Thanks for your feedback. Now I must ask, is there a reason that you need this to validate perfectly?

    After a little research, I found that the <image> tag is a fallback for when <svg> is not supported.

    http://css-tricks.com/svg-fallbacks/

    However, it’s only a fallback for Android 2.3 and IE 8 & below.

    The problem here is that the <image/> tag fallbacks are not compliant….

    – not self-closed with a />
    – missing the width & height attributes
    – missing the href attribute

    Also, I noticed this theme is really screwed up bad in IE 8, which makes me ask the question, is this “fallback” image really necessary?

    On the other hand, we’re only talking about a handful of static icons which are not scaling up/down, is SVG really necessary?

    IMO, we have three options:

    1. Fix the <image/> tag fallbacks so they are HTML compliant.
    2. Remove the <image/> tag fallbacks since we may not care about older browsers support.
    3. Dump the SVG as it appears to be overkill here. Replace them with HTML <img/> links – we know these will work in all browsers.

    I’m leaning towards doing #3, unless I’m missing something here… the <img/> renders the exact same size as the <svg> version in both desktop and mobile versions.

    Sorry, I posted my last reply without seeing yours first.

    Thanks for your feedback. Now I must ask, is there a reason that you need this to validate perfectly?

    1. When HTML is not valid, it’s totally unpredictable. A new browser version may come out tomorrow and choke on improperly constructed unordered lists. Following the agreed upon set of “standards” reduces these issues.

    2. I’m a professional programmer and I’d like the code running my own website to be valid. We all have different tastes when it comes to design but you’ve either programmed it correctly or you haven’t… I don’t believe there’s much of a gray area here.

    3. Removing a duplicate id has nothing to do with perfectionism. JavaScript will not play nice when there are multiple instances of an id.

    I’m open to killing the fallback if it isn’t necessary, but SVGs are vital because users can alter the colors of their social icons. Note that I’m using Inline SVGs here which have lower browser support. And I only target IE 9 and greater, IE 7 and 8 should be readable but little more—this is a lightweight theme that uses modern techniques.

    Like I said, I’ll fix the duplicate IDs. Those definitely shouldn’t be there. The <image> tag hackyness is up in the air at this point, I really wouldn’t mind killing it off but the issue is that this would render social icons completely useless in IE 8 and lower.

    Good point on the dynamic color changing of the icons. I may pick my option #1 or #2 then and keep the SVG.

    There’s no reason why you can’t fix the <image/> fallbacks so they’re compliant. We just need…

    1. an xlink:href attribute
    2. to self-close the tag
    3. the width and height attributes

    EDIT: I spoke too soon. It doesn’t seem possible to validate the <image/> tag. One error always remains.

    Is width="auto" height="auto" href="" valid? I really don’t need to use these properties. (But I want to make the HTML valid)

    width="auto" height="auto" is good.

    /> is good.

    href="" is no good.

    xlink:href="#" is a bit better…

    one error remains…

    “Attribute src not allowed on element image at this point.”

    As per the link I posted above, it’s looking for a .svg file at the xlink:href attribute. I’ll have to research some more but it might not be possible to validate the <image/> fallback. Although, at least the number of errors on each icon has been reduced by 75%.

    Yes, an improvement at the very least. I can wrap up all the other validation issues too.

    I have a 100% compliant version already but only because I’ve tentatively dumped the <image/> fallbacks.

    So basically the site looks like hell in IE 8 anyway and since IE 8 usage is dropping fast, I may not support it at all. I display a nice “site will not render properly – upgrade your browser” message via a jQuery plugin. It’s tied to a cookie so it only nags the user once.

    I’m more interested in Android 2.3 support. If I drop support, I’ll make that a version bump of its own so users wanting support can head back and get the previous version.

Viewing 15 replies - 1 through 15 (of 51 total)
  • The topic ‘[Resolved] Lots of W3C HTML Validation errors’ is closed to new replies.