Deeper DOM

What you will learn this week from w3schools is a VERY simplified view on HTML DOM used by Javascript. This post is for those who want to know somewhat more, have a better orientation in the HTML5 technologies trends.Object that you might be used to usually are special data structures supported in the memory after instantiation. In other words, they are “real” physical structures. HTML objects are a figment of imagination brought to life by browser interpretation of simple flat texts (like the one you can create in your Notepad). The ability of modern browsers creating such virtual objects with their properties and methods allowing to work with these properties and other elements creates a new world of virtualization.

This allows really modern programming against browsers (especially in HTML5-based development). APIs (Application Programming Interfaces) allow to standardize JS operations on DOM, like:

document.createElement("h1");

This allows standard and simple way of performing various operations on HTML text and its object interpretations. The growing number of special methods of HTML processing create a growing number of APIs instead of inventing programming methods of doing same things again and again. For example HTML5 DOM includes standardized methods allowing to handle:

• Contacts - The HTML5 specification mentions that the Contacts API allows to have a common contacts repository in the browser which can be access by any web application.
• Selection - The selection API supports selecting items in DOM (supports CSS3 type of selectors), to be used along with jQUERY.
• Offline apps - This API allows marking pages to be available in Offline mode. This is useful if a resource requires dynamic processing.
• Indexed database - This API is meant for a database of records holding simple values (including hierarchical objects). Every record has a key and a value. An indexed database is supposed to be implemented using b-trees. Web SQL DB is no longer being pursued as part of HTML5 specification.
• File API - The File APIs are used by the browser to provide secure access to the file system.
• Etc.

 Given the dynamism and growing expansion of HTML-based development it has include two functions: create standards to support globally acceptable and “re-combinable” applications and allow for the evolving nature as any language has. Therefore the two main organizations W3C and WHATWG (in ots living satndard) correspondingly split these functions.

The modern evolution of the HTML DOM goes in the direction supporting the emerging needs of effective (allowing for the latest enhancements in programming methods, operations, and interfaces) and efficient (simplifying) programming (mainly Javascript-but other languages are possible - on HTML and styles, but also on device resources like memory, sensors, etc.). For example, since the regular HTML DOM tree lacks encapsulation (one of the key features in using object-orieneted programming)  there are spreading to life such exotic things as Web Components allowing for it that also include so-called Shadow DOM.

PHP can do the same what JS does on the client – but on the server side thus nicely supplementing client or server side implementation options. For example finding an element in DOM can use the domdocument class of Php like th efollowing:

// a new dom object

$dom = new domDocument;

// load the html into the object

$dom->loadHTML($html);

// discard white space

$dom->preserveWhiteSpace = false;

//get element by id

$some_div = $dom->getElementById('someID');

if(!some_div)

{

    die("Element not found");

}

echo "element found";

Responsive Images, etc.

Media is playing an increasingly big role in RWD methodology evolution. Only 2 years ago there were battles between client- and server-side fans of media optimization. Then the time came for RESS as a mix of responsive (at the time was reserved for client side) and adaptive (server-side) strategies.

In our learning of RWD you can see that more professional and industry-level idea of responsiveness without creating and supporting a great number of specialized sites and their components requires additional serious efforts when it comes to multimedia. Making your fixed width video and image files resize to fill any mobile device can seem a lot more complicated than using the basic general methods of RWD. And you’ve touched only images… Video, for example, is a bigger problem since is capable to hamper user experience much more. It includes more parameters to consider (like bit-rate, aspect ratio, etc.).

Some directions include control of the loading of multiple sized images via the choice by special analysis/information, like JavaScript that determines the specific features of the browser and the device with further requesting the proper media files. Others get maximum quality media (like images twice the required quality) and then simplify them for the screen (like shrinking images down).

 

With media queries getting better and better support in modern browsers sensing the local situation and ordering the proper image is not that difficult… if it is done in CSS where the image is placed as a background image order. But if you have to use the src attribute in HTML where you have to indicate a particular source – then JavaScript injection of that statement is recommended (JavaScript can modify the HTML on the fly in its DOM – model). Placing special cookies with information about the local context might serve as another way of informing the server (letting it do some work in analyzing cookies) what and how to serve.

More advanced combinations of server intelligence with browser figuring out the local context and sending some information to the server the solutions are improving. Industrial level scaling of serving video streams and multiple images already have to use cloud and grid intelligence and scalability instead of just servers (see Akamai as an example).

At the same time there are undergoing efforts in enhancing HTML5 allowing for some solutions to the problem,  its discussion, and more on picturefills.

There is a vast area of literature on the topic but at least read this (which is a couple of years old showing the ideas of that time) and this ( a bit later), this, and Blink/Gecko implementation. Look at src-N discussion.

 

Browser Support for Layered Enhancement

During progressive enhancement you use a lot of JS functionality at the top enhancement layer. But... some browsers do not support enough of JS. In order not to break your app - the usual browser response to the errors in JavaScript which makes the script stop working at that point - is to continue rendering HTML. This might look as an OK work but some parts of your JS or the whole thing might not working correct. This is why in real life watching the HTML page working is not enough for JS debugging.

Methodology is important: Progressive Enhancement vs Graceful Degradation

This week you will make another step in mastering RWD. And this is a methodological step. You can understand the components of RWD well but might start having methodological problems, that sometimes can kill a project.
    

Please read http://www.peachpit.com/articles/article.aspx?p=1586457 to get a better picture of this approach. Compare with top-down Graceful Degradation...

It doesn't mean that graceful degradation (especially if done right) is wrong :) This depends on the type of your project, its use cases, and your resources. There are proponents stating that in some cases they want to show the best modern technology can offer in order to beat the competition and demonstrate the latest advantages. Then there are only three ways: progressive enhancement, creating a separate advanced site, or use graceful degradation techniques that analyze the context and start simplifying/dropping some features depending on the situation. This requires knowledge of additional "context sniffing" and project simplification methods, more coding, but can still lead to an RWD version that will work on all devices and browsers with automatic adjustments. 

More details on media queries

After going through week 2 tasks and spending time on experimenting and really understanding the code - you should have a fairly good idea about the main techniques of RWD. Still I would recommend reading the seminal article of the founder of the RWD idea Ethan Marcotte  where he discusses the main ideas of the methodology.

 

But you should be aware that in real life the use of RWD might require more details and be somewhat more complicated. Below I am offering a few aspects of such reality checks.

Using more than 2 screen designs

The book walks you through only two CSS groups. In reality you might want to create designs for more window/device sizes, like, for example, having 4 column for laptops, 2 columns for tablets, and 1 column for smartphones. Often it is not even about columns but the order and amount of information and number of interactions/services offered for different use cases (like detailed analysis on the desktop versus a quick hint on the phone, etc.). Below is a list of screen/window pixel formats usually requiring special considerations:

• 320px
• 480px
• 600px
• 768px
• 900px
• 1200px
  
  

Designing for all of them is not necessary and depends on the particular application, its uses, and… your resources. 

One combined CSS versus several

The book also offers the method of placing designs for various window sizes into one CSS file. In practice, you might have different groups responsible for different devices, audiences, and use cases. Each might develop a separate CSS that can be loaded when that specific window size is met (media query evaluates to true).
 

Example of the use of the <link> element in HTML like:

<link rel=”stylesheet” type=”text/css” media=”all and (color)” href=”styles/colorstyle.css”>

Alternatively, you can use @import rules like:

@import url(“styles/colorstyle.css all and (color); 

Different media queries

But the most interesting and important feature of media queries is their ability to examine the context of the device and particular browser state far beyond the window/screen size. Not all of these features are implemented in all browsers yet, but a lot of other media features are defined in w3.org standards. For example they include such features of device as: height, orientation, aspect-ration (4:3, 16:9, etc.), color/monochrome, resolution, and some others. Distinguishable media types include: ‘aural’, ‘braille’, ‘handheld’, ‘print’, ‘projection’, ‘screen’, ‘tty’, ‘tv’ and more.

 

The trend is in increasing the features that the browsers can determine and send to media queries that can play role of sensors of various context features (what device and what specific use is happening). This allows very adaptive/responsive development approaching raw native device programming with access to hardware and their OS. There are methods of obtaining such information from media queries and passing them to JavaScript where the response can be determined dynamically and programmatically. 

Logic of media queries

Another power of media queries is in the use of logic where each media query is in fact a logical statement with AND, OR, NOT, and ONLY  logical statement allowing the creation of very complex conditions you want your design to respond to.

AND-operator combines several media features into a single media query, comma separator between the features works like an OR-operator, while ONLY activates media query ONLY when the entire query evaluates to true, and NOT negates the whole query. Here are some examples:

 

@media (min-width: 700px) and (orientation: landscape) { ... }

@media (min-width: 700px), handheld and (orientation: landscape) { ... }

 

See more details here.

 

Testing W2P2 on Mobile

If you haven't done it already - test the site on your mobile phone. It should all be in one column, while having 3 on your computer.
Remember that there are no good debugging environments for this work (although some might be somewhat helpful - we will talk later about when the code gets more complicated). Therefore small syntax errors will not send error messages but also will not let your site work properly. Check and re-check your code in such cases.


But after the success - try to really understand ALL parts of the HTML and CSS code re-reading the book, experimenting with code, etc.

Power of HTML5

Although we learn RWD by using HTML5 and CSS3 elements for a simple document, you should realize that once (outside of the program) you learn more about other elements in HTML5 and CSS3 - your code can be more than just documents.
Please see below a couple of games created pure HTML5 technologies that potentially could be your full app or parts of your pages:

Game 1
Game 2

Here is an example of CSS3 only animation - nothing else has been used

 More on RWD is coming later. Stay tuned...

A Few Words About RWD

Looks like it is a strong class. Although the general promise of the course was to study Responsive Web Design (RWD), we can do more, and this is why this book was chosen allowing to go further.
RWD is just one of the mobile design approaches. It basically has 4 components allowing for web page adaptivity to various devices:

• CSS media queries
• Fluid grid layouts
• Fluid images and media
• Fluid text features

Each of these components has its own adaptive mechanisms and being used together - they increase the flexibility of the application.

We will go through all of them, and you will see how RWD could be used for creating aps that could be used on many different devices. But there are other approaches  and engineering methods. This is why we will get to learn more than you originally were hoping for :-)

Hosting Instructions

Free SmarterASP account

1.       After confirming email in the 60 day free trial on SmarterASP - log into your new account with chosen name and password.  When logged in – go to the Hosting Control Panel, 60 Days Free Trial. Click Try Now button.

2.       After reviewing the textboxes and choosing PHP type – you will have something like this:

 

3.       Confirm the summary presented by the site as following

Record the FTP information and click SUBMIT

4.       After the account is created – walk through the Quick Introduction that will pop-up on your screen.

5.       Click on Hosting Control Panel to see your temporary domain name. Go to Website Domain Manager following the on-screen hints. Your domain name should look like this:

 http://profven-001-site1.smarterasp.net

Note that site1 is your root directory and for each week you should create a new subdirectory INSIDE this SITE1 with names like week1, week2, etc. Each subdirectory becomes your website

6.       In the view of your folders find site1, click on it, and on the menu icons below your folders click new folder. Enter “week1” name for the tasks of week 1 and click CREATE. The resulting view should be like the following:

7.       Click on week1, then on the icon with “+” sign and a pencil to create a test html file testing the url and the host setting correctness.

Enter in the file window something like:

<html>

Testing the link

</html>

 

…And give the file a name like: test1.html

The .html extension is very important here

8.       Now try your new web site by copying the name of your site given to you before, adding to the url the name of the new directory (it is week1), and the name of the new html file to have something like the following:

http://profven-001-site1.smarterasp.net/week1/test1.html

As a result you should see a screen like the following:

 

This is the full path that you will specify in this course by adding to the main site address (like http://profven-001-site1.smarterasp.net)   via backslash the names of all nested directories and the final file name that you want to be seen from the innermost subdirectory.

Each website is just a subdirectory in the root directory of your account (site1)

9.       Upload to the week1 the HTML file that you were supposed to create and test on your local computer. Don’t forget that pictures require you to upload the actual picture files with links corresponding to the picture file name (and, possibly, the chain of subdirectories leading to it if you create special subdirectories within week1 like “pictures.” If it sounds not clear – then google on the web the material on managing files in directories, subdirectories, and web links, knowledge of which is the prerequisite for this course.

 

A Few Words about CSS

CSS is a separate from HTML language. It is used for defining styling, positioning and some other behaviors of HTML elements across ALL pages on the site where you do not need to repeat such "styling" for each HTML element, like font and it's size but rather simply refer to the one place determining the way all chosen elements look and behave (to a certain extent). Complex behaviors require JavaScript but a LOT could be done using CSS definitions. CSS, and CSS3, as its last incarnation, is continuously developing assuming more and more power under the current course on HTML5 leadership in its trio of HTML, CSS, and JavaScript being the core  of these technologies.

The current trend is in giving HTML the role of the architectural and semantic tool in developing web resources (like web pages) where the HTML5 compliant browsers are the readers and interpreters of this information. Special semantic processors and search engines are coming in the near future to benefit from such clear structural/semantic role of HTML where they will be able to parse the HTML text and find the role, meaning, and relationship of various terms and sentences and understand them according to HTML blocks marked as "header," "section," "aside," "footer," "figure," "figcaption," etc.
CSS is supposed to separate content from presentation features that might be different for different users showing more or less and in different ways by just using different CSS files connected to the current HTML. This allows the separation of content and presentation/access management. Same goes for external JavaScript files that could be changed for different users and circumstances or programmed with lots of conditional IF statements changing behavior in relationship with different circumstances.

For simple general overview of CSS - you might see  Introduction (along with many other sources that you will find in your research on CSS). The list of new features can show you the way CSS3 is being enhanced in the current CSS3 info. An additional to w3schools example of some text-handling capabilities can be seen here.
I encourage you to read more about CSS and experiment with w3schools' examples as well as with examples in other sources. The more research and experimentation you put in this program - the more you get from it.

Introduction to HTML Tags

Some of you already know and used a number of HTML tags while others are new to this. In the following video lecture I am showing how to use a simple text editor (Notepad for PC in this case) creating an HTML document and work with it in a WYSIWYG fashion making changes and immediately seeing how the page will look like. You can just follow the video for your HTML task or (which is encouraged)_ after following use your own content and adding ALL required HTML elements.