NUKnightLab / NUKnightLab/TimelineJS3
TL.TimeScale._computePositionInfo has hardcoded width (100px) for all markers, creating potential overlap between markers for no reason
Nobody has claimed this yet.
- Dominant language
- JavaScript
- Stars
- 3.2k
- Forks
- 645
- PR merge metrics
- No merged PRs in 30d
Description
TL.TimeScale._computePositionInfo has hardcoded width (100px) for all markers. It means that if two markers are separated in time by less than the equivalent of 100px in the timeline, they will be on the same row, creating an overlap.
It is not a problem with the default style, but adapting timeline.js to be shown on giant screens (larger font sizes) means that basically every markers will be overlapping.
Technical explanation:
_computePositionInfo has 3 arguments, the third one being "optional" :
_computePositionInfo: function(slides, max_rows, default_marker_width) {
default_marker_width = default_marker_width || 100;
...
}
This function is only called once in the whole project, in TL.Timescale.initialize, without the third argument :
this._computePositionInfo(slides, options.max_row);
One workaround (not proper fix?) would be to give the "marker_width_min" option if it exists. Proper fix would be to get the actual width of each marker.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start in timeline.js at TL.TimeScale._computePositionInfo and its single call from TL.Timescale.initialize. Read how marker_width_min and marker layout are handled, then determine how each marker's actual width should affect row placement. Done means markers sized for large fonts no longer overlap because of the fixed 100px default.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- javascript
- Domain
- frontend
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100