- From: Ian Hickson <ian@hixie.ch>
- Date: Thu, 26 Jan 2012 21:48:36 +0000 (UTC)
- To: Matthew Slyman <whatwg@aaabit.com>
- cc: public-webapps@w3.org
On Fri, 23 Sep 2011, Matthew Slyman wrote: > Quoting Ian Hickson <ian@hixie.ch>: > > > > We took it out because it was just far too complicated a solution to > > solve far too narrow a set of use cases. > > > > However, there is a lot of ongoing work in this area of research, > > especially currently in the public-webapps@w3.org group. I encourage > > you to bring up the suggestion there. Unfortunately, coming up with a > > declarative solution whose cost-to-usefulness ratio is good enough has > > proven over the years to be a rather elusive goal. > > I find this surprising. Unless of course you're trying to create a tool > to do everything (in which case you're diving head-first down a > rabbit-warren), or otherwise, have already tried that and decided it > doesn't work, and therefore decided that it's not worth attempting a > solution to any part of this problem. The constraint is inventing technologies that have broad appeal. There is a tradeoff made in all technology development between the amount of effort required to develop and maintain the technology, and the return on investment -- in the case of Web technologies, the number of pages that will be able to make use of the feature. For example, one could imagine that we could add to HTML a feature designed to help with the creation of model railway layout control tools. It would certainly be possible to develop a markup language for model trains -- one can imagine <track> elements and <switch> element and <train-sensor> elements and <light> elements -- but the amount of work that would be needed to make such a feature would be disproportionate to the number of people who could make use of it. On the other end of the scale, we have elements like <h1>, which are relatively cheap to design and implement, and yet apply to nearly every HTML page on the Web. With templating features like the repetition model, we found that the cost of the feature was relatively high, and the number of pages that could actually make use of it was relatively small. A large number of other proposals have also been considered in this area, but most have a similar cost/benefit ratio. > ===CONCLUSIONS===: We need a declarative solution for HTML repetition, > the same way Chemists need a declarative solution for repetition of > chemical formulae. I don't think you'll find anyone who disagrees with this. The problem is coming up with a solution that is generic enough that it can be used for a large number of classes of repetition problems such that the benefit of the feature is not so small relative to the cost. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Thursday, 26 January 2012 21:49:12 UTC