textarea onFocus i dziwne zachowanie opery Opcje

[skutlik]

Witam,
mam do czynienia z pewną anomalią której nie potrafię sam rozgryźć, w związku z czym zwracam się do Was o pomoc. Mam taki kawałek kodu

Kod

<textarea name="name" id="id" cols="80" rows="10" onBlur="if(this.value=='')this.value=this.defaultValue;else sprPoprawnosc(this.value);" onFocus="if(this.value==this.defaultValue)this.value='';">

Gdy uruchamiam ten kawałek kodu na localhoscie wszystko works fine, zarówno pod ff jak i operą, natomiast gdy wrzucę na serwer to onFocus nie działa pod operą (pod ff działa bez zarzutu). Gdyby ktoś wiedział o co chodzi, to fajnie by było gdyby podzielił się wiedzą bo mi się już kończą pomysły

opera 10.01
default value w textarea zawiera polskie znaki i nowe linie
kodowanie utf-8
choć to i tak chyba bez znaczenia skoro to samo na localhoscie działa bez zarzutu

Ten post edytował skutlik 10.11.2009, 15:04:53

[erix]

Zerknij do konsoli błędów najpierw, potem prześledź przebieg linia po linii przez DragonFly.

[skutlik]

Dzięki za odpowiedź, w konsoli błędów oczywiście pustki, natomiast w akcie desperacji wpadłem na pomysł napisania enterów "na sztywno" czyli \r\n (samo \n nie działało), teraz działa jak należy zarówno pod ff jak i operą, mam nadzieję że pod unix'ami również tak będzie, ale narazie nie mam tego jak sprawdzić. Nie mniej jednak dzięki za odpowiedź, pozdrawiam i przepraszam za zbędny topic.

Ten post edytował skutlik 10.11.2009, 15:22:34

[erix]

Pod Uniksem tak nie będzie, gdyż wprowadzany jest tylko \n, a nie \r\n jak to ma miejsce pod Windows.

Nie wiem, czy nadal tak jest, ale niektórzy szamani mawiali, że MacOS wysyła samo \r.

[skutlik]

Też tak kiedyś czytałem że mac samo \r interpretuje jako new line, mogliby to w końcu wszyscy ujednolicić ,

Pod Uniksem tak nie będzie, gdyż wprowadzany jest tylko \n, a nie \r\n jak to ma miejsce pod Windows.

Niby tak, ale ff prawidłowo interpretował mi samo \n pod windows'em, liczę więc na to że chociaż te najpopularniejsze przeglądarki działające pod systemami unix'owymi (i na mac'ach) będą poprawnie interpretować \r\n. Zresztą co by nie było dla unix'ów taki ciąg powinien oznaczać biały znak i enter, analogicznie dla mac'ów

[erix]

mogliby to w końcu wszyscy ujednolicić

A wiesz, że idea systemu przerwań w pecetach ma dwa razy tyle lat, co ja? Nie zmienia się czegoś, co mogłoby mieć fatalne skutki jeśli chodzi o kompatybilność wsteczną.

liczę więc na to że chociaż te najpopularniejsze przeglądarki działające pod systemami unix'owymi (i na mac'ach) będą poprawnie interpretować

No wyświetlą prawidłowo nową linię, ale pozostaje jeszcze kwestia liczenia znaków, która nie jest już taka przewidywalna, jak zresztą sam zauważyłeś.

[skutlik]

Nie zmienia się czegoś, co mogłoby mieć fatalne skutki jeśli chodzi o kompatybilność wsteczną.

Zmiany można wprowadzać stopniowo, zachowując w początkowych etapach kompatybilność wsteczną, np. tak jak producenci procesorów przechodzą z produkcją jednostek 32bitowych na 64bitowe - najpierw wprowadzili 64bitowe z obsługą kodu skompilowanego dla 32 bitów a za jakiś czas ta kompatybilność zostanie po prostu zerwana.

pozostaje jeszcze kwestia liczenia znaków, która nie jest już taka przewidywalna, jak zresztą sam zauważyłeś.

na szczęście nie potrzebuję dokładnie zliczać ilość znaków z textarea więc ten problem póki co mogę sobie darować

[erix]

najpierw wprowadzili 64bitowe z obsługą kodu skompilowanego dla 32 bitów a za jakiś czas ta kompatybilność zostanie po prostu zerwana.

64-bitowość polega na rozszerzeniu 32-bitowych procesorów o dodatkowe rejestry; podstawowe pozostają bez zmian. Dlatego aplikacje/systemy 32-bitowe na sprzęcie x64 działają praktycznie przezroczyście. Zapraszam do lektury odpowiednich materiałów.

I żebyś się nie zdziwił, że za 20 lat wciąż będziemy działać na tych samych przerwaniach.