What should EPUBCheck do about CSS validation?

[rdeltour]

Currently (v4.1.0), EPUBCheck has limited support for CSS validation, for instance:

• it checks some syntaxic rules
• it inspects some @-rules, notably to check which font resources are used
• it inspects some properties, for instance to verify that fixed positioning is not used in reflowable EPUBs.

but:

• it does not fully validate conformance to the EPUB CSS profile (e.g. it does not check the -epub prefixed properties and values
• it does not perform more general CSS validation, nor does it implement a fully conforming CSS parser

The EPUBCheck team would like some guidance on what to do with CSS validation in future versions.

The options include (non-exhaustively):

• keeping existing checks (updated to EPUB 3.2 of course) without implementing new features
• fully implement validation of the the EPUB CSS profile
• implement a fully-conforming CSS parser
• totally remove the CSS-checking code
• hide CSS-checking behind a switch

The EPUBCheck team currently envisions to keep the existing changes, update them to 3.2 rules, and also add an on/off switch to be able to enable/disable the CSS checks.

Thoughts?

[rdeltour]

Note: this issue was mentioned in w3c/publ-epub-revision#1185

@mattgarrish said:

The question was whether it should be silent by default about CSS or whether it should be something that is turned off. (For the record, I prefer the former, but it's something we need to get the CG to agree on.)

@dauwhe said:

I think we have some sort of consensus that EPUB is not in the business of validating CSS. But there is a question of whether EPUBCheck should optionally report on things that are likely to be problematic. Would it be appropriate to (optionally?) provide info that position:fixed is used, or the direction property? And how would these things be expressed in the spec so that it would be appropriate for EPUBCheck to have an opinion?

[dauwhe]

Some random thoughts:

1. EPUBCheck should (non-controversially) continue to examine CSS files for @font-face rules. Does it check for decorative images that are applied with the content property, just to make sure the images are there and declared in the manifest?

2. Is there value in checking the formal structure of a CSS file? I know that some user agents will abort parsing a stylesheet after finding mismatched braces, uncommented text outside of declarations, etc. I'd need to investigate more to see if this is possible, and if CSS syntax actually defines this kind of stuff.

3. There are some problematic CSS features that we've mentioned in previous versions of EPUB — position: fixed, direction, etc. In fact, some of the Web Platform Tests fail EPUBCheck because some i18n tests use direction. I see some value in issuing "info" level messages from EPUBCheck, but I don't think these deserve errors or warnings.

4. I absolutely don't think we should do anything extreme, like checking every CSS declaration and property against the CSS Snapshot. As I've commented elsewhere, CSS has well-defined error handling, is designed to be future-compatible, and we can't predict what clever things the next generation of EPUBFolks will do with CSS. :)

5. I'm neutral about a switch. Haven't thought about it enough yet.

[rdeltour]

1. Does it check for decorative images that are applied with the content property, just to make sure the images are there and declared in the manifest?

I don't think it does.

2. Is there value in checking the formal structure of a CSS file?

As long as we want to inspect anything in the CSS (@font-face included), then I think we need a parser that follows CSS Syntax (at least partially).

3. There are some problematic CSS features (…) I see some value in issuing "info" level messages from EPUBCheck, but I don't think these deserve errors or warnings.

👍. Note btw that it is possible to provide overridden severity levels for EPUBCheck checks, so if anyone want to make that a warning or error in their production workflow they can.

4. I absolutely don't think we should do anything extreme, like checking every CSS declaration and property against the CSS Snapshot

👍. The big question IMO is whether we should better implement CSS Syntax, or instead ignore CSS validation altogether (as we do for JS, btw).

[dauwhe]

The big question IMO is whether we should better implement CSS Syntax, or instead ignore CSS validation altogether (as we do for JS, btw).

I think it would be tremendously helpful for users.

EPUB creators live in a world without dev tools, which is horrifying. Anything that can be done to help them understand what is going wrong in their books would be valuable.

(although I don't have any information on how reading systems respond to malformed stylesheets, or if the community sees this as useful. Might be a useful discussion to have in the CG sometime soon.)

[dauwhe]

I learn something every day! EPUBCheck is finding at least basic syntax errors in both internal and external stylesheets:

body { color: red; }
}
p { color: green; }

Excellent!

[rdeltour]

I learn something every day! EPUBCheck is finding at least basic syntax errors in both internal and external stylesheets

Yes, EPUBCheck does include its own CSS parser (hat tip to Markus Gylling!). It's just that it's not fully compliant to CSS Syntax… (although I don't remember the details of the known false positives or false negatives).

[jenstroeger]

My 2￠ on this discussion and based on my issue https://github.com/w3c/epubcheck/issues/935#issuecomment-467590671.

While I do see the reasoning behind @dauwhe’s points above, I also see epubcheck as a tool for active development, not just passive post-process validation.

As such I am very much interested in errors in a CSS file, even though a renderer has well-defined behavior to tolerate them. It is certainly not my intent to ship an invalid CSS file, so if a typo snuck in then I want to know about it. The renderer/e-reader will hide it from me well, and that’s certainly no use for me as the developer. (As pointed out in my original comment, W3C’s CSS validator does catch syntax errors so folks can fix them.)

[JayPanoz]

although I don't have any information on how reading systems respond to malformed stylesheets

I mean, even well-formed stylesheets will become an issue as time passes and the CSS snapshot is updated accordingly.

Some older SDKs – I won’t name but hey it’s still used by a lot of devices/apps – will ignore the entire stylesheet if they can’t parse a value e.g.

font-family: var(--ff);

or

width: calc(100% - 20px);

So I wouldn’t personally expect much from epubcheck or the W3C’s CSS validator in the longer term. OTOH, getting syntax errors is a nice-to-have because sometimes you’re in a rush and authoring can become sloppy, etc.

But I’m a lot more worried about the adoption of new (and generally more robust/easier to author) CSS modules in EPUB-Land because even well-formed stylesheets can be an issue.

[llemeurfr]

Again, this would be eased if there was a notion of EPUB reading system "level" or "profile", a standardized classification of RS'es in the field.

RS relying on web rendering engines will evolve in a natural way (because they use the OS native engine of the device or because new versions can easily be released each year, with a new version of the rendering engine). RS using a "home made" rendering engine are stuck with a given snapshot of CSS 2 / 3.