Fore 3.0

[JoernT]

a glimpse towards Fore 3.0

Maybe there will another 2.x release but i started some work towards 3.0.

This release will be breaking by removing some <fx- elements where a better, native HTML alternative exists. For instance we've discussed the <fx-instance> element before as being unluckily named - it always requires extra explanation to say it's a data-container. Further HTML already defines the <data> element. Though it's purpose is to define key/value pairs mainly it does not prohibit child content and would be a more natural match for the purpose. This means that <fx-instance> will just be replaced with the native HTML element.

Example:

<fx-fore>
    <fx-model>
         <!-- instead of ... -->
         <fx-instance id="mydata" src="mysource.xml"></fx-instance>
         <!-- use data element instead -->
         <data id="mydata" data-src="mysource.xml"></data>
    </fx-model>
...
</fx-fore>

This comes to the price to use data- prefixes for the attributes (as the standard requires for custom attributes) but otherwise is more expressive than the old syntax and builds directly on an already existing element.

This is probably only one change that will go into 3.0. The <fx-dialog> is another candidate as HTML defines this also in the meantime. - we'll critically review other candidates. The rationale behind it is to give already existing elements priority over custom elements and simplify either the codebase and the usage of Fore by building upon the common ground.

drop it or keep it

Of course the question arises if we should just keep the <fx-instance> element and add the use of <data> as an additional option. However i decided against it:

• it takes much more effort to keep them both as it requires some code-branching and duplicate functionality
• it would encourage a mixed use of both elements not doing clarity and maintainability a favor
• it would also lead to a mix in the demos likely leading to confusion for users
• the documentation would also take this into account
• just deprecating now and removing later does only push the problem into the future and cost us precious dev-time not being spend elsewhere

Enough reasons i hope to justify a 'hard' break requiring users to update their pages when upgrading to 3.0

Making these changes is still a pile of work but at least will shrink the codebase and bring us closer to the platform.

Originally posted by @JoernT in #269