On Sat, Sep 3, 2011 at 8:20 PM, Ian Hickson <i...@hixie.ch> wrote:
> On Sat, 3 Sep 2011, Dominic Cooney wrote:
>> >
>> > I think the XBL approach is far superior here -- have authors use
>> > existing elements, and use XBL to augment them. For example, if you
>> > want the user to select a country from a map, you can use a <select>
>> > with a list of countries in <option> elements in the markup, but then
>> > use CSS/XBL to bind that <select> to a "component" that instead makes
>> > the <select> look like a map, with all the interactivity that implies.
>>
>> That sounds appealing, but it looks really hard to implement from where
>> we right now.
>
> I don't think "it's hard" is a good reason to adopt an inferior solution,

Likewise, intimating that something is better because it's hard is a
distraction.

> especially given that this is something that will dramatically impact the
> Web for decades to come.

The more complex the thing, the more we're saddled with. XBL(2) is
more complex than the proposed model. It likewise needs to be
justified all the more.

> XBL already has multiple implementations in various forms. I certainly
> agree that we should adjust XBL2 to take into account lessons we have
> learnt over the past five years, such as dropping namespaces and merging
> it into HTML instead of forcing an XML language on authors, but taking a
> significantly less capable solution simply because XBL is difficult seems
> like a very poor trade-off.

It *may* be capable of handling the use-cases in question, but that
case hasn't been made, and from where I sit, it's not easy or trivial
to do by inspection.

Regards

Reply via email to