1 Reactie door David Hund

(9 reacties, geschreven in Front-end technieken)

Meerdere H1's per pagina is in HTML5 toegestaan en, indien juist gebruikt, heeft geen nadelige gevolgen voor je (Google) ranking.
Als je HTML5 sectioning en de 'outline' een beetje duidelijk is dan lijkt er zelden noodzaak voor het gebruik van H3+.

Dat wil niet zeggen dat je H1's *moet* gebruiken voor elke nieuwe sectie. Het lijkt mij het meest logisch, maar als je b.v. een H2 gebruikt dan *kan* dat net zo goed: deze H2 wordt dan echter wel 'geïnterpreteerd' als een 'first-level' H1...

Er zijn een aantal bezwaren tegen meerdere H1 elementen op 1 pagina, de meeste vanuit het oogpunt van toegankelijkheid. Screenreaders ondersteunen het HTML5 outline algoritme nog niet wat betekent dat deze geen duidelijke Heading hierarchie kunnen weergeven. Omdat sommige blinde gebruikers van screenreaders het fijn vinden om 'over headings te springen' is dit een nadeel.

Ik heb hierover gesproken met een blinde developer die ik ken en hij raadde mij aan hier niet teveel gewicht aan te geven: het is de verantwoordelijkheid van screenreaders om de spec te gaan ondersteunen en daarnaast dacht hij dat het aantal blinde gebruikers dat hierdoor 'in de problemen' zou komen erg gering is. Zoals altijd: probeer een zo goed/duidelijk mogelijke structuur aan te brengen in je content en je vermijdt veel problemen.

To conclude: ik vond (zoals bijna altijd) een uitstekende omschrijving over Secties en de Outline op MDN.

Ga naar forum: Front-end technieken

2 Reactie door David Hund

(7 reacties, geschreven in Front-end technieken)

Ja <legend> is (zoals je ongetwijfeld weet) <del>een bitch</del><ins>vervelend</ins> om te stylen. Of is dat inmiddels anders? Bovendien is een Hn toch semantisch net zo waardevol (of mis ik iets met AT [ARIA] ?)

Ga naar forum: Front-end technieken

3 Reactie door David Hund

(22 reacties, geschreven in Front-end technieken)

Ik sluit me helemaal aan bij Egor: mijn voorkeur gaat ook uit naar LESS omdat het 'dicht bij CSS blijft'  en niet meer doet dan ik(!) wil.

Verder ben ik meer van de 'compile at build time': en dat kan met tools als Less.app prima (met compass etc. natuurlijk ook).

In het begin liep ik met LESS nog wel eens tegen bugs aan zoals het feit dat de syntax voor CSS animaties en Media Queries compilatie brak enzo maar tegenwoordig gaat dat veel beter.

De uiteindelijke CSS is erg afhankelijk van hoe je het gebruikt denk ik. Ik gebruik LESS zoals gezegd heel selectief (enkele mixins, variables en wat calcs. enz) en vind de output reuze meevallen.

Anyway, ik kan weinig toevoegen aan Egor's conclusie behalve dat ik denk dat je in een team uiteraard dit samen moet afspreken. Het lijkt mij persoonlijk vervelend als ik nu opeens met de SCSS file van iemand anders moet werken terwijl ikzelf een beetje een LESS workflow heb gemaakt wink

Ga naar forum: Front-end technieken

4 Reactie door David Hund

(7 reacties, geschreven in Front-end technieken)

Ziet er prima uit Thijs, formstyling blijft nou eenmaal een b%tch.

Ik gooi meestal de inputs in de labels en gebruik zelden lijstjes maar vaker p elementen (klopt niet echt, I know) of gewoon div's.

Wat ik wel wat vaker doe is, in een label, nog een spannetje zetten met daarin de labeltekst. Dus: <label><span>text</span><input/></label>

Dit stelt mij in staat om met 1 class de labels zowel boven als naast de inputs te zetten.

Verder gebruik ik voor het sterretje* vaak de tekst "(verplicht)" in een span of em (semantischer) en verander ik die in een "*" sterretje met :after{content: "*";} maar dat is natuurlijk geneuzel wink

Ik gebruik niet zovaak (meerdere) fieldsets en legend al helemaal niet. Daar gebruik ik (net als jij) gewoon een Hn voor.

Ga naar forum: Front-end technieken

5 Reactie door David Hund

(18 reacties, geschreven in Front-end technieken)

Ik denk dat het goed is om op te merken dat personen op verschillende maniere leren. Terwijl de een veel oppikt van het doorlezen van Specs leert de ander misschien veel meer van trial-and-error (+feedback).

De absolute basis ("wat is HTML, CSS?" etc.) wordt idd. snel opgepakt met b.v. het Opera Curriculum[1]

Ik denk dat het voor vrijwel iedereen enorm fijn is om een stukje "op sleeptouw" genomen te worden door een ervaren front-ender: een paar tips van een "mentor" scheelt uren lees- en probeer-tijd.

Tegenwoordig zou ik ook niet teveel terugschrikken om mensen gewoon naar de Specs te verwijzen.

Maar daarnaast heb ik - en ik weet veel anderen ook - altijd veel geleerd van view:source (met alle gevaren van dien smile )

[1] http://dev.opera.com/articles/view/12-t … s-of-html/

Ga naar forum: Front-end technieken