node width and height should be optional

[pketh]

For importing, Kinopio computes a node's dimensions dynamically based on it's contents so explicit width and height are unnecessary in my context (manual resizing is an optional action that the user can take). Also because Kinopio's design also has to work on mobile, Kinopio cards might have more padding or a larger default font size than other apps.

But also going the other way with exporting, the width and heights that kinopio uses might look wonky in another app so I can specify them but I wouldn't want them to be treated as gospel elsewhere.

[capak07]

I plan to start my work on this, was wondering if just setting the height and width to 100% should be the fix or just remove the explicit width and height variables?

[pketh]

my first impression of 100% is that it would be 100% of the width of the page (like width:100% in css). If width and height are optional, then the importing app can make it's own width determination based on the node content. It might even want to do that even if width and height are specified because of differences between apps imo.

[lishid]

I do not agree with this - without explicit widths and heights, there is no way for an engine to consistently layout nodes properly. Especially with auto-formatting text, should the engine fit all text on a single line, or some default width and then wrap the lines? How would the engine size two cards that are side-by-side but would otherwise run into each other without explicit widths?

The other issue is with text sizing and font. Different apps will have different font sizes, text layout algorithm, and text wrapping algorithms. Without explicit sizing it will make canvases on one app look completely different on another app.

What I think would make sense, is to always require width for text nodes - having a specified/required width makes layout at least somewhat predictable. Auto-sizing text can dynamically determine the height based on how much space the text ends up being formatted as. Even then I would argue that this could work for some kind of user content (like a row of cards) but not for others (like a kanban, where cards are stacked below others) because you can still run into issues where cards auto-size to different sizes and run into another card below.

[pketh]

there is no way for an engine to consistently layout nodes properly. Especially with auto-formatting text, should the engine fit all text on a single line, or some default width and then wrap the lines?

In the case of kinopio and some other canvas apps I've seen, nodes have a default width before text starts to wrap - but the user can optionally explicitly adjust the width at which wrapping occurs. Some nodes will have this width explicitly set, other nodes will not.

The other issue is with text sizing and font. Different apps will have different font sizes, text layout algorithm, and text wrapping algorithms. Without explicit sizing it will make canvases on one app look completely different on another app.

Importing content that appears broken or malformed in an app for the sake of dogmatic consistency seems like an anti goal to me. If node size is important than it can be explicitly specified in the canvas file.

having a determined width makes layout at least somewhat predictable. Auto-sizing text can dynamically determine the height based on how much space the text ends up being formatted as.

this is exactly what I proposed: that determined width is determined by the importing app when an explicit node width is not specified

[capak07]

So you're saying leave the width as it is and just adjust the height to 100%? Also I checked that the node -text height is fixed which makes setting the height to 100% efficient?

What I think would make sense, is to always require width for text nodes - having a determined width makes layout at least somewhat predictable

[lishid]

In the case of kinopio and some other canvas apps I've seen, nodes have a default width before text starts to wrap - but the user can optionally explicitly adjust the width at which wrapping occurs. Some nodes will have this width explicitly set, other nodes will not.

Right, I guess it depends on the target use case of the app, but IMO from a specifications perspective leaving this to the implementation leads to poor user experience as nodes will be rendered significantly differently across apps with different defaults, font sizes, and text wrapping algorithms. If there's any consensus that these are to be marked as optional, then I would still suggest setting them for interoperability between apps and consistency, and require that the specification explicitly state the algorithm to be followed for missing width/height values.

Importing content that appears broken or malformed in an app for the sake of dogmatic consistency seems like an anti goal to me. If node size is important than it can be explicitly specified in the canvas file.

I believe the whole point of a specification is for apps to be able to share content in a predictable way and not have content appear broken or malformed when going from one app to another. If content becomes broken then there's no point in having a standard format, no?

this is exactly what I proposed: that determined width is determined by the importing app when an explicit node width is not specified

Apologies, my original use of "determined" was supposed to mean "specified", as in that it's specified (required) in the format. I will revise my earlier comment.

[lishid]

So you're saying leave the width as it is and just adjust the height to 100%? Also I checked that the node -text height is fixed which makes setting the height to 100% efficient?

Do you mean by 100% to be the equivalent of the css rule "fit-content"? My suggestion is to keep the width fixed and mandatory, and consider the possibility of letting the height be optional.

[capak07]

Yeah that's what I meant. I agree on your suggestion

My suggestion is to keep the width fixed and mandatory, and consider the possibility of letting the height be optional.

[lishid]

One thing to consider is that marking width or height optional would inadvertently lead to requiring the implementers to deal with the possibility of a nonexistent value. The downside here is the additional implementation burden that one would have to follow a proposed algorithm to consistently (or at least, gracefully) render the contents.

On the flip side, the specification could also call out that null/undefined or zero values be handled in the same way.

[pketh]

requiring the implementers to deal with the possibility of a nonexistent value

wouldn’t that just be the default value that the app is already using when width hasn’t been explicitly specified by the user ?

[clbarnes]

my first impression of 100% is that it would be 100% of the width of the page (like width:100% in css)

Just a note that at present, there is no way of setting a height or width to a percentage (regardless of how that percentage might be interpreted); only integer pixel values are allowed in the spec.

In this case (specifically supporting an infinite canvas), having a percentage match the size of the container (which may be the canvas) doesn't make sense, as any percentage of infinity but 0 is infinity.