Jeśli Margaret
i Olivia
są to jakieś dane z JSON, to należałoby założyć, że nie znasz tych danych. A tymczasem w stylu masz klasę:
.Margaret-data,
.Olivia-data {
display: none;
}
i podobne.
Czyli z jednej strony robisz stronę, która zachowuje się dynamicznie i pobiera dane do wyświetlenia z JSON, a tymczasem masz w CSS na sztywno napisane nazwy klas na podstawie danych z JSON. Nie ma to większego sensu. Zamiast tworzyć osobne klasy CSS do każdego nazwiska, wystarczyłoby wymyślić jakąś wspólną klasę, jakąkolwiek, nawet niech to będzie klasa candidate
, jeśli to są kandydaci.
Dalej. Jeśli piszesz tego rodzaju brudny kod (funkcja z wieloma podobnymi instrukcjami):
https://github.com/krystianwojtowicz/nested-list-from-api/blob/f9eb47fa1dfc9bd0baf4d182b6f2663839ac878d/index.html#L66
to dobrze jest stawiać entery po każdym logicznym kawałku. Wtedy ta sama funkcja, ale od razu bardziej czytelniejsza się robi. Już nie mówię o jakimś większym refaktoringu/wydzielaniu funkcji itp., ale choćby te głupie entery, żeby było od razu widać, który appendChild dotyczy którego createElement. Bo teraz to jest strasznie nieczytelne.
Dalej. Jeśli potrzebujesz mechanizmu pokaż/chowaj, to nie musisz tego emulować za pomocą checkboxa, ponieważ w HTML masz to z automatu za pomocą tagu <details>
:
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/details
Co do styli, to tego rodzaju selektory jak input
czy ul li
i inne podobne dotyczą wszystkich elementów danego typu. Więc jak walniesz coś takiego w CSSach:
input {
display: none;
}
to sprawisz, że jakikolwiek input
na stronie będzie domyślnie ukryty. Co sprawi, że jak o tym zapomnisz, to możesz mieć później zagwozdkę "czemu dodałem inputa, a on jest niewidoczny? Tutaj więc zamiast stylować po tagach, lepiej nadać jakąś klasę CSS tym konkretnym inputom, które powinny być domyślnie ukryte.