Propose recommendations, not a specification
#2

Comments

The current draft[1] is written and intended as a specification, while I don't think this is the right format for your intented goals per the charter proposed on March 6th.

Specifications, especially when on the standards track (which is not an immediate option for community groups), mandate behavior of conforming entities, in this case user agents. The crux here lies in the fact that user agents are by no means required to adhere to certain specifications. Since there are some highly controversial items listed in the current draft, such as proprietary vendor-specific features ("apple-" prefixed meta options), certain proprietary video codecs and MUST requirements on many other specifications in various stages of maturity, I think you should propose recommendations instead.

Creating a specification is a nice goal, but you should also take feasibility into account. In my opinion, implementation of features in rendering engines should be prioritized based on usefulness and end-user demand. One way to convince them would be to provide use-cases and potentially test-suites for each of these features, leading to sane and interoperable implementations. Having a MUST requirement on the "apple-touch-icon-precomposed" meta option without a reference neither explains its purpose, nor shares the intended behavior of semantics.

Instead, consider creating a requirements document such as the Speech Incubator Group has done[2], potentially with the addition of writing conformance tests for several features.

This is not a final document, it is a draft. Some of the issues you mention would normally be solved in the process of evolving it. So I wouldn't focus on those if your intent is to make a broader point about the approach taken by the document.

I don't really understand your specification versus recommendation distinction — W3C Recommendations tend to be specifications, even though this is not a Rec-track document. I also don't really understand how a requirements document with conformance tests is not a specification. If you can conform to it — something which is a clearly a goal here — then it's a specification.

The list of features in the document is in fact based on usefulness and end-user demand. Where it does not match that, it will evolve to do so.

The documents we produce in the CG will only be useful if they are implemented. So I don't really see the value in softening the requirements they place on UAs.

Since I don't understand the change you're suggesting I'm not closing this issue, but please indicate the sort of concrete change you are suggesting so that we can make that decision.

Robin, my main concern is exactly echoed by your remark: "documents produced by the CG are only useful if they are implemented". This is only true when the group is producing a specification (which it currently is). What exactly do you believe the incentive for vendors to be, making them implement this specification? Would a vendor change their mind on supporting H.264 or Touch Events/CSS3 UI because it's listed in the document?

This specification says "this must be implemented", while taking a recommendation-based approach would mean creating a document saying "this should be implemented, and this is why", thinking much more in terms of use-cases. See the document produced by the Speech Incubator Group I linked to as an example of this. Advocating development and interoperability of features important for the mobile Web should be done by convincing vendors about its importance.

I suggest:

Drop all the MUST requirements, make them SHOULD. This is already quite fierce per RFC 2119.

Remove proprietary codecs from at least Level 0. is capable of supporting multiple codecs and this is considered a good practice. The codec discussion is out of scope for this work.

Instead of just only providing a list of reference to other specifications, provide mobile-specific use-cases as to why they are important.

Yes, the goal is that a vendor would prioritise their implementation efforts (or, in a number of cases, porting and/or feature-activation efforts) based on this document. If you look at the list of participants in the CG, you will see that we do have quite a fair number of vendors involved — and more are in the process of joining.

To take your points one by one:

• I don't see the value in weakening the MUSTs. From the developers' point of view it's simple: either it's there and usable, or it's not. If it's not, even if it's for the sort of good reasons that RFC2119 allows for SHOULDs, it's useless. We don't want useless requirements in the list, so anything that would justifiably be a SHOULD probably ought to be removed plain and simple.

• No one likes proprietary codecs, but if there is only one with universal support (or close enough) and no vendor objects to it, there is no reason not to list it — quite the contrary, real-world developers benefit from being able to use a single format, no matter how (justifiably) dislikable it may be. Please see the quick exchange on the mailing list for that.

• As far as I'm concerned, producing use cases for every single item in the list is just make-work, and does not make it any more convincing. I really don't see what we gain by listing a use case for child selectors, and I think we would be positively insulting everyone's intelligence by listing use cases for Geolocation or Touch events. Not only would it require a fair amount of time (a proper UC document of this scope would require at least a year's work), but it would dilute the document. As part of the feedback process, given that we have participation from vendors in the first place (and that they have very strong incitations to express their point of view as they will be under a lot of pressure to support what is in this document), if one or another of the requirements is not clearly motivated then we will certainly expand on it and document its use cases. But I expect that to be required only for a minority of the features, if any at all. If you have any such doubts, your feedback would be very welcome.

I am familiar with the Speech XG's report, and it is a good document, but honestly I think that it is mostly coming from a different place. Speech on the Web is relatively new, and still rather exploratory in its exact form. How and where it may apply is not something that can be seen as obvious to implementers. That's a very different starting point from what we're working on. People know about rounded corners and viewports. What the industry is asking for is essentially a decent shopping list on which to prioritise resources.

Agreed, GH issues are mostly for more nitty gritty spec-editing issues. I'm closing the issue here but very much invite your comments to the list.

@beverloo How about you simply join the CoreMob CG? It's a very open process and the mailing list really is the right place for this discussion since it will then be in plain sight of all the participants. See http://www.w3.org/community/coremob/ and don't hesitate to ping @tobie or I with any questions you may have.