HTML5 Zone is brought to you in partnership with:

Paul is a principal consultant at ThoughtWorks. He is enthusiastic about open source in particular. He is known for Dependency Injection (one of its pioneers with PicoContainer), Selenium browser automation (co-founder), Branch by Abstraction and most recently Client-Side MVC frameworks. Paul is a DZone MVB and is not an employee of DZone and has posted 69 posts at DZone. You can read more from them at their website. View Full User Profile

Application Development Glass Ceilings

  • submit to reddit

Sometimes in app-dev we’re using technologies that have a delayed cost. Simple to use now, but with shortcomings that mean that later features might be much harder to add. The term ‘Glass Ceilings’ (whilst classically meaning something else) seems to apply here.

An Example

I’ll Assume you are familiar with Agile. The customer/product-owner asks for a change to an existing dropdown in the UI. She wants a picture of the fruit next to the name of the fruit. He remembers Visual-Basic application development from the mid 90’s where this was easy. Also, She’s seen it in Java-Swing applications not so long ago. Now, that most enterprise apps are web-based, and fifteen years have passed since She first saw it, She thinks it should be easy!

Well, it is not. HTML does not support this be default. Most formal Web-Frameworks don’t do icon+text combo boxes. If they do it at all, it is because the authors have written something special in JavaScript. It’s a very custom control in HTML-land.

Lets say that the original feature (dropdown of fruit names load and saving to the database for the ‘thing’ in question) took a day to write. If we’re using a technology that does not have that feature we are going to have to go back to the product owner with some bad news or VERY bad news. It could take an eternity or be impossible to do it with the technology we are currently using.

What you really hope for is an ‘easy’ addition of something that’s correct for your technology choices. If you were using JQuery as your substantial in-browser technology, or were compatible with it, and you had this exact problem, then you’d be very happy that you found Fairway Technology’s FlexBox. Refer example 7 on their demo site like so:

Punching through the glass ceiling yourself

If we are using a commercial closed-source technology we are beholden to the vendor to even think our change request is important, or have a channel open for such communication. Moreover, we hope they are a competent outfit, and can ship a release quickly. If the technology is open source, then we’ve recourse to fork it and make a change ourselves. In that eventuality, we hope that the canonical version’s team will accept back the changes, and not make too many changes. Incidentally, this is one place that open source teams fails – not-facilitating someone else’s idea for that technology.

The worst-case scenario is that you have to change technologies. You might be halfway through the product buildout cycle, and heads will roll on this bad news!

The best-case scenario, is that the open or closed source team has ‘plugin’ mechanism for adding capability. Even better if there’s a way of leveraging/extending supplied components.

Even in the best-case scenario we’re going to have to suggest to the product owner that the feature She needs is going to take five days, but after that’s done, similar changes to other dropdowns will take half a day.

Thus, in summary, we hope that if we encounter glass ceilings during the building of an app, we can punch though them. Perhaps we are unsure about how much effort that will be in advance of encountering it. It is probably best that we are diligent in technology choices up front. I’m going to return to that particular thought in my next blog entry.

Not just UI controls

The problem of glass ceilings does not just apply to UI affordances and effects. You could encounter it in mismatches between a self-designed relation-schema for your app, and perhaps the Object-Relational Mapping (ORM) technology you chose. Perhaps your synchronous RPC technology should have been asynchronous.


I’ve talked about this before Ruby versus JavaScript for Web3.0 in 2006. That one was proposing changes to web-app coding that have not come into fruition. Perhaps they could with a future version of Dart, but I’m not chasing that agenda for the time being.

I’ll link to other proper HTML combobox solutions if people email me, or comment below.

Published at DZone with permission of Paul Hammant, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)



Karl Peterbauer replied on Tue, 2012/05/15 - 7:40pm

If we are using a commercial closed-source technology we are beholden to the vendor to even think our change request is important, or have a channel open for such communication. Moreover, we hope they are a competent outfit, and can ship a release quickly. If the technology is open source, then we’ve recourse to fork it and make a change ourselves.

Web development is a different beast, and it will remain so in the near future. A web developer's runtime environment is the browser - one of the most limited programming environments on earth. A web developer has a few dozen HTML tags at disposal, historically grown, more or less well defined, implemented more or less standards-compliant, accompanied by a few dozen CSS rules, again historically grown, inconsistent and quite arbitrarily chosen, and a very limited JavaScript API (mostly due to security constraints). HTML 5 does not save the day: Either one sticks to DOM/CSS3, or one bets on the canvas, but that's a total new story (the HTML 5 "schisma").

Let's face it: HTML is not extensible, and it will never be, by design. Thousands of web developers reinvent the wheel every day, over and over again: List boxes with icons, menu bars, tables supporting scrolling, resizing and reordering of columns, date pickers, combo boxes for textual input and list selection, keyboard shortcuts, modal dialogs, and worst of all: no full control of the layout geometry and the rendering cycle...

There is no "channel for change requests" (W3C? Mozilla? Microsoft? Apple? Safari?), and forking is obviously not an option. Roll your own solution or pick one of the cool frameworks/libraries, but JQuery and friends are just workarounds for a limited design. 


John Esposito replied on Thu, 2012/05/17 - 5:21pm in response to: Karl Peterbauer

OOC, why isn't W3C or WHATWG an acceptable 'channel for change requests'?

Karl Peterbauer replied on Sun, 2012/05/20 - 6:50am

Because chances are high that the software in question reaches end of service life before the change request even reaches "last call" status...

John Esposito replied on Mon, 2012/05/21 - 5:27pm in response to: Karl Peterbauer

Good point. Are you on the 'W3C is too damn slow' side, or do you think web standards just need to evolve this slowly? (and do you think the growing Webkit dominance might make a difference -- improving the speed of adoption and providing a good 'change request' recipient, but maybe also monolithizing..?)

Karl Peterbauer replied on Tue, 2012/05/22 - 5:17pm in response to: John Esposito

At least we see a faster standardization pace now, compared to the complete stagnation between - say - 1999 and 2004, and we see a fierce competition between all big boys, both for performance and for compliance.

But major shortcomings are evident. <audio> is a joke, <video> without a common codec is madness, and the CSS/JS vendor prefix quagmire is ridiculous. Webkit dominance is a real menace. Some random quotes from the February W3C meeting with the conspiratorial title "Why and How to Implement Other Vendors' Prefixes":

  • "Non-WebKit browsers face prisoners dilemma".
  • "If we don't support webkit prefixes, we are locking ourselves out of parts of the mobile web."
  • "We are currently losing market share because of not implementing -webkit- properties." 
  • "The cat is out of the box".
  • "If we open this Pandora's box, we're going to be stuck with it".

It would be interesting to estimate manpower and money which will have to be spent world-wide to work around those flaws.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.