[TYPO3-core] Browser version support for next LTS
Jigal van Hemert
jigal.van.hemert at typo3.org
Fri Aug 15 23:28:40 CEST 2014
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
> * 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
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 /
> 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
> 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
More information about the TYPO3-team-core