Nesting span tags is valid HTML.
A span tag is non-semantic markup intended for grouping inline content, and is a valid wrapper for phrasing content. This includes tags like strong, em, time, and etc, but also additional span tags.
You can confirm this by pasting the following code into the W3C Markup Validator:
Tool from Yandex
The "Structured data validator" supports JSON-LD.
Alexander Shubin (working for Yandex) wrote:
Pls, take into account that in order to check JSON-LD you need to put it in tag (since this is how it should be embedded into html).
"@type" : "...
The reason it was marked invalid is because it was deprecated, i.e. at the time you tested it was no longer part of the current HTML spec.
It's now been reintroduced to the HTML5 spec, albeit with a different use. Helpful discussion here.
While there is a relationship, technical validity and desirability or efficacy for the purposes of SEO are not ...
This looks like a job for a div:
<span id="deftext">No file selectedspan</span>
If you wanted to take that further, you might be using <form> tags, <input> tags, etc, but that's going further off topic.
Divs and spans have no semantic value or ...
isolating error triggers
assessing what all the error triggers had in common (they all referred to external .svg files)
The answer is:
Google Structured Data Testing Tool doesn't yet know how to process (or just ignore) references to SVG files.
You could edit your hosts file or run a DNS server on a local network to create a machine with a top level domain name. The email address will be only accessible if it's routed only within that local network but it's a possible configuration.
The linked article is from 2009. Since then some improvements have been made in regards to form validation. One being that HTML 5 already has built-in form validation, but fails in older browsers with no HTML 5 support.
jQuery Validation ...
In Debian/Ubuntu you can do:
sudo apt-get install w3c-markup-validator
This will get you the web interface.
If you want to validate from the console, edit /usr/share/doc/w3c-markup-validator/examples/validate.pl and install libwebservice-validator-html-w3c-perl. Now you can run validate.pl with an URL to validate.
In HTML5+Microdata, only the meta element can have the content attribute.
(In HTML5+RDFa, every element may have the content attribute.)
So if you want to add the string value "in_stock", and it should not be visible on the page, using the meta element is the correct choice:
<meta itemprop="availability" content="in_stock" />
You were probably ...
Though you'll probably block out most attacks with the check provided above, you should not treat the data as safe afterwards. The actual issue here isn't so much the above validations, but what you do with the data after this.
If, for instance, you were to use this 'validated' data in a SQL statement and simply insert the $password var you'd be open for ...
Include a reference link in your <head></head> the same way you
would link your CSS file:
<link rel="stylesheet" href="https://fonts.googleapis.com/icon?family=Material+Icons">
Reference your <icon> as <i class="material-icons">cloud</i>
You can learn more about it at W3Schools Icon Tutorial
Note also that web browsers are not required to perform any validation checks. Older browsers don't do anything special with the email address. Newer browsers may validate, but the 'email' type is most useful on mobile devices where a specialized keyboard may be shown to the user.
Well as you said its semantically horrible and should be avoided, its impossible to tell if its impacting on the rankings as such as Google but it's definitely will not help rankings.
You should test the following site using the following to determine how bad the situation is:
Markup Validation (I suspect there are dozens to hundreds of errors). Some ...
W3C errors (css or html) increase the chances of your site not rendering correctly across all devices.
You should worry about the css errors and get them fixed.
There is an awesome W3C Validator Chrome plugin that makes troubleshooting easy.
The first step would be to do a check on the domain to identify the mail exchangers using the command...
nslookup -q=mx domain.com
You should receive a response similar to...
domain.com mail exchanger = 0 mx1.domain.com
domain.com mail exchanger = 0 mx2.domain.com
NB: The number of records returned will be the number of MX ...
There are lots of websites that provide free SSL certificates (like cloudflare, letsencrypt, google firebase and blogger.com (Only for their blogs), Wordpress.com (Only for their blogs)...) and people using it widely. And I think Google already know about that. But they still haven't announced anything on their blog about ssl certificate choices.
In old ...
This kind of spam prevention is usually provided by the reCAPTCHA service from Google. IMHO this is an advanced spam protection service based on the principles of CAPTCHA. While I do not think reCAPTCHA is a technical name and there could also be other advanced implementations of CAPTCHA-like spam protection.
There are a few search engines which have a management interface that address situations like this. They are normally named in the format of "(search engine name) webmaster tools". For example, in Google, theirs is called "Google Webmaster tools".
Simply sign up for a free account and upload your sitemap to them and in a few days, check the sitemap section ...
The short answer is, if they are just giving you a list of IP numbers, there is no way to verify that they are all owned by the company. However for large corporations, you can do a whois lookup on an IP range and determine the owner: http://whois.arin.net/ui
For example, if I enter 220.127.116.11, it returns that 18.104.22.168 - 22.214.171.124 are assigned to Google, with ...
You could physically send someone to the company and check with a simple "ifconfig" what the IP is...this is a silly solution and it's pretty bad if you're based in US and the company is in AUS. You could think about something else but the point is you should avoid IP Based Authentication at all. Suppose someone knows your company and one of your customers, ...
That's going to depend from site-to-site. Some only want to initially validate your site to make sure it is legitimate at the time of submission. Others will require it as they periodically check to maker sure your site is still there as they try to keep their directory fresh and prevent dead links.
Considering how little traffic and SEO value these ...
tkent, a chromium developer who worked to resolve that browser's value truncation issue, found WHATWG specifications stating that the Vertical Tab (U+000B) is legal and should be unmodified in various contexts. Pertinent to this question on input type=text is the following:
What works for validator.w3.org as well as for www.google.com/webmasters/tools/richsnippets is the schema.org example but with data instead of time:
<data itemprop="openingHours" value="Mo-Su 07:00-22:00">
7 days a week, 7 am to 10 pm
You don't say what you are using to validate your markup.
According to this post StackOverflow: schema.org openinghours some validators don't accept the datetime format suggested by schema.org and instead expect the ISO 8601 format which doesn't support day of the week.
Another solution suggests using a much more granular format for your opening hours:
Google and Bing do not, have not and will never use CSS or HTML validation as a ranking factor.
The majority of websites have dozens to hundreds of errors and you need not worry about them because all search engines care about is how the page renders. Just ensure your website renders correctly in all major browsers and Google's Fetch.