If you're writing an Eclipse plug-in, you can make use of APIs (caveats below) from the Web Tools Platform (WTP) HTML plug-ins. A headless plug-in will require:
- org.eclipse.wst.html.core
- org.eclipse.wst.xml.core
- org.eclipse.wst.sse.core
- org.eclipse.text
- org.eclipse.core.resources
It's a lot of dependencies to take on, but these are the same models that run under WTP's HTML Editor (and most of the editors provided by WTP, aside from the JavaScript tools).
import org.eclipse.wst.sse.core.internal.provisional.IModelManager;
import org.eclipse.wst.sse.core.internal.provisional.IStructuredModel;
import org.eclipse.wst.xml.core.internal.provisional.document.IDOMDocument;
import org.eclipse.wst.xml.core.internal.provisional.document.IDOMModel;
import org.eclipse.jface.text.IDocument;
import org.w3c.dom.Element;
...
IModelManager modelManager = StructuredModelManager.getModelManager();
IDOMModel model = null;
try {
model = (IDOMModel) modelManager.getModelForEdit(anIFile);
// W3C-like DOM manipulation
IDOMDocument doc = model.getDocument();
Element ele = doc.createElement(HTML40Namespace.ElementName.P);
doc.appendChild(ele);
// JFace IDocument compatibility
IDocument textDocument = model.getStructuredDocument();
textDocument .replace(0, textDocument .getLength(), "<tag>some text</tag>");
Element ele2 = doc.createElement(HTML40Namespace.ElementName.P);
doc.appendChild(ele2);
/* You can do more with either, or both, mechanisms here. DOM
* changes are reflected in the text immediately and vice versa,
* with a best effort by the DOM side if the source itself is
* "broken".
*/
}
finally {
if (model != null) {
model.save();
model.releaseFromEdit();
}
}
- Once loaded, you can modify the file contents using Eclipse's JFace Document APIs or something very close to the W3C DOM API. Our models are fully modifiable as text documents, and some of the W3C APIs weren't built with that in mind. There are also a few historic implementation mistakes on our part, e.g. the XML declaration has the wrong node type in the XML DOM.
- Some required classes are still in
internal
or provisional
packages for legacy binary compatibility. Changing them would break an unknown amount of downstream plug-ins.
- Neon handles AngularJS-style attribute names better than prior releases, if that matters.
- CSS and JavaScript sections and attribute values should automatically be handled and out of your way.
- If you put
org.eclipse.wst.sse.ui/actioncontributor/debugstatusfields=true
(it's a trace option) into a file and use the file as the argument value to -debug
when launching Eclipse, supported file types will have an extra field in the status bar that shows the selected text offset in the open editor. Double-clicking it will open some nerdy info about that selection. You can even set this up for your actual installation; aside from the numbers being shown, the only performance impact is when you double-click there.

When launching from Eclipse to test your plug-in, you can just set it from the launch config dialog:
