No More Posting New Topics!

If you have a question or an issue, please start a thread in our Github Discussions Forum.
This forum is closed for new threads/ topics.

Navigation

    Quasar Framework

    • Login
    • Search
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Groups
    • Search

    Thoughts about w3c validator and quasar

    Framework
    2
    2
    174
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • T
      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 1 Reply Last reply Reply Quote 0
      • qyloxe
        qyloxe @tobiassodergren 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.

        1 Reply Last reply Reply Quote 1
        • First post
          Last post