I developed a web page and now i am validating it with w3c HTML4.0... I got one error it says
Error Line 30, Column 57: there is no attribute "DATA-FLEXMENU"
href="about.php" class="mainlink" data-flexmenu="flexmenu1">About Us</a></div>
You have used the attribute named above in your document, but the document type you are using does not support that attribute for this element. This error is often caused by incorrect use of the "Strict" document type with a document that uses frames (e.g. you must use the "Transitional" document type to get the "target" attribute), or by using vendor proprietary extensions such as "marginheight" (this is usually fixed by using CSS to achieve the desired effect instead).
Any ways of getting rid of this error .... Any suggestion...
data attributes are present in HTML5.
see HTML 5 data- Attributes
Either you can change the doctype to html5 or remove the data attribute.
You can specify HTML 5 doctype like
<!DOCTYPE html>
As unhelpful as it will sound, either remove the attribute "data-flexmenu" from your markup, or accept a non-valid result.
The results are accurate, the A element in the DTD does not contain an attribute definition for the attribute data-flexmenu.
Alternatively you could define your own DTD and host it on a central server and reference that instead of the w3c one.
Or (as pointed out) use HTML5 DTD not HTML 4 DTD
Related
My Sitecore website is on 7.5. I have implemented a media protection request feature, but I can see too many errors in Sitecore logs saying that:
ERROR MediaRequestProtection: An invalid/missing hash value was
encountered. The expected hash value: Media URL: , Referring URL:
My question is How to handle an image tag in Rich Text field in Sitecore, so that it can handle the media hash automatically?
Since version 7.5 Sitecore introduced a Media Request Protection which is a hash added to assets' URLs. I think that this was a good thing to avoid any kind of denial of service attacks.
On every incoming media request Sitecore calculates the hash of the request query string parameters and compares it with the given hash. If they are equal then Sitecore will perform the needed routine based on the provided URL parameters (for example, image resizing), but if they are not equal then Sitecore will throw a MediaRequestProtection error and send the original file as is.
There is a known issue in Sitecore Rich Text Editor (RTE) with 438674 Ticket Id and "Media request protection is not applied to media in a hyperlink within the RTE" description. Sitecore Support can provide a patch to override the method for rendering media links from RTE fields to also include the hash value. See the reference under Sitecore 8.2 release notes here.
If you don't have any Sitecore Support coverage by now then you can implement a workaround as follows:
Hook into saveRichTextContent pipeline to alter the RTE content before saving. For items that haven’t been modified after the saveRichTextContent pipeline has been introduced you can create a new renderField pipeline for Rich Text field type, but I would rather recommend to stick to saveRichTextContent pipeline approach and simply re-save all items with RTEs containing media assets.
Write your custom code to loop through images within the RTE HTML and modify the image rendering accordingly. Note, that you need to use Sitecore.Resources.Media.HashingUtils.ProtectAssetUrl() method to generate the full URL with the hash added, for example:
string mediaUrl = Sitecore.Resources.Media.MediaManager.GetMediaUrl(yourMediaItem);
string safeMediaUrl = Sitecore.Resources.Media.HashingUtils.ProtectAssetUrl(mediaUrl);
In the SonarQube Web Plugin, the InternationalizationCheck rule searches for internationalization in the form of <fmt:message key=...>. Is there any way to change this? All my internationalization is in the format <f: message key=...>. I assume this was alterable in the 'attributes' section, but I haven't figured out what exactly that section is for, or what to put there.
For example, currently the rule searches for any internationalization in the form of
<fmt:message key="login.label.username" />
As described in the rule's noncompliant/compliant code example. However, in my application, internationalization takes the form of
<f:message key="login.label.username" />
Which is incorrectly labelled as an error by the rule. Nothing in the InternationalizationCheck's source code shows how it explicitly looks for the that format, so I need to find a way to make it accept my format as an acceptable line of code instead of giving it a false positive.
Is there any way to specify for the InternationalizationCheck to look for a different format of Internationalization, other than the JSTL taglib prefix of 'fmt'?
Microdata allows elements with itemprop but without parent itemscope, as long as they are referenced by an itemref somewhere on the page. (See my question Is 'itemprop' without parent 'itemscope' valid? Does it create an item?).
So this example should be valid:
<body>
<div itemprop="email" id="orphan">
alice#example.com
</div>
<div itemscope itemtype="http://example.org/Person" itemref="orphan">
<span itemprop="name">Alice</span>
</div>
</body>
Now, when someone is using the Schema.org vocabulary instead (replacing "example" with "schema" in the itemtype value), it’s my understanding that this example would no longer be valid, because on http://schema.org/WebPage it says:
Every web page is implicitly assumed to be declared to be of type WebPage, so the various properties about that webpage, such as breadcrumb may be used. We recommend explicit declaration if these properties are specified, but if they are found outside of an itemscope, they will be assumed to be about the page
So this would mean that the following items and name-value pairs would be created:
Item <http://schema.org/Person>
name: Alice
email: alice#example.com
Item <http://schema.org/WebPage>
email: alice#example.com
But http://schema.org/WebPage can’t have an email property, so this is invalid Microdata, as in this case the itemprop value has to be
[…] a defined property name allowed in this situation according to the specification that defines the relevant types for the item
So this statement on http://schema.org/WebPage, if respected by consumers and implementors, would result in invalid Microdata in cases where an element with itemprop has no itemscope parent and the property is not allowed on WebPage.
Is this correct or am I missing something?
How should I deal with this? Ignore this statement? AFAIK Microdata doesn’t require to follow those "informal rules", right?
It's not often discussed in these terms, but validity is a relative concept. A document is valid or invalid only with respect to the requirements of a particular specification.
In this case, the microdata spec says nothing about WebPage, so the inclusion of the itemprop in an implicit WebPage item has no effect on the validity of your document with respect to the Microdata spec.
On the other hand, with respect to the schema.org WebPage spec, your document, or at least the WebPage item within it, would be invalid.
Whether this matters to you or not is your choice. There are really only two practical outcomes. A consumer of the microdata of your page can either create a WebPage item, or not create WebPage item. It is highly unlikely that a consumer would refuse to create a WebPage item because of the presence an additional out-of-schema itemprop, where it would have created the WebPage item otherwise.
And that's ultimately what validity is all about. It's there to establish a common language that producers and consumers of documents both understand. Providing that consumers understand the information that producers provide, technical violations of the validity rules of any particular specification are of little consequence.
Should the link attribute rel="canonical" validate against html5?
It is the first time I am using this and I am getting the following validation errors:
"Bad value canonical for attribute rel on element link: Keyword canonical is not registered."
It kind of suggests it shouldnt although I cant find any concrete documentation on this.
Edit - Here is the line that is throwing the validator off:
<link rel="canonical" href="http://dev.local/" />
I have tried it with and without the closing slash
Validator is marking canonical invalid because canonical is a recent addition (as Gutmann pointed out) and the validation tool does not update real time. The W3C tells us why canonical is on the Micorformats wiki but does not validate. It is because the updates of wiki data in the validator are manual.
You will see this in the validation reporting:
"A whitespace-separated list of link types listed as allowed on in the HTML specification or listed as an allowed on on the Microformats wiki without duplicate keywords in the list. Note that updates of the wiki data in the validator are manual and do not happen in real time"
This will validate on their next manual update.
There is no definition for the canonical rel in the HTML5 spec, but it does also say that:
The rel attribute has no default value. If the attribute is omitted or if none of the values in the attribute are recognized by the user agent, then the document has no particular relationship with the destination resource other than there being a hyperlink between the two.
So, it's not technically conforming HTML5, but it will simply be ignored by UAs which don't understand it.
Use this data-rel
<link data-rel="canonical" href="http://dev.local/" />
In error description they do reference Microformats wiki as list of valid link types, their list contains "canonical" link type.
I believe that this a temporary bug in validator because it reported error for rel="canonical" only on my HTML5 website, but not on my other XHTML website.
From what I can gather from the output of the validator and the part of the spec that defines the link's rel attribute I'd say the validator is marking the document as invalid due to the "canonical" type being only a proposal and not part of the official linkTypes right now.
At the same time that page also says ...
Types defined as extensions in the
Microformats wiki existing-rel-values
page with the status "proposed" or
"ratified" may be used with the rel
attribute on link, a, and area
elements in accordance to the "Effect
on..." field. [MFREL]
The validation message refers to this list of currently valid extensions to the "official catalog".
Up until June 2 this list did not contain the canonical link type so the validator was IMO correct in marking the document as invalid.
But now that the canonical type is is in the list of proposed types, I think this is just a matter of time before also the validator will recognize it :-)
I have a field "length" in one of my struts 2 form. The data-type of "length" is "double". I have applied the "double" validation in XML file. But when I key-in alphabets in the "length" text field, it shows the error message as
Invalid field value for field "length"
I don't want this message to be shown like this. This message is generated by struts 2 itself and not entered by me. I guess, this message comes as the conversion of data fails. I also applied the "conversion" validator, but the above error message is still showing up. Please suggest the solution.
Thanks in advance.
You're in luck. This text is customizable.
The text is defined in xwork-messages.properties in the xwork jar. You can override it by adding the following to your global i18n resource bundle:
xwork.default.invalid.fieldvalue=Invalid field value for field "{0}".
As you guessed, this error message occurs for all type conversion failures. The XWorkConverter class has some useful javadoc about this:
Any error that occurs during type conversion may or may not wish to be reported. For example, reporting that the input "abc" could not be converted to a number might be important. On the other hand, reporting that an empty string, "", cannot be converted to a number might not be important - especially in a web environment where it is hard to distinguish between a user not entering a value vs. entering a blank value.
By default, all conversion errors are reported using the generic i18n key xwork.default.invalid.fieldvalue, which you can override (the default text is Invalid field value for field "xxx", where xxx is the field name) in your global i18n resource bundle.
However, sometimes you may wish to override this message on a per-field basis. You can do this by adding an i18n key associated with just your action (Action.properties) using the pattern invalid.fieldvalue.xxx, where xxx is the field name.
It is important to know that none of these errors are actually reported directly. Rather, they are added to a map called conversionErrors in the ActionContext. There are several ways this map can then be accessed and the errors can be reported accordingly.
try this,
<field name="percentage">
<field-validator type="double">
<param name="minExclusiveExpression">${minExclusiveValue}</param>
<param name="maxExclusiveExpression">${maxExclusiveValue}</param>
<message>Percentage needs to be between ${minExclusive} and ${maxExclusive} (exclusive)</message>
</field-validator>
</field>