- From: Ivan Herman via GitHub <sysbot+gh@w3.org>
- Date: Thu, 10 Dec 2015 09:48:11 +0000
- To: public-annotation@w3.org
To give a bit more content to this issue, trying to reproduce the discussion that also took place at the TPAC meeting... At the moment, the [FindText API](https://w3c.github.io/findtext/#findtext-api) relies on a large number of parameters, involving such features as the editing distance. Although there is no full consensus on assessing the browser vendors' reactions at, e.g., TPAC, there is a sense that the complexity involved in implementing this interface may be too high. An alternative that was briefly discussed at TPAC is to provide two different interfaces, something that we may call 'FindText API Lite' and the 'FindText API (full)'. 'FindText API Lite' may try to capture the search/find facilities that browsers implement already, which is (probably) a subset of the functionalities encapsulated in the 'FindText API'. In other words, the "only" thing that browsers would have to do is to open access to the guts of what they already implement, without requiring them to implement new functionalities and algorithms. There are obvious pros and cons; this approach would have a higher chance to offer at least *something* that implementations may rely on. The downside is that it may push the implementation of 'FindText API Full' even more down the line. On the other hand, but offering an all or nothing alternative as now, we also incur the danger of getting nothing... -- GitHub Notification of comment by iherman Please view or discuss this issue at https://github.com/w3c/findtext/issues/18#issuecomment-163558524 using your GitHub account
Received on Thursday, 10 December 2015 09:48:13 UTC