<div dir="ltr">To put a bit more of a pragmatic spin on Antranig's rather abstract or ideological response, it might help to consider a concrete example:<br><div><br></div><div>Imagine you're writing a browser-based assistive technology. Something that, for example, restructures a page to make it easier to read, or makes it simpler. Or perhaps even a screenreader, where it needs to see and understand all the widgets, sections, and controls on a page.</div>

<div><br></div><div>With Web Components, as they exist today, the rich semantics of a component are hidden away--encapsulated as you say, Steve. The browser itself has access to the "shadow DOM" used by the component, but other components and scripts in the page don't. The shadow DOM is completely inaccessible to JavaScript code outside the component. So while a desktop AT is able to break through the encapsulation of a Web Component's markup using the "composed tree" that is exposed by the browser to the platform assistive technology API, web-based tools can't.</div>

<div><br></div><div>I think there is a really strong future for assistive technology and user interface adaption implemented entirely using Web technologies--HTML, CSS, and JavaScript. But if all the components that a web-based AT needs to represent or adapt are invisible to it, this whole possibility is foreclosed.</div>

<div><br></div><div>One of the primary advantages to HTML and the DOM is that it provides a clear, standard, and open way for scripts to be able to traverse and understand the semantics of a page. That's why, at least in Infusion, we really encourage the use open, transparent markup and JSON configuration for all the presentational, behavioural, and compositional aspects of a web application--so that an assistive technology, built using web technologies, can fully understand how the application works and can adapt it according to the user's needs and preferences.</div>

<div><br></div><div><div>Unfortunately, at least as they're implemented today, Web Components seem to work against that vision.</div></div><div><br></div><div>The good news is that I don't think transparency and lack of hiding/encapsulation has to involve "exposing all the guts" of a component. There are plenty of great ways to provide a user-friendly facade for a component without hiding and encapsulating everything in such a way that it can't later be adapted.</div>

<div><br></div><div>Colin</div><div><br></div><div><br></div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Aug 14, 2014 at 3:26 PM, Steve Lee <span dir="ltr"><<a href="mailto:steve@opendirective.com" target="_blank">steve@opendirective.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">Ah, a slightly different angle. One I heard about at ICCHP when you where mentioned.</p>
<p dir="ltr">Would be good to discuss when we next meet.</p>
<p dir="ltr">My stance, for now, is encapsulation is useful if carefully applied. Grey or white boxes rather than black. If I use a tool I'm happy to learn how to use it without all its guts exposed to confuse me. Unless I want to adapt it, then I dig in and learn the glorious details within.</p>

<div class="im HOEnZb">

<p dir="ltr">Steve</p>
<p dir="ltr">Autocomplete may have messed with my text</p>
</div><div class="HOEnZb"><div class="h5"><div class="gmail_quote">On 14 Aug 2014 20:11, "Antranig Basman" <<a href="mailto:antranig.basman@colorado.edu" target="_blank">antranig.basman@colorado.edu</a>> wrote:<br type="attribution">

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.<br>



<br>
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".<br>



<br>
Cheers,<br>
Antranig<br>
<br>
On 14/08/2014 19:53, Steve Lee wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hmm, I disagree. Web components are simply an architectural<br>
modularisation technique. At least with custom elements, and largely<br>
shadow DOM etc.<br>
<br>
You get all the advantages of ease of use of your new tags as a black<br>
box (just like standard elements) but all code is part of your project.<br>
If you use existing web components you just pick open source ones with<br>
healthy community. Same as any thing else you will depend on.<br>
<br>
Or am I missing your point?<br>
<br>
I used XBL, a precursor W3C standard, in Maavis and found the approach<br>
added much to what is otherwise architecturally easy in JS.<br>
<br>
Steve<br>
<br>
</blockquote>
______________________________<u></u>_________________________<br>
fluid-work mailing list - <a href="mailto:fluid-work@fluidproject.org" target="_blank">fluid-work@fluidproject.org</a><br>
To unsubscribe, change settings or access archives,<br>
see <a href="http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work" target="_blank">http://lists.idrc.ocad.ca/<u></u>mailman/listinfo/fluid-work</a><br>
</blockquote></div>
</div></div><br>_______________________________________________________<br>
fluid-work mailing list - <a href="mailto:fluid-work@fluidproject.org">fluid-work@fluidproject.org</a><br>
To unsubscribe, change settings or access archives,<br>
see <a href="http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work" target="_blank">http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work</a><br></blockquote></div><br></div>