Download CS142 Midterm Exam and more Study notes Web Application Development in PDF only on Docsity!
CS 142 Midterm Examination Solutions
Winter Quarter 2022
You have 1.5 hours (90 minutes) for this examination; the number of points for each
question indicates roughly how many minutes you should spend on that question. Make
sure you print your name and sign the Honor Code below. During the examination you
may consult two double-sided pages of notes; all other sources of information, including
laptops, cell phones, etc. are prohibited.
I acknowledge and accept the Stanford University Honor Code. I have neither given nor received aid in answering the questions on this examination.
(Signature)
(Print your name, legibly!) [email protected] (Stanford email account for grading database key)
The HTML language standards group has added tags like , , , and that could have easily been implemented in older HTML using a div tag with a class attribute specifying the formatting that should be done for that type of document section. Explain how adding these new tags to HTML makes sense (i.e. consistent with both the philosophy and practical usage of HTML) even though the formatting they direct can be done relatively easily with existing div tags. HTML is a markup language that is intended to identify parts of a document with styling specified by CSS style sheets. Extending the set of HTML tags to include more details of the different sections of a document is consistent with this intent. This ability to give a more detailed description of a document's contents is useful for programs that examine the HTML like screen readers.
Some CSS properties are inherited (e.g. font-size) and some properties are not inherited (e.g. border). For the inherited properties, does a DOM Node inherit from the parentNode or offsetParent? Explain your answer. The parentNode of a DOM element is always the element containing the DOM element. The offsetParent is the element that is the CSS positioning context of the element. Inheritance follows the document structure so it would inherit from the parentNode. It's possible that the offsetParent is the same as the parentNode but often it is not.
Assume you are given a deeply nested HTML document with no CSS styling and a global JavaScript variable named element that points to a DOM leaf node somewhere in the middle of the document many tree levels down from the root node. Show JavaScript code that changes element.offsetParent without explicitly assigning to element.offsetParent. Since we know the element is a leaf node it must have a parentNode and being deeply nest it is not the body element. Since there is no CSS styling then the positioning context will the body element so element.offsetParent will start pointing at the body element. One easy way of changing element.offsetParent is to change the positioning context of the element. Making the offsetParent the positioning context would work. element.parentNode.style.position = "absolute"; element.style.position = “fixed”; // offsetParent returns null (see the doc)
When building traditional web pages (i.e. static HTML documents), the use of element styling (style=attributes) is discouraged in favor of using CSS style sheets for styling. When programming in React.js with JSX, element styling (style=attributes) is not discouraged. Explain the problem with using “style=attributes” in static HTML documents that is not present in JSX usage. Using "style=attributes" syntax is discouraged in static HTML documents because it not only gets messy, but it also neglects the opportunity to put styling rules in CSS classes so that you can save yourself from redundancy and apply the style with the class. It fails the DRY principle. Using the "style=attrributes" syntax is not discouraged in React.js with JSX you are associating styling with the tag but since it is embedded in JavaScript you are not repeating yourself. Even with style= you can set it up so the specification is only in one place.
Below we list pairs containing an HTML hyperlink and a URL that resulted from a click on the hyperlink (i.e. resultant URL). (a) Click http://localhost:999/a/b/c.html (b) Click http://localhost:999/a/b/c.html (c) Click http://localhost:999/z/a/b/c.html (d) Click http://localhost:999/a/b/c.html#foo None of the URLs in the hyperlinks are full URLs meaning the browser's current location URL of the page containing the hyperlink is used in determining the resultant URL. For each of the pairs (a)–(d), describe what the browser's current location URL must have been to have the given resultant URL. Note many possible current locations could cause the listed resultant URL. Your answer should describe the possible values for all the parts of the current URL (i.e. scheme, hostname, port number, hierarchical portion, query parameters, fragment). (a) any URL starting with http://localhost: scheme: http hostname: localhost port number: 999 hierarchical portion: anything query parameters: anything fragment: anything (b) http://localhost:999 or any URL starting with http://localhost:999/something scheme: http hostname: localhost port number: 999 hierarchical portion: empty or something without a / query parameters: anything fragment: anything (c) any URL starting with http://localhost:999/z/something scheme: http hostname: localhost port number: 999 hierarchical portion: z/something without a / query parameters: anything fragment: anything (d) any URL starting with http://localhost:999/a/b/c.html scheme: http hostname: localhost port number: 999 hierarchical portion: /a/b/c.html query parameters: Nothing fragment: anything
When looking at a DOM node other than the root of the tree, there are two pointers that point at nodes further up the tree towards the root (parentNode and offsetParent), following either of these pointers up the tree will eventually get to the body tag node. Considering these two paths up the tree, answer the following questions: (a) Are the nodes in the parentNode path always in the offsetParent path? Explain your answer. No. The nodes in the parentNode path are not always in the offsetParent path. This is because if a node in the parentNode path is not positioned, it will not be in the offsetParent path. The condition for this statement to be true is for all elements in the parentNode path to be positioned. (b) Are the nodes in the offsetParent path always in the parentNode path? Explain your answer. Yes. The nodes in the offsetParent path are always in the parentNode path. This is because the parentNode path contains all the ancestors (at every level), regardless of whether or not they are positioned. This essentially means that the nodes in the offsetParent path are a subset of those in the parentNode path and as such, all the nodes in the offsetParent path are always in the parentNode path.
Consider the following HTML document:
One
Two
Three
Four
We run the following JavaScript on the document: const divs = window.document.getElementsByTagName('div'); for (let i = 0; i < divs.length; i++) { divs[i].addEventListener("click", (e) => console.log('bubble', e.currentTarget.id, e.currentTarget == e.target, e.currentTarget.textContent.replace(/[\s]/g, '')), false); divs[i].addEventListener("click", (e) => console.log('capture', e.currentTarget.id, e.currentTarget == e.target, e.currentTarget.textContent.replace(/[\s]/g, '')), true); } Hint: the third parameter in addEventListener is named useCapture. problem continued on next page…
AngularJS showed the usefulness of binding JavaScript values in controllers to expressions in an HTML template. A programmer could simply change the value of a JavaScript variable and AngularJS would detect and re-render the component with the updated template expressions. Although this binding was a hit with programmers, it required AngularJS to compare all the expressions in the templates to see if some state had changed every time some JavaScript code ran. For views with much state, this checking for changed JavaScript state variables got too expensive to be useful. Explain the mechanism ReactJS used to be able to employ a similar binding of JavaScript variables to HTML template expressions yet didn't suffer large overheads when only small amounts of the state changed. Rather than evaluating all the template expressions to see if something has changed, ReactJS requires the developer to notify it anytime the state is modified. That is the reason all component state changes must call into ReactJS (i.e., through the this.setState function) to update component state, rather than assign to this.state directly. Only the component constructor that runs prior to the first call to render is allowed to directly assign to this.state.
Explain how a ReactJS web application can appear to behave like an old-style web application (where the user clicked on hyperlinks to navigate between view "pages" and uses HTML forms to input data), yet be considered a single page application. When the first single-page applications (SPAs) came into existence, they often did not provide a way to link to a specific part of the website that only would show up after clicking through the website. To "behave like an old-style application" means that each "page" within the ReactJS application has its own URL, that can then be shared, bookmarked, or otherwise persisted. In practice, modern ReactJS applications often employ "router" libraries (such as React Router), that are broadly responsible for:
- parsing the URL to figure out what components should be displayed, and with what parameters (i.e., deep linking);
- updating the current URL without triggering a browser refresh (either by changing the URL fragment or using the History API) when the user navigates between pages or submits a form; and
- handling backward/forward navigation using either the hashchange or popstate event. With these three features, a ReactJS application can function like an old-style web application. However, it can still be considered a SPA, since clicking on a hyperlink (or submitting a form) does not make the browser reload the page and preserves the JavaScript execution state of the previous "page".
Internationalization (I18N) and Accessibility (ARIA) are two important properties of a web application that frequently don't make it into the first release of a web application. When adding features to a web application, the work can be considered independent if the changes required don't interact with each other and features can be added by teams working concurrently. State whether Internationalization (I18N) and Accessibility (ARIA) are dependent or independent from each other, and explain. ARIA and internationalization are dependent of each other. ARIA provides text alternatives for any non-text contents/media, while internationalization supports user-based text/dates/numbers, etc. If the text alternatives provided by ARIA is only in one language that the user does not recognize (no internationalization), that would defeat the purpose of accessibility. Therefore, they are dependent.
