I am using the W3C XHTML validator to check my sites and I am getting some errors on pages with FBML. Most of the cause of such errors is the "&" character. Since FBML values and attributes are generated on the fly, I have no way to encode the character properly before displaying it.
Question: Is there a way for me to tell Facebook Connect to render the mark up properly?
Thanks.
Try to put the facebook code in CDATA:
<script type="text/javascript">
/* <![CDATA[ */
document.write('<fb:login-button length="long" size="large" show-faces="true" perms="" onlogin="window.location=\'<?=current_url()?>\'"></fb:login-button>');
/* ]]> */
</script>
In short, not as far as I know. To make matters worse, the fb:* tags don't validate either, even if you make your html tag look like this:
<html xmlns="http://www.w3.org/1999/xhtml" xmlns:fb="http://www.facebook.com/2008/fbml" xml:lang="en" lang="en">
If this is a huge issue for you, you might be able to get away with putting non-XHTML-compliant markup in its own HTML-4.01-strict iframe, to basically sweep the crap under the rug.
This might be helpful:
http://wiki.developers.facebook.com/index.php/Facebook_Platform_for_Mobile:_XHTML
Some german guy also worked on it:
http://translate.google.com/translate?js=y&prev=_t&hl=en&ie=UTF-8&layout=1&eotf=1&u=http%3A%2F%2Fwww.ka-mediendesign.de%2Fblog%2Ffbml-in-xhtml-neue-version%2F&sl=de&tl=en
This is how i am doing it. Wrap around all fbml tags inside and then use js to simply uncomment the fbml code using javascript. Heres an example:
Markup:
<P class="fbreplace" style="display: none;">
<!-- FBML
<fb:like layout="standard" show_faces="false" colorscheme="light"></ fb: like>
->
</ p>
JS (JQuery Required):
$(document).ready(function() {
$(".fbreplace").html.replace(/<!-- FBML /g, "");
$(".fbreplace").html.replace(/ -->/g, "");
$(".fbreplace").style.display = "block";
});
Related
I have a webpage that uses an iframe to embed another one of our websites. However, FireFox is having issues rendering the contents of the iframe. When I inspected the raw html that was in the DOM, I noticed the following DOM structure inside the iframe:
#document
<!DOCTYPE html>
<html>
<body></body>
<head> … </head>
<body> … </body>
</html>
Notice the body tag above the head tag - that's not in the source DOM! Removing it from within the developer tools fixes all of the rendering issues. For some reason, FireFox is adding a second body tag just before the head tag. Here is my puzzle:
The extra body is not in the source HTML being delivered
The extra tag only shows up in FireFox, Chrome and IE do not have it in there iframes
If I go straight to the url the iframe is loading in FireFox, the extra body tag is not there!
I have no addons - FireFox install is clean
I have the latest FireFox as of this post (v24.0)
Does anyone know what could be causing this? The site being embedded is really simple and does not have any javascript that could be adding this extra tag.
I don't know what causes this to happen in some FF iframes and not others, but if you have access that allows you to change the code of the page that is loaded into the iframe, you could add this script that removes the first empty body tag:
<script type="text/javascript">
var ffFixCount = 0,
clearExtraBody = function(){
var bodies = document.getElementsByTagName("body");
if(bodies.length > 1){
// assumes the empty, extra body tag you want to remove is the first one
bodies[0].parentNode.removeChild(bodies[0]);
window.clearInterval(ffBodyFixer);
}else{
ffFixCount++;
}
if(ffFixCount = 20){
window.clearInterval(ffBodyFixer);
}
};
//check for extra body tag will run every 100ms,
// 20 times, or, for 2 seconds (to give time for bug to happen)
// or will stop if extra body tag is found
var ffBodyFixer = window.setInterval(
function(){
window.clearExtraBody();
}, 100);
</script>
Imagine a fairly simple HTML document
<!DOCTYPE HTML >
<html>
<body>
<table> <tr> <td> This is a test </td> </tr> </table>
</body>
</html>
where we are applying this css
body {background-color: ffffff;
font-size:100px;
font-style: normal;
font-family: MankSans,Arial,Helvetica, sans-serif;
}
In every single modern browser out there the font properties will apply. in my WebView however, they wont.
Looking around I found out that the problem is that the WebView goes into quirksmode, where the td tag lacks inheritance so the body css doesnt apply.
Im aware that there are ways around this, like using a more explicit 4.01 doctype, or adding this to the css
table, thead, tbody, tr, td, th {
font-size: inherit;
font-family: inherit;
}
these however dont fix the root of the problem, which is that WebView decides against all logic to suddenly "missunderstand" the HTML5 doctype and switch to quirksmode, when all other WebKit-based browsers (Safari, Chrome, etc) behave correctly.
Is there any way to programmatically fix this?
Ok, my stupid mistake
it turns out that the doctype is getting screwed because before sending the HTML document to the webview im treating it, and adding an internal ID to all tags (this internal ID is required for features inside my app)
but in case someone screws up in the same way I did and wonder whats going on, I'll offer a lenghty explanation.
DOMDocumentType has several fields, among them you have name, publicId and systemId.
for example, consider the typical HTML 4.01 transitional doctype
it can be divided in
name = html
publicId = -//W3C//DTD XHTML 1.0 Transitional//EN
systemID = http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd
and you can add a Custom ID to it as long as the format is preserved, like this
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd" CustomID="1">
the problem with the HTML 5 DOCTYPE is that while it looks like a)
<!DOCTYPE html>
for the DOM, it actually is b)
<!DOCTYPE html PUBLIC "" "">
long story short, adding my CustomID="1" at the end of a) caused the DOM to not recognize it as a valid DOCTYPE, hence switching my WebView into quirksmode. If you want to have an HTML5 DOCTYPE and add a custom id to it you should do
<!DOCTYPE html PUBLIC "" "" CustomId="1">
w3schools.com tells us that the id attribute is not valid in: base, head, html, meta, , script, style, and title.
they should warn us that, poorly placed, it can also screw your DOCTYPE =)
It says here that it is not within HTML4, though I don't really see where that's spelled out in the text.
From what I can tell, based on this, it is ok to do so in HTML5 but I'm not entirely sure (assuming style is an HTML element?)
I am using this to rotate out a stylesheet and want it to be as valid as possible according to HTML5 specs, so wondering if I should rewrite it with a data-* element.
+1 Interesting question!
Instead of using a style block, you should consider linking (link) to your stylesheets and then switch them out by referencing an id or a class.
That said, title is perfectly acceptable for a style tag in HTML5. You can use this as a hook for your stylesheet switching.
http://www.w3.org/TR/html5/semantics.html#the-style-element
Fyi... this validates
<!DOCTYPE html>
<html>
<head>
<title>Title</title>
<style title="whatever"></style>
</head>
<body>
Test body
</body>
</html>
http://validator.w3.org/#validate_by_input+with_options
I've just put the following code into the W3C validator and it has no errors :)
<!DOCTYPE html>
<html>
<head>
<title>Title</title>
<style id="test"></style>
</head>
<body>
Test body
</body>
</html>
I think the W3C Validator is a good resource for this type of thing, it is marked as experimental but that's because the standard is yet to be be finalised.
It is not valid in HTML4 (as per the spec) and data-* attributes are not either. That is, the document will not validate against the Doctype spec if you use these attributes.
Regardless of whether the document validates or not, browsers will ignore elements that they do not recognize.
Style tags are DOM elements like any other tag, so you can add any attributes you want.
I'm using AJAX inside my JSF portlet. When the session expires, We are suppose to get the following message(this is the response of AJAX request when session expires)
This page is used to hold your data while you are being authorized for your request.
You will be forwarded to continue the authorization process. If this does not happen automatically, please click the Continue button below.
<CONTINUE BUTTON>
In IE 6 and 7 I can see the continue button. But in Firefox I don't see that button. Only the text is visible.But in the source code I can see that section, but it is grayed in Firebug.I've the screenshot uploaded to http://img31.imageshack.us/img31/619/firefoxcontinue.jpg
Ideally it should automatically forward the user to the login page, since AJAX cannot redirect that, it just displays the response.So Continue button has to be shown inside the portlet. Can someone please tell me why the HTML form is not shown in Mozilla Firefox.
Thanks
I created a test page. The problem is there when we try to insert the Form inside a table.
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML>
<HEAD>
<TITLE> New Document </TITLE>
<META NAME="Generator" CONTENT="EditPlus">
<META NAME="Author" CONTENT="">
<META NAME="Keywords" CONTENT="">
<META NAME="Description" CONTENT="">
</HEAD>
<BODY>
<script type="text/javascript">
function insertAjax(){
// alert('inside ajax');
document.getElementById("wpsportlet").innerHTML='This page is used to hold your data while you are being authorized for your request.<br/><br/>You will be forwarded to continue the authorization process. If this does not happen automatically, please click the Continue button below.<form action="http://www.google.com" method="get" name="AUTOSUBMIT"><input type="submit" value="Continue"/></form>';
}
</script>
<input type=button value="Submit" onclick="insertAjax();">
<div id="wpsportlet">
</div>
</BODY>
</HTML>
If I nest the form inside a table then the Form is not displayed in Firefox. Can someone please help a work around for this.
Your generated DOM is invalid. Character data (text) and <br>, <form> and <script> elements may not be child elements of elements - only <tbody>, <thead> and <tfoot> element may (although in XHTML you can have <tr> elements too).
For those elements to exist inside a table, they must appear entirely within a table cell.
Given broken HTML, Firefox will do a good job of compensating for author errors, but when the broken DOM is generated with JS, you bypass some of the autocorrection routines.
As an aside, your Doctype (HTML + Transitional + No system identifier) triggers Quirks mode - which doesn't generally help matters.
I suggest:
Switch to a Doctype that triggers Standards mode
Validate your markup
Build the content you are adding with JavaScript using plain HTML instead
Make that validate
Write JavaScript to generate the DOM you have now tested as being valid
Why don't you add a button using JavaScript when the response is shown to the screen?
This way should work on all browsers...
function addButton() {
//Create an input type dynamically.
var element = document.createElement('input');
//Assign different attributes to the element.
element.setAttribute('type', 'button');
element.setAttribute('value', 'Continue');
element.setAttribute('name', 'somename');
element.setAttribute('id', 'someid');
var foo = document.getElementById("fooBar");
//Append the element in page
foo.appendChild(element);
}
I have been reading up on this, and it seems that if you use ajax you can only bring in content that resides on the same domain whereas with an iframe you can bring in content from any domain. Is that the case? What other differences are there?
Bear in mind they're two completely separate technologies.
A (i)frame really loads a complete HTML page in area into the browser. Whether the page is on the same or another domain, for pure viewing, doesn't matter.
Ajax only describes a system to facilitate JavaScript to talk with (and with current security restriction across browser, only with) the server from which you document within which you generated the JavaScript call from.
The (i)frame technology loads and renders a complete HTML page from any URL given. Certain security restrictions accessing other documents from other domains with JavaScript still apply.
With Ajax, it's only meant to use purely JavaScript to talk to the originating server (send some data) and usually get some data back. In JavaScript. What this data is and what you do with it, is up to you. Whether you insert it into the DOM (Document Object Model), exchange parts or load a new page is up to you.
To a certain degree you have all freedom you want. You can have an (i)frame on a page, still make a Ajax call and decide to load another URL into the (i)frame. Or use the Ajax return value to generate new HTML dynamically inside the (i)frame. Or outside, in another document.
The security restrictions applying in this case is called "same origin policy".
Quite simply, an iframe is like a regular frame, but it doesn't split the browser window up into sections, it sits right inside a page and is affected by the scrollbar.
Ajax, on the other hand, uses javascript to do partial loads of a page, allowing small amounts of data to be loaded from the server without needing to do a complete postback. For example, Youtube uses Ajax when you post comments, vote, queue videos to play, etc. They do this so that your video isn't interrupted and restarted by a complete page postback.
Besides these differences mentioned by others, there are others as well.
iframe loads an entire html/php page, whether it is from the own server or other external server. Usually, it has a fresh <html>, <head> and <body> tag as well. Ajax only loads part of the html/php page.
Besides, Ajax pulls the CSS (and maybe, even javascript codes) from the parent file, but in case of Iframe, it cannot pull the same.
E.g this is the master file coding.
<!doctype html>
<html>
<head>
<style>
.gappu {background-color:black;color:red;}
</style>
<meta charset="utf-8">
<script src="../AllJqueries/jquery-1.11.3.min.js"></script> <!-- Use your own jQuery file -->
<script>
<!--
$(document).ready(function(){
$.ajax({url:"slave1.php?bare=true", success:function(data){
$(".myDomain").html(data);
}});
}); /* End of Main Jquery */
//-->
</script>
<title>Ajax vs Iframe</title>
</head>
<body>
<div class="myDomain"></div>
<div>Iframe below</div>
<iframe width="100%" height="500px" src="slave1.php"></iframe>
</body>
</html>
Now, we also have another file, named as slave1.php
<?php
if(isset($_GET['bare'])) $bare = $_GET['bare'];
else $bare = false;
if(!$bare):
?>
<!doctype html>
<html>
<head>
<meta charset="utf-8">
<style>
.gappu {background-color:blue;color:yellow;}
</style>
<!-- You can remove the above style later, and see the difference. The parent style will not apply for iframe -->
<title>Inside the Iframe</title>
</head>
<body>
<?php endif; ?>
<div class="gappu">Hi, welcome to this demo</div>
<?php if(!$bare): ?>
</body>
</html>
<?php endif;
In case of Ajax call, the line Hi, welcome to this demo will be in black background and red color, since it is borrowing the css from the parent. But in iframe, it will be in blue background and white color, which is defined in slave1.php. You can remove the style from slave1.php, and you will find plain text printed in iframe format.
Hope this helps. Cheers.
Vijay Srinivas