Open main menu

lensowiki β

Changes

Computer Science/164/HW3

3,558 bytes added, 07:41, 21 November 2009
Part 1: Choose the problem that your language will solve: beef
==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.
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 a language with a special syntax designed specifically to make this process easy and fun. 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="/one.htm">One</a></li><li><a href="/two.htm">Two</a></li><li><a href="/fun/">Fun</a></li></ul></div></nowiki></pre> ;Corresponding CSS<pre><nowiki>#social { background: #6d6d6d; color: white; padding: 1em 0px; margin: 0px auto; clear: both; bottom: 0px; position: absolute; width: 100%;} ul { 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 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, navigational menus can often contain 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 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.htm*Two | /two.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 then the URL for the item. If the developer wants to include a structured hierarchypipe 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 requires additional javascript coding can be useful for drop-down menus. Creating hierarchical menus is simple. For 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.htm*Item two | /two.htm</nowiki></pre> By default, all the submenus inherit the styles of their parents. If this is not desired, properties to override can be specified in the curly braces. The <tt>direction</tt> keyword shown above simply controls where the submenu appears relative to work properly its parent item. In the example above, the "Submenu item one/two/three" elements appear below the navbar containing "Item one/two", and further detracts the "Subsubmenu item a" appears to the left of that menu. This problem is worth solving because it allows web page designer from concentrating on accomplishing his task; namelydevelopers to save time and not have to deal with debugging browser issues. Our library will allow 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, working on as the actual ''design'' of the menucode we generate will be accessible to users with disabilities and will be 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==
1,277
edits