The idea is to give a fallback to gif and the option to an alternative extension for each user. That way there can be alternative and smaller packages for the content af the "img" folder. (The code could be changed to edit the paths as well, there is no problem exchanging the folder names.)
There can be variables $prefImgExt and $prefVidExt you set somewhere and provide the widget with the standard gif and those variables.
This way you can exchanges parts or all of the content without breaking anything. Error handling provides an easy way to use the old gifs.
The different error handling makes sense since there is either a fallback to video or to image. Sure i provide more than is probably needed, but that has next to no effect on parsing and compile time.
The "simplicity" of the widget code isn't really importent, you only call it. The widget itself is easy enough for me. If you prefer to call the widget with just one argument you can do that as well.
The values i set are of type boolean, see
There can be variables $prefImgExt and $prefVidExt you set somewhere and provide the widget with the standard gif and those variables.
Code:
<<image "<path to standard image>.gif" $prefImgExt>> /*for images or*/
<<image "<path to standard vid>.gif" $prefVidExt>> /*for videos*/
The different error handling makes sense since there is either a fallback to video or to image. Sure i provide more than is probably needed, but that has next to no effect on parsing and compile time.
Code:
/*this is handled by your quoted code*/
<<image "<path to img/vid>.<imgExt>" "mp4">>/* this needs a fallback to image from video*/
<<image "<path to img/vid>.<vidExt>" "mp4">>/* this needs a fallback to video from video*/
<<image "<path to vid>.mkv" "mp4">> /*example usage: if the standard gif changes in the future to a better video container format, but the user prefers his mp4 content (mkv is currently not supported :'( )*/
The values i set are of type boolean, see
You must be registered to see the links
. Sorry my knowledge in C++ is better than of this HTML stuff, so I read a bit. Technically for booleans it can even be attributName="whatever" since the presence of a boolean attribute sets it to true. Therefore muted=true is valid, even muted=false would set it to true