Arrange images in a configurable grid
  • TypeScript 74.8%
  • Python 23.5%
  • CSS 0.9%
  • Shell 0.4%
  • HTML 0.4%
Find a file
2025-09-16 19:19:56 +02:00
config Starts using pythonbuilder instead of BuildMachine 2025-09-12 15:59:51 +02:00
pythonbuilder Starts using pythonbuilder instead of BuildMachine 2025-09-12 15:59:51 +02:00
src Removes remains of BuildMachine build system 2025-09-15 20:02:05 +02:00
.c8rc.json Initial public commit 2022-12-10 16:45:12 +01:00
.eslintrc.json Removes optimistic assumption that the key for indexedDB guarantees a type-correct result 2024-01-25 17:18:25 +01:00
.gitignore Removes remains of BuildMachine build system 2025-09-15 20:02:05 +02:00
.npmrc Upgrades all packages 2024-01-20 16:31:06 +01:00
.prettierrc.json Upgrades all packages 2024-01-20 16:31:06 +01:00
dependencies.svg Adds publishing to the build process 2025-09-16 19:16:00 +02:00
doublewatch Starts using pythonbuilder instead of BuildMachine 2025-09-12 15:59:51 +02:00
ISSUES.md Initial public commit 2022-12-10 16:45:12 +01:00
jasmine.json Replace chai and a home-brewn test runner with Jasmine 2024-01-22 19:27:28 +01:00
Notes.md Initial public commit 2022-12-10 16:45:12 +01:00
package.json Activates eslint-language-service for tsserver 2025-09-14 08:48:08 +02:00
pb Adds publishing to the build process 2025-09-16 19:16:00 +02:00
README.md Fixes link to the app 2025-09-16 19:19:56 +02:00
serve Starts using pythonbuilder instead of BuildMachine 2025-09-12 15:59:51 +02:00
tsconfig.json Fixes JSON problem 2025-09-15 16:05:39 +02:00

arrangeimage — arrange images in a configurable raster

Web application to arrange several photos into one based on a simple but adaptable raster.

Goal: no server, loading and saving should work locally.

See the arrangimage at work

An Experiment

This is an experiment to see how far one gets with the plain Javascript API provided by browsers.

No Web Components

This project does not use Web Components for the following reasons:

HTML Inheritance

For long it was discovered that favoring composition over inheritance is a good thing. Web Components go the opposite way and suggest to create "new" HTML elements inheriting from existing ones.

The components in this project are based on a different approach. A component is typically a (Javacript/Typescript) class which encapsulates aspects of working with an HTML element structure:

  • creation and destruction
  • changing the sub-DOM rooted by the element
  • attaching behaviour

It turned out that not even all aspects need to be covered by one class. Rather it seems useful to separate the first two from the third: one class is responsible for handling the DOM structure and provides an API to change it, for example a structure having a variable number of like elements (think of a list) is managed by a class which provides an API to add, remove, or rearrange these elements. Another class, not even maintaining its own DOM subtree may use the API together with user interaction event handling (mouse, keyboard) to allow the user to interact with the list.

Shadow DOM

The Shadow DOM seems like a weird concept. To cite two sentences from the MDN page (as of 2022-12-04)

The difference is that none of the code inside a shadow DOM can affect anything outside it, allowing for handy encapsulation.

This seems to define encapsulation the wrong way round. Normally you encapsulate things to not have them screwed up arbitrarily from the outside. And later:

When you've attached a shadow DOM to an element, manipulating it is a matter of just using the same DOM APIs as you use for the regular DOM manipulation

So where is the encapsulation here. The one encapsulation I can see is the inclusion of <style> elements inside shadow DOM trees to style elements in the shadow without leaking to the outside.

In this project this is solved with "unique" CSS class names provided by the Javascript classes that tend to a DOM subtree. Obviously this uniqueness can not be guaranteed universally and globally. But this is roughly on the same level as Web Components used in one project should better have "unique" names.