Skip to main content

Opengraph validation for HTML5


Is there any way to get facebook's crappy open graph meta tags to validate if my doctype is <!DOCTYPE html> (HTML5)?



Other than facebook's opengraph meta tags, my document validates perfectly.



I really don't want to use <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML+RDFa 1.0//EN" "http://www.w3.org/MarkUp/DTD/xhtml-rdfa-1.dtd"> as that creates a whole new set of problems.



Here is an example of one of the validation errors in question...



Error Line 11, Column 47: Attribute property not allowed on element meta at this point.




<meta property="og:type" content="website" />



Any help would be appreciated... I have been searching off and on for days to no avail.


Source: Tips4allCCNA FINAL EXAM

Comments

  1. You could use the name attribute instead of property attribute. Facebook lint will throw a warning, but the meta value will still be recognized and parsed.

    Example: <meta name="og:title" content="Hello Facebook" />

    Proof: This example on pastebin and
    parsed by Facebook Lint.

    Edit: example has wrong doctype so does not validate. XHTML doctype does validate.

    ReplyDelete
  2. These meta tags are only required when facebook scans the page for these tags.

    <?
    if(eregi("facebookexternalhit", $_SERVER['HTTP_USER_AGENT'])){

    echo '<meta property="og:type" content=xxxxxxxxxxxxx';
    // continue with the other open graph tags
    }
    ?>


    The said tags will only be present when facebook needs them - this method with PHP removes them completely for all other instances including W3C validation.

    ReplyDelete
  3. Bad solution for the meta tags. If you wrap those in Javascript then the Facebook Linter won't find them. That's the same as not putting them in at all.

    Wrapping like buttons and such in script works to help validate against XHTML 1.0 but not HTML5.

    ReplyDelete
  4. More than a Year has passed and the best solution we've got is to wrap the meta tags in some sort of server-side verification.

    In PHP I did:

    <?php if (stristr($_SERVER["HTTP_USER_AGENT"],'facebook') !== false) { ?>
    <meta property="og:title" content="Title of the page" />
    <meta property="og:url" content="http://www.example.com/" />
    <meta property="og:type" content="website" />
    <meta property="fb:admins" content="123456789" />
    <meta property="og:image" content="http://www.example.com/images/thumb.jpg" />
    <?php } ?>


    It really works for Facebook. But I really don't like this idea!

    ReplyDelete
  5. The short answer is no, not at this time. All other answers are workarounds, hacks, or just plain crazy. The only long-term solution is that Facebook needs to create an alternate syntax that is valid HTML5.

    To those recommending targeting Facebook by the "facebookexternalhit" User Agent, you have to remember that other companies are following Facebook's lead with these tags. For example, Google+ will fall back to the OpenGraph tags if their preferred Schema.org markup isn't present. Since most sites aren’t using Schema.org attributes (especially if they’re spending the time to use OpenGraph correctly), you can easily miss out on enhancing your snippets on sites like Google+ by following this advice.

    With the ubiquity of Facebook, it really isn't a good solution to target them directly--even if their choice of implementation is problematic for developers. When looking for solutions on a site like Stack Overflow, you always have to remember that there can be unforeseen consequences to these methods.

    For our main sites, we've stuck with XHTML+RDFa for validation sake, and it's worked well enough. I'm hoping that as HTML5's usage grows, the Facebook team will start accepting a valid format for this metadata.

    As for why we care about validation:
    We've found that validation, when possible, helps to alert us to errors in our pages by not teaching us to ignore them. Since we all use validation extensions in our browsers, we know instantly if there's a validation error (or warning) on a page, and can investigate whether it's possible to eliminate it (which 99+% of the time it is). This saves us time dealing with restrictive implementations of the specs, especially on fringe and mobile platforms nowadays. We've seen a huge reduction in odd bugs because we're aware of our pages being valid and know that what's going on in the browser doesn’t have to do with invalid markup that a particular UA might not interpret as expected.

    ReplyDelete
  6. In JSP:

    <%
    String ua=request.getHeader("user-agent").toLowerCase();
    if(ua.matches(".*facebookexternalhit.*")){
    }
    %>
    <meta property="og:image" content="images/facebook.jpg" />
    ...
    <%
    }
    %>


    Or:

    <c:set var="ua" value="${header['User-Agent']}" scope="page"/>
    <c:if test="${ua.matches('.*facebookexternalhit.*')}">
    <meta property="og:image" content="images/facebook.jpg" />
    ...
    </c:if>

    ReplyDelete
  7. Although it will cut off non-Javascript users, I've used this

    <script type="text/javascript">
    //<![CDATA[
    document.write('<fb:like href="" send="false" layout="button_count" width="100" show_faces="true" font=""></fb:like>')
    //]]>
    </script>


    and it validated perfectly. It shows and works fine with Firefox, Opera, IE, Chrome, Safari on Windows, and with Firefox, Opera, Safari on Mac.

    ReplyDelete

Post a Comment

Popular posts from this blog

[韓日関係] 首相含む大幅な内閣改造の可能性…早ければ来月10日ごろ=韓国

div not scrolling properly with slimScroll plugin

I am using the slimScroll plugin for jQuery by Piotr Rochala Which is a great plugin for nice scrollbars on most browsers but I am stuck because I am using it for a chat box and whenever the user appends new text to the boxit does scroll using the .scrollTop() method however the plugin's scrollbar doesnt scroll with it and when the user wants to look though the chat history it will start scrolling from near the top. I have made a quick demo of my situation http://jsfiddle.net/DY9CT/2/ Does anyone know how to solve this problem?

Why does this javascript based printing cause Safari to refresh the page?

The page I am working on has a javascript function executed to print parts of the page. For some reason, printing in Safari, causes the window to somehow update. I say somehow, because it does not really refresh as in reload the page, but rather it starts the "rendering" of the page from start, i.e. scroll to top, flash animations start from 0, and so forth. The effect is reproduced by this fiddle: http://jsfiddle.net/fYmnB/ Clicking the print button and finishing or cancelling a print in Safari causes the screen to "go white" for a sec, which in my real website manifests itself as something "like" a reload. While running print button with, let's say, Firefox, just opens and closes the print dialogue without affecting the fiddle page in any way. Is there something with my way of calling the browsers print method that causes this, or how can it be explained - and preferably, avoided? P.S.: On my real site the same occurs with Chrome. In the ex