I am reviewing an educational website and it does not pass HTML5 nor CSS w3.org acessibility tests. Is this the norm? Do any sites these days pass these tests?
Eg.
Bad value Format for attribute name on element meta: Keyword format is not registered.
& did not start a character reference. (& probably should have been escaped as &.)
Property border-radius doesn't exist in CSS level 2.1 but exists in [css3] : 10px
Unknown pseudo-element or pseudo-class :nth-child
I am reviewing an educational website and it does not pass HTML5 nor CSS w3.org acessibility tests. Is this the norm? Do any sites these days pass these tests?
The W3C validator was updated about two months ago to look at HTML5. There are some bugs, but I haven't been following the progress. The bugs are mainly around some ARIA-stuff. In general it is good to get the code as valid as possible. Note if the validator says it is 100% valid code, that doesn't mean the site is accessible, it isn't an accessibility tester. The same goes for the CSS test, it matches your CSS to the spec, and makes sure that youu have : and ; in the right places. It may some color contrast tests, but I am not 100% on that. If the validator does, it uses WCAG 2.0 to check the ratios.
Bad value Format for attribute name on element meta: Keyword format is not registered. & did not start a character reference. (& probably should have been escaped as &.)
This is an age old issue. Somewhere you have an &, maybe for a link, such as: mysite.com/var1=Ryan&var2=B. The validator thinks you are trying to say &var2 is a valid HTML entity and saying that your link should be coded as mysite.com/var1=Ryan&var2=B.
Property border-radius doesn't exist in CSS level 2.1 but exists in [css3] : 10px Unknown pseudo-element or pseudo-class :nth-child
Either the CSS Validator is still checking against the CSS 2.1 Spec or it is saying "Hey not all browers understand CSS3 yet, so you may want to change it."
Related
Time and time again I'm reading about a very interesting CSS property on MDN only to see that MDN considers some values it can take "experimental", recommends against using it in production and warns that its behavior may change in the future.
Two examples: width: max-content and display: contents.
What does it precisely mean that a property or value is 'experimental'? Is it a status given to such a keyword by MDN or is it an official status given to this keyword by an appropriate standarization body (W3C perhaps?)
Where can I find if MDN's warnings are not out-of-date? For example for max-content, MDN links to this standard document, but I can see no warnings about the experimental nature in the paragraph about max-content - perhaps the whole document MDN linked to is experimental?
Context: I'm asking because I'd dearly like to use both width: max-contents and display: contents, both seem to make my life so much simpler, and I'm wondering if (a) it's OK to use them, (b) I shouldn't use them, (c) I really really shouldn't use them?
Basically what this means is that the developers that make it so that CSS works are creating new functions that aren't available in every major browser and very-well could be removed as they continue to develop. Think of it as an alpha test of new CSS declarations. In theory, every CSS identifier was 'experimental' at some point and was then moved to 'stable.' Eventually if it falls out of favor, it turns to 'deprecated.'
You can find more info here: https://developer.mozilla.org/en-US/docs/MDN/Contribute/Guidelines/Conventions_definitions
Here is a site that allows you to see cross-browser compatibility as well: https://caniuse.com/
At the very beginning of your linked document (CSS Box Sizing Module Level 3
Editor’s Draft, 5 June 2019), there is this paragraph
[...]This is a public copy of the editors’ draft. It is provided for discussion only and may change at any moment. Its publication here does not imply endorsement of its contents by W3C. Don’t cite this document other than as work in progress.[...].
So as long as a css property is only listed in the draft of the specification it has to be considered as experimental, as it is not even guaranteed that it will be finalized ever. Drafts have been completely rejected or had a major rewrite in the past if they were not practicable.
And if you look at this link https://www.w3.org/TR/css-sizing-3/ you can see that the current version of CSS Intrinsic & Extrinsic Sizing Module Level 3 is still W3C Working Draft, 22 May 2019.
[...]This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress[...].
So to figure out if a property or value is still experimental you need to check where it is defined and if those specs are final.
If those specs are final then the property/value is not experimental anymore and you only need to check if it is available in the browsers using e.g. caniuse.com
What happens if a browser doesn't support a CSS pseudo-class, like :dir?
For instance:
html:dir(rtl) {
color: red;
}
Would browsers just ignore this rule if they don't understand the :dir pseudo-class? I'm more interested in the general case then in this particular pseudo-class. My intuition tells me yes, but I haven't found documentation confirming my intuition.
This question is different from this one: Invalid CSS selector causes rule to be dropped: What is the rationale? . It is more narrow, I'm asking what the browser does when it sees a pseudo-class that it doesn't recognise, not what it does for invalid CSS selectors in general. For all I know, an unrecognised pseudo-class may still be considered a valid selector, for instance.
Browsers currently make no distinction between unrecognized or unsupported selectors, and invalid selectors. If a browser recognizes a selector, generally it'll have implemented it to the best of its ability (and any behavior that's not to spec can be classified as a bug on its bug tracker), even if it doesn't implement all other features in the same level of Selectors (as is currently the case with :dir() for example, and historically Internet Explorer 7 and 8 with level 3 attribute selectors, and Internet Explorer 6 with the universal selector). If it doesn't recognize the selector, it follows CSS2.1 §4.1.7 to the letter and drops the entire ruleset, no questions asked. Notice that it says
When a user agent cannot parse the selector (i.e., it is not valid CSS 2.1), it must ignore the selector and the following declaration block (if any) as well.
which implies that if a user agent cannot parse a selector, it must therefore be invalid CSS2.1 (or invalid in some other level of Selectors); and inversely that if it can parse a selector, it must therefore be valid. But this assumes the user agent conforms fully to the standard; we all know that in reality, different implementations have different levels of conformance to each standard, and certain implementations even have their own vendor-specific selectors which are not part of any standard. So I treat this as "When a user agent cannot parse the selector" without the parenthetical, and I imagine browser vendors do the same.
In fact, Selectors itself makes no distinction between a pseudo-class token with an ident or function that doesn't correspond to a valid pseudo-class, and a series of characters that cannot even be parsed as a pseudo-class — they're both equally invalid — see section 12 of css3-selectors and section 3.9 of selectors-4. Essentially, this means that the current browser behavior is in full compliance with the standard, and not just an arbitrary decision agreed upon by browser vendors.
I've not heard of any browser that recognizes a pseudo-class as valid for the purposes of error handling, and proceeds to ignore either just that pseudo-class or the entire complex selector (leaving other complex selectors in the selector-list unaffected). WebKit did use to have a really bad habit of accepting CSS rules with unrecognized pseudo-elements, allowing things like ::selection, ::-moz-selection, which proved useless anyway because every other layout engine followed the spec more strictly. I believe WebKit no longer does this, however, but you know how WebKit is with these things. But AFAIK it has never done this with pseudo-classes.
On the standards side, selectors-4 appears set to change this with the introduction of the static and dynamic profiles. My email on the subject was addressed in a CSSWG telecon; you can find the minutes here (search for "Behavior of Selectors not in Fast Profile"). However, it was resolved that selectors not in the dynamic (previously fast) profile should be treated as invalid and cause the entire CSS rule to be dropped, as usual. See section 2.1:
CSS implementations conformant to Selectors Level 4 must use the dynamic profile for CSS selection. Implementations using the dynamic profile must treat selectors that are not included in the profile as unknown and invalid.
This code triggers an error when run through the W3C CSS Validator:
p{
text-overflow: ellipsis;
}
I get:
Line Code context Error/Warning
2 p Parse Error [empty string]
Is it just a bug in the validator or am I missing something really obvious?
This is a bug in the CSS validator, it has been already reported. text-overflow:ellipsis is a valid rule, however the W3C CSS validator is unfortunately prone to errors (see bug list).
However, note that the current working draft lists some text-overflow values as feature at risk:
The Working Group has identified the following features as at risk of being removed from CSS Basic User Interface Module Level 3 when exiting CR. Implementors are urged to implement these features, if they wish to see these features remain in this specification. All other features are either defined in a normative reference (e.g. CSS 2.1 [CSS21] or Selectors [SELECT]) or are believed to have two or more implementations, and thus will not be dropped without returning to last call.
[...]
text-overflow property value: <string>
text-overflow property 2-value syntax and definition.
While this doesn't affect the ellipsis value, it could be the source of the bug in the validator:
Parse Error [empty string]
References
W3C: CSS Basic User Interface Module Level 3 (CSS3 UI): (WD-20120117)
Features at risk
8.2. Overflow Ellipsis: the ‘text-overflow’ property
It's valid based on MDN's reference, which also links to the spec: http://dev.w3.org/csswg/css3-ui/#text-overflow
Out of curiosity, I ran one of my own sites through the validator. I noted that it listed a few things that I would not consider errors, such as properly prefixed vendor extensions and data URIs.
I know that in HTML4 classes and id cannot start with numbers.
I am coding in HTML 5/php and alot of my ids and classes have just numbers in them that point to a primary key in my database for jquery ajax calls.
I cannot find the documentation for HTML5 classes and id spec. Is it valid in HTML 5 to have class and id names such as,
class="122"
id="13213"
I have ran my output code through w3c conformance checker and all is good, but still I would like confirmation!?
Thanks
I’ve researched this thoroughly and wrote about my findings: The id attribute got more classy in HTML5. From that article:
HTML5 gets rid of the additional restrictions on the id attribute. The only requirements left — apart from being unique in the document — are that the value must contain at least one character (can’t be empty), and that it can’t contain any space characters.
To target a classname or ID that starts with a digit in CSS or in JavaScript using the Selectors API, you should escape them. For example, to target the element with id="404", you can’t just use #404 — you’d have to escape it as follows:
#\34 04 {
background: pink;
}
The official html5 specs are here: id-attribute in html5.
(Here you go for html4)
So in html5 the only restriction is minimum 1 char and no whitespaces.
I am using to check my CSS http://jigsaw.w3.org/css-validator but I get error for -webkit-border-radius, -moz-border-radius and border-radius. I know that this site test for v2.1 and all these border-radius is from v3. So why they don't use CSS v3 as testing? Or CSS v3 should't be used?
They do, you just need to select the profile under More Options. The default is CSS level 2.1 as that's the most complete and final standard as of now. CSS level 3 is still in its early drafting stages — meaning any part of the spec can change drastically — and even the validator may be wrong sometimes, so it's not made default yet.
Bear in mind that vendor-prefixed styles will never validate as they are non-standard, but as Juhana says you can at the very least have them trigger warnings to allow your CSS to validate tentatively.