Adding to our Docs pages

• Status: Completed; Available on all documentation pages
• See in action: Take a look at all example pages listed in #Templates changed
• Next steps: TBD, see #TODO

Summary

Which MediaWiki templates are involved to display the compatibility tables data.

What has been done

For instructions on how to set in place, refer to Template:Compatibility at How to use.

Templates changed

Each of them might have had a {{Compatibility_Form_Section}} (at least in the Form) and we removed it. Instead we made sure the Template had the new {{Compatibility}} template in both Form and Template … templates.

NOTE: the topic= argument is optional (e.g. {{Compatibility}}), refer to Template:Compatibility documentation, it should describe how to use more in depth.

• CSS_Property, in Template, Form

  • category: Category:CSS_Properties
  • topic page: css/properties
  • example pages: css/properties/align-content, css/properties/border-radius

• CSS_Selector, in Template, Form

  • category: Category:CSS_Selectors
  • topic page:
  • example pages: css/selectors/attributes/hyphen, css/selectors/combinators/general_sibling, css/selectors/attributes/existence

• CSS_Function, in Template, Form

  • category: Category:CSS_Functions
  • topic page:
  • example pages: css/functions/brightness, css/functions

• CSS_At_Rule, in Template, Form

  • category: Category:CSS_At_Rules
  • topic page:
  • example pages: css/atrules/@page, css/atrules/@import

• CSS_Media_Feature, using topic="css", in Template, Form

  • category: Category CSS_Media_Feature
  • topic page:
  • example pages: css/media_queries/device-width, css/media_queries/color, css/media_queries/height

• API_Object_Method, using topic="webapi", in Form, Template

  • category: Category:API_Object_Methods
  • topic page:
  • example pages: apis/css-regions/Region/getComputedRegionStyle, dom/Document/createTreeWalker, apis/web-messaging/MessagePort/close, apis/file/FileReader/abort

• API_Object, using topic="webapi", in Form, Template

  • category: Category:API_Objects
  • topic page:
  • example pages: apis/css-regions/Region, dom/EventTarget, dom/Error

• API_Object_Property, using topic="webapi", in Form, Template

  • category: Category:API_Object_Properties
  • topic page:
  • example pages: apis/css-regions/Region/regionOverset, apis/webaudio/AudioBufferSourceNode/buffer, dom/TextRange/boundingWidth

• JS_Basic, in JS_Topics template and JavaScript global JS_Basic form template

  • category: Category:JS_Method, Category:JS_Object, Category:JS_Function, Category:JS_Property
  • topic page: javascript
  • example pages: javascript/Date/getSeconds, javascript/Array, javascript/Uint16Array/set, javascript/unescape

• Markup_Structure, in Markup_Structure template, Markup_Structure form template

  • category: Category:Markup_Structures
  • example pages: html/entities

• Markup Element, in Form, Template

  • category: Category:Markup_Elements
  • topic page: svg/elements, html/elements, mathml/elements
  • example pages: Meta:HTML/Elements/div, html/elements/div, html/elements/option, html/elements/noscript, svg/elements/feFuncB, svg/elements/a, mathml/elements/merror, mathml/elements/mrow

• Markup_Attribute, in Form, Template

  • category: Category:Markup_Attributes
  • topic page: svg/attributes, html/attributes, mathml/attributes
  • example pages: html/attributes/autocomplete, html/attributes/altdom/alt, html/attributes/colSpan, html/attributes/placeholder, svg/attributes/baseline-shift, svg/attributes/fill-rule

Templates that has been emptied

For depreciation.

The Compatibility_Section template has been purposefully muted so we can add the compat data only where we want.

See list of pages using Template:Compatibility_Section in an hardcoded fashion.

The Template:Compatibility_Form_Section should be removed from all templates as they are being replaced with the new Compatibility template

TODO

Next steps

Rough estimate of tasks to do:

• Document how to add data in our compatibility-data GitHub project
• Ensure manual JSON input is valid and doesn’t break, tool to minify the file (for deployment)
• Automate deployment on Merge to master
• Clear appropriate caches (Varnish, Memcached, Redis, et al.)

Reminders

• CSS_Media_Feature, in Template, Form, has feature hardcoded at “media-queries”
• In all javascript pages, the Compatibility inclusion is made through Template:JS_Topics and should be moved somewhere that is used only within the new JavaScript docs pages.
• Page css/media_queries/device-height has more than one form , listed from css/mediaqueries

Former Compatibility table template

Should we mute them from the template, or their call? Decision: remove from page, or empty.

• Template:Compatibility_Section MUTED (diff)
• Template:Compatibility_Table MUTED (diff)
• Template:Compatibility_Form_Section REMOVED from Form Templates
• Template:Compat_Unknown

Where they *might not* make sense to have a Compatibility table?

Should we?

• In guides/advanced_selectors_guide, via Form:Guide, category Category:Guides
• In tutorials/inheritance_and_cascade, via Form:Tutorial, category Category:Tutorials

Things to improve

• CSS_Selector: Form, Template, need improvements in template+form
• CSS_Function: Form, Template, need improvements in template+form
• CSS_Media_Feature: Form, Template, need improvements in template+form
• CSS_At_Rule: Form, Template, need improvements in template+form
• In html/apis, the APIs subsection is hardcoded and doesn’t list what we have. Should we just move that to JavaScript? (NOTE: I didn’t added compatibility)
• In html/entities, its the *only* one using Markup_Structure template and Markup_Structure form template. Refactor html/entities as basic page instead? (NOTE: I didn’t added compatibility)
• In html/data_types, it feels empty. Should we really keep that section, or merge with Category:Data_Type ? (NOTE: I didn’t added compatibility)
• In svg/attributes, listing is hardcoded, but could use SMW
• Is it relevant that svg/attributes/baseline-shift is listed in DOM?
• Do we really want svg/methods, svg/events and svg/properties are (mostly) empty, do we really want to list stuff that is related to the DOM on SVG elements specifically. Should we just merge them instead?
• In mathml, we have mathml/elements, but no mathml/attributes at all.
• See if we can get good data from the pages that has a “Compatibility Section” along with data

Pastebin

When changing page for this project

 Installing Compatibility tables, see [[WPD/Projects/CompaTables/Adding_to_our_content]]

Listing pages based on URL prefix

Like it is done at concepts/Internet_and_Web

 {{Special:PrefixIndex/concepts/Internet_and_Web/|hideredirects=1|stripprefix=1}}

Listing index based on SMW properties

Like it is done at html

  {{Page_Index_Listing
  |query = [[Category:HTML]][[Category:Markup Attributes]][[Path::~html/*]]
  [[Standardization Status::W3C Recommendation||W3C Proposed Recommendation||W3C Candidate Recommendation]]
  }}