I installed the package and it worked perfectly. Except when I checked the w3 validation, this now failed. I removed the httpmodule& handlers and checked the validation again. Now it validates.
These are the warnings:
Unable to Determine Parse Mode!
The
validator can process documents either as XML (for document types such
as XHTML, SVG, etc.) or SGML (for HTML 4.01 and prior versions). For
this document, the information available was not sufficient to
determine the parsing mode unambiguously, because:
the MIME Media Type (text/html) can be used for XML or SGML document types
No known Document Type could be detected
No XML declaration (e.g <?xml version="1.0"?>) could be found at the beginning of the document.
No XML namespace (e.g <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">) could be found at the root of the document.
As a default, the validator is falling back to SGML mode.
No Character encoding declared at document level
No character encoding information was found within the document, either in an HTML meta
element or an XML declaration. It is often recommended to declare the
character encoding in the document itself, especially if there is a
chance that the document will be read from or saved to disk, CD, etc.
This error may appear when the validator receives an empty document.
Please make sure that the document you are uploading is not empty, and report any discrepancy.
Note: when i copied the source code and uses direct input validation method, the error was gone.
i really like the compress package, but do not like the not able to validate problems... anybody got this too?
if the page validates without compression, then it's fine. The compression also compresses the page itself, resulting in a document that the validator can't read properly, but browsers have no problems with it.
@Peter: Is it something that is possible to fix somehow?
Most of the time people will off course develop their templates statically before implementing them into Umbraco. During that time they probably also validate the HTML/CSS before copying the templates into Umbraco.
But I think there can also be circumstances where people only have access to Umbraco and need to make changes to the HTML structure. If something looks wrong in the browser, due to some improper HTML people want have the possibility to validate their document because the validator can't figure out the doctype used.
In that case it can be a bit frustrating so it would be very nice if there was a fix or workaround.
Apart from that you i'm really a big fan of your great package :-)
To be honest, I think the validator is a bit flaky when it comes to this.
For example, it doesn't vaildate either when there's a blank line as first line in the HTML. The compression works a bit the same, it removes the linebreak. This results in the doctype being on the first line, but it is directly followed by the rest of the HTML. As said, the validator does not accept this allthough it is perfectly valid HTML.
A quick workaround is to temporary disable the compression (edit the config-file and disable the front-end).
I'll have a look if I can get it to work with the validator somehow though.
In addition to this: I'm not sure if I should put a lot of effort in this package anymore since the next version of umbraco will have compression built-in.
@Peter: Well if it's going to be implemented into Umbraco directly then I think you should not bother - it's not your fault that the validator is flaky :)
"For example, it doesn't vaildate either when there's a blank line as
first line in the HTML. The compression works a bit the same, it
removes the linebreak. This results in the doctype being on the first
line, but it is directly followed by the rest of the HTML. As said, the
validator does not accept this allthough it is perfectly valid HTML."
When I looked at the source with the compression enabled, I noticed that there was a blank line as the first line. Maybe this broke the validation?
The rest of the document looked as it should in source view. So maybe it is enough to just make sure the first line isn't empty?
I believe some browsers decompress the page when you view the source. I've seen this behaviour in Firefox at least.
You could try indeed to remove the first empty line. Best change is to change the master-template for that (place the first couple of lines all on t he first line).
Markup Validation Fails When Using Compress package
Hi,
I installed the package and it worked perfectly. Except when I checked the w3 validation, this now failed. I removed the httpmodule& handlers and checked the validation again. Now it validates.
These are the warnings:
The validator can process documents either as XML (for document types such as XHTML, SVG, etc.) or SGML (for HTML 4.01 and prior versions). For this document, the information available was not sufficient to determine the parsing mode unambiguously, because:
text/html) can be used for XML or SGML document types<?xml version="1.0"?>) could be found at the beginning of the document.<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">) could be found at the root of the document.As a default, the validator is falling back to SGML mode.
No character encoding information was found within the document, either in an HTML
metaelement or an XML declaration. It is often recommended to declare the character encoding in the document itself, especially if there is a chance that the document will be read from or saved to disk, CD, etc.And this is the error:
Line 1, Column 1: end of document in prolog
✉
This error may appear when the validator receives an empty document. Please make sure that the document you are uploading is not empty, and report any discrepancy.
Note: when i copied the source code and uses direct input validation method, the error was gone.
i really like the compress package, but do not like the not able to validate problems... anybody got this too?
Hi,
if the page validates without compression, then it's fine. The compression also compresses the page itself, resulting in a document that the validator can't read properly, but browsers have no problems with it.
HTH,
Peter
@Peter: Is it something that is possible to fix somehow?
Most of the time people will off course develop their templates statically before implementing them into Umbraco. During that time they probably also validate the HTML/CSS before copying the templates into Umbraco.
But I think there can also be circumstances where people only have access to Umbraco and need to make changes to the HTML structure. If something looks wrong in the browser, due to some improper HTML people want have the possibility to validate their document because the validator can't figure out the doctype used.
In that case it can be a bit frustrating so it would be very nice if there was a fix or workaround.
Apart from that you i'm really a big fan of your great package :-)
/Jan
To be honest, I think the validator is a bit flaky when it comes to this.
For example, it doesn't vaildate either when there's a blank line as first line in the HTML. The compression works a bit the same, it removes the linebreak. This results in the doctype being on the first line, but it is directly followed by the rest of the HTML. As said, the validator does not accept this allthough it is perfectly valid HTML.
A quick workaround is to temporary disable the compression (edit the config-file and disable the front-end).
I'll have a look if I can get it to work with the validator somehow though.
Peter
In addition to this: I'm not sure if I should put a lot of effort in this package anymore since the next version of umbraco will have compression built-in.
@Peter: Well if it's going to be implemented into Umbraco directly then I think you should not bother - it's not your fault that the validator is flaky :)
/Jan
"For example, it doesn't vaildate either when there's a blank line as first line in the HTML. The compression works a bit the same, it removes the linebreak. This results in the doctype being on the first line, but it is directly followed by the rest of the HTML. As said, the validator does not accept this allthough it is perfectly valid HTML."
When I looked at the source with the compression enabled, I noticed that there was a blank line as the first line. Maybe this broke the validation?
The rest of the document looked as it should in source view. So maybe it is enough to just make sure the first line isn't empty?
I believe some browsers decompress the page when you view the source. I've seen this behaviour in Firefox at least.
You could try indeed to remove the first empty line. Best change is to change the master-template for that (place the first couple of lines all on t he first line).
HTH,
Peter
is working on a reply...