# Tesseract Web ## Rationale - Every component library makes their own conventions of component organization - Graceful degradation through backwards compatibility with HTML controls is not the main focus - In return, aspects such as accessibility may suffer since HTML controls are generally compliant to accessibility considerations suggested by approved standards - Emerging Web applications are at risk of deviating through said standards which can fragment the Web platform implementation - Hopefully we can inspire component development through the component organization we are proposing; everyone can have their own implementations - cf. Authoring (publishing interfaces) vs Dependency (coercing consumers to adapt to concrete implementations) ## Ground Rules - Each component is an enhanced version of an HTML control (see [HTML enhancement](#html-enhancement)) - Each component should only do one thing and one thing only in terms of purpose and appearance (contrast to HTML's `` where its function is overloaded depending on its `type` attribute) - Each component has decoupled styling, wherein each styling has their own API - This styling API is then made cross-framework compatible - This styling API allows use of dynamic styles (which then requires CSS-in-JS way of application) ## HTML enhancement | HTML element | Tesseract counterpart | Remarks | |----------------------------------------------------------------------------|-------------------------------|-----------------------------------------------------------------------| | `