dzek69 napisał(a)
żeby zobaczyć, że wybiera Ci Object Text - co wg tego co piszą w Internetach jest obiektem od inputa z type="text". I za cholerę nie wiem skąd to, ale po usunięciu jakiejkolwiek przerwy między , a <select> Twój kod działałby dobrze
Wybiera pierwszy węzeł (.firstChild) w komórce tabeli, czyli w <td>. Szkopuł w tym, że węzły DOM to nie tylko elementy. To również np. węzły tekstowe. A na początku komórki, przed elementem input, jest jeszcze tekst -- trochę białych znaków (przeglądarki normalizują ciągi białych znaków -- spacji, tabulacji, znaków nowej linii -- do pojedynczej spacji). Więc pierwszym węzłem w komórce tabeli jest węzeł tekstowy z białymi znakami. Stąd ten "[Object Text]". NIE jest to element input typu text, tylko węzeł tekstowy.
Dlatego, gdy przeglądamy DOM, choćby za pomocą childNodes, musimy zawsze odfiltrowywać węzły, które nas nie interesują. Zwykle obchodzą nas tylko elementy, więc powinniśmy sprawdzać, czy dany węzeł ma .nodeType równe 1, co oznacza ELEMENT_NODE (oczywiście, najlepiej zdefiniować sobie pseudo-stałą var ELEMENT_NODE = 1).
Od razu powiem, że taka np. pseudoklasa CSS :first-child się na tym nie wykrzacza, bo ona wybiera pierwszy ELEMENT, a nie pierwszy węzeł. No ale w końcu prawie zawsze stylujemy tak naprawdę elementy. Ze skryptami jest inaczej -- skrypty operują również na tekście i muszą być w stanie pobrać tekst. Dlatego widzą wszystkie węzły, łącznie z tekstowymi. Na co dzień to ździebko niewygodne.
unikalna_nazwa napisał(a)
co to w ogóle za pomysł żeby tak się dopierać do elementów? w ogóle mogłeś zacząć od elementu "window"...
do inputów zazwyczaj się odwołuje opakowując je w formularz <form> i przez
document.forms['nazwa_formularza'].elements['nazwa_elementu']
Eee, czasami szwędanie się po drzewie DOM na różne sposoby nie jest takie złe. Nieraz chcemy wybierać elementy kontekstowo. Przecież korzystając z jQuery, piszemy czasem $this.find("> .foo > input:first-child").
Gdy pracuje się z tabelami, często używa się .rows i .cells. Nie ma w tym generalnie nic złego. Ja w ogóle uważam, że w wielu miejscach użycie kontekstu jest znacznie lepsze niż spamowanie ID-kami na siłę tylko po to, by móc użyć document.getElementById, co jest charakterystyczne dla script-kiddies.
Zauważ, że document.getElementsByName('nazwaSelecta') po pierwsze zwraca nie jeden element, a kolekcję, więc trzeba by coś z tym zrobić (choćby dodając [0] :P), a po drugie... Mogłoby wprowadzić swoje własne zależności. Może tabela czasem ma 3 wiersze, a czasem 50? Jak sprawdzać, czy się skończyła? Strzelać w inputy o name równym lstBasic, lstBasic2, lstBasic3 i tak dalej, aż zwróci nam pustą listę? Ale wtedy w tabeli nie będzie mogło być luk. A może iterować index po rows.length i na podstawie index zbudować nazwę elementu? Ale wtedy gdy dojdzie nam jakiś wiersz wprowadzający/nagłówkowy, to skrypt trzeba będzie zmodyfikować.
Nie to że tworzę problemy na siłę -- mówię tylko, że różne sposoby mają swoje plusy i minusy. Pisząc skomplikowaną aplikację musimy dokonać analizy kompromisów. Czasami wychodzi, że wybór elementów w oparciu o strukturę DOM da największe korzyści. Prawie nigdy nie jest tak, że trzeba wybrać element wyłącznie w oparciu o jego położenie, bo to dopiero bywa fatalne. Ale w niektórych przypadkach np. wybór "nagłówka poprzedzającego element X", gdzie element X wybieramy przez klasę, to dobre rozwiązanie.
Masz rację, autor się w tym wszystkim trochę nie połapał (jak widać), ale mi się podoba to, że próbuje i uczy się również nieskopoziomowych metod. Dobrze wiedzieć, co się dzieje na niższym poziomie niż wywołania jQuery.