Johan Tibell <johan.tib...@gmail.com> wrote: > On Fri, Mar 5, 2010 at 3:46 PM, Achim Schneider <bars...@web.de> > wrote: > > > Johan Tibell <johan.tib...@gmail.com> wrote: > > > > > = A high-performance HTML combinator library using Data.Text = > > > > > > > May I add > > > > * Conceptual compatiblity with the W3C DOM. The library shoud be > > designed in a way that allows a thin / automatically generated > > wrapping layer to support DOM operations, where applicable. > > > > ? > > > > It is a "keep that in mind", not absolute, requirement. > > > > I'm not quite sure I understand what you have in mind. Do you mean > that given a value of type Html you can e.g. query by ID to find > children? > The overall idea is that if we chose to write a browser in Haskell, which will come with an ECMAscript implementation in Haskell, it'd be nice if that HTML library could be developed into something that can be used as internal DOM representation (and messed with from the ECMAscript side) without breaking the already existing Haskell interface.
Also, web developers that know DOM inside out shouldn't be alienated by Haskell doing things in a way that isn't compatible with their intuition about how DOM/HTML works. That is, the library should show potential to be queryable (with some generics library) with the same semantics as DOM, meaning that the information necessary to do that should be present. ...I don't mean that the library as implemented for the SoC must support such queries, but that e.g. a (to be written) library with the same haskell combinators that spews out an ADT instead of a string should be. -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
