[TYPO3-core] Browser version support for next LTS

[Jigal van Hemert]

Hi,

Thank you for thinking about this second subject.

On 15-8-2014 19:25, Philipp Gampe wrote:
> Jigal van Hemert wrote:
>
>> This will also mitigate the issue that the development is too
>> developer-orientated. Unfortunately we have no vision or general
>> direction team / person.
>
> The persons at the ACME in Nürnberg seemed to share a rough idea of what to
> do:
> * generic concept fixes: workspaces, l10n, mobile
> * cleanup and cleaner API
> * cloud readiness, automatic deployment and automatic maintenance
> * interoperability with other systems: REST, SOAP, custom APIs

These are all really relatively small, technical and short term 
subjects. Even with a changed future release schedule it takes time to 
get new code into real projects. This means that a product should start 
developing things that are needed in a few years.
The usual reply is that it's impossible to tell the future and that you 
can only build for reality. On the other hand we can see that technology 
is moving in a certain direction, that trends are emerging and new ideas 
are taking shape.
Of course it's impossible to have a fully functional implementation of 
something that is still in its infancy but it wouldn't be bad to see if 
the general idea is useful for the product and if implementation 
(without knowing every detail) has a huge impact or not.

A few concrete examples:
- until now systems have been made to "remember" as much as possible. 
The ForgetIT project is exploring the concept of machines forgetting 
information. Google recently faced the need to forget information upon 
request. I wouldn't be surprised if the teams behind solr and lucene are 
already pondering about this concept
- semantic markup is slowly being used; html5 has some implementation 
for it and the concept is being discussed for some years. Before the 
exact standards are known we could at least see what the impact for CMS 
would be and in which way it would be possible to have support for this. 
Can an RTE based on browser editable content support this or is an 
alternative editor necessary? And so on

These are all things that need to be done without producing a single 
line of code. Concepts, trends,... vision.

> For the frontend part, there is not much we can do further (except some
> mobile/responsive helpers) and the backend mainly lacks a consistent API.

The frontend lacks a good video element (perhaps two; one that can 
easily embed online videos and one that follows the most strict 
accessibility guidelines). Frontend output is mainly usable for HTML/XML 
and can do a bit of JSON. To communicate better with other systems it 
needs to be more flexible and support more formats somehow.
More conditions for rendering content elements (device / user properties 
/ other).

The backend needs an overhaul. It's not suitable for touch devices. 
Editors need to be able to work with less clicks. It needs to be more 
adaptable for the needs for various people (editors / integrators / 
developers).

> After all, all that vision foo is mainly bullshit, just because this is an
> open source project. Nobody can be forced to work on issues and nobody is
> going to work on issues that does not bother him.

That is a rather developer-centered view. There are developers who would 
like to work on implementing concepts made by others. Some of these 
projects might even be funded. Not everybody scratches only their own 
itches.

> Next to that, the only real thing we might want to discuss are the formal
> rules of development:
> * commit rules
> * team organization (official functions)
> * code rules (CGL, etc)
> * (feature integration)
> * (feature deprecation)

The are the fine details. They need to be arranged, but so far these 
were also the favourite discussion topics. Sad, but true.

-- 
Jigal van Hemert
TYPO3 CMS Active Contributor

TYPO3 .... inspiring people to share!
Get involved: typo3.org