Can I translate this article to Japanese, to let Japanese web devs know better this?

This was exactly what I needed! I’ve used it in a C# WinForms application to allow me to parse HTML with the Html Agility Pack (built-in XPath support), while allowing me to select and modify specific elements (without ids) that are previewed in a WebBrowser control.

The only modification I had to make to the code was adding a line to the _XPathMsxmlDocumentHelper activateDom function.

dom.setProperty(“SelectionLanguage”, “XPath”);

Apparently the default selection language uses 0-based indicies (i.e. “//p[0]/a[0]” to select the first anchor in the first paragraph) whereas XPath is defined as using 1-based indicies (i.e. “//p[1]/a[1]” to select the first anchor in the first paragraph). There may be other differences, but this was the one that tripped me up.

I found the setting at this URL in the JavaScript example:
http://msdn.microsoft.com/en-us/library/windows/desktop/ms754523(v=vs.85).aspx#snippetGroup
(Search: Msxml2.DOMDocument selectNodes)

I’m not sure if it was intentional, so I figured I’d just raise the point in case it wasn’t.

Regards,
Trevor

The way to writing more functional and bugfree apps is not abstracting complexity, it’s removing complexity. I think the added complexity of a shadow dom would not be a good idea. I do think standardizing the look and customisability of the elements we have now would be a good idea (like what happened to buttons, sort of). HTML + CSS + Javascript is about dynamic interactive applications, not about structured data anymore. If you ask me there should be a single standardized browser css template, and a collection of public domain fonts that are enforced be included.

Bah!