I have been working on some exciting new WordPress things that I plan on releasing in compliance with the GPL.
First, since there wasn’t a decently simple (free) front-end profile management system, I decided to write one if my own. It is completely customizable with short codes and allows you to validate input with regular expressions before you save the data. All of this is controlled in the post editor. It is nonced using WordPress’ nonce API. It’s pretty elegant in its implementation.
Next, I plan to release some sort of iteration of my SCSS/CSS and WordPress template framework tools. I have tons of code generation spreadsheets that make grid design and implementation a piece of cake. Provide a couple parameters and the spreadsheet will calculate responsive grids. The grid is based on 6 columns and intelligently resizes all the way down to small screens. I have spreadsheets to make a lot of development work easier. It would be a shame if I didn’t share.
I started a new GitHub repo to fill with jQuery utilities and behaviors.
The initial commit is filled with viewport sizing utilities. The utilities make it easy to use viewport-relative sizing in situations where browsers do not support VW and VH.
Something that I use a lot is the Letterboxing module. Simply by adding .jq-letterbox, you can strictly enforce an element to have a widescreen aspect ratio. This is very handy for sites that show lots of YouTube movie trailers.
Grab the Repo
1. Import a recent version of jQuery
Note: script tags do not need
2. Import the utilities AFTER jQuery
Full usage information is available at the head of the jqUtilities.viewport.js file.
.js-vh: Viewport Height positioning
data-vh: a numeric value greater than 0 (zero). 1vw is 1% of the viewport's height.
<div class="js-vh" data-vh="50"
<!-- this will be half the height of the viewport -->
via jqu_log: reports new height in vh
via jqu_log: reports when requested vh is invalid
By default, these utilities log errors to the console.
- Mixed markup and style information. Style information is hard-coded into HTML markup. This might be undesirable.
- This is not a polyfill. It is a workaround. Nice polyfills exist, and that might be a better option for you.
These past 10 years have hosted a huge evolution in our data distribution technology. Since 2000, we’ve watched household broadband speeds move from about 0.5 mbps to somewhere around 20 mbps on average. This is awesome.
We have new LTE networks that are capable of pushing around 50 mbps over the air. Please note: this is faster than most household connections.
We live in an era of increasing bandwidth, and this is good news for web developers. This allowed sites like YouTube to become popular, because they finally had customers that could enjoy their product.
But developers have new struggles! Now, developing truly mobile applications (both native apps and web apps) must account for the new obstacle: carrier data caps.
How annoying. We’ve finally been given a trove of bandwidth (both low latency and high capacity), and we have to start using it very carefully–dare I say responsibly…
It’s food for thought. We have better networks and more ubiquitous access but increasingly more consumers have charted courses for the edge of a bandwidth cliff every single month.
So we must continue to adapt.
Things That Are Concerning
- Popular development frameworks can be rather bloated. Twitter Bootstrap (minified) is 101kb and another 17kb if you want the responsive tweaks. .
- Developers that don’t pay attention to client-side caching techniques. Make browsers get changes by using ?ver=[autoincrement] to force browsers to reload only when content changes.
- Everybody wants “apps” and these apps need data. Lots of these apps send a lot of data (either as JSON or XML) without implementing a cache mechanism. Twitter uses a neat trick to keep data transfer down: the since_id query parameter. This minimizes payload by ignoring content that the client probably already has.
- XML has too much data overhead on structure to be considered efficient, yet it is hailed as a great data interchange format–NOT FOR THE WEB! Typically ever XML tag is matched by a closing version of the tag. Look at the overhead here: <strong>this is bold text</strong>. The strong tag and its closing tag take up 17 characters, which is equal to the length of the content it formats. This is a massive overhead! Mobile clients shouldn’t rely on XML for updating content (like a timeline of continuously updating information).
This was merely a brief rant about implications about data load. This doesn’t even consider some of the changes that occur with data throttling, and packet shaping.
Worrying about data overhead is the new black.