Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>I am really having a hard time reconciling this idea after a serious thought. Assuming such a framework exists, it would only be as good as the current implementation status in any one browser. Let's say there are only two browsers and the HTML5 implementation status looks like this:</p> <pre><code>Browser | Feature X | Feature Y ------------------------------- A | ✔ | ✘ B | ✘ | ✔ </code></pre> <p>Then your most bleeding-edge HTML5 application can either have X or Y, but not both. If the features your application needs are available on the latest versions of most major browsers, then that feature is not bleeding-edge. It would have been bleeding-edge a year ago.</p> <p>So depending on the project scope and goals, the most B-E application that can be written will conform to a single browser (the one that offers all/most of the features needed for your application).</p> <p>If you're writing for a lone browser and do not want to fix any implementations deviations from the spec (as the spec is not yet finalized), then it's basically writing code for that chosen browser regardless of any specs.</p> <p>If that is the case, then a framework is basically extra baggage to carry around. Instead, shortcuts for most commonly used APIs and other general simplifications would be the best way to go.</p> <p>That said, if you're goal is to have a framework that vastly simplifies the HTML5 APIs oblivious of where the browsers stand today, then I would love to contribute towards that project.</p>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
    1. COIf we go back from A&B to real world, we can see that we've got many more "major browsers": IE6, IE7, IE8, IE9 soon, Webkit-based Chrome and Safari, Mozilla Firefox (taking only major milestones) 2, 3, 3.6, 3.7. A set I call "modern browsers" consisting of Firefox 3.6+, Chrome 4+, Safari 4+, and Opera 10 very close have got significant set of common (or slightly differently implemented) features which even IE9 is still far away from, not to say about IE 7 and 6 and Firefox 2, for example.
      singulars
    2. COAnd as far as I see, it is nod hard today to convince a user to consider using a "modern browser" of his choice if he is specifically interested in our application features. So supporting legacy browsers, I think, can be really needed only on public mass-oriented traffic-driven websites and very large unflexible enterprises, while non-profit community (especially those made for tech enthusiasts) projects and enterprise intranets can enjoy all the goodness of modern browsers.
      singulars
    3. COI totally agree, and it's always good to start with that mindset without the fear of losing out users, especially for niche websites where the audience is open to the idea of installing something on their computer and knows how to do that. But even in niche sites, if users get accustomed to viewing your site on IE7, and you later drop the bomb on it, they are going to be pissed off because that's just the nature of things - nobody likes change. Instead, if users are constantly informed that support for a particular browser will be dropped if the browser starts going out of line.
      singulars
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload