Re: Spec organizations and prioritization

On 3/22/2012 3:46 PM, Marcos Caceres wrote:
>
> On Thursday, 22 March 2012 at 19:15, Jeff Jaffe wrote:
>
>>> My money is still on 2022 :)
>>
>> While you jest; many a truth is said in jest so I need to respond.
>>
>> We as a developer community owe it to our stakeholders to get a stable
>> HTML 5 to them.
> Stability of specification is not the issue here. The spec may be rock solid today, but if no one can pass the test suite, or a test suite does not exist, then the spec is not going nowhere on the REC track. Consider also that HTML5 sits on-top two specs under development: WebIDL and DOM4. Those specs will need to progress quickly, and also require test suites, etc… then they too have dependencies, and so on.

Yes that is our challenge.

>
> Let me cite from the WHATWG FAQ:
>
> "For a spec to become a REC today, it requires two 100% complete and fully interoperable implementations, which is proven by each successfully passing literally thousands of test cases (20,000 tests for the whole spec would probably be a conservative estimate). When you consider how long it takes to write that many test cases and how long it takes to implement each feature, you’ll begin to understand why the time frame seems so long."
>
> See: http://wiki.whatwg.org/wiki/FAQ#What.27s_this_I_hear_about_2022.3F
>
> The FAQ also states that:
>
> "Now that we've moved to a more incremental model without macro-level milestones, the 2022 date is no longer relevant."
>
> Hence, WHATWG HTML, at least, is not concerned with reaching a status.
>> HTML is a living technology. So there certainly needs
>> to be continued enhancement which I assume we will call HTML.next or 5.1
>> or 6. But it would be irresponsible not to provide something until 2022.
> It would be more irresponsible to do another HTML4.01 - or to violate the W3C process to meet some arbitrary date. We have the Process Document in place for a reason (and having _at least_ two independent implementations passing tests for every feature is what makes W3C RECs of high quality).

Yes, we must not violate our process to meet some arbitrary date.

>
>> I meant browsers.
>>
>> I agree that innovation (aka differentiation, lack of standardization)
>> must proceed in parallel with standardization. I would not favor an
>> extreme position where everyone moves in lock-step with exactly the same
>> solution. The vitality of the web would be lost if there were not
>> continued experimentation and innovation.
> exactly.
>> But I don't believe it is strictly a market prioritization issue
>> either. A standard interoperable web has raised all boats for 20 years,
>> and is clearly better economically for the world than if we would have
>> evolved as walled gardens with each browser grabbing its own section of
>> the web.
> Yes, but not all features are created equal. I don't want to point fingers, but you need to ask why it took some browsers longer than others to pass Acid 3. Also, browser companies don't have unlimited money and resources (and like you suggest, the sector is extremely competitive - in the past, I led an engineering team at Opera, so I know how tough it's like to go head-to-head with Chrome, FF, and Webkit with limited resources… and kick some butt!:)… but it's challenging and sometimes quirky little things in a spec just don't find the resources to get implemented or fixed).
>
> --
> Marcos Caceres
> http://datadriven.com.au
>
>
>

Received on Thursday, 22 March 2012 20:23:15 UTC