tilingPadding functions should take an argument which is the node for which the padding is being calculated

[finger563]

This would allow us to determine what kind of tiling padding we want on a per-node basis :)

[maxkfranz]

Actually to be consistent with every other layout, CoSE should allow for per-element functions for every possible field in the options object. The majority options could support this; only a small number absolutely must be layout-global options.

[finger563]

Even better :)

[maxkfranz]

The other layouts do something like this. With a function, it's not that hard to support.

let optVal = ( name, ele ) => {
  let field = options[name];
  
  if( isFunction( field ) ){
    return field( ele );
  } else {
    return field;
  }
};

// e.g. 
let edgeLength = optVal( 'edgeLength', edge );

@metincansiper Could this approach be used in the layout?

[metincansiper]

@maxkfranz sorry I just realized this. I think in general per-element functions would be supported in this layout by attaching result of optVal to layout nodes around here and to layout edges around here.

I think that tiling padding options namely tilingPaddingVertical and tilingPaddingHorizontal can be evaluated per compound node.

Also the padding values assigned in the same line would needed to become user options defined per node. In the past we thought that we can directly read the real values for them by calling node.css('padding') instead of letting users specifying them per node. However, I think that trying to read node.css('padding') is problematic while running the layout in headless mode. Am I right?

About whether the options like idealEdgeLength would be defined per element @ugurdogrusoz would have a clear idea.