The problem

The DNA of the web is user interface but the DNA of websites is HTML

Issues with HTML as a building block of websites

• Browsers had to write interpreters for web coding languages before the web became universal popular, so the majority of the lasting decisions on the html standard weere made without the foreknowledge of what the web could be, href= 'hypertext reference', 'a' anchor for a web link. Based on naming conventions and suppositions of a small group of decision makers at a particular moment in history.
• Additions to HTML standards were done in a legitimately conservate way to preserve compatability and momentum, consistency etc.
• Falls into the Prescriptivist/descriptivist trap in linguistics.
• Example: Académie française, french institute that acts as a watchguard on the usage of french language, voices opinion to government about the 'corruption' of the language based on common usage, foreign influences, etc. http://en.wikipedia.org/wiki/Acad%C3%A9mie_fran%C3%A7aise#Role_as_authority_on_the_French_language
• Another http://instruct.westvalley.edu/lafave/DFW_present_tense.html

Not completely semantic

• Examples: hgroup, ul, li, href,
• What would the logical children elements for these elements be?
• TR > TD (What is a td anyone know?)
• Hgroup > h1 h2 (How does this make sense?)
• UL > LI (Why? Who thought of this?)
• There's nothing semantic about an hgroup. It' as idiomatic as me referring to a group of people a a pgroup. Maybe over time my friends could get used to me saying this, but why should they?
• Who here refers to links as "hypertext references", yet now HREF is codified. And links are 'a' as in short for anchor?
• Ok this may be taking things overboard but its to prove a point, that coding language is unconventional

Incompleteness compels developers to add their own conventions

• Everyone who codes front end knows the possible minefield you encounter when collaborating on a large project.
• Every developer is king of their own naming domain, and has idiomatically created their own schemas for naming everything. Everything on the site had at some point to be subjected to their own naming decisions. These decisions could be influenced by personality, culture, what mood their in, etc.
• How many ways can we say the same thing?

• Example: A modal has just poped on the screen. What should it be called?

  <div id="modal_visible"> <div id="login"> <div class="pop_up_login"></div>

• All of these are correct by nature, but why are we redefining everything?

How to fix the problem

A semantic approach

Well if progressing html isnt the future of a re-useable, semantic web than what could be?

What's good from HTML

• A good way to approach what's useful is to look at whats used.
• People really liked 'ul' and 'li' for explaining grouping. All sorts of things people dont usually think of as lists seem to find representation in html usage as Unordered list is a slightly obtuse concept, but perhaps there's something in the nature of defining a plural and singular relationship.
• Classnames appear to be the most useful aspect of code because they allow for everything. A catch-all for all the things html hasnt defined.

Some presumptiveness

• HTML and CSS are languages used to describe structural relations and appearances, which is a much easier task to accomplish than giving a more abstract explanations of behavior or instructions.
• Physical, declarative langauge was one of the first aspects of language to evolve. Think caveman running into a cave and saying "two big tiger". this is enough to convey to the other caveman to run further into the cave.
• Language have been selected for and evolved since prehistoric times. Its terse, universal, and selected for by convention and usage not top-down.
• How many words do you need in a vocabulary? To read a chinese newspaper you need around 4,000 characters. That's good enough for describing most anything you will encounter or experience. And thats damn near everything in the world! We only need to account for a language and (definition) for a website, which needs a much much smaller subset of language. Maybe even a hundred or so discrete element definitions.
• For proof that this concept is viable, and that not all the web is idiosyncratic, and unable to be defined in common ui, look at the success of Twitter's Bootstap library, which paved the way for reusable UI components.
• These UI elements can be defined in language anyone can understand. Dropdowns, Modal, Button Groups. These are all parts of the english vernacular that did not exist two decades ago, but miraculously has evolved as language has adapted to fill in the gaps. This is what should inform our naming decisions in code. Usage.

How we actually do the dirty business of making a semantic standard for ui

• Define a set of elements as nouns. "ui button", "ui field" "ui form"
• Define a set of modifiers that are universal and carry the same meaning (when appropriate). i.e. if "large" means 20px tall. Then anything that is large should be 20 pixels tall, ex1. "large button", "large header". ex2. red. "grey field", "grey button".
• Assume prototypical qualities if no modifiers present. I.e. If i ask you to imagine a bunny, you probably imagine a white furry animal with 2 long ears." without having to imply all those characteristics. In the same way the definition of "button" should account for all the prototypical qualities while the modifiers only the modifying qualities.
• Reduce language complexity (KISS) by defining relationships using plural/singular relations. We dont go around saying "there is a large man and a large man and a large man", you just say "There are three large men". in the same way "
  " can define the size and proportions of its children elements more succinctly then classing them all.
• Avoid jargon and idiomatic expressions, stick to common usage. (Keep the ego out)

Once you create a visual vocubulary

• If you can define a standard for a button, say that it can be either tiny, small, medium, big, large, huge or gigantic. Or it can be red, yellow, green, or blue. Then the task for a front end developer becomes explaining how this website's definition of a button strays from standard, not redefining what a button is from scratch over and over.
  
• This task now only requires them redefining the modifiers, not the button element, or any of the causal relationships.
• Once a consensus spec is built for user interface. Then modules have predefined ui components to work with. No arbitrary selectors, or redefining ui elements on a module level. If a modal needs a button then it would use

As it would exist

• Nouns are classnames, modifiers are also classnames
• All ui elements are subclass "ui" to avoid collissions.

As it might exist

• Nouns are tags and always end in a noun, modifiers precede them. <two large button> <button>one</> <button>two</> </>

Why try to fix this problem

Its important to acknowledge there has been lots of work which has attempted to solve this already. Or to take these techniques at heart when creating a language. The higher order-ness of SQL for example "SELECT FROM TABLE WHERE CONDITION"

Make coding more accessible

There have been numerous make programming accessible, KhanAcademy, Code Academy, meetup groups. Gamification. All these problems are great, but solve the issue of making learning programming more difficult Tackling the issue of making programming less difficult is a separate issue entirely. This has been tackled in the past from the perspective of gurus helping making programming less difficult for gurus, i.e dart/cofeescript, or less/sass, but has not been tackled much for making languages easier for complete beginners.

stopped writing for time constraints.