On Mon, Apr 25, 2011 at 11:31 AM, Jonas Sicking <jo...@sicking.cc> wrote:
> First off is document.createTreeWalker and > document.createNodeIterator. They have the same signature which > currently is: > > document.createX(root, whatToShow, filter, entityReferenceExpansion); > > Given that entity references are being removed, we should simply > remove the last argument. Note that this is a backwards compatible > change since additional arguments to any DOM function are just ignored > in all browsers I think. Additionally, I see no reason to keep the > 'filter' argument required as it's quite common to leave out. > FWIW, WebKit already has filter and entityReferenceExpansion as optional. I expect there would be no opposition to making whatToShow optional as well. We could even make the whatToShow argument optinal and default it to > SHOW_ALL. Originally I was going to propose that we default it to > SHOW_ELEMENTS as I had thought that that would be a common value, > however it appears that SHOW_TEXT is as, if not more, commonly used. > The downside to defaulting to SHOW_ALL is that people might use the > default and then do filtering manually, which is slower than having > the iterator/treewalker do the filtering. > I agree with everything here. I think SHOW_ALL is the default people would expect. > I'd like to give some DOM XPath a similar treatment. The following > three functions could be simplified: > > XPathEvaluator.createExpression(expression, resolver); > Here I think we can make the 'resolver' argument optional as > namespaces are commonly not used on the web. > > XPathEvaluator.evaluate(expression, contextNode, resolver, type, result); > We can make 'resolver', 'type' and 'result' optional. 'type' would > default to ANY_TYPE(0) and the other two to null. > > XPathExpression.evaluate(contextNode, type, result); > Here all but the first could be optional. The defaults would be the > same as for XPathEvaluator.evaluate. > These are already all optional in WebKit. We could also make contextNode optional by defaulting it to the document, no? > I'd like to make these changes to firefox, but first I wanted to hear > what people here think. I support this. As it is, I believe the verbosity of these methods hurts their adoption. > I know we don't have editors for the relevant > specs, but I think we can make an informal decision that these changes > sound good if people think they are. > > / Jonas > >