The problem that we seek to address is that designing navigational elements in HTML is needlessly complicated and requires too much plumbing. Therefore, we propose have implemented a language with a special syntax designed specifically to make this process easy and fun.

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 then the URL for the item. If the developer wants to include a pipe as part of the item title, the title simply needs to be enclosed in quotes. 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.

This problem is worth solving because it allows web developers to save time and not have to deal with debugging browser issues. Our library will allow 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 be familiar to those who have worked with this before (the formatting elements). It also improves the user experience, as the code we generate will be is accessible to users with disabilities and will be 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.

==Part 2: Study a language that solves a similar problem and describe it in this homework==# One simple 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 exampleto draw the described navigation bar. Your comments must sufficiently explain Although this does allow users to create navigation bars quickly and easily, it has several limitations. The first is the meaning 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 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 codeof the original navigation bar, and replace it.# Describe Our program has a file for the implementation. (Two paragraphs navigation bar that can easily be modified, and pseudocode of since the navigation bar is generated dynamically, the implementationchanges can take effect immediately.)

==Part 3: What features specifically will your language support==# The domainSome sample programs were listed above. Give a list of Here's a few small programs that you hope to be able to write in your language. These will guide your language design.# 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?)more.

==Part 4: Decide on the implementation==Choose two alternative implementations*Design a simple, and compare them along these aspects. For each aspect, write horizontal navigation bar with three elements which have a paragraphtab-like appearance. Your <pre><nowiki>{ layout: horizontal; element-style: rounded-tab; }*One | /one*Two | /two approaches may be identical in some aspects.* frontend: How will you translate the input (source) program into the program's internal presentation (often, this is an AST)? You know that this can be done with a parser or with an embedded DSL, as in rake or protovis. Some languages may not need an internal representation.Three | /three</nowiki></pre>

The decision to go *Design a vertical navigational bar with a parsed input rather than an embedded DSL was not one we made lightlysections and subelements (all shown together)<pre><nowiki>{ layout: vertical; }*Roadmap | /roadmap. The primary advantage of the embedded DSL is simplicityhtml*Projects | /projects*Coding | /developer{ direction: same; it doesn't require us to go through the trouble of writing a grammar for the input. However, that simplicity comes at the price of flexibilitymarker: dot; the parsed input can be specified in any format we choose, whereas the input of an embedded DSL must fit into the syntax of the parent language}**Module Owners | /about/owners. Considering that the main goal of this language is to provide a clean and simple syntax, restricting ourselves html</nowiki></pre>(Similar to the syntax of the parent language is clearly counterproductive[[Image:mozillanav.png]])

* the core language: Are some features built as sugar on top of Design a simplerhorizontal navigation bar with drop-to-implement language? If yes, what is that core language, and how will you desugar those features?down menus<pre><nowiki>{ layout: horizontal; }*About us{ direction: below; }**Directors | /directors**Developers | /developers**Users | /users*Support**FAQs | /faq**Knowledge Base | /kb</nowiki></pre>

The purpose of While this language does not provide true objects, some code reuse is to provide a convenient and concise way for users to create CSS navigation barspossible. As suchExisting menus can be embedded in larger ones by simply prepending all the elements with an additional '*' character (or more than one, it must be implemented entirely as sugar depending on top of CSS and HTMLhow deeply in the navigational hierarchy you are inserting the nav bar). The input will take <tt>direction</tt> keyword effectively controls the form of a list with associated attributesinteraction between these navigation bars and their relationship to each other. Furthermore, and some "inheritance"-like features make the program will translate task easier for the input into web developer. For example, the corresponding CSS code along with <tt>direction</tt> keyword needs to be specified only on the first submenu and is automatically applied to all the plumbing needed to arrange sibling submenus in the bar properlyhierarchy. 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; }* internal representationOne | /one. What are 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 alternative ways of representing the program for 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 interpreter or compiler?third menu item highlighted (moused over)]]|}

We considered using 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. Our input is not going to come in the form of a deeply-nested hierarchy, so the tree structure is unnecessary; the input is a collection of data points, each of which has a set of associated attributes. This lends itself very well to object representation===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 simplicity comes at the price of flexibility; the parsed input can be specified in any format we choose, whereas the input of an embedded DSL must 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 a library. This parser process the input to the program and outputs JavaScript objects for the interpreter/compiler.* the core language:: how will you interpret or compile 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 CSS, HTML, and JavaScript. As described above, the input to the language? Is there is a prepossessing stephierarchical list of menu items with associated attribute lists. The program translates the input into the CSS, HTML, and 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. Although navigation bars are hierarchical, eg translation and hence seem to lend themselves to ASTs, the hierarchy is not explicit in the syntax. While this makes the input files much easier to modify and extend, it also makes it difficult for the parser to create an explicit tree from AST the syntax. Hence, we process the input lines as individual objects, and allow the interpreter to bytecode? If you want deal with the implicit tree structure.* interpreter/compiler::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 generate codeplace 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), what 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 target language? Why did you choose prototypes of its level and all the levels above it and then overrides/adds additional formatting of its own that language?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 parse is complete.* debugging::Our distribution is packaged with an HTML page with a text box. You can type an input program into the text box, and the output navigation bar is displayed below. If there is an error, the error message is displayed instead of the navigation bar.

==Addendum: succinct description of all language features==The interpretation formatting declaration inside the curly braces can contain any CSS properties you desire, which will be fairly straightforwardpassed 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.*hover allows you to specify CSS attributes which apply to nav bar elements only when they are hovered over (i.e. the interpreter will go through a:hover and span:hover CSS selectors). uses exact same syntax as the "normal" formatting declaration.*direction determines the object representation direction of the inputsubmenus (i.e. items with level > 1) relative to their parent item. valid choices are right, left, above, below, generating and same. The last is the appropriate CSS 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 it goesper standard CSS.*element-style specifies the style of the nav bar item. current either 'rounded-tab' or 'regular'; latter is default.

* debugging: How 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 implementation 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 language?same nav bar with the same level will have the same formatting, as will their children, unless they are overridden themselves.

We will provide an HTML page with 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 text boxprototype for the first time). You can type an input program into Note that this override will complement the text boxexisting prototype, and the output navigation bar so any values not explicitly overridden will be displayed aboveinherited as usual. If there is Such an error, override lasts for the error message will be displayed instead duration of the navigation barbranch 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>