Mailinglisten-Archive |
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