Zhenbin Xu wrote:
I think we are now off track.
Nonetheless we should realize that customer cannot
write an interoperable page with my fictional home grown browser if it doesn't
exist
or doesn't have the needed feature when the page was written. I doubt customers
would write against particular browser if equal efforts can results in
interoperable
solutions run on top multiple browsers. Now that the solutions are in place,
they
deserve our consideration.
I would argue it is important to think about customer's migration path when we
design
new feature or standardizing existing ones. Otherwise we would be painting
customers
into corner and blaming them for their dilemma.
So I think the sticking point here is if there really are site
interoperability issues or not. In the cases where all UAs behave the
same way I certainly agree that that is a good indication that sites
depend on that behavior, and so we should specify that behavior.
However when existing UAs with significant marketshare do different
things, then that is a good indication that sites don't really depend on
any particular behavior. Especially if the UA vendors haven't received
any input about this being a problem, despite having a large user base.
In these cases I think we should choose the API that is most friendly
towards JS developers. Of course it is debatable what is the best API
from that point of view, but I would like to at least frame the
discussion from that viewpoint in those cases.
/ Jonas
