W3C home > Mailing lists > Public > public-coremob@w3.org > April 2012

Re: Rough first draft of Level 0

From: Robin Berjon <robin@berjon.com>
Date: Thu, 12 Apr 2012 15:33:32 +0200
Cc: public-coremob@w3.org
Message-Id: <55489705-F8E9-4D4B-92DD-2BC534771100@berjon.com>
To: Marcos Caceres <w3c@marcosc.com>
On Apr 1, 2012, at 15:41 , Marcos Caceres wrote:
> ----
> 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?   

We could drop it, I don't much care either way. Pull request welcome.

> ----
> 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.  

I'm not confusing things, but then again I haven't had the honour of having Thomas Jefferson walk up to me at a Web conference to ask how he could ship his damn video in a way that works.

This is an issue. It's colloquial. Anyone in this community who hasn't spent the past ten years sleeping under a rock know what is meant by "codecs are evil". It avoids restating the entire discussion, and yet everyone's on the same page.

And if there is in fact someone here who's been sleeping under a rock for the past ten years, they must be wondering why ActiveX and Flash and LASeR haven't taken everything over! I wonder if it may have something to do with the fact that we went ahead to develop JS APIs even though everyone was saying that it would destroy the mobile Web because we weren't taking then-feature phones into account.

> ----
> 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),

Because: [..............]
Proposed alternative: [..................]

> 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).

We do plan to refine requirements on specs that only have partial support. It's probably the hardest part.

> 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.").

Well, it seems that despite knowing these things we still don't have alignment. Maybe there genuinely is a problem?

Could the problem be at least in part that people involved in these efforts prefer to provide all manner of philosophical high level metaphysical arguments over actually producing concrete change proposals? Maybe if we dug into the details instead of just talking about them we'd find things that some of us don't know about?

> 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.  

That's how we get vendors shipping mobile browsers that support WebGL but can't play sound with less than a 1sec latency. If anyone's spoken to developers before shipping the current mobile stack that we have, they're not developers from a species I've encountered.

> 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.

It's less easy to find gaps if you don't know between what the gaps are.

> 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.

Which in turn means that we need to know what to test. It *can* be a simple shopping list. But it needs a shopping list. Otherwise we'll end up with WebGL and ponies.

Robin Berjon - http://berjon.com/ - @robinberjon
Received on Thursday, 12 April 2012 13:34:01 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:05:45 UTC