[whatwg] Provding Better Tools (was: Re: 184.108.40.206: trailing slash and atheism)
mikeschinkel at gmail.com
Tue Dec 5 03:30:15 PST 2006
Henri Sivonen wrote:
>> Are you saying that you don't believe the ecosystems around those
languages to be capable of producing HTML5 parser libraries or are you
saying that programmers wouldn't use the libraries even if the ecosystems
The biggest problem (80%) is they won't use them unless they are called out
by the specification because a.) they don't know they exist, b.) they don't
know which one to choose, c.) programmers want to write them theirselves,
d.) they have a policy of not using external code, or e.) they have a policy
not to use anything but commerical code and they haven't approved budget for
it. I *know* this to be true from my 12 years running the component
reseller VBxtras/Xtras.Net and studying my customers use of components, both
commercial and open-source. (Note if they were part of the spec then "d."
and "e." wouldn't be an issue.)
The lesser problems (20%) are that it will take time for reasonably good
ones to evolve, and many will be subtly incompatible because of a variety of
reasons: a.) lack of complete understand of the spec, b.) time-to-market
concerns, c.) belief that full compatibility is not worth the expense,
and/or d.) poor programmer skillls.
It's my opinion that the spec needs to be the catalyst for people using
these HTML5 parser libraries because sa I understand it achievement of many
of the HTML5 goals is predicated on people moving to HTML5 parsers.
>> That's a problem with C-based libraries for dynamic
>> languages--not as much pure-dynamic language
>> implementations, whose status is comparable to the
>> application code.
True, but on Windows servers you can't write ISAPI without C++, and Windows
will continue to be a large market. In other cases, pure-dynamic language
implementations are too slow to be viable. Put references to implementations
in the spec, and the web hosts will use it.
More information about the whatwg