Forums

WordPress › Support » Requests and Feedback

Pictures/Gallery Insertion Code not XHTML 1.0 Strict Compliant (5 posts)

  1. Stoick
    Member
    Posted 3 years ago #

    Problem #1:

    I noticed a problem with the gallery insertion code that prevents strict XHTML web sites from validating and was hoping it could be fixed in an upcoming release. WordPress has been supportive of standards based design and this error seems like a small oversight.

    The problem exists because in strict XHTML, internal style sheets may only be used in the <head> of a document.

    <style type="text/css">
.gallery{margin: auto;}
.gallery-item{float: left;margin-top: 10px;text-align: center;width: 33%;}
.gallery img{border: 2px solid #cfcfcf;}
.gallery-caption{margin-left: 0px;}
</style>

    Whenever a Gallery is inserted automatically into a post though, it inserts this code into the site as well - into the body of the document.

    The fix is to remove the code insertion and stick it into the style sheet itself. The problem is that the insertion code is buried in:

    /wp-includes/media.php

    It is not inside of the wp-content/themes directory which makes it likely that users would rewrite over this code anyway when updating. This insertion code should not exist in its current form.

    Problem #2:

    When inserting an image into a post using WordPress's "Add Media" functionality the code that it inserts into the post includes width and height attribute which do not validate in strict XHTML design.

    This could easily be fixed by instead inserting:

    style="width: #;height: #;"

    These two issues seem like quick fixes to me that were probably just missed along the way to releasing a fabulous blog platform as quickly as possible. I hope that someone might be able to take the time to quickly fix these in a future version.

    Thanks!

  2. flipper52
    Member
    Posted 3 years ago #

    I'm curious why you would expect WP, which identifies itself in the DOCTYPE as being XHTML 1.0 Transitional to be compliant with the XHTML 1.0 Strict DTD?

    I'm not disagreeing with your points, especially the burying of the gist of "Problem #1" outside of the wp-content directory; personally, I wish they'd go to the Strict DTD, also, but I definitely don't expect elements of a 'Transitional' body of code to all of a sudden start validating against 'Strict' DTDs.

    If my wp blog was nested in a Strict site (as all of my own sites and those I produce are defined as) it would be my responsibility to bring the nested code into Strict compliance. Not something that I'd be in a hurry to do,myself, especially considering the comment about Issue #1 in your post (for which I'm grateful, by the way). :)

  3. Mark
    Member
    Posted 3 years ago #

    I'm also just looking at this issue, and my problem is not so much with the validation as well as with the fact that I don't like inline CSS that I can only remove by editing core files.

    Can this be fixed without editing any of the core files?

  4. Stoick
    Member
    Posted 3 years ago #

    flipper52, my problem is that WordPress should not be Transitional. The transitional doctype tells you not to use it. In the doctype itself it declares:

    "Authors should use the Strict DTD when possible, but may use the Transitional DTD when support for presentation attribute and elements is required." - W3C

    Transitional doctype exists to allow web designers/developers to declare a doctype until they have the time and resources required to fix it and make it strict compliant.

    So by the very nature of using the transitional doctype it is a statement that it is broken and needs to be fixed. With that fact established, then you can see why someone would request stuff that is broken be fixed.

  5. Ryan Hellyer
    Member
    Posted 3 years ago #

    I was surprised to see this code sprew is still present in WordPress. I reported it back in 2.5 and read that it was going to be fixed. However we are now at 2.7.1 and the inline styling still remains. This is a real pain in the neck.

    I'm assuming there is some way to program around this, but it would be quite tedious I think and a fix to the core code would be a lot better IMO.

Topic Closed

This topic has been closed to new replies.

About this Topic

Tags