Re: Food for thought (resurfacing)

+1 to what Marcos said. The important thing for organisations about Chrome
Frame was that it let them *out* of the world where their renderers were
stuck in time and weren't auto-updating.

So yes, TAG members and (some) browser vendors have thought about this
problem at length and the current consensus is that auto-updating runtimes
and real competition deliver much of the value with fewer downsides. We're
not to a fully auto-updating world yet, but are closer than ever before and
the trend lines are good.
On 24 Jul 2014 13:08, "Marcos Caceres" <w3c@marcosc.com> wrote:

>
> On July 24, 2014 at 5:13:45 PM, Marc Fawzi (marc.fawzi@gmail.com) wrote:
> > 90% of our bug reports are browser specific, and I just started this job,
> > so I'm working with a lot of sub optimal decisions and scenarios, until
> we
> > can get ahead of the defect backlog, which again is 90% cross browser
> > issues.
>
> It might be worth looking to see if it's really a Web platform problem, or
> development/developer problem, or a user problem (out of date browsers).
> There is a fairly stable and interoperable base across browsers, and if
> your cross-browser bugs are that significant it might be that the
> developers at your company are indeed using proprietary features/quirks
> rather than using core Web platform features. Otherwise, it might be that a
> subset of your users are stuck on some old browser version and upgrading
> them might fix the cross-browser issues.
>
> Calling for the ability to hot-swap engines doesn't address the core
> problem: interoperability. It actually makes things worst, because it no
> only means being able to hot-swap the engine, but probably target a
> particular version of that engine (e.g., IE7). Imagine now how many
> different engines would need to be bundled into a hot-swap browser. You
> would have - i.e., 6,7,8,9,10,11,12 + then every version of Gecko + every
> version of WebKit + every version of Blink. And it means supporting those
> versions and their bugs forever (which, through their quirks, expose
> security issues). That is, of course, unrealistic (ask Microsoft how that
> strategy worked out for them, as they tried to do this a few times over the
> years with just IE).
>
> No software is stable, and has to be maintained (this applies to both
> websites and browsers, obviously). On the Web, we (browser folks) try to
> support legacy content as much as possible where it makes sense (e.g.,
> silly tags like <blink>) - but we also often have to fix and correct issues
> to benefit/protect users, which sometimes breaks corporate apps, etc. It's
> why we have things like Chrome Canary and Firefox Nightly + beta versions
> of each browser, which allows folks that maintain applications to check
> that their apps won't break with each new release + gives devs time to fix
> any issues and test out new features. This buys developers on the ground
> about 3 months to make sure their apps will work well before users get
> their browser's automatically updated.
>
> So, my recommendations would be to review the development practices inside
> your organization + try to understand which browsers users are using (e.g.,
> some users might be stuck on some old browser version - so actually just
> updating those users to a more modern browser would address the cross
> browser bugs without the need to fix the web application - which may be
> actually be fine).
>
> HTH!
>
>
>
>
>