There's modularisation, and there's balkanisation. Web components fight
against the spirit and also the practice of the free and open web, by
making it impossible to influence or even access the markup and UI
material operated by another component. "black boxes" are exactly what
we don't want. The aim of Infusion, for example, is to make even more
parts of an implementation open for inspection and modification than
were previously available - by taking material that used to be locked up
in JS implementation files and exposing it publically as JSON
configuration. Web Components take us decisively in the wrong direction,
by taking what used to be exposed in a public DOM with public behaviour
and locking it away.
These issues take a while to talk around and to establish - since this
terrain isn't easy or obvious. A lot of what is "established wisdom" in
Computer Science - re, for example, modularisation, insulation,
encapsulation, and abstraction, has grown up over the years as a
self-reinforcing network of ideas - and may not well-founded. Such
"insulation-based thinking" is certainly inappropriate and unhelpful for
a community whose aim is to promote the development and use of
accessible interfaces. As well as working in the open (open source), we
need to promote the creation of open artifacts. Open artifacts are ones
where the intention of the user can reach down right to the ground level
in every area of the implementation - with no "black boxes".
Cheers,
Antranig
On 14/08/2014 19:53, Steve Lee wrote:
Hmm, I disagree. Web components are simply an architectural
modularisation technique. At least with custom elements, and largely
shadow DOM etc.
You get all the advantages of ease of use of your new tags as a black
box (just like standard elements) but all code is part of your project.
If you use existing web components you just pick open source ones with
healthy community. Same as any thing else you will depend on.
Or am I missing your point?
I used XBL, a precursor W3C standard, in Maavis and found the approach
added much to what is otherwise architecturally easy in JS.
Steve
_______________________________________________________
fluid-work mailing list - fluid-work@fluidproject.org
To unsubscribe, change settings or access archives,
see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work
