[Typo3-dev] Less features, more future
Kasper Skårhøj
kasper2005 at typo3.com
Wed Oct 12 12:48:55 CEST 2005
> 1. Pagetypes: Hide in Menu, Advanced, Backend User Section, Spacer, huh?
> Why can't we just have page properties, nicely arranged and collapsable,
> but with the possibility to have any combination of them. Quite a few
> feature requests in the bugtracker go like "I want checkbox X in
> pagetype Y". Since Pagetype is essentially only a filter field, this
> should be trivial to implement even without breaking stuff (as Stucki
> pointed out concerning not-in-menu).
I agree. Today the page editing form should have tabs to divide the different
types. Maybe you can justify types like Sysfolder being different.
> 2. Static templates (or at least the old ones), content(default) and
> friends. If there are none, get rid of the static templates select form
> and only use static from extension.
Yes
> 3. Content Elements: search box, login have been superseded by
> index_search and newloginbox (and others). Either replace them or get
> rid of them completely.
Hmm. I agree for modern sites they should be disabled. Yet, they do their
simple job.
> 4. Fields in content elements: Space after/before, Frame, Align? All
> those can be replaced by *one* CSS-class field in which these properties
> can easily be defined for the wrapping div field.
Good.
>
> 5. Typoscript properties: I'm sure there's lots more, but here are some:
>
> XHTML-cleaning, disableImgBorderAttr, page.bodytag etc. - these are ugly
> hacks. Instead, let's make it XHTML strict (or trans for the beloved
> target-attribute which also pops up everywhere in TS) and that's it.
> Yes, HTML 4 is not obsolete yet but why would you need to use this (and
> please don't come up with that legacy stuff again.)? If you think: Why
> can't we just leave it in, please see the condition hell when rendering
> stuff, the various places where tags are changed afterwards, and ask the
> content rendering group.
yes, lets face the future.
>
> xMENU_LAYERS: This may be a personal issue but the configuration is
> horrible, the resulting html not very nice, and most of all: it can all
> be done with a regular xMENU, some CSS and JS.
>
I'm not so sure.
> cObjects: PHP_SCRIPT_x, CTABLE, OTABLE, HRULER?, CLEARGIF???!
In fact PHP_SCRIPT_EXT had a surprising comeback in a discussion I had with
JH, but theoretically yes.
These changes will however not apply to version 4.0. Some might apply to
version 4.5 due to their usability enhancement effect. And all of them - and
possibly going much further - will be the home of version 5.0 in my mind.
Thanks for your input. Maybe others have some dreams about the future? Anyone?
- kasper
BTW: "Think future, not feature" was invented as a slogan for a little sales
speech to the supporting members of the association where I wanted to stress
the point that much of the future core development will not be focused
directly on creating a new gizmo this-or-that but needs to deal with
architecture etc. that can prepare TYPO3 for a long-term life. Hence be an
investment we must trust is for the better.
>
>
> Okay, enough for now. Flame me or add to the list ;)
>
> Greetings,
> Michael
> _______________________________________________
> Typo3-dev mailing list
> Typo3-dev at lists.netfielders.de
> http://lists.netfielders.de/cgi-bin/mailman/listinfo/typo3-dev
--
- kasper
-----------------
Think future, not feature
More information about the TYPO3-dev
mailing list