Those HTML Attributes You Never Use

Louis Lazaris - Those HTML Attributes You Never Use

Frontend Architects, like all architects, should have a breadth of actionable knowledge. We should keep a mental library of technical solutions that will help us fulfill our duties, such as:

a) Evaluate ideas and needs coming from Business;
b) Offer more feasible/realistic recommendations;
c) Have leveled discussions with Engineers – if they resist the requested changes.

This last one (c) is a tricky one. If we start giving too many technical solutions to our teams of engineers, we soon start being seen as some sort of “global lead developer”, constantly pulled to assist with technical challenges, which deviates us from our architectural work.

However, without a satisfactory depth and breadth of knowledge we would not be able to (1) properly elaborate the plans that will carry out the business’ directives, (2) help the plans succeed – in case there is a roadblock, and (3) be able to fight back the natural resistance that developers present when new requirements come their way, a discussion that they will naturally win if they hold a much higher technical knowledge. In fact, their respect for our technical expertise is essential for them to get in the boat with us and embrace our recommendations.

To learn new things and keep yourself up-to-date, I recommend some key e-mail feeds, forums, blogs, and professional websites. Among the top ones is the Smashing Magazine. What a great resource!

Recently, when I read the title of Louis Lazaris’ article (Those HTML Attributes You Never Use), I assumed that I would know (or remember) 100% of anything he might’ve mentioned. However, I was surprised to see that it was actually towards 60%. The remaining 40% that I either learned or refreshed through his post, were not merely interesting content. They have the potential to help me carry out my front-end architect’s responsibilities, as discussed above.

So as you read Louis’ article (click here), imagine how those attributes can (a) help shape your architectural recommendations, (b) avoid unnecessary back and forth arguments with developers, (c) enable you to propose solutions for current roadblocks, and so on.

Leave a Reply