gmane.org.w3c.validator

Re: Bug: ARIA Landmark Role "main" invalid on section element

Michael[tm] Smith — 2013-05-23T01:38:36

Katrin Kerber <katrinkerber< at >gmail.com>, 2013-04-22 11:09 +0100:


Thanks very much for catching this, and sorry I missed this when you
reported it last month.

The cause was a regression I introduced when I made some ARIA-related
updates a few weeks back. But I've fixed it now.

  --Mike

Issue in localhost W3C validator : Can't locate loadable object for module SGML::Parser::OpenSP

Ramasamy, Kiruthika — 2013-05-21T11:45:58

Hi,

I am following the same steps explained in http://validator.w3.org/docs/install_win.html

But when I try to validate some pages getting below error,

Can't locate loadable object for module SGML::Parser::OpenSP in < at >INC (< at >INC contains: C:/www/perl/site/lib C:/www/perl/lib .) at C:/www/validator/httpd/cgi-bin/check line 65.
Compilation failed in require at C:/www/validator/httpd/cgi-bin/check line 65.
BEGIN failed--compilation aborted at C:/www/validator/httpd/cgi-bin/check line 65.

Here is the 65th line in file CHECK.pm  -->  use SGML::Parser::OpenSP 0.991 qw();

I am using the correct SGML parser version 0.991 but still I couldn't figure out what is causing this issue. Please guide me to resolve this issue, also please let me know if I have to provide more details.

Awaiting for your guidance...  Your earliest response would be greatly appreciated!!!

Thanks and regards,
Kiruthika

Re: File Validation

Jukka K. Korpela — 2013-05-19T19:41:08


The validator has a "Validate by File Upload" feature. If this is not 
what you need, please specify. Note that the uploaded file must be an 
HTML file (not e.g. a PHP or ASP file - they need to be validated by URL).

Yucca

File Validation

John Fraser — 2013-05-19T14:19:05

Good morning;

 

            Your site has a place for validating HTML, but it only validates
a page.  I want to validate a file before I post it as a page.  How, and
where, do I do that?

 

Cheers,

John

twitter button and the validator check

Nexxite Internet — 2013-05-17T09:58:12

Is there anyone who can tell me how I can add a twitter button without
upsetting the validator check?
This is part of my page website laten
maken<http://www.nexxite.nl/web/website-laten-maken.html>
..

Re: Adding FB LIKE button to HTML 4.01 down right impossible

Mordechay Kaganer — 2013-05-16T19:17:43

B.H.

Hi!

On Thu, May 16, 2013 at 10:07 PM, Jukka K. Korpela <jkorpela< at >cs.tut.fi>wrote:



If you really want to dance on both weddings, you can put the invalid meta
tag only when the request contains FB's user agent signature... So you can
make get this green icon and also make FB happy :-)

Re: Adding FB LIKE button to HTML 4.01 down right impossible

Jukka K. Korpela — 2013-05-16T19:07:47


You cannot. Facebook decided to use invalid markup. See
http://lists.w3.org/Archives/Public/www-validator/2011Sep/0015.html


No.

Yucca

Adding FB LIKE button to HTML 4.01 down right impossible

Frits Nieuwenburg — 2013-05-13T09:31:29

Is there anyone who can tell me how I can add a FB like button without
upsetting the validator?

Maybe with an enclosing TAG which makes everything ok again?

It is meant for this page: http://www.mrsoso.nl

 

Frits Nieuwenburg

Koog aan de Zaan

The Netherlands

[VE][108] Add Subject Here

Xay dung LaLa — 2013-05-14T04:48:52

Hello

 

I check and get error in Line 7, Column 18: there is no attribute "property"

  <meta property="og:locale" content="vi_VN" />

 

I do not know how to fix it. Please guide me to fix it

Validating http://xaydunglala.com/ 
Error [108]: "there is no attribute X"

Re: Unable to Determine Parse Mode and other related problems

Brian Barnett — 2013-05-11T04:14:00

Determined that the character data before <!DOCTYPE> is a result of
HTTP/1.1's transfer-encoding chunked functionality. There are three spots
where the additional data is injected into the html stream - top, middle and
bottom. I don't think that this is the cause of the validator's problems or
IE10's problems in validating/rendering the page as there are other pages
that have this additional character data that are fine.

For example, the following URL passes validation and renders in IE10:

http://test1.calcxml.com/calculators/home-affordability?skn=504

If you run this URL through the HTTP Viewer here
http://www.rexswain.com/httpview.html, you will also see the additional
character data.

Then run this URL through the validator and the Viewer:

http://test1.calcxml.com/calculators/home-affordability?skn=502 

and if fails validation, fails to render in IE10, and the Viewer shows the
additional character data.

So both URLs have the additional character data, but one works in
validator/IE10 and the other does not. There must be something else going on
but neither the validator nor IE10 give any clues.

Mid war love and adventure in Andros

Mare e Vista — 2013-05-10T17:27:17

Άνδρος: Η “Μικρά Αγγλία” του περασμένου αιώνα

Mare e Vista — 2013-05-10T06:22:28

Re: Unable to Determine Parse Mode and other related problems

Jukka K. Korpela — 2013-05-10T05:59:25


Perhaps the most absurd part of this is that the validator announces at 
the start “Error found while checking this document as HTML 4.01 
Transitional!”, yet later says “Unable to Determine Parse Mode!” There 
is of course only one possible parse mode for HTML 4.01 (SGML parsing). 
The reason is that the validator tries to be informative by identifying 
the “document type” prominently at the start, but that information is 
often absurd.

Anyway, the problem with the page is that there is some character data 
before the <!DOCTYPE ...> thing.


Technically, the validator is not really saying that the document is 
invalid. Rather, that it is outside the scope of validation: validation 
proper wasn’t even started.

If you View Source in a browser, or save the page locally, you will not 
see anything special at the start. The reason is that browsers silently 
remove the character data before <!DOCTYPE ...>. But if you access the 
page with
http://www.rexswain.com/httpview.html
so that on that page, “Display Format” has been set to “Hex”, you will 
see that the server actually sends data that begins in hex with 
“3737390D0A”. In UTF-8, the declared encoding, these mean the 
three-digit string “779” followed by a line break, as Carriage Return, 
Line Feed (U+000D U+000A). How they get there can only be known by 
analyzing what the server is doing.

Strangely, if I submit such a document to validation via File Upload, I 
get the much more understandable error message.

QUOTE
Error Line 1, Column 1: character "7" not allowed in prolog

779
UNQUOTE

But when processing a server response, the validator seems to get confused.

For comparison, validating by URL, http://validator.nu starts its 
message as follows (and http://validator.w3.org/nu/ does the same):

QUOTE
Info: The Content-Type was text/html. Using the HTML parser.

Error: End of file seen without seeing a doctype first. Expected e.g. 
<!DOCTYPE html>.
UNQUOTE

This is a bit more informative, but it raises the question why the 
validator scans the rest of the document (without parsing any tags) in 
search for a <!DOCTYPE> string, without seeing it while it clearly is there.


Because it failed to note the <!DOCTYPE ...> due to character data 
before it. *And* because validator.w3.org, unlike the apparently 
improved validator.w3.org/nu and validator.nu, thinks that the parse 
mode must not be defaulted to SGML parsing even though the media type is 
declared text/html.


Apparently because the character data at the start confuses it so that 
it reads past the entire document looking for <!DOCTYPE> (which is there 
but gets unnoticed).


On IE 10, the page looks completely empty, and doing View Source, I see just

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv="Content-Type" content="text/html; charset=utf-8"></HEAD>
<BODY></BODY></HTML>

So apparently IE 10 has an issue with the character data before 
<!DOCTYPE>, rather similar to the issue that the validator has. It 
presumably does not recognize anything in the document – it just looks 
for <!DOCTYPE> without finding one, encounters end of data, thereby 
getting an empty document, and then it constructs HTML markup for it. 
Notice the 4.0 doctype without URL as opposite to the actual 4.01 
doctype with URL in the document.

Yucca

Unable to Determine Parse Mode and other related problems

Brian Barnett — 2013-05-09T23:40:15

One URL I test gives the "Unable to Determine Parse Mode!" warning as well
as the "Line 1
<http://validator.w3.org/check?uri=http%3A%2F%2Ftest1.calcxml.com%2Fcalculat
ors%2Fhome-affordability%3Fskn%3D502&charset=%28detect+automatically%29&doct
ype=Inline&ss=1&outline=1&group=0&No200=1&verbose=1&st=1&user-agent=W3C_Vali
dator%2F1.3+http%3A%2F%2Fvalidator.w3.org%2Fservices> , Column 1: end of
document in prolog" while a nearly identical URL (HTML nearly identical)
succeeds without warnings or errors.

Valid URL: http://test1.calcxml.com/calculators/home-affordability?skn=504
Invalid URL: http://test1.calcxml.com/calculators/home-affordability?skn=502

I understand that the problem would have to be related somehow to the slight
difference in the two htmls, but I have no idea what to do to find out what
the problem is. There is not enough information in the warnings and errors
for me to figure this out.

Questions:
1.Why is it unable to determine the parse mode?
2.Why does it think the html is empty?

If you browse to the invalid URL in a browser (except IE10 I believe, which
is why I am trying to figure this out), you will see that the invalid URL
does render and indeed returns html.

TIA,
Brian

Re: Regardless of the DOCTYPE I specify, always says "DOCTYPE Override in effect!"

Jukka K. Korpela — 2013-05-09T19:43:00


...and the validator does not check whether this means an actual 
override, i.e. whether the document type declaration or definition 
differs from the one declared in the document.

Yucca

Re: Regardless of the DOCTYPE I specify, always says "DOCTYPE Override in effect!"

David Dorward — 2013-05-09T14:48:08


Because you told the validator to use a Doctype other than "(detect 
automatically)" in the validation options.

Regardless of the DOCTYPE I specify, always says "DOCTYPE Override in effect!"

Brian Barnett — 2013-05-08T17:51:16

I can put any DOCTYPE declaration at the top of my page and I always get the
warning:

"DOCTYPE Override in effect!"

Even if I put in HTML 4.01 Strict, which is what it is overrided to, it says
it is overriding it.

The detected DOCTYPE Declaration "<!DOCTYPE html PUBLIC "-//W3C//DTD HTML
4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">" has been suppressed and
the DOCTYPE for "HTML 4.01 Strict" inserted instead, but even if no errors
are shown below the document will not be Valid until you update it to
reflect this new DOCTYPE.

And here is line 1 in the source listing used for the validation:

*  <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd"><!-- <!DOCTYPE html PUBLIC
"-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"> -->


It is replacing the exact same doctype line!! Why would it do this?

Thanks,
Brian Barnett

Re: [VE][html5] Add Subject Here Getting an error for using Unicode PUAs!

Anon SU — 2013-05-03T20:28:44

Thank you again for this detailed answer Yucca.

I must disagree however on what you said about icons not being characters,
as a rule. In fact, many characters are icons or "symbols" (see here:
http://www.unicode.org/charts/PDF/U2600.pdf ).

You say that icons should be represented using the <img> tag, however while
we could very well use a data attribute on the <img> tag to display the
font-icon using CSS, the drawback of that is that the <img> tag requires a
valid src attribute. That means that we'll most probably use an empty 1px
gif or png eventually for the src attribute, but you must admit that this
is another unnecessary HTTP request that could be avoided by using any
other HTML tag.

If you were referring to not using font-icons but instead using regular
images for icons, let me clarify that the enormous advantages of font-based
icons is that we're talking about vector graphics here: they are not only
much smaller in size than their image equivalents, but they are perfectly
appropriate for high-pixel-density displays (i.e. "Retina"). They can be
zoomed and will scale up like any other text without quality
loss/pixelisation. They can also be styled and animated using simple CSS.

At a time where more and more websites are delivering 2 versions of their
images through javascript or UA sniffing methods — a standard version, and
a double-sized version alternative for high-pixel-density displays
(devicePixelRatio == 2) — Choosing to use vector graphics for icons is the
smartest choice as it allows to deliver only one format for all devices.

*The main practical problem with icon fonts is that they so easily lead to


I don't mean to be rude at all but I believe that this is totally
irrelevant. We could say the same thing about literally *anything*. What,
we shouldn't recommend nor facilitate font-icons just because there're too
easy to use? But since you mention it: font-icons are monochromes which
means that they are much, much more sobers than what images can be, or
worse, animated gifs, should we drop support for images altogether because
people make ugly sites with them?!

Best,
Anon SU



On Sat, May 4, 2013 at 12:41 AM, Jukka K. Korpela <jkorpela< at >cs.tut.fi>wrote:

Re: [VE][html5] Add Subject Here Getting an error for using Unicode PUAs!

Jukka K. Korpela — 2013-05-03T17:41:41


That's trickery upon trickery: They use data-icon and CSS generated 
content to add a character in the rendered content and CSS settings to 
render that character as an icon that has nothing to do with the 
character. And when they realize that some browsers might actually read 
the character as what it is (as opposite to what they try to display 
instead), they then change e.g. a Latin letter to a Private Use 
character. So what happens when some browser makes a real effort at 
displaying or speaking the Private Use character? Uttering “Private Use 
character U+E000” would be a reasonable move, and would make the page 
look foolish.


It is very, very wrong, especially since they clearly offer their 
techniques for use on WWW pages. But this is a matter of principle 
rather than a serious practical issue. (The main practical problem with 
icon fonts is that they so easily lead to excessive use of icons, often 
ugly icons.)


Icons are not characters, as a rule. They are images, and should be 
presented in HTML using <img> tags.


A warning is seldom "wrong"; it can be useful, or useless, or sometimes 
misleading. Here it is useful, even though it is not based in HTML5 or 
Living HTML. Private Use characters *can* be used in HTML, but they 
*should not* be used as a rule, and this applies particularly strongly 
to open information interchange (as opposite to use in a standalone HTML 
application for example).

On the other hand, the real impact of icon font trickery is relatively 
small.

On the formal side, this is not a conformance issue, and HTML5 
validation in general means informal and experimental checking against a 
mutable definition.

Yucca

Re: [VE][html5] Add Subject Here Getting an error for using Unicode PUAs!

Anon SU — 2013-05-03T17:13:44

Thank you for the long and detailed reply.

The use of PUA is optional in IcoMoon, as according to their
documentation:

*Using Latin letters is not recommended for icons fonts. Using the Private



Is it a wrong usage? if so, what would you suggest as an alternative?
I have customers asking me why their website gets a warning by the W3C
Validator, what should I tell them? that the Validator is wrong?
Thanks for your explanations.



On Fri, May 3, 2013 at 9:42 PM, Jukka K. Korpela <jkorpela< at >cs.tut.fi> wrote:

Add this error...

Multiblitz USA — 2013-05-03T14:21:39

How can we get rid of the Addthis error:

 there is no attribute "addthis:userid"
…this_button_facebook_follow" addthis:userid="MultiblitzUSA" rel="nofollow"></a>
✉

On our website Multiblitz Studio Lighting ?


Sincerely, 
Your Multiblitz USA Team
+ Professional Studio Lighting + Made in Germany
facebook: /MultiblitzUSA | twitter: < at >multiblitzusa
web: www.multiblitzusa.com | pinterest: /multiblitzusa 
phone: +1.800.811.3392 | email: info< at >multiblitzusa.com

SIGN UP for the Multiblitz USA - IN THE FLASH newsletter

Disclaimer: The CAN-SPAM Act of 2003 establishes requirements for those who send commercial email, spells out penalties for spammers and companies whose products are advertised in spam if they violate the law, and gives consumers the right to ask mailers to stop spamming them. The above mail is in accordance to the Can Spam act of 2003: There are no deceptive subject lines and is a manual process through our efforts on World Wide Web. If you'd like to make sure we don't contact you again, unsubscribe here.