Smarty strip tags not working - smarty

Is there a particular reason why {strip} tags in smarty don't work? I have two templates. In one of them, it works. In the other it doesn't. But I put them in the exact same place
{strip}
<!DOCTYPE html PUBLIC"-// W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html>
......
</html>
{/strip}
I would just like to know what are the possible causes to this.

If you have improperly nested or improperly closed Smarty tags elsewhere on the page, it could be breaking the strip pair, since they're the outermost pair.
Leaving something like {literal} unclosed or having a syntax error that's causing the page to stop rendering before the end of the page (view source; do you have the whole source, up to and including the final </html> tag?) would cause the final {/strip} to not get included/evaluated.

Related

W3C validator issue in magento product view page

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^^

CSS - line-height:0 ignored in XHTML strict in Firefox

I'm using :first-line { line-height:0px; } to hide the empty first line in a block statement
curiously if I define doctype in XHTML strict Firefox ignores this statement and prints the empty line (seeable through the border)
I validated my quellcode and used Firefox' webdeveloper to check, if there is anything wrong, but they told no error
the (stripped) example quellcode is:
<?xml version="1.0" ?>
<!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"><head><title>T</title>
<style type="text/css"><!--
.v { white-space:pre; display:inline-block; border:1px solid black; }
.v:first-line { line-height:0px; }
--></style>
</head><body>
<p class="v">
Foo
Bar
</p>
</body></html>
Is there anything wrong with my code and other browsers (I've tested Opera,Gnome,Safari) just ignore the strict, or is Firefox buggy abiding strict?
I'm not sure if it's really a bug …
I guess the internals of the :first-line selector fail to recognize an empty line with just a newline character in it, but I'm not sure if this is wanted or not. There is nothing inside the W3C Recommendations to prove this behaviour as wrong or right:
CSS 2.1 Specifications:
5.12.1 The :first-line pseudo-element
The :first-line pseudo-element applies special styles to the contents
of the first formatted line of a paragraph.
--
16.6 White space: the 'white-space' property
'white-space'
...
pre This value prevents user agents from collapsing sequences of white space. Lines are only broken at preserved newline characters.
If you're generating your HTML code dynamically just try to eliminate the empty line before outputting it. That's the only advice I can give at the moment.
Try using two colons instead of one. From Mozilla:
The :first-line CSS pseudo-element applies styles to the first line of
a element. However, the selector :first-line does not match any real
HTML element.

Microdata itemprop causes W3C validator error

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.

Is it OK to style the <html> tag?

Sometimes you want two body backgrounds. One for the header and one for the footer.
I accidentally discovered that it is possible to style the actual <html> tag.
HTML:
<html xmlns="http://www.w3.org/1999/xhtml">
CSS:
html {background:#000}
Is it OK to style this, or will it cause any problem?
Although it's debatable as to whether it's valid [see here]:
For HTML documents, however, we recommend that authors specify the
background for the BODY element rather than the HTML element. ...
Many large sites still use it with seemingly consistent results.
Yes, it's OK to style the html tag.
It is very common practice. Used all the time on many websites including this one.

contentEditable on nodes in a XML/compound document?

I have an XML document that I'm displaying in a web browser, with a stylesheet attached:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<?xml-stylesheet type="text/css" href="abc.css"?>
<myxml xmlns:xhtml="http://www.w3.org/1999/xhtml">
<para>I wish i was editable</para>
<xhtml:script type="text/javascript" src="abc.js"/>
</myxml>
With the xhtml namespace declaration, and xhtml:script tag, I can execute javascript.
What I'd like to do is to make arbitrary non-XHTML elements in this document content editable. (Actually, they'll be in another namespace)
Even if I explicitly add #contentEditable="true" (ie without resorting to Javascript), the content is not actually editable (in Firefox 3.0.4).
Is it possible to edit it in any of the current browsers? (I had no problems with <div contentEditable="true">Edit me</div> in an XHTML 1.0 Transitional doc)
I can't even edit an xhtml:div in this document (in Firefox); if I could do that, that may offer a way forward.
In Firefox 3, #content-editable="true" only makes the relevant element editable if the
content type is text/html (which also happens if a local filename ends with .html)
It doesn't work for content types app/xhtml+xml or text/xml (local filenames ending with .xhtml or .xml)
I've logged an enhancement for this: https://bugzilla.mozilla.org/show_bug.cgi?id=486931
contentEditable works (tested in Firefox and Chrome) on elements which are foreign to html/xhtml if I use this doctype:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
and a .html file extension (instead of .xml).
I don't have to include any html elements at all (eg head, body, div, p).
css isn't applied though (if my xml is in a namespace, which i guess makes sense, given the doctype!).
Not an elegant solution.
Firefox is one of the few browsers that strictly enforces the XHTML spec. So, to make an element editable, you must specify the contenteditable attribute as true. Note that the whole attribute name is lower case. In your example the first "E" in editable was capitalized.
Another quirk that should be mentioned is that IE(6,7,8) act exactly the opposite. To make an element editable in IE, you MUST add contentEditable="true" exactly. For what ever reason, contenteditable="true" (as well as any other variation in capitalization) does not work.

Resources