==Part 1: Choose the problem that your language will solve==# What problem Navigation bars are you addressing? First, describe the context and the general nature a standard feature of the problemmany web pages. Then describe a instance of the problem: depending on your problemIn recent years, you may want to## show a fragment somewhat standard paradigm has developed of ugly code that you want using unordered lists to improve create them. The lists are then styled with your language, or## describe CSS to give them a code development scenario that your language will make less tedious and more automatic. ## missing features that you want to add to a language; say what these features would allow that is not possible (or too hard to do) today.# Argue why this problem is hard. For example, the code example you show may be obviously ugly, but do programmers indeed find it difficult to write this code, or to debug it?# Argue why this problem is worth solving. Aren't there simpler solutions than designing a language? For exaple, it may be possible to work around the problem, sidestepping it by switching to a different, existing language. Of course, switching languages is not always possible, which motivates embedded languages and tools for dealding with existing languagestraditional appearance.

Navigation bars are Accomplishing this in a good-looking and cross-browser-compatible manner is not trivial and requires a standard feature fair amount of many web pagesCSS fiddling. In recent yearsFurthermore, the HTML code which must be written to set up the navigational elements contains a somewhat standard paradigm has developed fair amount of using unordered lists, extraneous markup which are then styled with detracts from getting a clear picture of the navigational elements and their actions. Yet another problem is that the CSS and HTML code live in separate files, requiring the user to have two separate documents open to give them a more traditional appearancedesign their navigational bars.

Accomplishing this in In addition, navigational menus can often contain submenus for a good-looking and cross-browser-compatible manner is not trivial and structured hierarchy. This requires a fair amount of CSS fiddling. Furthermore, the HTML code which must be written additional javascript coding to set up work properly and further detracts the navigational elements contains a fair amount of extraneous markup which detracts web page designer from getting a clear picture concentrating on accomplishing his task; namely, working on the actual ''design'' of the navigational elements and their actionsmenu.

FurthermoreThe problem that we seek to address is that designing navigational elements in HTML is needlessly complicated and requires too much plumbing. Therefore, navigational menus can often contain submenus for we have implemented a language with a structured hierarchy. This requires additional javascript coding special syntax designed specifically to work properly make this process easy and further detracts the web page designer from concentrating on accomplishing his task; namely, working on the actual ''design'' of the menufun.

For comparison, here's an example of a very simple group of navigational links:;HTML<pre><nowiki><div id="social"><ul id="socialinks"><li><a href=Part 2: Study "/one.htm">One</a language that solves ></li><li><a similar problem and describe it in this homeworkhref="/two.htm">Two</a></li><li><a href="/fun/">Fun</a></li># One simple code example. Your comments must sufficiently explain the meaning of the code.</ul># Describe the implementation. (Two paragraphs and pseudocode of the implementation.) </div></nowiki></pre>

==Part 3: What features specifically will your language support==;Corresponding CSS<pre><nowiki># The domain. Give a list of a few small programs that you hope to be able to write in your language. These will guide your language design.social { background: # Give an outline of the programming model of your language. What are the "objects" in your language? What operations on these objects will you allow? How will you combine small programs into bigger ones, hiding the implementation details of the smaller ones (what abstraction mechanism will you support, if any?).6d6d6d; color: white; padding: 1em 0px; margin: 0px auto; clear: both; bottom: 0px; position: absolute; width: 100%;}

==Part 4ul { margin: 0px auto; padding: 0px; list-style: none; min-width: 15em; text-align: center;} li { display: inline; margin: 0px; padding: 0px;} li a { padding: 0.25em 0.5em; margin: 0px; text-decoration: none;} li a { color: #82c753; } li a:hover { background: white; text-decoration: underline;}</nowiki></pre> ;To produce the following[[Image: Decide on navbar.png]] Note that there is a lot of information here which is rather superfluous. If we want to add an element here which is not linked, the CSS becomes more involved. Furthermore, adding things like submenus is far from trivial and requires knowledge of JavaScript and avoiding a number of pitfalls to deal with different browser vendors. Our solution seeks to abstract away all of these problems with a simple syntax which makes the implementation==important things clear immediately. The example above simply becomes:<pre><nowiki>{ color: #82c753; background: #6d6d6d; text-decoration: none; padding: 0.25em 0.5em; hover: { background: white; text-decoration: underline; };layout: horizontal; }*One | /one.htmChoose *Two | /two alternative implementations.htm*Fun | /fun/</nowiki></pre> The formatting definition immediately preceding the list of items contains CSS properties in <tt>property: value</tt> format separated by semicolons. <tt>hover</tt> is a special keyword whose value is another set of definitions applied to hovered navbar elements. <tt>layout</tt> is another special keyword whose value is either <tt>horizontal</tt> or <tt>vertical</tt> and controls whether the navbar elements are shown side-by-side or one above the other, respectively. The navbar elements are delimited by a newline and an asterisk and consist of a string of text (for the title of the navbar item) followed by a pipe and compare them along these aspectsthen the URL for the item. The URL is optional and leaving it out results in an item which does not link to anything. This can be useful for drop-down menus. Creating hierarchical menus is simple. For each aspect, write example:<pre><nowiki>*Item one{ direction: below }**Submenu item one | /submenu/one.htm**Submenu item two | /submenu/two.htm**Submenu item three | /submenu/three.htm{ direction: left }***Subsubmenu item a | /submenu/sub/a paragraph. Your htm*Item two | /two approaches may .htm</nowiki></pre> By default, all the submenus inherit the styles of their parents. If this is not desired, properties to override can be identical specified in some aspectsthe curly braces. The <tt>direction</tt> keyword shown above simply controls where the submenu appears relative to its parent item. In the example above, the "Submenu item one/two/three" elements appear below the navbar containing "Item one/two", and the "Subsubmenu item a" appears to the left of that menu.* frontend: How This problem is worth solving because it allows web developers to save time and not have to deal with debugging browser issues. Our library allows developers to make beautiful-looking text-based navigation bars in just a few seconds and the syntax is designed to be intuitive such that new features take very little time to learn (the content description element) while existing features will you translate be familiar to those who have worked with this before (the input (sourceformatting elements) . It also improves the user experience, as the code we generate is accessible to users with disabilities and is designed in such a way that it degrades nicely across browser versions and vendors. Thus we are actually solving two problems at once: a development problem, in which creating well-functioning and nice-looking navigational elements is difficult, and a user interface problem, in which users are often presented with poorly-designed navigational tools. ==Study a language that solves a similar problem and describe it in this homework==There are not currently any languages or libraries that solve this problem. The closest thing to it is an HTML form application that takes in a few parameters and a list of name-link pairs and spits out the HTML, CSS, and JavaScript code to draw the described navigation bar. Although this does allow users to create navigation bars quickly and easily, it has several limitations. The first is the fact that the navigation bar can only be customized using the very limited set of parameters the creators of that program allow you to specify. Our program into gives users access to a much broader set of CSS attributes. Secondly, the navigation bar is inconvenient to change down the road; the customer would have to essentially create a new navigation bar from scratch, find the code of the original navigation bar, and replace it. Our programhas a file for the navigation bar that can easily be modified, and since the navigation bar is generated dynamically, the changes can take effect immediately. ==What features specifically will your language support==Some sample programs were listed above. Here's internal presentation a few more. *Design a simple, horizontal navigation bar with three elements which have a tab-like appearance.<pre><nowiki>{ layout: horizontal; element-style: rounded-tab; }*One | /one*Two | /two*Three | /three</nowiki></pre> *Design a vertical navigational bar with sections and subelements (all shown together)<pre><nowiki>{ layout: vertical; }*Roadmap | /roadmap.html*Projects | /projects*Coding | /developer{ direction: same; marker: dot; }**Module Owners | /about/owners.html</nowiki></pre>(oftenSimilar to [[Image:mozillanav.png]]) *Design a horizontal navigation bar with drop-down menus<pre><nowiki>{ layout: horizontal; }*About us{ direction: below; }**Directors | /directors**Developers | /developers**Users | /users*Support**FAQs | /faq**Knowledge Base | /kb</nowiki></pre> While this language does not provide true objects, this some code reuse is possible. Existing menus can be embedded in larger ones by simply prepending all the elements with an ASTadditional '*' character (or more than one, depending on how deeply in the navigational hierarchy you are inserting the nav bar). The <tt>direction</tt> keyword effectively controls the interaction between these navigation bars and their relationship to each other. Furthermore, some "inheritance"-like features make the task easier for the web developer. For example, the <tt>direction</tt> keyword needs to be specified only on the first submenu and is automatically applied to all the sibling submenus in the hierarchy. CSS properties are inherited by child menus from their parents. ===Demo==={|! Code || Preview|-| <pre><nowiki>{ color: #82c753; background: #6d6d6d; text-decoration: none; padding: 0.35em 0.5em; hover: { background: white; text-decoration: underline; };layout: vertical; layout-width: 10em; }*One | /one.htm{ color: #84b6d5; marker: &#9758; }**Two | /two.htm*Fun | /fun/{ background: white; }**Funtwooverride | /override***Third level | /goodtimes.htm{ background: gray; }****Fourth | /four*Oneback | /oneback{ marker: dot; }**Choo choo | /choo***Overrides | /woo****Gray | /gray</nowiki></pre> || [[Image:Navlang-overrides.png|thumb]]|-| <pre><nowiki>{ layout: horizontal; }*About us{ direction: below; }**Directors | /directors**Developers | /developers**Users | /users*Support**FAQs | /faq**Knowledge Base | /kb</nowiki></pre> || [[Image:Navlang-horizontal.png|thumb|A horizontal menu with the first menu item highlighted (moused over)]]|-| <pre><nowiki>{ layout: vertical; layout-width: 200px; element-style: rounded-tab; border: yellow thin solid; hover: { border: red thin solid; }; }*Roadmap | /roadmap.html*Projects | /projects*Coding | /developer{ direction: right; marker: dot; }**Module Owners | /about/owners.html**More modules | /owners</nowiki></pre> || [[Image:Navlang-vertical.png|thumb|A vertical menu with the third menu item highlighted (moused over)? You know ]]|} ===Poster slides===*[[Media:Navlang.ppt|Poster slides]] ==Decide on the implementation==* frontend: :The decision to go with a parsed input rather than an embedded DSL was not one we made lightly. The primary advantage of the embedded DSL is simplicity; it doesn't require us to go through the trouble of writing a grammar for the input. However, that this simplicity comes at the price of flexibility; the parsed input can be done with a parser or with specified in any format we choose, whereas the input of an embedded DSLmust fit into the syntax of the parent language. Considering that the main goal of this language is to provide a clean and simple syntax, restricting ourselves to the syntax of the parent language would clearly be counterproductive. We decided to use the JS/CC parser generator, since it provides a simple online interface, supports grammars similar to those used in CS164, and outputs a stand-alone JavaScript parser file that can be included in our distribution as in rake or protovisa library. Some languages may not need an internal representationThis parser process the input to the program and outputs JavaScript objects for the interpreter. * the core language: Are some features built :The purpose of this language is to provide a convenient and concise way for users to create CSS navigation bars. As such, it must be implemented entirely as sugar on top of a simpler-CSS, HTML, and JavaScript. As described above, the input to-implement the language? If yesis a hierarchical list of menu items with associated attribute lists. The program translates the input into the CSS, what is that core languageHTML, and how will you desugar those features?JavaScript code needed to create and arrange the bar properly.* internal representation::We considered both an AST and objects for the interpreter's internal representation of the input. In the end, we decided that objects are better suited to the data. What Although navigation bars are hierarchical, and hence seem to lend themselves to ASTs, the alternative ways of representing hierarchy is not explicit in the syntax. While this makes the program input files much easier to modify and extend, it also makes it difficult for the parser to create an explicit tree from the syntax. Hence, we process the input lines as individual objects, and allow the interpreter or compiler?to deal with the implicit tree structure.* interpreter/compiler: how will you interpret or compile :The interpretation is fairly straightforward; the interpreter goes through the object representation of the input, generating the appropriate CSS and HTML as it goes. The interpreter keeps track of the current item's location in the hierarchy to place it at the proper level of the navigation tree. The interpreter generates unique class identifiers for the levels as it encounters them, generates the CSS for the level (if any), and inserts it into a separate stylesheet created specifically for the purpose of the nav bar. Items are assigned classes for their level and all the levels above them. This allows inheritance to take place entirely using CSS's own inheritance mechanisms. Individual submenu overrides are also entirely handled by CSS as far as inheritance is concerned (i.e. an override inherits from the prototypes of its level and all the levels above it and then overrides/adds additional formatting of its own that affects it and its direct children & siblings).:The interpreter itself does only minimal error-checking. If errors occurred during parsing, they can be inspected via JavaScript after the language? Is there parse is complete.* debugging::Our distribution is packaged with an HTML page with a prepossessing steptext box. You can type an input program into the text box, eg translation from AST to bytecode? and the output navigation bar is displayed below. If you want to generate codethere is an error, what the error message is displayed instead of the target navigation bar. ==Addendum: succinct description of all language? Why did features==The formatting declaration inside the curly braces can contain any CSS properties you choose that language? desire, which will be passed and set to the nav bar items' <nowiki><a> and <span></nowiki> tags. A number of special keywords allow additional features. Namely:*layout determines the direction of the navigation bar. choices are horizontal/vertical; horizontal default.* debugginghover allows you to specify CSS attributes which apply to nav bar elements only when they are hovered over (i.e. the a:hover and span: How hover CSS selectors). uses exact same syntax as the "normal" formatting declaration.*direction determines the direction of submenus (i.e. items with level > 1) relative to their parent item. valid choices are right, left, above, below, and same. The last is the default and does not create pop-out menus.*marker specifies a marker which precedes all nav bar items. either 'none', 'dot', or any HTML entity such as <nowiki>&#9758;</nowiki>; none default.*layout-width specifies the width of the nav bar for vertical nav bars. default is 100% as per standard CSS.*element-style specifies the style of the nav bar item. current either 'rounded-tab' or 'regular'; latter is default. In general, formatting specs are inherited in much the same way as in CSS when a class name is appended to the element's class field. In particular, this means that children of any given element will you debug inherit all of its properties unless they are manually overridden. Furthermore, the first time a level (i.e. *, **, ***, etc.) appears, its formatting declaration (including a lack of one) is made as that level's "prototype" formatting specification. All further items in the same nav bar with the same level will have the same formatting, as will their children, unless they are overridden themselves. However, it is possible to override this prototype inheritance on a per-branch basis by specifying a different formatting spec before beginning the branch (i.e. as if declaring a prototype for the first time). Note that this override will complement the existing prototype, so any values not explicitly overridden will be inherited as usual. Such an override lasts for the implementation duration of the language?branch in which it was introduced and is discarded once the branch is complete. Consider and play with the following example to get a hands-on demo of how these concepts interact:<pre><nowiki>{ color: #82c753; background: #6d6d6d; text-decoration: none; padding: 0.35em 0.5em; hover: { background: white; text-decoration: underline; };layout: vertical; layout-width: 10em; }*One | /one.htm{ color: #84b6d5; marker: &#9758; }**Two | /two.htm*Fun | /fun/{ background: white; }**Funtwooverride | /override***Third level | /goodtimes.htm{ background: gray; }****Fourth | /four*Oneback | /oneback{ marker: dot; }**Choo choo | /choo***Overrides | /woo****Gray | /gray</nowiki></pre>