<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>MOleYArd (MOYA) blog &#187; XHTML</title>
	<atom:link href="http://www.moyablog.com/tag/xhtml/feed/" rel="self" type="application/rss+xml" />
	<link>https://www.moyablog.com</link>
	<description>A Software Developer&#039;s Blog</description>
	<lastBuildDate>Sat, 07 Apr 2012 13:38:59 +0000</lastBuildDate>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.2.1</generator>
		<item>
		<title>How to validate custom attributes of HTML elements in W3C validator?</title>
		<link>https://www.moyablog.com/2011/11/17/how-to-validate-custom-attributes-of-html-elements-in-w3c-validator/</link>
		<comments>https://www.moyablog.com/2011/11/17/how-to-validate-custom-attributes-of-html-elements-in-w3c-validator/#comments</comments>
		<pubDate>Thu, 17 Nov 2011 21:41:41 +0000</pubDate>
		<dc:creator>MOYA</dc:creator>
				<category><![CDATA[Utilities]]></category>
		<category><![CDATA[Web development]]></category>
		<category><![CDATA[AddThis]]></category>
		<category><![CDATA[attributes]]></category>
		<category><![CDATA[CSS]]></category>
		<category><![CDATA[CSS3]]></category>
		<category><![CDATA[doctype]]></category>
		<category><![CDATA[DTD]]></category>
		<category><![CDATA[HTML]]></category>
		<category><![CDATA[strict]]></category>
		<category><![CDATA[target]]></category>
		<category><![CDATA[transitional]]></category>
		<category><![CDATA[validation]]></category>
		<category><![CDATA[Validator]]></category>
		<category><![CDATA[W3C]]></category>
		<category><![CDATA[XHTML]]></category>
		<category><![CDATA[XML namespaces]]></category>

		<guid isPermaLink="false">http://www.moyablog.com/?p=463</guid>
		<description><![CDATA[<p style="text-align: justify;">Sometimes you need to use (X)HTML element attributes that are not part of any W3C standard doctypes. Or you may want to use strict version of doctype with some attributes that are only in transitional version of doctype. Well, it certainly has its reasons (I will mention it) why they were removed and [...]]]></description>
			<content:encoded><![CDATA[<p style="text-align: justify;">Sometimes you need to use <strong>(X)HTML</strong> element attributes that are not part of any W3C standard doctypes. Or you may want to use <strong>strict version of doctype </strong>with some attributes that are only in <strong>transitional version of doctype</strong>. Well, it certainly has its reasons (I will mention it) why they were removed and if you would like to use strict doctype then you shouldn&#8217;t use them. </p>
<p style="text-align: justify;">Most of the time, you can follow this rule. In fact, you should use strict doctype instead of transitional doctype where possible. In strict versions of doctypes <strong>presentation attributes</strong> are removed and are expected to be replaced with <strong>CSS properties</strong>. I prefer strict doctypes. Apart from other things modern browsers use their most standards compliant rendering mode and therefore it is easier to make appearance of the site look exactly the same in various browsers. (commonly spaces between elements may be problematic)</p>
<p><span id="more-463"></span></p>
<p style="text-align: justify;">But let me tell you a counterexample. It is the <em>target</em> attribute of the anchor (a) element. I agree that it&#8217;s a presentation matter. And <strong>CSS3</strong> actually implements support for it (look at <a href="http://www.w3.org/TR/css3-hyperlinks/" title="CSS3 hyperlinks draft" target="_blank">CSS3 hyperlinks draft</a>). But support for this CSS3 property is still not sufficient enough. But what if we want to use <strong>strict doctype</strong>, while still using <strong>target</strong> attribute, not using <strong>any CSS3</strong> (which not may be supported by visitors&#8217; browsers) <strong>nor JavaScript</strong> (which may be disabled), but still want to pass <strong>W3C validation test</strong>?</p>
<p style="text-align: justify;">Another example when we might need to use custom attributes is when we use <a href="http://www.addthis.com" title="AddThis" target="_blank">AddThis</a> service for sharing content on social networks. When you use this service you may want to specify custom sharing settings. To accomplish this, you need to add attributes like <em>addthis:url</em> or <em>addthis:title</em>.</p>
<p style="text-align: justify;">They actually propose some solutions on their Help site to make it valid. One solution is adding a custom namespace:</p>
<pre name="code" class="html">
&lt;html
    xmlns="http://www.w3.org/1999/xhtml"
    xmlns:addthis="http://www.addthis.com/help/api-spec"&gt;
</pre>
<p style="text-align: justify;">As they mention, external custom namespaces are ignored by <strong>W3C validator</strong>. What you can do is to use inline extensions to your doctype definition (<strong>DTD</strong>). Here I will give an example that solves previously mentioned problems.</p>
<pre name="code" class="html">
&lt;!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"
[
  &lt;!ATTLIST div addthis:url CDATA #IMPLIED&gt;
  &lt;!ATTLIST div addthis:title CDATA #IMPLIED&gt;
  &lt;!ATTLIST a target CDATA #IMPLIED&gt;
]&gt;
</pre>
<p style="text-align: justify;">
This is the solution, you will validate your page using these inline extensions. But it is just a partial solution because (as is also mentioned on AddThis Help site) most browsers render the trailing ]&gt; in the page itself. I have tested it in several browsers (current versions) and out of them only Opera (update: this applied for Opera 11.5x, but not anymore for Opera 11.60) browser treated this correctly without rendering. AddThis Help does not offer any solution here… But luckily this is not so big problem and there is a solution. We just need some CSS to fix it:</p>
<pre name="code" class="css">
html{color: transparent;}
div#wrapper{color: black;}
</pre>
<p style="text-align: justify;">The whole trick is setting global font color transparent which will hide trailing ]&gt; and then insert wrapper div in body tag (or possibly somewhere else) with font color we need. There is one more thing to mention for XHTML documents. Colon inside attributes has a special meaning, it denotes namespace prefix. In case of <em>addthis:url</em> and <em>addthis:url</em> it is namespace prefix <em>addthis</em>. Although external custom namespaces (their content) are ignored by <strong>W3C Validator</strong>, namespace prefixes still need to be included to pass validation (otherwise validator will state that a prefix for an attribute on an element is not defined), like this (look at line 3): </p>
<pre name="code" class="html">
&lt;html
    xmlns="http://www.w3.org/1999/xhtml"
    xmlns:addthis="http://www.addthis.com/help/api-spec"&gt;
</pre>
<p style="text-align: justify;">Actually, because external content is ignored this</p>
<pre name="code" class="html">
&lt;html
    xmlns="http://www.w3.org/1999/xhtml"
    xmlns:addthis=""&gt;
</pre>
<p style="text-align: justify;">is actually enough. In case of HTML document colon (:) has actually no special meaning because the HTML syntax does not support namespace declarations. So you can simply stay with <em>&lt;html&gt;</em>.</p>
<p style="text-align: justify;"> So that&#8217;s it &#8211; the way to validate custom attributes of HTML elements in W3C validator.</p>
]]></content:encoded>
			<wfw:commentRss>https://www.moyablog.com/2011/11/17/how-to-validate-custom-attributes-of-html-elements-in-w3c-validator/feed/</wfw:commentRss>
		<slash:comments>9055</slash:comments>
		</item>
		<item>
		<title>Inner/Outer XHTML &#8211; or how to get truly original source of element in JavaScript?</title>
		<link>https://www.moyablog.com/2011/10/06/innerouter-xhtml-or-how-to-get-truly-original-source-of-element-in-javascript/</link>
		<comments>https://www.moyablog.com/2011/10/06/innerouter-xhtml-or-how-to-get-truly-original-source-of-element-in-javascript/#comments</comments>
		<pubDate>Thu, 06 Oct 2011 09:44:41 +0000</pubDate>
		<dc:creator>MOYA</dc:creator>
				<category><![CDATA[Web development]]></category>
		<category><![CDATA[ajax]]></category>
		<category><![CDATA[element source]]></category>
		<category><![CDATA[HTML]]></category>
		<category><![CDATA[innerHTML]]></category>
		<category><![CDATA[innerXHTML]]></category>
		<category><![CDATA[javascript]]></category>
		<category><![CDATA[original source]]></category>
		<category><![CDATA[outerHTML]]></category>
		<category><![CDATA[outerXHTML]]></category>
		<category><![CDATA[page source]]></category>
		<category><![CDATA[XHTML]]></category>
		<category><![CDATA[XMLHttpRequest]]></category>

		<guid isPermaLink="false">http://www.moyablog.com/?p=19</guid>
		<description><![CDATA[<p style="text-align: justify">There are some ways to get the original source of any HTML element in JavaScript. And they work fine in most situations. However, there are situations where these ways are not really sufficient and I especially mean not cross-browser enough.</p> <p style="text-align: justify">innerHTML property is probably the most frequently used method, but it [...]]]></description>
			<content:encoded><![CDATA[<p style="text-align: justify">There are some ways to get the original source of any HTML element in JavaScript. And they work fine in most situations. However, there are situations where these ways are not really sufficient and I especially mean not cross-browser enough.</p>
<p style="text-align: justify"><strong>innerHTML</strong> property is probably the most frequently used method, but it has some well-known drawbacks. First of all, <strong>innerHTML </strong>property does not contain (X)HTML written by original author of (X)HTML page. Instead, it contains some sort of browser specific Document Object Model string representation. Especially in IE this representation is quite ugly (missing quotes, capital letters of tags, …). And thus we encounter another problem &#8211; content of <strong>innerHTML</strong> property differs in different browsers!</p>
<p style="text-align: justify">But why is this important that it differs? Should we care? Maybe, we should. There might be situations when we may need the same value of innerHTML property for all browsers. There are always some tricks to get around this need and make it in other way, or simply make different solutions for different browsers. But wouldn&#8217;t it be nice to have function that not only returns same content in all modern major browsers, but moreover returns exactly the content that was created by author of webpage? Getting truly original source code is in fact another thing that might be sometimes useful.</p>
<p><span id="more-19"></span></p>
<p style="text-align: justify">So let&#8217;s show how to do this. I have written such a function for you.</p>
<p style="text-align: justify">The means to accomplish the most important initial building block of this task is <strong>XMLHttpRequest</strong>. We need to get the original source code of the whole page. Here is the function:</p>
<pre name="code" class="javascript">
function originalPageSource()
{
	var httpRequest = new XMLHttpRequest();
	if (window.ActiveXObject)
		httpRequest = new ActiveXObject ("Microsoft.XMLHTTP");
	else if (window.XMLHttpRequest)
		httpRequest = new XMLHttpRequest();

	httpRequest.open('GET',document.location.href,false);
	httpRequest.send(null);
	if (httpRequest.status === 200)
	{
		return httpRequest.responseText;
	}
	else return false;
}
</pre>
<p style="text-align: justify">This first function will be contained within the main function called <strong>originalInnerXHTML</strong>. It takes two parameters. The first parameter <em>element</em> is the required (X)HTML element, of which HTML content we want to see. The first parameter <em>includeElement</em> is a boolean parameter and determines whether to include element itself in (X)HTML string. This is known as an <strong>outerHTML</strong> function or property, so I as well made <strong>originalOuterXHTML</strong> to not to be required to call function with two parameters for this task. So finally, here is the code or <strong>originalInnerXHTML</strong>:</p>
<pre name="code" class="javascript">
function originalInnerXHTML (element, includeElement)
{
var elementXHTML = originalPageSource();
var elementIndex = 0;
var elementNodeName = element.nodeName;
var elements=document.getElementsByTagName(elementNodeName);

for (var i = 0; i &lt; elements.length; i++)
{
	if (element === elements[i])
	{
		 elementIndex=i;
		 break;
	}
}
openingElementRegExp = new RegExp("&lt;"+elementNodeName, "i");
closingElementRegExp = new RegExp("&lt;/"+elementNodeName, "i");
for(var i=0; i &lt;= elementIndex; i++)
{
	elementXHTML=elementXHTML.substring
	(
		elementXHTML.search(openingElementRegExp)+1
	);
}

elementXHTML="&lt;"+elementXHTML;
if
(
	element.hasChildNodes() == false &#038;&#038;
	(elementXHTML.indexOf("/") &lt; elementXHTML.indexOf("&gt;") ||
	elementXHTML.search(closingElementRegExp)==-1)
)
{
	if (includeElement)
	{
		elementXHTML=elementXHTML.substring(0, elementXHTML.indexOf("&gt;")+1);
		return elementXHTML;
	}
	else return "";
}
elementXHTMLCopy=elementXHTML;

while
(
	elementXHTMLCopy.search(new RegExp(openingElementRegExp))
	&lt; elementXHTMLCopy.search(new RegExp(closingElementRegExp))
)
{
	if (elementXHTMLCopy.search(openingElementRegExp)!=-1)
	{
		elementXHTMLCopy=elementXHTMLCopy.substring
		(
			elementXHTMLCopy.search(openingElementRegExp)
		);
		elementXHTMLCopy="&lt;"+elementXHTMLCopy;
		elementXHTMLCopy=elementXHTMLCopy.substring
		(
			elementXHTMLCopy.search(closingElementRegExp)
			+ elementNodeName.length+3
		);
		elementXHTMLCopy="&lt;"+elementNodeName+"&gt;"+elementXHTMLCopy;
	}
}

var endOffset = elementXHTMLCopy.length - elementXHTMLCopy.search(closingElementRegExp);
elementXHTML = elementXHTML.substring(0,elementXHTML.length - endOffset);
elementXHTML = elementXHTML+"&lt;/"+elementNodeName.toLowerCase()+">"

if (includeElement) return elementXHTML;
else
{
	elementXHTML=elementXHTML.substring
	(
		elementXHTML.indexOf("&gt;")+1,elementXHTML.lastIndexOf("&lt;")-1
	);
	return elementXHTML;
}

function originalPageSource ()
{
	var httpRequest = new XMLHttpRequest();
	if (window.ActiveXObject)
		httpRequest = new ActiveXObject("Microsoft.XMLHTTP");
	else if (window.XMLHttpRequest)
		httpRequest = new XMLHttpRequest();
	httpRequest.open('GET',document.location.href,false);
	httpRequest.send(null);
	if (httpRequest.status === 200)
	{
		return httpRequest.responseText;
	}
	else return false;
}
}
</pre>
<p style="text-align: justify;">And finally source of originalOuterXHTML:</p>
<pre name="code" class="javascript">
function originalOuterXHTML(element)
{
	return originalInnerXHTML(element, true);
}
</pre>
<p style="text-align: justify;"><strong>Limitations</strong></p>
<p>The main limitation lies in the fact that this function returns only the original source code, so it cannot show potential javascript source code modifications. After the original source code is changed by script, we often simply have to rely only on internal browser object model representation… But after all, it is programmer&#8217;s responsibility in exactly which way his or her code is changed, so this can be mostly resolved. I believe that getting exact original source code might be useful in quite many situations.</p>
<p>You can download JS file with these functions <a href="http://www.moyablog.com/innerouter-xhtml/">here</a>.</p>
]]></content:encoded>
			<wfw:commentRss>https://www.moyablog.com/2011/10/06/innerouter-xhtml-or-how-to-get-truly-original-source-of-element-in-javascript/feed/</wfw:commentRss>
		<slash:comments>9061</slash:comments>
		</item>
	</channel>
</rss>
