[CSS]Dynamische gegenereerde id's juist weergeven

[The Great HooD]

Ik ben een site in Python m.b.v. Django aan het maken waarbij ik de CSS op orde moet brengen.
Nu heb ik een 4-tal componenten, waarbij er een bepaalde soort codering op uitgevoerd wordt.

code:

<label for="id_question_o_1">When was the picture taken?</label>
<input id="id_question_o_1" type="text" name="question_o_1">

Waarbij de nummers dynamisch gegenereerd worden, en de letter voor het nummer staat voor de soort vraag.

Wat ik me afvroeg of je dat nummer kan afvangen zodat je alleen de id_question_o afvangt waarbij het nummer dus niet uitmaakt wat het is, wat ook niet uitmaakt in mijn applicatie.

Bijvoorbeeld in SQL kan je dat nummer vervangen door een * en dan maakt het niet uit wat voor nummer er staat...

[Kard]

Is het geen mogelijkheid om classes te gebruiken? Volgens mij zijn die voor zulk soort situaties bedoeld. Als je bijvoorbeeld elk element met zo'n id de class question_o (of gewoon question voor alle soorten vragen) meegeeft, kun je ze allemaal in één keer 'aanspreken' in CSS.

[T-MOB]

Dat kun je met een attribute selector doen:

Cascading Stylesheet:

label[id^=id_question] { color: red; }

Zie hier voor compatibility en hier voor meer selectors

[David Mulder]

Wel moet je weten daarbij dat dat alles behalve snel is@de soort selectors die T-MOB voorstelt en het slimmer is om bijv. classes te gebruiken (attribute selectors zijn ook nog wel ok, maar subqueries op attributes worden al snel redelijk traag).

[marko77]

Volgens mij wil TS gewoon weten hoe hij de labels tegelijk kan stylen. Dan heb je niet eens een select nodig.
Een class toekennen aan de labels maakt het wel overzichtelijker, maar meer dan dat is zeker niet nodig.

ID based stylen is alleen bij uitzonderingen nodig, zeker bij labels.

[Mastermind]

The Great HooD schreef op vrijdag 18 november 2011 @ 16:49:
Wat ik me afvroeg of je dat nummer kan afvangen zodat je alleen de id_question_o afvangt waarbij het nummer dus niet uitmaakt wat het is, wat ook niet uitmaakt in mijn applicatie.

Je zou alle input elementen-van het document kunnen opzoeken met Javascript, door middel van var inputElements = document.getElementsByTagName("input");

Dat retourneert een array van elementen, waar je doorheen kunt loopen. Dan haal je de ID op met var id = inputElements[i].getAttribute("ID");

met een substring op de id kun je vervolgens kijken of het element met "id_question" begint zoja, dan is het er een.

[OkkE]

Leuk al die "oplossingen", maar hier zijn classes voor bedoelt, zoals Kard al direct zei; al het andere zijn work-arounds voor slechte HTML.

[T-MOB]

OkkE schreef op woensdag 23 november 2011 @ 16:59:
Leuk al die "oplossingen", maar hier zijn classes voor bedoelt, zoals Kard al direct zei; al het andere zijn work-arounds voor slechte HTML.

Je kunt erover discussieren wat lelijke HTML is, het koppelen van labels aan input elementen vind ik niet bepaald slechte HTML. Het toevoegen van een class maakt dat niet per se mooier. Maar goed, je hebt niet altijd controle over de HTML. TS geeft aan dat hij de CSS op orde moet brengen. De oplossing in louter CSS is dan wel handig (al is het alleen maar voor iemand die dit topic later tegenkomt).

Daarnaast betwijfel ik of er een performanceverschil is tussen het gebruiken van [for=^bla] en het toevoegen van een extra class*. Ik kan me daar weinig bij voorstellen, op het web kon ik er ook niets echt iets over vinden. Als iemand daar een bron voor heeft, dan graag...

* In javascript uiteraard wel, omdat je daar vaak native functies hebt voor id- en classlookups. Maar met querySelector() en querySelectorAll() gaan ook css-selectors een native implementatie gaan krijgen.

[Janoz]

T-MOB schreef op donderdag 24 november 2011 @ 11:23:
Je kunt erover discussieren wat lelijke HTML is, het koppelen van labels aan input elementen vind ik niet bepaald slechte HTML. Het toevoegen van een class maakt dat niet per se mooier.

Het gaat dan ook niet over het wel of niet koppelen van labels of het weghalen van de ID. Waar het om gaat is dat TS alle velden met id "id_question_o_*" op een bepaalde manier wil style omdat het allemaal vragen van het type 'o' zijn. De juiste oplossing daarvoor is, om naast het id ook gewoon de class "question_o" op te nemen en deze voor het stylen te gebruiken. Het toevoegen van een class maakt het dus wel degelijk mooier aangezien je niet allemaal javascript of selector meuk nodig hebt om alle vragen te kunnen stylen.

[OkkE]

T-MOB schreef op donderdag 24 november 2011 @ 11:23:
Je kunt erover discussieren wat lelijke HTML is, het koppelen van labels aan input elementen vind ik niet bepaald slechte HTML. Het toevoegen van een class maakt dat niet per se mooier.

Zoals Janoz ook al aangeeft en wat ik bedoelde: als je een aantal elementen het zelfde wil stijlen hoor je daar gewoon classes voor te gebruiken. Sowieso is het goed om zo min mogelijk IDs te gebruiken voor stijling.

Daarnaast betwijfel ik of er een performanceverschil is tussen het gebruiken van [for=^bla] en het toevoegen van een extra class*. Ik kan me daar weinig bij voorstellen, op het web kon ik er ook niets echt iets over vinden. Als iemand daar een bron voor heeft, dan graag...

Hier de performance van verschillende CSS selectors: http://csswizardry.com/20...-efficient-css-selectors/

[T-MOB]

Janoz schreef op donderdag 24 november 2011 @ 11:39:
[...]
Het gaat dan ook niet over het wel of niet koppelen van labels of het weghalen van de ID. Waar het om gaat is dat TS alle velden met id "id_question_o_*" op een bepaalde manier wil style omdat het allemaal vragen van het type 'o' zijn. De juiste oplossing daarvoor is, om naast het id ook gewoon de class "question_o" op te nemen en deze voor het stylen te gebruiken. Het toevoegen van een class maakt het dus wel degelijk mooier aangezien je niet allemaal javascript of selector meuk nodig hebt om alle vragen te kunnen stylen.

Juist, maar als al die vragen al id_question_o_* hebben - omdat de serverside dat nu eenmaal genereert - zie ik niet in wat er mooier aan is (of enig ander voordeel) om er ook nog een class aan te hangen. En qua "selectormeuk" valt het reuze mee. Minder leesbaar is het iig niet:

Cascading Stylesheet:

label[for=^id_question_o] { }
input[id=^id_question_o] { }
/*versus*/
label.id_question_o { }
input.id_question_o { }

Waarbij je voor de laatste optie ook je markup moet aanpassen.

Ik wil overigens niet beweren dat je een applicatie ook zo zou moeten ontwerpen, integendeel. Ik ben het er helemaal mee eens dat type-informatie eigenlijk niet in een id thuishoort. Maar als dat toch al gebeurd is, zoals in de app van de TS, dan vind ik dat je daar best mee kunt werken. Sterker nog, ik kom liever code tegen waarin een ongelukkige initiele keuze consequent is doorgewerkt dan code waarin die keuze half is weggewerkt (dit idee: <input class="question_A" id="question_B_1"> ). Maar goed, dan doe ik wat aannames over de achterligggende code die niet hoeven te kloppen.

[T-MOB]

OkkE schreef op donderdag 24 november 2011 @ 12:14:
[...]
Zoals Janoz ook al aangeeft en wat ik bedoelde: als je een aantal elementen het zelfde wil stijlen hoor je daar gewoon classes voor te gebruiken. Sowieso is het goed om zo min mogelijk IDs te gebruiken voor stijling.

Je "hoort daar niet gewoon classes voor te gebruiken". Je kunt daar classes voor misgebruiken. Het idee van CSS is dat je een scheiding aanbrengt tussen markup en layout. Idealiter voeg je dus een class in omdat een element een bepaalde functie heeft, of van een bijzonder type/klasse is - en dus niet omdat je een bepaalde layout wil bereiken. Als de bijzondere functie al uit de context blijkt heb je geen klasse nodig. Je geeft niet alle plaatjes in een link een class omdat je ze een randje wil geven (dan gebruik je gewoon a img). Waarom zou je dat dan wel doen voor input[type=text] of eender welk element dat je met leesbare selectors kunt benaderen?

Hier de performance van verschillende CSS selectors: http://csswizardry.com/20...-efficient-css-selectors/

Ik twijfel er niet aan of .class sneller is dan [attr^=foo] - browserbouwers hebben ongetwijfeld optimalisaties voor class selectors ingebouwd. Maar in het geval van TS moet de klasse ook nog worden toegevoegd. Je krijgt dan dus ook de extra overhead van het parsen van de klasse en het bijhouden van die klasse in de DOM. Het zijn pico-optimalisatie die imho nauwelijks boeiend zijn, maar GreatSlovakia beweerde dat de attribute selector "redelijk traag" zou zijn.

[Janoz]

T-MOB schreef op donderdag 24 november 2011 @ 12:19:
Juist, maar als al die vragen al id_question_o_* hebben - omdat de serverside dat nu eenmaal genereert - zie ik niet in wat er mooier aan is (of enig ander voordeel) om er ook nog een class aan te hangen.

Dan verschillen we daarin van mening.

[Arjan321]

T-MOB schreef op donderdag 24 november 2011 @ 12:19:
[...]
Juist, maar als al die vragen al id_question_o_* hebben - omdat de serverside dat nu eenmaal genereert - zie ik niet in wat er mooier aan is (of enig ander voordeel) om er ook nog een class aan te hangen.

Dan verwijder je toch de id?

offtopic:
(moet de layout dit natuurlijk wel toestaan)

code:

<label>When was the picture taken? <input class="question_o" type="text" name="question_o_1"></label>

werkt exact hetzelfde

[ Voor 6% gewijzigd door Arjan321 op 24-11-2011 13:43 ]

[Bosmonster]

Arjan321 schreef op donderdag 24 november 2011 @ 13:42:
[...]
Dan verwijder je toch de id?

offtopic:
(moet de layout dit natuurlijk wel toestaan)

code:

<label>When was the picture taken? <input class="question_o" type="text" name="question_o_1"></label>

werkt exact hetzelfde

Implicit labels zijn een afrader. Dus werkt hetzelfde, maar wordt er niet mooier op

[ Voor 6% gewijzigd door Bosmonster op 24-11-2011 13:52 ]

[OkkE]

T-MOB schreef op donderdag 24 november 2011 @ 12:19:
Juist, maar als al die vragen al id_question_o_* hebben - omdat de serverside dat nu eenmaal genereert - zie ik niet in wat er mooier aan is (of enig ander voordeel) om er ook nog een class aan te hangen.

Wat nu als er vragen toegevoegd worden met een andere opbouw van ID? Dan moet je ook de CSS aanpassen.

Classes geven je meer flexibiliteit. Veranderen om wat voor reden je IDs, blijft je vormgeving overeind zonder wijzigingen. Wil je een deel van de elementen een andere stijl geven, een Class toevoegen en klaar, in plaats van een hele lijst aan IDs (die je elke keer als er een element bij komt ook weer moet updaten).

[T-MOB]

OkkE schreef op donderdag 24 november 2011 @ 14:09:
[...]
Wat nu als er vragen toegevoegd worden met een andere opbouw van ID? Dan moet je ook de CSS aanpassen

Ja, dat moet je ook als er vragen worden toegevoegd met een ander class.

Classes geven je meer flexibiliteit. Veranderen om wat voor reden je IDs, blijft je vormgeving overeind zonder wijzigingen.

Ja, veranderen om wat voor reden dan ook je classes dan stort ook de hele boel in. Het punt is juist dat die ID's voortvloeien uit de werking / opzet van de applicatie. Die veranderen dus niet zomaar. Dan kun je de applicatie verbouwen zodat de type-informatie in een class terecht komt ipv in een id. Of je laat het voor wat het is en je gebruikt een attribute selector op het id: [id^=question_o] {} versus .question_o {} in je CSS. In mijn optiek is dat precies waar al die handige selectors voor bedoeld zijn.

Wil je een deel van de elementen een andere stijl geven, een Class toevoegen en klaar, in plaats van een hele lijst aan IDs (die je elke keer als er een element bij komt ook weer moet updaten).

Je hoeft niet alle id's apart te benoemen. [id^=question_o] matcht alle id's die beginnen met "question_o".

[The Great HooD]

Kickje

De eerste optie werkte bij mij uitstekend!

Echter zijn dit nieuwe CSS regels dus worden de oude browsers IE6, 7 ,8 niet ondersteund, terwijl die wel ondersteund moeten wroden. Mijn site wordt voor 80% door dit soort browsers bekeken ( Ja ik weet het )

Is er nog een manier om dit op te lossen dan?

[C0rnelis]

De tweede optie? Er is meer dan 1 optie aan bod gekomen in dit topic, nietwaar?