0

i have a userjs script for opera which displays its own interface, currently using DOM methods to create elements. This works well, but is hard to maintain as the interface is tied to the code. So I'm looking for a way to separate layout from code. Also i want to keep things simple and really don't want to rely on a framework (jquery...) for that. I don't care about cross-browser functionality, this thing can only work on opera anyway.

i got all the style stuff into css, that helped. Now i'm looking for a way to abstract the layout. A good part of the UI is quite dynamic, so I can't just use one big static html. The idea that came up was to have a piece of html containing the layout for the different UI parts, extract fragments from that and put everything together as needed.

This works pretty well to some degree:

  • create a div, never parent it.
  • use .innerHTML to load the html into it
  • use this getElementsByClassName() to find widgets in it
  • clone them with widget.cloneNode(true)
  • parent it etc...

I know of some issues with cloneNode() (risk of duplicate ids, and event handlers missing in the clone) but i can work around them.

The problem is, with .innerHTML loading i get different results from the current DOM code, even though i use a captured layout from the DOM code version ! I'm seeing this with tables for example. For a simple

<table><tr><td></td></tr></table>

the innerHTML version shows up with <tbody> tags in it in dragonfly, and css rules like this one don't apply anymore because of it:

table > tr > td { ... }

I have a baaaad feeling about all this ...

  • Are there other big differences between DOM and html layouts ?
  • Maybe i should really be using <tbody> in the DOM stuff ?
  • How would you do this ?

Bonus question:

  • what is the reason behind createDocumentFragment() existence ? what can you do with it that can't be done otherwise ?
lemonsqueeze
  • 1,041
  • 8
  • 19
  • according to [this question](http://stackoverflow.com/questions/1678494/why-does-firebug-add-tbody-to-table) when using XHTML the DOM corresponds more closely to the source XML. could try that also, i'm using html currently ... – lemonsqueeze Jan 24 '13 at 15:25

1 Answers1

1

You're right, it looks like a table whose markup doesn't define <tbody>, will be converted to markup with the <tbody> tag present when reading the innerHTML poperty of a table.

But this shouldn't cause too much trouble for you: as for the CSS issue, drop the > from your selectors (restricts to direct descendent).

One possible benefit of DocumentFragment is that when you need to do significant amount of DOM manipulation, it may cause some performance gain if only a document fragment is manipulated and once all transformations are done, it is attached to the DOM.

marekful
  • 14,986
  • 6
  • 37
  • 59
  • thanks, i was thinking perhaps with `DocumentFragment` it's possible to use things like `getElementById` which is not available in an unparented node ... – lemonsqueeze Jan 24 '13 at 15:19
  • updated the css rule, that helps. there are still some strange differences remaining, need to investigate deeper... – lemonsqueeze Jan 24 '13 at 20:07