Saturday, July 26, 2014

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";

Sunday, July 20, 2014

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.

 

Tuesday, July 15, 2014

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. 

Saturday, July 12, 2014

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.

Tuesday, July 8, 2014

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...