search

ga-wdi-boston / html-css

High-level overview of HTML and CSS.
Other
4 stars 170 forks source link

Discuss which best practices to introduce #2

Open jrhorn424 opened 9 years ago

jrhorn424 commented 9 years ago

I suggested the following:

These rules may be hard to follow initially, but will become easy to follow with Sass.

jrhorn424 commented 8 years ago

Related #11

gaand commented 8 years ago

From an accessibility perspective, this probably includes using forms for input whenever possible. Screen readers grok forms.

jrhorn424 commented 8 years ago

I want to note that there was a point of confusion with this:

Never use ids for CSS, only JS (this follows Sass style guides and default linter config)

This was parsed by one developer as recently as today as: "Only use IDs for JavaScript, don't use classes". Logically, this is an error; it's not a proper inverse.

Here's the thrust of the mistake:

- use ids only in JS // bad
+ use ids in JS only // good

Anyway, it bears being super careful of this when speaking the rule.

raq929 commented 8 years ago

I would love to add a section about accessibility either in this lesson or in https://github.com/ga-wdi-boston/html-css-layout. Writing accessible HTML is in demand (especially for healthcare and other government sites that have to meet strict requirements), and it often leads to better UI anyway (don't put a thing that blinks more than 3x a second on your screen. No one wants that, even if it won't cause a seizure.) Some quick tips can lead to better HTML/CSS and more accessible sites. I'm curious about your thoughts and where you think it would best fit.

gaand commented 8 years ago

:robot: :speaking_head: it probably needs to be repeated several times. So, it likely belongs in many/most/all html/[s]css material.

jrhorn424 commented 7 years ago

@MicFin Feel free to contribute by opening an issue with any best practices you feel are missing, either before or after delivery, or both. Thanks!