# 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 |
|---------------------------------------------------------------------------------------------------------------|-------------------------------|-------------------------------------------------------------------------------|
| `