The preferred way is to avoid touching core and as much as possible rely on components relying on core. If it becomes BOTH too convoluted and is a recurring need, then and only then should core be modified. In this specific example as arguably a relatively clean and easy way exist, it's probably better not to modify core.
This has also probably happened once before with e.g onreleased as it was later changed from ondrop.
Consequently it's important to find a better way to go from experiments in a branch back to a master branch that include such recurrently needed features.
At the very least work has to be documented enough (as function name, component name, comments or external documentation) to be found when needed, even if only merged back into a non-master branch.
Billboarding has been done at least twice, cf :
the "clean" way https://git.benetou.fr/utopiah/text-code-xr-engine/src/branch/game-multiple-levels/index.html#L957
vs
the "dirty" way https://git.benetou.fr/utopiah/text-code-xr-engine/src/branch/gesture-manager/jxr-core.js#L165 despite being done even later.
The preferred way is to avoid touching core and as much as possible rely on components relying on core. If it becomes BOTH too convoluted and is a recurring need, then and only then should core be modified. In this specific example as arguably a relatively clean and easy way exist, it's probably better not to modify core.
This has also probably happened once before with e.g `onreleased` as it was later changed from `ondrop`.
Consequently it's important to find a better way to go from experiments in a branch back to a master branch that include such recurrently needed features.
At the very least work has to be documented enough (as function name, component name, comments or external documentation) to be found when needed, even if only merged back into a non-master branch.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Billboarding has been done at least twice, cf :
the "clean" way https://git.benetou.fr/utopiah/text-code-xr-engine/src/branch/game-multiple-levels/index.html#L957
vs
the "dirty" way https://git.benetou.fr/utopiah/text-code-xr-engine/src/branch/gesture-manager/jxr-core.js#L165 despite being done even later.
The preferred way is to avoid touching core and as much as possible rely on components relying on core. If it becomes BOTH too convoluted and is a recurring need, then and only then should core be modified. In this specific example as arguably a relatively clean and easy way exist, it's probably better not to modify core.
This has also probably happened once before with e.g
onreleasedas it was later changed fromondrop.Consequently it's important to find a better way to go from experiments in a branch back to a master branch that include such recurrently needed features.
At the very least work has to be documented enough (as function name, component name, comments or external documentation) to be found when needed, even if only merged back into a non-master branch.