Topic on Manual talk:Coding conventions/CSS/Archive 2

This came up on en.wp and I figured I'd write something on it. I came to the following summary of what I think the current status quo is, but it is difficult to write something that is simple and accurate at the same time :D

Browser support

Support for browsers when using CSS is dictated by the overall Browser support matrix. From this guideline several conclusions follow:

• Grade A browsers should be fully supported by the CSS delivered
• Grade C browsers have limited support and limited testing. All content should be readable, but might not always be pretty. Basic functionality of the wiki should be accessible (read, edit, history, delete, move, block and the various lists).
• Browsers older than Grade C are not supported. Consumers should not expect pages to render correctly.
• When CSS is disabled all content should be correctly machine readable.

Practices for CSS browser support

From the principles the following additional practices are followed:

• CSS supported by both Grade A and Grade C browsers is always safe to use.
• CSS supported only by Grade A browsers:
  1. Should have a fallback with CSS that is supported by Grade C browsers
  2. Should be used for features that are NOT available on Grade C browsers (JS based). However, use of `.client-nojs` might be required to provide graceful degradation of the page in this case.
• CSS supported by a subset of Grade A can be used to further enhance, but should never be required to render.
• We remove vendor prefixed statements and browser hacks for browsers that can't realistically receive html any longer.
• Avoid depending on vendor prefixed CSS for the lowest supported browsers. Vendor prefixes are for experimental features and many confusing browser bugs can hide in this experimental fase of support. For your lowest supported browsers you want something that is predictable, especially because older browsers are harder to test with. Use vendor prefixed CSS to progressively enhance Grade A, but not to provide a baseline of support.

Feedback welcome: ping @Krinkle, @Volker E. (WMF), @Jdlrobson ?

Overall this sounds great to me. I think a practical application of Compatibility aimed at implementors has long been needed.

When CSS is disabled all content should be correctly machine readable.

I understand the intention here, but I think this might be redundant and seems easily misinterpreted. For one, I think it could be misinterpreted to mean that Grade C browser support is limited to only issues with CSS, whereas TLS, HTTP, and HTML are highly relevant there as well in terms of affecting what can and can't read. (As well as e.g. graceful skipping of the JS payload, etc.) As such, this sentence, I think, is not meant to say anything about unsupported browsers being able to consume the HTML, as those unsupported browsers may be unable to even connect to the web server at all, or may encounter HTML format that will break the layout in some way.

I also don't think we test or support manually turning off in an otherwise supported Grade A or C browser (maybe with JS still turned on?). There may be other conventions we follow that allow this to somewhat work currently as happy side-effect, but any issues specific to it I would decline without second thought.

Perhaps underlying your point is that we should strive use of semantic, accessible, and portable HTML. Thus in accordance with the Architecture Principles, for our content to be easy to re-use, archive, and render offline or standalone. Thinking about Kiwix, IPFS, Apple Dictionary Lookup, Internet Archive, HTML dumps, etc. It might also be worth to consider at least two text-based browsers in the Grade C matrix for longevity, along with a new code conventions page for HTML?