Is there a way to use data-fancybox-type="iframe" with strict xhmtl at all so that it validates? I have everything working except for that error that I get.
Is there a way to write it so that it works with my current doctype?
Since the data-* attribute validates only with HTML5, you may prefer to use the fancybox special class to set the content type, so instead of this :
<a class="fancybox" data-fancybox-type="iframe" href="page.html">open</a>
... try :
<a class="fancybox fancybox.iframe" href="page.html">open</a>
... then your document will validate with your current DOCTYPE and it will have exactly the same effect.
Related
I'm using the SyntaxHighlighter plugin for CKEditor to insert code into my pages. The plugin uses <pre> tags to contain the code whilst making use of "brush" classes to define the programming language. My problem is that upon submission of the page HTML Purifier is stripping the class attribute from the pre tags, which effectively prevents the syntax highlighting from occurring.
The source code goes from:
<pre class="brush:php;">
<?php echo '<p>Hello World</p>'; ?>
</pre>
to:
<pre>
<?php echo '<p>Hello World</p>'; ?>
</pre>
I'm hoping there is some magical setting to stop HTML Purifier from doing this.
The reason is brush:php is not a valid class name per the HTML4 specification. I guess you could write your own class name validator and override the builtin using http://htmlpurifier.org/docs/enduser-customize.html
But a better solution might be to run the syntax highlighting before you run HTML Purifier!
I have error in product view page on w3c validator
my product is downloadable product. i have a custom option for that product
when i validate the test-product page in w3c validator it shows a error like this
there is no attribute "price"
…" id="options_21_2" value="27" price="0" />
Error line:
<ul id="options-21-list" class="options-list"><li><input type="checkbox" class="checkbox product-custom-option" onclick="opConfig.reloadPrice()" name="options[21][]" id="options_21_2" value="27" price="0" /><span class="label"><label for="options_21_2">Test Product</label></span></li></ul>
help to fix this issue.
Background
The problem here is, that price is a custom attribute. Even though it's usable by almost all browsers per JavaScript the way you posted it, it's not a valid (X)HTML attribute, like id or name are, for example.
The W3C validator validates your source code against the DTD (Document Type Definition) found in the <!DOCTYPE .. > declaration of your document.
Magento CE/EE 1.x versions use a XHTML 1.0 Strict DTD by default.
A DTD declares which rules a document must follow to be valid for the given document type. It defines which element types are allowed, which attributes a specific element can have, which entities can be used, etc.
If you check the linked DTD above, you'll see that there's no price attribute defined anywhere in the file.
That's why the W3C validator rightfully complains .. there is no attribute "price".
What can you do?
Mainly the following three things come to my mind on about how to handle such situation:
Ignore after double checking
You could simply ignore this (and only this) specific kind of W3C validation errors.
I guess that's what most devs do with ".. there is no attribute attr_name" validation errors when they already double checked, that it's a custom attribute really in use and only failing W3C validation (using a pre-HTML5 DTD), but working completely fine otherwise.
Extend the DTD
You could extend the XHTML 1.0 Strict DTD, adding custom attributes to specific elements.
Example on how to add a custom price attribute for input elements, using an internal subset:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"
[
<!ATTLIST input price CDATA #IMPLIED>
]
>
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-type" content="text/html;charset=UTF-8" />
<title>Test</title>
</head>
<body>
<p>
<input type="checkbox" class="checkbox product-custom-option" onclick="opConfig.reloadPrice()"
name="options[21][]" id="options_21_2" value="27" price="0" />
</p>
</body>
</html>
Containing this internal subset, the W3C validator will validate without errors.
But, most major browsers will render an ugly ]> as a result, when internal subsets come into play.
Maybe, because they don't support nested tags (at all, or correctly), or maybe they switch to their hardwired DTDs as soon as they found an official one in the <!DOCTYPE .. >, I can't tell exactly.
To avoid the ]>, you could build a custom DTD, using the original DTD as a base, extend it with custom attributes and change the !<DOCTYPE .. > to use that custom DTD.
The crux with custom DTDs is, even though it's technically correct and the browsers won't render that ugly ]> anymore, you also can't use the W3C validator anymore. It doesn't support custom DTDs.
So, if W3C compliance is a must, your only choice is to stay with internal subsets. But then you still need to get rid of the ugly ]> somehow. And to achieve this, you could use some CSS, e.g. similiar to this:
html {
color: transparent;
}
Be aware though, that extending DTDs can result in lots of work. You'll need to extend all element types where your custom attribute could appear. And you'd need to do this for each custom attribute, of course.
Use HTML5 data-* attributes
You could rewrite your Magento templates to use HTML5 and its data-* attributes, a way where you only have to prefix custom attribute names with data- to make them perfectly valid.
But since fully transferring Magento 1.x from XHTML 1.0 Strict to HTML5 would result in tons of complex work, I don't really consider this an option.
Afaik, even Magento 2.x will not switch to HTML5, but continue to use XHTML 1.0 Strict.
Maybe for the very same reason^^
After adding Microdata to my pages, I got many errors from W3C validator complaining the itemprop:
there is no attribute "itemprop"
From code like this:
<p itemprop="description">...</p>
This is my DOCTYPE and html tag
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"
xmlns:fb="http://www.facebook.com/2008/fbml">
How to fix the validator errors?
p.s. Previously I have the validator error for itemscope as well. But after I changed it to itemscope="itemscope" then the error is fixed.
Documents with HTML 5 plus Microdata used to validate successfully but because of Bug #14020 the validator has become more strict on declaring documents as "valid". Your document is valid HTML 5 + Microdata, but is not strictly an HTML 5-only document.
You can use http://Validator.nu/ to validate HTML 5 + Microdata.
The site linked to in Fabian's answer is not the W3C site he mentions, so I wouldn't trust that as much for HTML 5 as I might have for earlier (pre-2000) versions of HTML.
The reason you had to change itemscope to itemscope="itemscope" is that previous browsers and specifications have defined incompatible interpretations (sometimes true, sometimes false) of code such as itemscope (no value), itemscope="" (an empty string is interpreted as false by XPath) and itemscope="false" (any non-empty string sometimes interpreted as true). Thus the statement in the spec that "The values 'true' and 'false' are not allowed on boolean attributes." However, "true" and "false" can appear in certain attribute values because they are allowed on enumerated attributes such as draggable. See bullet #4 regarding coding boolean values.
The workarounds (elsewhere) to insert invalid code with scripting may hide that code from the validator, but it won't create a document that is any more valid than using static HTML code because the HTML 5 specification is defined in terms of the internal document model, not the external representation. See HTML 5 Specifications focus on the DOM.
OK, here is what I did to make this work with the Validator:
Referring to this page: http://www.w3.org/TR/2011/WD-microdata-20110525/
I enclosed the main in my page (the "wrapper" if you will) with the following:
<div id="layout" itemscope>
If you have itemscope in the div tag for your page or for the div containing microdata, then the W3C Validtor will like it just fine.
The DOCTYPE needs to be HTML5 for microdata to validate.
<!DOCTYPE html>
<html xmlns:fb="http://www.facebook.com/2008/fbml">
.....
It will work with paragraph tag:
http://www.w3.org/TR/2011/WD-microdata-20110525/
if you just want to remove this tag you can do so by removing tag from file which is located in main root folder
"wp-includes/general-template.php" at 891 line
you can just remove extra tag.
I have a structure which is as follows:
<a href="#">
<footer>
<p>Some text</p>
<h2>A Heading</h2>
</footer>
</a>
This works and displays as expected in all browsers (even IE6 with the HTML5shiv.js) except Firefox 3.6. In Firefox 3.6 the display is completely screwed and if you use Firebug to inspect the DOM, the <footer> element is empty and the elements which should be inside it are outside of it.
All the tags are closed correctly. The <a> is set to display:block in the CSS.
The W3C validator validates the document and does not mark this structure as incorrect.
The spec states that an <a> element may be classed as flow content when it contains other flow content. The <footer> is flow content.
Is it just that Firefox 3.6 doesn't render HTML entirely correctly?
Any ideas for a fix?
Ta!
According the W3C HTML5 Reference the Footer Elements content model is:
Flow content, but with no heading
content descendants, no sectioning
content descendants, and no footer
element descendants.
Which an a element is interactive content.(Which also can be a Flow Content)
So using the a element will validate, if you validate it against HTML5 Standards. Using something like the W3C validator.
So to answer your question, FireFox 3.6 Doesn't conform to HTML5 standards completely. FireFox 4.0 conforms better than 3.6. You can find a list of what elements of HTML5 (and CSS3) are supported by legacy browsers here.
As for the fix I would suggest that you hide the footer from Firefox, and show a div with your content in that is hidden for everything but firefox. I would accomplish this using jQuery CSS Browser Detection using jQuery instead of Hacks is a good place to start.
Firefox 3.6 doesn't implement the HTML5 parsing algorithm; it has an HTML4 "parser", basically.
I think your workaround options are:
Avoid "block level" HTML tags inside the footer.
Put a <span> as a child of <a> wrapping the <footer>.
Put a <div> as a child of <a> wrapping the <footer>.
I recently have found a strange occurrence in IE8 & FF.
The designers where using js to dynamically create some span tags for layout (they were placing rounded corner graphics on some tabs). Now the xhtml, in js, looked like this: <span class=”leftcorner” /><span class=”rightcorner” /> and worked perfectly!
As we all know dynamically rendering elements in js can be quite processor intensive so I moved the elements from js into the page source, exactly as above.
... and it didn’t work... not only didn’t it work, it crashes IE8.The fix was simple, put the close span in ie: <span class=”leftcorner”></span>
I am a bit confused by this.
Firstly as far as I am aware <span class=”leftcorner” /> is perfectly valid XHTML!
Secondly it works dynamically, but not in XHTML?!?!?
Can anyone shed any light on this or is it simply another odd occurrence of browsers?
The major browsers only support a small subset of self-closing tags. (See this answer for a complete list.)
Depending on how you were creating the elements in JS, the JavaScript engine probably created a valid element to place in the DOM.
I had similar problem with a tags in IE.
The problem was my links looked like that (it was an icon set with the css, so I didn't need the text in it:
<a href="link" class="icon edit" />
Unfortunately in IE these links were not displayed at all. They have to be in
format (leaving empty text didn't work as well so I put there). So what I did is I add an few extra JS lines to fix it as I didn't want to change all my HTML just for this browser (ps. I'm using jQuery for my JS).
if ($.browser.msie) {
$('a.icon').html(' ');
}
IE in particular does not support XHTML. That is, it will never apply proper XML parsing rules to a document - it will treat it as HTML even with proper DOCTYPE and all. XHTML is not always valid SGML, however. In some cases (such as <br/>) IE can figure it out because it's prepared to parse tagsoup, and not just valid SGML. However, in other cases, the same "tagsoup" behavior means that it won't treat /> as self-closing tag terminator.
In general, my advice is to just use HTML 4.01 Strict. That way you know exactly what to expect. And there's little point in feeding XHTML to browsers when they're treating it as HTML anyway...
See I think that one of the answers to Is writing self closing tags for elements not traditionally empty bad practice? will answer your question.
XHTML is only XHTML if it is served as application/xhtml+xml — otherwise, at least as far as browsers are concerned, it is HTML and treated as tag soup.
As a result, <span /> means "A span start tag" and not "A complete span element". (Technically it should mean "A span start tag and a greater than sign", but that is another story).
The XHTML spec tells you what you need to do to get your XHTML to parse as HTML.
One of the rules is "For non-empty elements, end tags are required". The list of elements includes a quick reference to which are empty and which are not.