A Few Words About Our HTML5 Work

 

 

 

 

We experienced one of those ‘ouch’ moments last week. A misunderstanding about our intent behind our support of HTML5, coupled with less than optimal communication, led to the publishing of a story alleging Maxthon tried to game HTML5test.com results. As is the case with a lot of web stories these days this one was long on assumptions and short on verification. A few well-meaning media types recommended we say nothing publicly — their logic was  we were right and that the story had no ‘legs’ beyond a small group of browser industry aficionados. That didn’t sit right with us for a couple of reasons: (1) we did nothing wrong and have nothing to hide; and (2) we’ve always had a completely open conversation with the global family of Maxthon fans about our intentions as a company and desire to build great products — and we aren’t about to change.

The absolute truth is Maxthon has not, nor will it ever attempt to ‘scam the score’ in HTML5test.com or any other third party web standards or browser-performance measure. Let’s not throw the baby out with the bathwater.  The Maxthon 3 engineering team has implemented and successfully tested many parts of the ever-evolving HTML5 standard. This first-ever accusation about scamming the score is a serious allegation that merits a response.

Specifically, some have cited our work implementing Web GL, ‘Get user media’ and ‘Subtitles.’  We looked into the work behind that, and here’s what we found: We pushed out code in a build of Mx3 that wasn’t ready to be pushed out. Plain and simple: That code should not have been released. It wasn’t complete.

Unfortunately, as it was implemented, it triggered a positive response from HTML5test.com. Hence the allegation of ‘scamming.’ That was a mistake; and we will fix the code within the week. It was not some effort to manipulate our score on HTML5test.com. It was a result of a development process that can be improved.

Engineers approach their work differently. Some start with an architectural idea of how they want to implement something, and they code toward that end vision. Others jump in, start coding and test until their code works. In this situation, one of our Mx3 engineers was coding, testing against the HTML5test.com and tweaking until it appeared to him that it worked. To put it another way, this was an engineer-error that should have been caught in QA.

Going forward, we plan to build a deeper dialogue and partnership with other members of the HTML5 community, as ultimately, we all share the same goal of helping to drive a new standard of web and application development that will spur greater innovation and products.  This is why Maxthon is spending time on HTML5.  The more we push HTML5 support and development now, the sooner everyone can realize more of the promises of that standard. That is a worthwhile goal to support at any level.

That’s it. No grand scam here. Just some code that should have been baked a bit longer.  HTML5 is a floating point that is continuously changing and morphing, and browser- and test-makers alike are stakeholders in helping shape it. We’ll continue to do our part as the standard evolves and wish to extend our thanks to the larger community for its contributions, too. When it comes to HTML5, we’re all on the same team.

Thanks and happy surfing!

7 Comments

  1. ntzphyr says:

    Thanx for the clarification. Perhaps that article was also pushed out a bit prematurely, surely the author could first have reached out to the devs before publishing it. All too common on the web where each persons opinion is regarded as fact.

  2. bricky149 says:

    Thank you for this response.

    Coding can be an annoyance as once it works, you believe that it will continue to work the way you intend. I’m not a coder myself (but would like to be) but I can understand the reasoning given here.

    The engineers do an excellent job, as always, but this one slipped the net and got caught with a negative response.

    Anyway, I hope to see at least some of the issues resolved in the near-future.

  3. [...] attributes too quickly and that, as a result, caused quite a backlash. Here is what they had to say: Specifically, some have cited our work implementing Web GL, ‘Get user media’ and [...]

  4. Paul Irish says:

    Feature detection false positives lead to broken sites, not just bad scores.
    For every feature that is passing and failing in Modernizr and HTML5 Test, Maxthon QA should verify that it does indeed match the feature status. I’ll help on the Modernizr side, gladly :)

  5. [...] the browser scored points in tests for technologies that it did not support, and while Maxthon was quick to react and blame early code for that which should have made it into the final version of the browser, the [...]

  6. [...] the browser scored points in tests for technologies that it did not support, and while Maxthon was quick to react and blame early code for that which should have made it into the final version of the browser, the [...]

  7. І ԁo trust аll the іԁeas you’ve introduced for your post. They are really convincing and will certainly work. Nonetheless, the posts are very brief for beginners. May just you please lengthen them a bit from next time? Thanks for the post.

Leave a comment