Robert KNOTEK | 1 Aug 16:47 2011
Picon
Picon

rel="home" --> Bad value home for attribute rel on element a: Keyword home is not registered.

<a href="http://www.toseco.at/" title="ToSeCo Consulting" rel="home">ToSeCo Consulting</a>

The output is….

Bad value home for attribute rel on element a: Keyword home is not registered.

…tp://www.toseco.at/" title="ToSeCo Consulting" rel="home">ToSeCo Consulting</a>

Syntax of link type valid for <a> and <area>:

A whitespace-separated list of link types listed as allowed on <a> and <area> in the HTML specification or listed as an allowed on <a> and <area> on the Microformats wiki without duplicate keywords in the list. You can register link types on the Microformats wiki yourself.

 

http://www.toseco.at

 

Ist in the Microformats wiki as i can see.

A few rel values have been developed as drafts as a result of going through most of the microformats process, and are thus listed here for your serious consideration. You may use these values, and if you find any problems with them please point them out on the respective "issues" page for the rel value.

rel value

summary

proposed in

external spec (if any)

pronunciation

…indicates that the destination of the 'link' element is a document providing a pronunciation lexicon for speech-synthesis purposes.

rel-pronunciation

directory

…indicates that the destination of the hyperlink is a directory listing containing an entry for the current page.

rel-directory

enclosure

…indicates that the destination of that hyperlink is intended to be downloaded and cached.

rel-enclosure

RFC4287

home

…indicates that the [referenced document] is the homepage of the site in which the current page appears.

rel-home

payment

rel-payment

 

 

Best regards

 

Robert

jpkozma | 1 Aug 02:57 2011
Picon

Validator does not report improperly terminated tags

The attached document was submitted by a student of mine.  It includes paragraph tags that are terminated as
empty elements, and as such, I 
don't think it should be considered valid under the strict DTD.  Nevertheless, the w3c validator reports it
as valid.  Validator.nu does 
report the improperly terminated paragraph tags as errors.  

Is this a bug or is it something I don't understand correctly?

Thanks for your help.

John Kozma

Attachment (works1.html): application/octet-stream, 3967 bytes
David Dorward | 2 Aug 11:25 2011
Picon

Re: Validator does not report improperly terminated tags


On 1 Aug 2011, at 01:57, jpkozma <at> knology.net wrote:

> The attached document was submitted by a student of mine.  It includes paragraph tags that are terminated
as empty elements, and as such, I don't think it should be considered valid under the strict DTD.

<!ELEMENT p %Inline;>
<!ATTLIST p
%attrs;
>

<!ENTITY % Inline "(#PCDATA | %inline; | %misc.inline;)*">

Paragraphs contain zero or more (various things). It is valid. (Nonsense, but still valid)

>  Nevertheless, the w3c validator reports it as valid.  Validator.nu does 
> report the improperly terminated paragraph tags as errors.

That looks like Appendix C checking. 

http://qa-dev.w3.org/~bjoern/appendix-c/validator/

--

-- 
David Dorward
http://dorward.me.uk

Leif H Silli | 2 Aug 23:06 2011
Picon

Re: [VE][html5] http="X-UA-COMPATIBLE" should be valid

Jukka K. Korpela, Sun, 31 Jul 2011 23:18:05 +0300:
> 31.07.2011 18:53, Leif Halvard Silli wrote:
>> Jeff French, Sat, 21 May 2011 10:21:42 -0700:
>>> I'm not sure why this error comes up. This http-equiv value has been
>>> around for at least a few years and seems like it should be valid.
>>>
>>> Bad value X-UA-Compatible for attribute http-equiv on element meta.
>>> <meta http-equiv="X-UA-Compatible" content="IE=edge,chrome=1">
>>
>> It is not necessary that it is valid, because there is  a valid way of
>> inserting it, see http://www.w3.org/Bugs/Public/show_bug.cgi?id=12072
>
> That discussion seems to revolve around comments before <!doctype>,
> though it mentions the X-UA-Compatible issue too. And it's a rather
> complicated discussion. (And I can't find a "valid way of inserting
> it" there.)

Sorry, I did not really mean not to point to that bug (although it *is* 
relevant). I simply mean to point to the message to this list - where I 
pointed to that bug ...

http://www.w3.org/mid/20110330034421114269.a22bfb58 <at> xn--mlform-iua.no

> Meta tags with http-equiv="X-UA-Compatible" are used for various
> purposes, such as making some versions of IE behave by the
> specifications in some issues or just reasonably.

Is X-UA-Compatible meta tags used for any other thing than that specific 
thing? AFAIK, X-UA-Compatible is only used for IE browsers: Either to 
trigger a certain "compatibility mode" within IE's native Trident engine. 
OR to trigger IE to start the ChromeFrame.

> For example, some
> versions of IE treat an Ascii hyphen "-" as a character that allows
> line break before and after it, and the "before" part is just absurd.
> The tag
> <meta http-equiv="X-UA-Compatible" content="IE=EmulateIE7">
> seems to cure this, though with some cost.

IE=Edge doesn't cure it?

> So are you sure that for _all_ issues that can be handled with
> X-UA-Compatible, there is an equally or better supported other way?

No. See below.

> But this isn't really about the validator, this is about the
> _specification_ of HTML5.

The point I wanted to make (by pointing to that the message - and not to 
that bug), was that it *is* possible to insert X-UA-Compatible in a HTML5 
page, without triggering an error message in the HTML5 validator.

In words, this is how you do it:

  * create an conditional *before* the DOCTYPE
  * place the X-UA-Compatible meta element inside the cond comment
  * if the conditional comments targets IE installations that
    perhaps will not react to your X-UA-COMPATIBLE meta, then you
    probably also need to place a DOCTYPE inside the cond comment,
    before the X-UA-COMPATIBLE meta element, to prevent quirksmode.

By example, this is how - with a general <!--[if IE]>:

<!--[if IE]>
<![if lte IE 7]><!DOCTYPE html><![endif]>
<meta http-equiv="X-UA-Compatible" content="IE=edge;chrome=1">
<![endif]-->
<!DOCTYPE html>
<html>

By example, targeting IE versions which react to X-UA-COMPATIBLE:

<!--[if gte IE 8]>
<meta http-equiv="X-UA-Compatible" content="IE=edge;chrome=1">
<![endif]-->
<!DOCTYPE html>
<html>

Why these hoops: X-UA-COMPATIBLE cannot occur inside a coniditional comment 
- it doesn't work then. But if the conditional comment is placed before the 
DOCTYPE, then IE moves it into the head element before reparsing it (at 
least, that is what I think happens). Hence it works anyhow.

NB: I have not tested if this trick also works for Chrome Frame.

As for HTML5: please file a bug, if you want HTML5 to allow "free use" of 
the http-equiv element. Personally, I think it is OK that there is no free 
use in HTML5, though.

The X-UA-COMPATIBLE is, from my POV, a vendor specific syntax. As such I'm 
fine with the fact that one can insert it via the MS vendor specific 
conditional comments.
--
Leif H Silli

Jukka K. Korpela | 3 Aug 20:58 2011
Picon
Picon

Re: Validator does not report improperly terminated tags

David Dorward wrote:

> Paragraphs contain zero or more (various things). It is valid.
> (Nonsense, but still valid)

Paragraphs with empty content are not quite nonsense. The HTML 4.01 spec 
mentions them as something that browsers should ignore and authors should 
not use, but between the lines, it becomes apparent that empty paragraphs 
have often been used for formatting, to create empty vertical space. It's a 
bad idea (though it may have been understandable in ancient, pre-CSS times), 
but not nonsensical.

>>  Nevertheless, the w3c validator reports it as valid.  Validator.nu
>> does
>> report the improperly terminated paragraph tags as errors.
>
> That looks like Appendix C checking.

Yes, it's an appendix C issue. But the XHTML DTDs allow the use of <foo/> 
for any element foo, so validators are required to accept them (not report 
an error).

Validator.nu is not a DTD-based validator but a heuristic checker for some 
varying version of the HTML5 draft.

Yucca 

Jukka K. Korpela | 4 Aug 08:01 2011
Picon
Picon

Re: [VE][html5] http="X-UA-COMPATIBLE" should be valid

Leif H Silli wrote:

> Is X-UA-Compatible meta tags used for any other thing than that
> specific thing? AFAIK, X-UA-Compatible is only used for IE browsers:
> Either to trigger a certain "compatibility mode" within IE's native
> Trident engine. OR to trigger IE to start the ChromeFrame.

It is used to select one of the modes of IE. The details are messy and not 
relevant here, since from the perspective of HTML specifications, the issue 
is realism versus attempt at regulate what may appear in meta tags.

> Why these hoops: X-UA-COMPATIBLE cannot occur inside a coniditional
> comment - it doesn't work then. But if the conditional comment is
> placed before the DOCTYPE, then IE moves it into the head element
> before reparsing it (at least, that is what I think happens). Hence
> it works anyhow.

"Conditional comments" and other tricks*) are pointless here. It is so much 
easier to use the meta tag that does the job, following the vendor's 
description, when you are doing something vendor-specific.

So since this is at most about one error message per document, it is easier 
to just let it appear and ignore it.

*) Other tricks include adding the meta tag via client-side scripting. It 
prevents (at present at least) validators from reporting an error, even 
though it does not remove the error (violation of HTML5 drafts treated as 
specifications).

Yucca 

Henri Sivonen | 4 Aug 08:43 2011
Picon
Picon

Re: [VE][html5] http="X-UA-COMPATIBLE" should be valid

On Thu, 2011-08-04 at 09:01 +0300, Jukka K. Korpela wrote:
> > Is X-UA-Compatible meta tags used for any other thing than that
> > specific thing? AFAIK, X-UA-Compatible is only used for IE browsers:
> > Either to trigger a certain "compatibility mode" within IE's native
> > Trident engine. OR to trigger IE to start the ChromeFrame.
> 
> It is used to select one of the modes of IE. 

Or put the other way, it is used to enable deliberate non-compliance
with the spec when choosing a past version of the Trident engine. It
would be rather odd for the spec to allow deliberate non-conformance
with the spec since requiring conformance is what specs do. (In the case
of choosing between Edge an Chrome Frame, it's choosing between a
different set of incidental compliance failures.)

> The details are messy and not 
> relevant here, since from the perspective of HTML specifications, the issue 
> is realism versus attempt at regulate what may appear in meta tags.

Just to understand your position about realism and validation better:
Should <g:plusone></g:plusone> validate in your opinion? (It's realism
created by blatantly disregarding the extension points that the HTML
spec does offer.)

> *) Other tricks include adding the meta tag via client-side scripting.

Does that actually work? (I doubt it but didn't test.)

--

-- 
Henri Sivonen
hsivonen <at> iki.fi
http://hsivonen.iki.fi/

Leif H Silli | 4 Aug 12:24 2011
Picon

Re: [VE][html5] http="X-UA-COMPATIBLE" should be valid

Henri Sivonen 4/8/'11,  9:43:
> On Thu, 2011-08-04 at 09:01 +0300, Jukka K. Korpela wrote:
>>> Is X-UA-Compatible meta tags used for any other thing than that
>>> specific thing? AFAIK, X-UA-Compatible is only used for IE browsers:
>>> Either to trigger a certain "compatibility mode" within IE's native
>>> Trident engine. OR to trigger IE to start the ChromeFrame.
>>
>> It is used to select one of the modes of IE.
>
> Or put the other way, it is used to enable deliberate non-compliance
> with the spec when choosing a past version of the Trident engine. It
> would be rather odd for the spec to allow deliberate non-conformance
> with the spec since requiring conformance is what specs do.

+1

>> The details are messy and not
>> relevant here, since from the perspective of HTML specifications, the 
>> issue
>> is realism versus attempt at regulate what may appear in meta tags.
>
> Just to understand your position about realism and validation better:
> Should <g:plusone></g:plusone> validate in your opinion? (It's realism
> created by blatantly disregarding the extension points that the HTML
> spec does offer.)

With regard to the uses that Microsoft IE makes of X-UA-COMPATIBLE, them I 
suppose that there aren't any relevant extension points...
--
Leif H Silli 

aykut.sensoy | 3 Aug 13:24 2011
Picon

Support for RDFa in HTML5

Hi,
according to the W3C Specification:

1. the xmlns attribute has been replaced with the prefix attribute in HTML5

example: <html prefix="rdfa: http://www.w3.org/ns/rdfa#">

2. the RDFa declaration must be defined with the version attribute in HTML5

example: <html version="HTML+RDFa 1.1">

Complete example:
<html version="HTML+RDFa 1.1" prefix="rdfa: http://www.w3.org/ns/rdfa#">

But both attributes are not supported in the W3C HTML5 Validator.
I would like to know if these attributes will be part of HTML5 Validator or is there another valid method to integrate RDFa into HTML5?


Kind Regards
Aykut


mahavir.patil | 4 Aug 12:47 2011
Picon

W3 validator gives Different validation results when validated through web service soap12 (in javascript using XMLHttpRequest) against online over the validator.w3.org site

Hi,

 

I am using W3C html validator service to validate my html content. I am doing it programmatically by calling the service (soap12 response) through javascript XMLHttpRequest using the below code:

 

var encodedContent = ‘<some html content>’;

xmlHttp = CreateXMLHttpRequest();

    var params = "fragment=" + encodedContent ;

    xmlHttp.open("POST", "http://validator.w3.org/check", false);

    xmlHttp.setRequestHeader("Content-length", params.length)

    xmlHttp.send(params);

 

What I am finding is, for a similar html content the validation results I am getting within the soap response from the service is different than what I am getting on the validator.w3.org as I pass the same HTML content as direct input on the site. Both provide different number of errors and warnings. Some are common but the difference sometime is like soap call is giving 2 errors and on site its giving 20.

 

Any hint?

 

Regards,

Mahavir

 


This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the email by you is prohibited.

Gmane