- TypeScript 74.8%
- Python 23.5%
- CSS 0.9%
- Shell 0.4%
- HTML 0.4%
| config | ||
| pythonbuilder | ||
| src | ||
| .c8rc.json | ||
| .eslintrc.json | ||
| .gitignore | ||
| .npmrc | ||
| .prettierrc.json | ||
| dependencies.svg | ||
| doublewatch | ||
| ISSUES.md | ||
| jasmine.json | ||
| Notes.md | ||
| package.json | ||
| pb | ||
| README.md | ||
| serve | ||
| tsconfig.json | ||
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.