phpbar.de logo

Mailinglisten-Archive

Re: AW: [php] iframe überdeckt restlichen inhalt der tabelle..

Re: AW: [php] iframe überdeckt restlichen inhalt der tabelle..

Ringo Großer swek at gmx.net
Fre Jan 21 16:41:26 CET 2005


hallo,

Lars B. wrote:
> also so ganz hab ich dass ja nicht verstanden was du meints, aber mit
> target kannst du da natürlich nicht arbeiten...

typisches beispielproblem: die warenkorb-darstellung in einem shop.

1. frameless
- vorteile: sind allen beteiligten scheinbar klar
- nachteile: die seite muss für das ablegen eines artikels und
aktualisierung
des warenkorbes komplett neu geladen werden. der nutzer verliert die
letzte scroll-position in der artikelliste

2. frames
- vorteile: der warenkorb kann in einem eigenen frame dargestellt und dort
ggf.
aktualisiert werden, indem nur dieser frame neu geladen wird.
die scrollposition des nutzers bleibt erhalten, sofern keine extra
warenkorb-seite
geöffnet wird
- nachteile: frames und die vielen sorgen, welche sie so mit sich bringen
;-)


ich habe die frage "frames oder nicht frames?" für mich selbst bereits
entschieden,
trotzdem steht man mit jedem neuen projekt vor einem kunden, bei dem man
überzeugungsarbeit leisten oder sich dessen wünschen fügen muss... "warum
scrollt
das menü denn weg?"

und da grad noch das stichwort "barrierefrei" fiel... richtig lustig wirds
dann, wenn
ein unbedarfter grafiker das layout vorlegt und ich das umsetzen soll. also
immer
schön zentriert und mit fixem border. weil dynamische fenstergrößen und
auflösungen
haben die nutzer ja nicht ;-)
andererseits muss man dem layouter zugestehen, dass er ggf. von lese-layouts
mehr
ahnung hat also die meisten hier. dazu zählen kontraste, schriftgrößen,
zeilenabstände
und zeilenlängen. und da sind wir eben bei dem problem: dynamische fenster
vs.
fixer inhalt... aber das geht nun etwas OT.

regards, Ringo



php::bar PHP Wiki   -   Listenarchive