Re: Rough first draft of Level 0

On Wednesday, 28 March 2012 at 15:57, Robin Berjon wrote:

> Dear all,
>  
> please find the (very) rough draft of "Core Mobile Web Platform — Level 0" at the following URL:
>  
> http://coremob.github.com/level-0/
Few additional notes and requests for clarification:

----
The documents says that a UA  MUST support:

"XHTML served as application/xhtml+xml"  

Yes, Opera's MAMA report states that:  

"Of the 3,509,180 URLs that MAMA analyzed, the vast majority (~99.9%) used a "text/html" MIME type (see full frequency table). "text/plain" and "application/xhtml+xml" types also had some occasional representation in the set (~1,000 cases each)." http://dev.opera.com/articles/view/mama-http-headers/

XHTML is statistically insignificant, so why bother mandating its support as a MUST?   

----
The document says "Codecs are evil. Thoughts?"  

Codecs are not evil. Codecs that are employed as a tool to degrade copyright law by misguided patent holders and governments (plus a severely broken patent system) is what constitutes "evil"… or better put "an embarrassment". As Thomas Jefferson put it:  

"Considering the exclusive right to invention as given not of natural right, but for the benefit of society, I know well the of drawing a line between the difficulty things which are worth to the public the embarrassment of an exclusive patent, and those which are not." [1] page 21.   

So, please don't confuse things. Maybe just note that "some codecs are patent-encumbered and may require prohibitive payment of royalties to certain parties. Thoughts?". It is within the patent's holders' right to demand licensing feeds - a necessary and legally valid evil for the life of the patent.  

----
The document says:
"User agents must support ECMAScript ed3 [ECMA-262] in full, plus all the parts from ed5 that can be shimmed, including native JSON."

This is an aspirational document/wish-list (probably shouldn't even use RFC2119 language), just say MUST support ECMAScript5. It's not really different from mandating user agents MUST support specs that are in their early stages of development, like Selectors API Level 2 (which is a FPWD).

----

I'll note that the WAC 2.0 Core spec contained a similar wish list to the one in this document - along with a long history lesson as to why each thing must be supported. In the end, I ended up collapsing it into a list of things into an statement of fact:

http://specs.wacapps.net/core/index.html#widget-runtime  

(It didn't really help - as it is impossible to test for conformance/support of so many specs)

I can't speak for browser vendors, but having worked for one for 3 years, browser vendors already know all this stuff (and I can feel them shaking their heads again and saying "oh yay, another 'industry' wish list… put it there, in the bin, with the others."). Browsers process and render billions of web pages every day - and browser vendors talk to web developers every day - there is nothing really new in this document to get excited about or that they don't already know.  

I think for this effort to have any significant impact, then it should focus on the use cases (i.e., what do we want to build that we can't do today (but we can do on iOS and Android)?) and where are the gaps in interoperability in the platform that is holding back real progress. Long lists of MUST, MUST, MUST, don't strike me as particularly helpful (and it's just a rinse and repeat of every other industry wish list that has been provided to browser vendors since the beginning of time). This is where I think the -apple-* stuff is of value, in the sense that "oh look at this awesome stuff we can do with Apple's proprietary stuff, which is completely missing from the Web Platform as defined by the W3C/WHATWG".  

If you want to do this right, we need some real apps that show where browsers fall on their asses: show where it is slow and painful and just can't compete with iOS and Android. If you can do that, then you have something new and of value that no other effort has been able to do.  

Kind regards,
Marcos  

[1] http://thepublicdomain.org/thepublicdomain1.pdf

--  
Marcos Caceres
http://datadriven.com.au

Received on Sunday, 1 April 2012 13:42:27 UTC