CSS Pointer-Events and Appearance Properties Not Recognized by CSS Validator

CSS pointer-events and appearance properties not recognized by CSS Validator

TL;DR: Focus more on the data in caniuse.com, which tells you what browsers are actually doing, as opposed to W3C validators, which require properties and values to achieve a high official status before being included. You'll often find properties and values that are too new or undeveloped for inclusion in the validators, but are nonetheless supported by major browsers.

---

From CSS Working Group archives:

I just checked my page redseen.3owl.com with the css validator.

I got this error:

Property pointer-events doesn't exist : none

Why is this shown as an error?

Because no CSS specifications currently define the pointer-events
property. It is defined in SVG 1.1, but the use of pointer-events in
CSS for non-SVG elements is experimental. The feature used to be part
of the CSS3 UI draft specification but, due to many open issues, has
been postponed to CSS4.

The W3C CSS Validator generally checks, in CSS3 mode, against a vague
collection of documents, consisting of CSS 2.1 and selected "CSS3
specifications", excluding many that are still at Working Draft level
- and pointer-events isn't currently defined even at WD level (or even in an Editor's Draft, as far as I can see).

http://lists.w3.org/Archives/Public/www-validator-css/2012Nov/0033.html

The excerpt above is from 2012. But it is still valid in 2017.

From MDN pointer-events:

[The pointer-events] extension to HTML elements, though present in early drafts of CSS
Basic User Interface Module Level 3, has been pushed to its level 4.

The CSS appearance property appears to be in the same situation (MDN). It's currently in Editor's Draft status and, therefore, not included in the CSS Validator.

---

A Side Note

In all sites I've developed it was always easier to validate HTML than CSS. In fact, while most of the time I can achieve full HTML validation, I don't think I've ever achieved full CSS validation.

This is because I use properties that are supported by most browsers, but are not always at validator threshold status in the standardization process.

For this reason, I don't use the CSS validator for anything more than general information. I would suggest you don't let CSS validation errors stop you from moving forward.

Focus more on the caniuse.com website to check browser support for CSS properties. You'll find that the pointer-events property, despite not being in a current CSS spec, has been supported by most major browsers for some time now.

ms-flex-positive is not a known CSS property

I believe this is a warning which you can ignore.

Someone has asked this before here: Not recognized by CSS Validator

Visual Studio CssLint Css Grid validation fails

It is now supported by the Visual Studio 2017

CSS 2.1 errors: not a known property name

Validation errors are all fine, because they are using the proper CSS 2.1 Documentation and your trying to validate CSS3 properties in a CSS 2.1 context.

What you probably want is to build your application bypassing the CSS Errors, no matter what they are, for that you can transform this "errors" into warnings using Visual Studio Options:

in The Visual Studio menu click on:

Tools > Options... and drill down Text Editor > CSS > Miscellaneous

and just make the CSS Errors to be treated as warnings

2013 version

How to change css class for the inputfield and label when validation fails?

Bind the input component to the view via binding attribute. It'll become available as an UIInput component reference in EL, so that you can use UIInput#isValid() in styleClass attribute.

<h:outputLabel for="emailInput" value="Email" 
    styleClass="#{emailInput.valid ? '' : 'error'}" />

<h:inputText id="emailInput" binding="#{emailInput}" ... 
    styleClass="#{emailInput.valid ? '' : 'error'}" />

(note that I fixed your label to be a real label; also note that you don't need to create some bean property at all as suggested by the answer of cubbuk)

Yes, this may produce quite some non-DRY boilerplate code in the view. You can abstract this away with a phase listener or a system event listener. You can also use OmniFaces <o:highlight> component which does all the job transparently. See also the live demo.

---

Related Topics