Showing posts with label HTML5. Show all posts
Showing posts with label HTML5. Show all posts

Friday, June 27, 2014

jQuery Crash Course –Part III ofthe HCJ Series

Back in June, 2013 (yes, that was a year ago) we published the final installment of the HCJ series in the Centriq Alumni Network newsletter.

Installment 3 provided an introduction to jQuery, including what it is and isn't, what the syntax looks like, and a few examples of jQuery in use.

You can access the piece in its entirety, as well as code samples:


Thanks, and best wishes on your continuing career development!

Thursday, July 25, 2013

CSS3 Crash Course – Part II of HCJ Series

[This post is re-published from a piece I wrote for the January 2013 edition of the Centriq Alumni Network newsletter.] Continuing the HCJ series (HTML5/CSS3/jQuery) we started last month, let's push on with CSS3. As noted in the opening salvo for the series, this is intended to introduce you to these concepts and get you up and running with some new code and implementations that will work in many environments. It is by no means an exhaustive resource.

The next piece in the series will introduce incorporating some jQuery into your websites.

CSS3 Usage

Over the years, CSS3 has begun to be supported in parts by more and more browsers. And this is a good thing, because CSS3 promises not only more formatting options, but also finer control over selecting tags to format on the page. (This improved ability to target items in the DOM ties in well with JavaScript and jQuery, as we'll discuss more in the next installment of this series.)

Use Well-Supported Properties But Be Prepared For Non-Compliance

Although there's still lots of CSS3 that receives only partial support (or none) in various browsers, that doesn't mean we can't use some CSS3. There are various philosophies on this, but a common perspective is that if a CSS property we wish to use is fairly well supported, we use it – with the understanding that it may be ignored by some browsers. If you do this selectively, there shouldn't be too much "code bloat" where the users are wasting download time to get formatting that will be ignored by their browser anyway.

For example, you can use a CSS property for multiple text-columns (like those in a newspaper) on one of your div tags – but you will need to be prepared for the fact that no form of Internet Explorer except IE10 supports that CSS. (IE10, by the way, is only installed by default on Windows 8 machines; and is currently used by only 0.25% of users globally.) So that CSS will be ignored by most forms of IE, and your page will display that div's content in the standard 1-column layout.

Push Compliance with Modernizr and Polyfills

On the other hand, if a particular CSS property and its formatting is truly mission critical and we know some browsers do not inherently support it, we could try to force the browser to implement that formatting by using Modernizr and polyfills.

Modernizr is a free service that incorporates both the HTML shiv we discussed in the last installment, and JavaScript that performs feature detection. Then polyfills (more JavaScript) can be used to "help" the browser support the desired CSS3 or HTML5. This of course can still fall victim to the limitation that the browser in question must not be configured to block the JavaScript or your desired formatting can still fail. And this also adds more code to the download, and the potential for code bloat again – especially if you overuse the technique. Fortunately, to avoid this, the people at Modernizr do make it easy for you to generate custom JavaScript code to "force support" for only the desired CSS features you choose.

Using the Modernizr and polyfills approach may take more work, but if used with some care to only force support for truly important features, it can ensure a more consistent implementation of your CSS across browsers.

CSS3 Resources

Deciding which CSS to use can often come down to how well supported it is. For that, I have two quick recommendations:
  • CanIUse.com (solid stats and information)
  • CSS3Test.com (interesting at a glance for testing features of the browser you're currently using)
To start digging into using Modernizr with polyfills, I'd recommend the following sites:

CSS3 Formatting Highlights

The following is a quick sampling of some fairly well-supported CSS3 properties you may want to start using in your projects.

Text Shadows

Adding a drop shadow to your text uses the text-shadow property. Here's the template for using it:
text-shadow: right-offset | down-offset | blur-radius | color

And two examples:
h1
{
   color: green;
   text-shadow: 5px -3px 5px red;
}

h2 {text-shadow: 3px 3px;}


So the h1's would be green with a red drop shadow 5px to the right, 3px above (negative offsets reverse the direction), and a blur radius of 5px.

The h2's would have a text-shadow of the default color that's 3px to the right and down.

Rounded Corners and Box Shadows

For block-level elements, sometimes you want to shave off the hard edges from those corners and/or add drop shadows to them. This has been popular in web and UI design for awhile, but previous to proper CSS support, required cumbersome image manipulation and CSS hacks to make it work. Of course, for this to work, you need some borders to round, so that's your first pre-requisite. Also, this is another CSS feature that has mixed and sometimes proprietary support in different (older) browsers, so to be safe, you may want to use both proprietary and standard property variants.

The templates:
border-radius: radius-amount-for-all-corners //set equally
OR
border-radius: top-left | top-right | bottom-right | bottom-left //clockwise

box-shadow: right-offset | down-offset | blur-radius | spread | color


Examples:
aside.pullquote
{
   border: 3px solid blue;
   border-radius: 5px;
   -moz-border-radius: 5px; //for older Firefox versions
}

#wrapper
{
   border:3px solid blue;
   border-radius: 5px 3px 3px 5px;
   -moz-border-radius: 5px 3px 3px 5px; //for older Firefox versions

   box-shadow: -3px -3px 3px 3px green;
   -moz-box-shadow: -3px -3px 3px 3px green; //older Firefox versions
   -webkit-box-shadow: -3px -3px 3px 3px green; //older Safari/Chrome versions
}


So any aside with a class of pullquote will have 5px radius for its rounded corners on all sides.

The tag with an id of wrapper will have left corners with 5px rounding, right corners with 3px rounding. Also, it will have a green drop shadow outside the borders of 3px to the top and left, with 3px radius and spread.

Text Columns

As we've already mentioned, you can add CSS text columns for a block-level element, and style them with spacing and/or a line between the columns. (Also, as noted previously, this is not supported in most forms of IE as of the time of this writing).

Templates:
column-count: number-of-columns;
column-gap: width-between-columns;
column-rule: border-specs-between-columns; //defaults to none if unassigned

Example:
article.threecol
{
//3 variants for column count
-moz-column-count: 3;
-webkit-column-count: 3;
-moz-column-count: 3;

//3 variants for column gap
-moz-column-gap: 15px;
-webkit-column-gap: 15px;
-column-gap: 15px;

//3 variants for column rule
-moz-column-rule: 2px dashed black;
-webkit-column-rule: 2px dashed black;
-column-rule: 2px dashed black;
}


So, for browsers that support it, the article tag with a class of threecol will have 3 columns with a spread between them of 15px, as well as a 2px dashed black vertical line.

Background Gradients

You can set a background gradient (where solid colors "fade" into other solid colors) through a variant implementation of the background-image property. Again, this is currently a property supported mostly through the proprietary browser variants, so you'd typically use them all if you're going to use them.

Template:
background-image: linear-gradient(direction | color % | color %);
background-image: -moz-linear-gradient(direction | color % | color %);
background-image: -webkit-linear-gradient(direction | color % | color %);


Examples:
header
{
   background-image: linear-gradient(left, red 20%, olive 70%);
   background-image: -moz-linear-gradient(left, red 20%, olive 70%);
   background-image: -webkit-linear-gradient(left, red 20%, olive 70%);
}

aside
{
   background-image: linear-gradient(45deg, gray 20%, blue 30%, green 70%);
   background-image: -moz-linear-gradient(45deg, gray 20%, blue 30%, green 70%
   background-image: -webkit-linear-gradient(45deg, gray 20%, blue 30%, green 70%);
}


So the header will go from red to olive, fading in from the left, beginning the red-to-green transition 20% after the starting point and ending in solid green 70% from the starting point to the end.

The aside will fade in at a 45 degree angle, from gray to blue to green, starting the first transition at 20% of the distance, then the next at 30% and then finally at 70%.

This can all be a little tricky, so I highly recommend playing with it and/or downloading the free CSS Grady or ColorZilla app for the Chrome browser to interactively play with gradients and see CSS code generated that you can copy or tweak.

CSS3 Targeting Highlights

The following is a quick round-up of a couple of fairly well supported CSS3 selectors you may want to start using to target tags better, with less markup. Why add tons of classes to your HTML tags to get them systematically formatted a certain way if you can do it just as well with some slick pseudo class and contextual selectors?

Here are a few quick targeting selectors that you may want to consider using.

Some Pseudo Class Selectors

Sometimes you want set the formatting differently for the first or last item in a container tag – like the last bullet point in an unordered list, or the first row in a table. Example:

ul li:last-child
{
   margin-bottom: 30px;
}

tr:first-child
{
   text-align: center;
}


So the last list item in an unordered list would have 30px added beneath it. And the first table row would have its content centered.

On the other hand, sometimes you want to set repeating formatting for alternating items (like rows in a table) and so you might want to set every "even" or "odd" child to receive certain formatting. Examples:

tr:nth-child(even)
{
   color: yellow;
   background-color: green;
}

tr:nth-child(odd)
{
   color: white;
   background-color: black;
}


So the even rows in a table would be yellow on green, while the odd numbered rows would be white on black.

What about selecting the immediate child li's in an unordered list, but not the ones nested in that ul's child tags? Or selecting a certain tag when it immediately follows a particular other tag?

ul > li:last-child //only last child LI of UL, but only direct-child, not nested descendant LI tags
{
   margin-bottom: 30px;
}

h1+p // select P tags that immediately follow an H1
{
   margin-left: 2em;
}


There are many more CSS selectors you may not have worked with, but that's a few to give you a taste, and they are pretty well supported now.

Additional Development

As noted in the previous installment of this series, I recommend you pick up the books we're using in our HTML/CSS/jQuery class now for a fuller treatment of these topics:
  • Murach's HTML5 and CSS3 (including intro chapters for JavaScript, jQuery, and jQuery mobile) by Zak Ruvalcaba and Anne Boehm
  • SitePoint's jQuery: Novice to Ninja by Earle Castledine and Craig Sharkie
Remember to take advantage of being part of the Centriq alumni network, and best wishes on your continuing career development!

Friday, February 8, 2013

HTML5 Crash Course – Part I of HCJ Series

[This post is re-published from a piece I wrote for the December 2012 edition of the Centriq Alumni Network newsletter.] I thought I would start off a series that tackles a few concepts that we've begun incorporating into our web design class in the Application Developer track in the past 6 months – HTML5, CSS3 and the jQuery JavaScript libraries. This reflects the growing adoption and support of these languages and technologies, especially in the wake of the explosion of various mobile devices. Of course, HTML5, CSS3 and jQuery could each be a book-long discussion in and of themselves. This will only be an introduction to HTML5 – but one intended to get your feet wet quickly and without a lot of fuss. The next piece in this series will be for CSS3, and the final installation will introduce getting started with jQuery in your websites.

HTML5 Evolution and Philosophy

HTML5 is just the next evolution of the HTML language family, just like XHTML was an evolution of HTML 4.01. However, one of the first trends you'll notice in HTML5 is that they have tried to simplify things – such as the new DTD (Document Type Declaration). All this line of code was ever intended to do was to identify what language was going to be used in the document that followed, so we could validate the code against that version of the language's rules. Now the DTD has been radically simplified in HTML5:

XHTML 1.0 Transitional DTD code:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

HTML 5 DTD code:
<!DOCTYPE html>

Part of simplifying HTML5 has included recognizing and supporting some of the common, real-world usage of HTML. So, for example, the target="_blank" attribute/value pair for the <a> tag (which can be used to cause a link to be opened in a separate browser window or tab) is so popular that HTML5 has rolled back its former deprecated (marked for deletion) status – it's now okay to use again. Similarly, all self-closing tags like <br /> and <img /> are no longer required to use the closing forward-slash explicitly stating that they are self-closing tags. Instead, in HTML5, you can write them simply as <br> and <img>. But in the spirit of being more loosely ruled, HTML5 doesn't disallow writing self-closing tags in the XHTML fashion with the closing slash – so adapting your XHTML documents to HTML5 is extremely easy, because you don't have to go back and change much. Just updating the DTD as noted above is your first step.

HTML5 Semantic Structural Tags

So what else is new and well-supported with HTML5? One of the strong trends with XHTML and CSS was to move away from using tables for page layout and to instead use a complex series of nested <div> tags combined with CSS to lay out any given page. However, since the <div> was such a generic structural container, we often coded them with a variety of classes and ID's describing their purpose. Through popular usage, some common container types became obvious: most pages would have a banner section, one or more navbars and a footer. Some pages would have sidebars for things like ads, highlighted side notes or pull quotes. Some pages might have tables or images that should be displayed with a consistently formatted caption.

HTML5 has new semantic tags for all these things, rather than just calling everything a <div> and manually assigning it some arbitrary ID or class to identify its purpose.
  • <header> – acts as a banner for the page, often containing the name of the site, logo or branding images and colors, and possibly navigation elements. Not to be confused with the <head> section of the document reserved for meta information and links to CSS, JavaScript, etc.
  • <nav> – for sections of the page with multiple links (especially for navbars used as the site's internal navigation system)
  • <footer> – a section, usually at the bottom of the page, with minor, closing details
  • <aside> – for sidebar/sidenote content of any kind
  • <figure> – to contain any illustrative information, especially that needs captioning (technically not a block-level element, but you'll often want to format it that way)
  • <figcaption> – a caption for the figure (also commonly formatted as block-level)
  • <article> – often used for blog posts, news items and periodically published content
  • <section> – another generic container, like the div. I'm not a fan of this one yet, but it's out there.
Transitioning to these new tags doesn't take that much work, especially if you are creating a webpage design from scratch. But you can also adapt an XHTML template by replacing things like <div id="banner"> with <header> and <div class="sidebar"> with <aside>. Just don't forget to make all the necessary changes in your CSS. Where #banner and .sidebar were included in your CSS (or div.#banner , or div.sidebar ), change them to header and aside instead.

Setting Basic HTML5 Compliance for Older Browsers (using Shiv and CSS)

Although many elements of HTML5 are well-supported in most modern browsers now (including most mobile devices), it's not universal. So to ensure that at least your basic HTML5 semantic tags (mentioned above) are handled properly by an older browser that is not familiar with these tags, it's an easy, two-step process.
  1. Add an HTML5 shiv/shim to the head of your HTML file.
  2. Add a style declaration to your CSS to ensure the newly introduced HTML5 tags that should be seen as block-level elements are formatted that way.
The HTML5 shiv is just JavaScript (or a link to JavaScript) that explains to an older browser that isn't familiar with HTML5 that these tags exist, and should not be ignored or rendered as plain text on the page. (The shiv is also sometimes called a shim.)
  1. 1.  Connecting to a shiv hosted by Google:
<head>
    <!--HTML5 Shiv-->
    <script
        src="http://html5shiv.googlecode.com/svn/trunk/html5.js">
    </script>
</head>


This script we're linking to off googlecode.com essentially performs the following JavaScript function for all HTML5 elements:
<script>
    document.createElement('header');
    document.createElement('footer');
    document.createElement('aside');
    //…and so on, for each HTML5 element
</script>


You could even include the code above (with an additional line for every HTML5 tag that needed to be "created" for the older browsers) in the <head> instead of the link to the shiv from Google – but it would be more work and would only create the tags you manually listed.
  1. 2.  To further specify in CSS that some new tags should be formatted as block-level elements:
article,aside,figcaption,figure,footer,header,nav,section {display:block;}

The CSS addition above is quick, and should be placed near the top of your CSS to set the baseline formatting for these new HTML5 tags. It's just to tell the older browsers that these new tags should be displayed as block-level elements – for the most part, newer browsers will already know. Later in your CSS you could and will add additional style declarations to further format these tags – perhaps centering your header and footer or floating all sidebars to the left and giving them a tasteful background color.

Additional Development

For a fuller (but still not exhaustive!) treatment of the topics in this series, I recommend you pick up the books we're using in our HTML/CSS/jQuery class now:
  • Murach's HTML5 and CSS3 (including intro chapters for JavaScript, jQuery, and jQuery mobile) by Zak Ruvalcaba and Anne Boehm
  • SitePoint's jQuery: Novice to Ninja by Earle Castledine and Craig Sharkie
Best wishes on your continuing career development!

Tuesday, July 10, 2012

HTML5 and the Future of the Universe

Web site people are always catching up. You get involved in an extended project and by the time you're done, they've changed the rules again and it's time to learn a new technology. I used to think this was a problem. Now I see it as a responsibility to manage the information of an ever expanding set of hardware devices that are becoming digital.

As these digital devices become of age, they mature into a web access point because of the value it adds to the device. Some devices like tablets are born with the ability to talk to the web at birth. Others, like DVD players, had to wait until they grew up.

HTML5 and CSS3 are expanding to fill the needs of the digital appetites of these new devices. As we innovate to market test a device at every screen size possible from phone to tablet to TV, the older development technologies will continually be updated until they break. So far, HTML and CSS are holding their own. CSS not so much. Even the old dog, JavaScript, is doing well but has some sturdy jQuery and CoffeeScript crutches.

The raft of programming languages not originally focused on the web that try to manage that environment push the simple text retrieval process to be more app like. In their desire to improve the unique asynchronous request-response communication model, they, in my mind, will eventually destroy it. Face it, it's slow. You can do faster communication with AJAX which is why you see Google using so much of it on their web apps. It's why jQuery Mobile designed their GUI library for speed with AJAX so much that it's the primary communication model that tolerates the web request model.

Now a newer model of finer grained I/O control in JavaScript is starting to appear called the WebSocket API. Did you not see this coming? It's not the end until each language has a way to use a simple library of functions/methods to talk to any device of your choice.

Languages are shifting little in popularity. A recent TIOBE trend announcement showing that the iOS platform language of choice, Objective-C, has been the faster gainer over the last two years to take the #3 spot on the chart, is the only major change. With Java trending downward and losing the lead to C, a venerable stalwart, I'm not seeing where anybody is picking up the slack. C# is on a slow trend upwards but not that much. Even php is losing ground.

My guess is that JavaScript is picking up the slack from reading language popularity articles. You can run a survey of projects on StackExchange and Github and find out that JavaScript has the top ranking there. Hacker News put JavaScript in the top three as well with Python and Ruby taking the top spots. Even job rankings on Dice.com show JavaScript in the top three to get a better sense of real world usage. Book sales from O'Reilly put JavaScript at #2 showing a mix of business and hobby use.

The next step for JavaScript would be to revive the server side version of the language and make it as available as php is for Apache. Then the major languages would write APIs to talk to JavaScript and we would have a programming interface for the web. Oh, yeah, and somebody do something in JavaScript to make CSS easier to work with. LESS is a good start.

So, if you are a web person, the future of the web looks like it centers on web application development and JavaScript is taking center stage. APIs will be promulgating and JavaScript/jQuery/minor language support plug-ins will be promoted. One of the APIs that is next on my bucket list is YQL. I think with the first book out on YQL in a few months from O'Reilly, we'll see an interest in mining the data of the web from JavaScript languages.

Excuse me now, I have to get back to the future and read about what's coming so when I start working again I won't be too far behind.



By: Doug Hoff

Thursday, November 3, 2011

The Web’s 4 Hats & an HTML5 Overview - Part II


Designer

The designer in me wants to have my great user interface so well integrated into the data and processes that you don't notice. And I want it to be beautiful. That hat wasn't the one the standards committees were wearing when they proposed the gradients and transforms. Misguided blink spans and easy marquees have been put to death as many times as Freddie and Jason but keep coming back for more. Now we have them again, only this time a little more well dressed. I really don't even like the drop shadows but some of these will look much better to the high-res tablet crowd.


I am happy with SVG support and the graphics we can do, but where is my visual SVG graphics designer integrated with HTML and CSS? Android was the last to jump on the SVG graphics bus and most of the rest of the cheesy effects have partial support so I know I will be trying out Inkscape and SVG Edit when I need.  Or I'll just sit back and let the widgets take over for me like the SVG based Chart control in Visual Studio and jQuery plugins.

I find the most pleasure with web fonts, especially Google's public accessible fonts and having Web Squirrel give me everything I need to do it on my server. I can talk to the device to get info I need to deliver a pleasing layout with the @media queries. And when I need that old-timey newspaper look, there's multi-columns, but I fear it's a retro feature that will be better left alone due to the complexity it creates for the layout.

Surprisingly, I think the designer ended up with some of the best improvements. Colors are better defined both with more names and flexible opacity. The video and audio elements will have to wait for the patents to become less profitable while we find a common standard to work with. The dominance of the iPad will force me to encode a different way but I don't like it.

Businessman

If you want to know who is going to win the HTML5 battle, you just have to follow the money. And the hat in charge of the money is the businessman. This hat is the hardest to wear since it requires you to not think technically and focus on the customer. Does the customer really want what we think is geeky cool warez? Probably not.

I liked the idea of doing a survey of the currently used names for divs and classes in the wild in order to understand how people used HTML. But what were we supposed to do with that? Did I really want a better element because I was really happy with just calling my div a wrapper in the id and not a section. You want me to recode it? When?

What helps me make money? Coding faster. Reusing other people's code. If all you do is rename things, then it's going to get in my way. Now if you make it easier to find elements in CSS by adding better selectors, I'm not going to complain but it is looking more and more like a grep or regex language these days.

I can reuse other people's code if they've marked up what I want to use and now we're back to microformats because what I want is not generic text groupings that are or aren't related. What I want are finer granulation on the most common business entities which is exactly what the microformats do.

Other types of useful abstraction that will be faster or give me critical information are the new communcations APIs like Web Workers or Web Sockets and the ability to let me work offline with session or local storage when paired with the page caching. Geolocation is just a one-trick pony but had to happen when you start moving yourself around instead of sitting at the same IP day after day. And the database storage on the client will improve the user experience for offline as well.

Conclusion

People want a desktop application experience on the web and want it whenever they want it there. People have to have it easy and that means the developers as well as the users. So will I use the semantic markup? Probably. It will help me as a programmer. Will I use the <canvas> and other graphic elements? Probably not. I like SVG and JavaScript generated graphics as long as I don't have to write it. I can use Adobe Edge or other visual programs for that. Will I use the features that aren't well supported like drag & drop and datepickers where I can use jQuery and jQuery mobile to get standardization now? Obviously not.

The 2-D and 3-D graphics are incredible and not in my realm as a web developer but if you are a game developer that wants to leverage the e-commerce platforms of the future like the Apple App Store, Android Marketplace or possibly the Amazon juggernaut commerce system, then you must develop using <canvas> because it's the fastest and standardized.


As to why standards groups like the W3C and WHATWG don't move too fast, it's because you have four different groups of people all lobbying for their view. The DBA had the upper hand in the last version and now the designer and the engineer seem to be dominating. But like a real business, it's the dialog that is important to crafting a best solution for the whole. Let one company or one hat take over and it would be an impending fail.

The businessman is going to take you to that application experience that you so want. And he will charge you for it and pay you to develop great apps for it. The standards committees don't think like businessmen so you'll need to see what people are really using, really need, and get paid for. My best bet is to watch Google for how they use search data and to watch Amazon for how they will use their e-commerce platform. Of course, you'll also be watching Apple and Facebook as app delivery leaders. Then code for it and enjoy.

- Doug Hoff, Business IT Expert; MCT, SCJP, ITILv3, COBIT LinkIn with Doug


Bookmark and Share

Thursday, October 27, 2011

The Web’s 4 Hats & an HTML5 Overview - Part I


I recently returned from speaking at a conference in Kentucky where I ended up putting on four hats and seeing HTML5 and the future of mobile computing differently each time. I was struggling with trying to figure out why standards committees take so long to come to an agreement. After all, the vision of the web is clear, right?

Why did we get off the XHTML superhighway and jump on the scenic route where we ignore the bumps and potholes of bad syntax and limited metadata? What kind of folks are driving the bus right now and are they really going the right direction? Should we stay on the bus while we head into Mobileville? I've decided that the questions you pose are at least if not more important than the answers you think are right. Because that tells you what your vision is and if you've followed a little of this blog, you know that strategic vision is important.

The four hats are:
  • The Engineer - who likes all of the functionality logically thought out
  • The DBA - who likes the the data well defined and stored
  • The Designer - who likes to deliver an emotional message to the customer
  • The Businessman - who makes sure the customer is happy and they make a profit
Those four hats have led me to not watch the standards groups as much as watch Google and Amazon for what to use in the future that people want. The real vision of the web is to make money by giving computer users what they want. Waiting for standards groups won't get you there. After all, the current prediction is that CSS3 will be completely standardized by 2022.  Here's a rundown of the first two hats:


Engineer
As a software engineer and instructor of many students who become programmers, I know that the web has become populated with these folks that want to turn it into an application environment. That way they can program for it and make it do their will. The back end servers are full of Java, C#, and php and that same force is heading to the browser with JavaScript.

I see the HTML world being altered so that these variable manipulators can have better code and read each other's functions easier. The push in HTML5 towards meaningful naming of the loosely typed datatypes that were divs and spans is going to give programmers a better handle on what it is they are talking to. The code will become less dependent on ids and more dependent on setting up the HTML with the proper element names like <mark>, <time>, <progress>, <meter>, <details> and some of the more argued over names like <style scoped>.


I can see where the types of activities previously handled by JavaScript are being pushed into HTML. This reduces the language down to one, slightly more complex, language. Do we want a merger here of interests? Is the MVC principle being corrupted and should we really mix our text markup with programatic data validation in the same code module? The data and its validation are View Model pieces that are tightly coupled and should be handled together in my mind.

So the future lies with the ultimate merger of HTML and JavaScript and we'll have a Razor style view engine in all browsers eventually. My opinion is not to follow the same syntax and find a better way to merge the two. But the merger will eventually come. Simplified syntax for CSS3 and JavaScript have started to reinvent these stuffy languages and if jQuery can simplify CSS with a replacement like EZ-CSS, sass, or less, then we're on our way. I'm hoping it's not like node.js and stylus, but I need to try those more.


DBA
I also love to understand data and its meaningful use. Having the right field name and the right multiplicity gives me a warm glow. But I also know that too much data analysis can torture those poor programming souls who have to recombine the data for the page they work on.


Here we're not talking about the fields where programmers hand over their data after the output is available but where the data can be semantically meaningful as text. These are the domain entities and at a high level they are represented by <header>, <nav>, <footer>, <section>, <aside> and <article>.

My biggest hurdle here is knowing that the data already comes from a semantically proper framework called the database. If all the work has been done there, then who benefits by rethinking the meaningful structure one more time for the web? The only answer is that the DBA traditionally send the data to the programmers who use that "data markup" for their benefit. The field names become bundled together and as I put back on my Engineer hat, I am happy to create complex View Model types for my View, the web page.


But it's reinventing the wheel when there's a database and it's better for team coding experiences to have more readable code. But wait, is there a web service that might be looking for my article elements? Not yet in the HTML5 way. If you are looking for a current semantic framework of entities, you have to look no further than Google's recommendations. The microformats they recommend carry much more weight for reasons to mark up with them than just a standards board. People are using the schemas for reviews, events, organizations, places, restaurants, recipes, etc. without even knowing about it but you are losing out on having Google process your data and provide search results with it if you don't.


The XHTML push that we unceremoniously dumped was a DBA's dream for a perfect interface language between data source and data consumer. The problem was that it's not a homogenous set of data. Our web DBA's don't work under the same domain and the complexity made it uncomfortable to work with so many needs and choices that we found had already been solved with another data model. Or two (relational and objects). We didn't need a third (XML).

To be continued...

- Doug Hoff, Business IT Expert;
MCT, SCJP, ITILv3, COBIT LinkIn with Doug


Bookmark and Share