Thoughts about w3c validator and quasar
tobiassodergren last edited by tobiassodergren
I’m using the html-validate (npm) framework to validate the resulting HTML from the quasar framework. By default it contains rules dictated by w3, such as the button element, which says that only phrasing (and no interactive) content may be used.
The quasar framework generates <div> elements inside QBtn, which violates the specification.
What are the thougts about the w3 specification and the components that builds up the quasar framework?
Here’s a link to the online w3c validator.
qyloxe last edited by
@tobiassodergren button ELEMENT is semantically simple, let’s say it’s a lawnmower. Q-btn COMPONENT is semantically complex, lets say it’s industrial harvester. Results of formal validation are important only in the context of compatible semantics. Frameworks and libraries (quasar, vue, react) are using formal html elements as a platform for optimally compiled htmls code with intention of optimal implementation of semantically complex behaviours and higher level abstractions. For example you can implement submenu with q-btn or ripple or debounce (composition, visualisation, behaviour).
There is another question, where formal validation would be OK in the context of frameworks and libraries? The answer is In user generated HTML code. For example, you can build optimized html app for CMS in Quasar, which would not be a valid formal html, but the content generated by user in this CMS, should be a formally valid html.
This is one way of thinking. Another way is the “island way”. When you have isolated generated code (from quasar, react) formal validation gives almost nothing. Such validation has only meaning, when this code is exchanged with other platforms. In this concept, the code formal validity is a protocol of interaction between platforms. In example, it could be useful for Quasar, when one would integrate generated quasar html code with cordova or electron platform. BUT it is integrated and yet formal validation is not so useful. Why? Because even in this integration scenario, the result is enginered as a single platform. This exactly is IMHO quite ingenious. Your question is very thought provoking because it shows what a great job @rstoenescu had done and how enlightening is his vision.