As you're all probably aware there has been some discussion recently
about the kss based content tab switching feature in Plone 3. I have
tried to get a good grasp on the situations and this is what I came
up with.

This discussions revolves around the implementation of PLIP 121 . This PLIP documents
a single reason for doing in-place replacement of the content view:
performance. Only reloading the content view but keeping the rest
of the page in place should be a lot faster.

Looking at the current situations there are a few problems:

- the in-place loading behaviour breaks the back button. This breaks
  user expectations and leads to frustration. 
- one of the risks mentioned in the PLIP mentions is that the tabs are
  no longer bookmarkable but says that we are willing to sacrifice this
  for the speed benefits. Later user testing has revealed that this
  might not be acceptable.
- at this moment the in-place reloading is not faster. The AT edit forms
  are too heavy, so loading the edit tabs takes long enough to negate
  any benefits from not reloading the whole page.
- javascript triggers do not work correctly when replacing the content
  (autofocus, form unload protection)

This makes me think that at this moment we should not ship with the
in-place content tab replacement functionality enabled. The concept is
still good, but in order to realize the desired benefits we need more
extensive work: the edit forms have to become a lot simpler and cleaner
and we need to find a way to keep the browser history updated so the
back button keeps working. We might be able to take some inspiration
from what gmail does. It is definitely a direction in which we should be

Opinions? Thoughts?


Wichert Akkerman <[EMAIL PROTECTED]>    It is simple to make things.                   It is hard to make things simple.

Framework-Team mailing list

Reply via email to