HTML Checking for Large Sites
Rocket Validator integrates the W3C Validator HTML checker into an automated web crawler.
The “type” attribute is unnecessary for JavaScript resources.
- javascript
- script
- type
The default type for <script> tags is JavaScript , so you don’t need to include the type for JS resources.
Related W3C validator issues
- script
- type
- src
The <script> tag allows authors to include dynamic scripts and data blocks in their documents. When the src is present, this tag accepts a type attribute which must be either:
- an empty string
- text/javascript (that’s the default, so it can be omitted)
- module
- script
- type
The value rocketlazyloadscript used in a <script> tag is not a valid one according to the HTML specification. It is introduced by the WP Rocket WordPress extension.
- script
- type
- subtype
- MIME
The specified type for an script element is not a valid MIME type as it’s missing a subtype.
A MIME type most-commonly consists of just two parts: a type and a subtype, separated by a slash (/) — with no whitespace between, for example:
- textarea
- type
The <textarea> element does not have a type attribute.
The HTML <textarea> element represents a multi-line plain-text editing control, and is useful when you want to allow users to enter a sizeable amount of free-form text, for example a comment on a review or feedback form.
Still checking your large sites one page at a time?
Save time using our automated web checker. Let our crawler check your web pages on the W3C Validator.
- async
- script
- bad value
The async attribute is boolean: the presence of a boolean attribute on an element represents the true value, and the absence of the attribute represents the false value. As a boolean attribute, it does not need to be passed any value such as true or 1 to activate the async property.
For classic scripts, if the async attribute is present, then the classic script will be fetched in parallel to parsing and evaluated as soon as it is available.
For module scripts, if the async attribute is present then the scripts and all their dependencies will be executed in the defer queue, therefore they will get fetched in parallel to parsing and evaluated as soon as they are available.
- type
- a
- bad value
- mime types
The value provided on the type attribute of an a element is not a valid MIME type.
The type attribute expects a MIME type that hints at the linked URL’s format.
25,000 HTML checks per month. Fully automated.
Save time using our automated web checker. Let our crawler check your web pages on the W3C Validator.
- a
- type
- bad value
- subtype missing
The type attribute on <a> elements, when present, gives a hint on the MIME type of the linked resource, for example:
That is, we’re talking about the type of the linked resource, not the type of the <a> element, as it’s sometimes misunderstood. The following example is invalid because button is not a valid MIME type.
- link
- type
- bad value
The value used to define the type of a link is not valid. You’re probably using a URL instead of a valid type.
Example of a valid type:
- zip
- input
- type
input elements can be of different types but zip is not one of the allowed. Consider using a generic type like text instead.
- async
- script
- src
The async and defer boolean attributes of the <script> element control how an external script should be executed once it has been downloaded. The async attribute makes sense when an external script (defined with the src attribute) is loaded, or when defining a script of type module:
Still checking your large sites one page at a time?
Save time using our automated web checker. Let our crawler check your web pages on the W3C Validator.
The fastest digital accessibility scanner for large sites.
Our Web Accessibility Testing Platform tests and monitors your websites
for HTML and A11Y compliance using the W3C Validator and Axe Core.
Remove "type" attribute from script tags in WordPress
I am working on WordPress Site,these warnings are coming on every single page, Is there any method to resolve this.
Warning:The type attribute is unnecessary for JavaScript resources. <script type=»text/javascript»>
4 Answers 4
As of WordPress 5.3 you can add ‘style’ and ‘script’ to add_theme_support for Html5 to remove the type attributes.
Add following code to your theme’s functions.php
This will change <script type="text/javascript"> to <script> And will change <style type="text/css"> to <style> . It can be done by script_loader_tag but its given theme check validation error.
Как удалить все атрибуты type=’text/javascript’ и type="text/css" из Вордпресс?
Здравствуйте!
Сделал проверку сайта в валидаторе и выяснилось, что теперь в HTML 5 не обязательно указывать type=»text/css» в стилях и type=’text/javascript’ в скриптах.
Вот что пишет валидатор:
Мой сайт на вордпресс. Подскажите, пожалуйста, можно ли удалить эти аттрибуты на во всех скриптах и стилях на сайте через указания в файле functions.php? Если можно, то прошу практическое решение.
Это решение не работает:
add_filter(‘style_loader_tag’, ‘clean_style_tag’);
function clean_style_tag($src) <
return str_replace(«type=’text/css'», », $src);
>
add_filter(‘script_loader_tag’, ‘clean_script_tag’);
function clean_script_tag($src) <
return str_replace(«type=’text/javascript'», », $src);
>
Remove type attribute from script and style tags added by WordPress
These errors are some new introduction by W3C and they have started to creep in last 3-4 days only.
We enqueue scripts like this →
Can we fix this from the above enqueuing method somehow?
Update →
these are the actual errors. In the red box are coming from W3 total cache.
12 Answers 12
WordPress 5.3 introduces a considerably simpler way to achieve this. By registering theme support for HTML 5 for script and style , the type=»» attribute will be omitted:
You can remove the type=’*’ attributes and values from wp_enqueue ‘ed scripts and styles, using respective *_loader_tag hooks.
The following worked for me:
Got this from the soil / roots plugin. did the job for the most part.
The style_loader_tag and script_loader_tag approaches above look like they should work for whatever markup WordPress is generating, in cases where the theme/plugin is using the proper enqueue functions.
If you have offending plugins that don’t cooperate (IIRC Jetpack is/was an offender unless a newer version since my recollection has revised this!), and you are adamant about solving this issue despite the fact that your visitors are not likely to be impacted in any way (their browser will render the page fine!), you can always go all-out and use output buffering:
Be warned that while this is a solution, it isn’t very efficient. You’d be running preg_replace() on the entire «final» output from WordPress before it gets sent to the client’s browser, for every request.
Output buffering is turned on at the start ( wp_loaded hook), i.e. right as wp + theme + plugins + etc are fully loaded, and is turned off at the last moment ( shutdown hook) which fires just before PHP shuts down execution. The regex must work through everything, and that could be a lot of content!
The style_loader_tag and script_loader_tag approaches above only run the regex on a very small string (the tag itself) so the performance impact is negligible.
I suppose if you had relatively static content and used a caching layer you could try to mitigate the performance concern.