Computer Science/164/HW3 - Revision history

Lensovet: Lensovet moved page CS/164/HW3 to Computer Science/164/HW3

2023-02-20T03:51:34Z

Lensovet moved page CS/164/HW3 to Computer Science/164/HW3

Lensovet: /* Poster slides */ link directly to ppt

2009-12-23T05:58:27Z

‎Poster slides: link directly to ppt

Lensovet: /* Demo */ +slides

2009-12-23T05:52:09Z

‎Demo: +slides

Lensovet: /* Demo */ add a little explanation to second/third ex

2009-12-21T02:44:21Z

‎Demo: add a little explanation to second/third ex

Lensovet: /* Demo */ OH HAI, IMAGES NEED EXTENSIONS LOL

2009-12-21T02:43:28Z

‎Demo: OH HAI, IMAGES NEED EXTENSIONS LOL

Lensovet: /* What features specifically will your language support */ add demo section

2009-12-21T02:36:53Z

‎What features specifically will your language support: add demo section

Lensovet: /* Decide on the implementation */ addendum on language features

2009-12-20T06:29:05Z

‎Decide on the implementation: addendum on language features

204.28.114.36: Removed semicolon

2009-12-19T09:05:00Z

Removed semicolon

Lensovet: /* Decide on the implementation */ clarify and some more impl

2009-12-19T07:41:07Z

‎Decide on the implementation: clarify and some more impl

Lensovet: /* Decide on the implementation */ interpreter details

2009-12-19T07:32:24Z

‎Decide on the implementation: interpreter details

@@ Line 159: / Line 159: @@
 ===Poster slides===
-*[[File:Navlang.ppt|Poster slides]]
+*[[Media:Navlang.ppt|Poster slides]]
 ==Decide on the implementation==

@@ Line 157: / Line 157: @@
 **More modules | /owners</nowiki></pre> || [[Image:Navlang-vertical.png|thumb|A vertical menu with the third menu item highlighted (moused over)]]
 |}
 ==Decide on the implementation==

@@ Line 147: / Line 147: @@
 *Support
 **FAQs | /faq
-**Knowledge Base | /kb</nowiki></pre> || [[Image:Navlang-horizontal.png|thumb]]
+**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; }; }
@@ Line 155: / Line 155: @@
 { direction: right; marker: dot; }
 **Module Owners | /about/owners.html
-**More modules | /owners</nowiki></pre> || [[Image:Navlang-vertical.png|thumb]]
+**More modules | /owners</nowiki></pre> || [[Image:Navlang-vertical.png|thumb|A vertical menu with the third menu item highlighted (moused over)]]
 |}

@@ Line 147: / Line 147: @@
 *Support
 **FAQs | /faq
-**Knowledge Base | /kb</nowiki></pre> || [[Image:Navlang-horizontal|thumb]]
+**Knowledge Base | /kb</nowiki></pre> || [[Image:Navlang-horizontal.png|thumb]]
 |-
 | <pre><nowiki>{ layout: vertical; layout-width: 200px; element-style: rounded-tab; border: yellow thin solid; hover: { border: red thin solid; }; }
@@ Line 155: / Line 155: @@
 { direction: right; marker: dot; }
 **Module Owners | /about/owners.html
-**More modules | /owners</nowiki></pre> || [[Image:Navlang-vertical|thumb]]
+**More modules | /owners</nowiki></pre> || [[Image:Navlang-vertical.png|thumb]]
 |}

← Older revision		Revision as of 02:36, 21 December 2009
Line 116:		Line 116:

	While this language does not provide true objects, some code reuse is possible. Existing menus can be embedded in larger ones by simply prepending all the elements with an additional '*' 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.		While this language does not provide true objects, some code reuse is possible. Existing menus can be embedded in larger ones by simply prepending all the elements with an additional '*' 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: ☞ }
		+	**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\|thumb]]
		+	\|-
		+	\| <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\|thumb]]
		+	\|}

	==Decide on the implementation==		==Decide on the implementation==

← Older revision	Revision as of 03:51, 20 February 2023
(No difference)

← Older revision		Revision as of 06:29, 20 December 2009
Line 129:		Line 129:
	* debugging:		* 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.		: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 formatting declaration inside the curly braces can contain any CSS properties you 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.
		+	*hover 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: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>☞</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 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 duration of the 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: ☞ }
		+	**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>

@@ Line 62: / Line 62: @@
 <pre><nowiki>{ color: #82c753; background: #6d6d6d; text-decoration: none; padding: 0.25em 0.5em;
 	hover: { background: white; text-decoration: underline; };
-layout: horizontal; };
+layout: horizontal; }
 *One | /one.htm
 *Two | /two.htm

@@ Line 125: / Line 125: @@
 :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, 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 the syntax. Hence, we process the input lines as individual objects, and allow the interpreter to 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 place it at the proper level of the navigation tree. The interpreter generates unique class identifiers for the levels as it encounters them, and consequently allows inheritance to take place entirely using CSS's own inheritance mechanisms. Individual submenu overrides, consequently, 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 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).
 * 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.