Homeopathic HTML solutions

Our lives as web developers are amazing. Information flows plentiful and is ever increasing and our quiver of tools to play with ever replenishing. Every week there is some new, groundbreaking thing happening and web technologies are promising amazing access to hardware and making our lives much simpler.

Instead of picking and choosing from these offerings and using the right one for the job, we seem to spend an extraordinary amount of time re-creating the same solutions in several technologies. Not because it is needed, but because we can.

This becomes almost painfully ironic when you see articles that are a massive pat on our own backs for using “plain HTML”, “vanilla JavaScript” or “pure CSS” that utterly and totally miss the mark of using these technologies. Or just omit or misunderstand enough to be broken and a worse performer than a “closed technology” solution.

back patting machine

Examples like these are beautifully styled forms that utterly fail to have labels that do what labels do – connect input elements with descriptive text (both in assistive technology and by making the text clickable in browsers) – as the author failed to understand that you need to nest elements inside labels or connect them with a for/id attribute coupling.

Other examples are creating complex graphical animations and paint with I, B or DIV elements. These are impressive, but no, they are not – at all – semantic HTML. True, SPAN and DIV are defined as elements with no meaning for us to use any which way we want to and I and B are defined as “visual” elements that could display anything. However, nowhere is a definition that adding a lot of nested empty elements is a good idea. That’s like raspberrying, watermelon or capybara your hedgehog in aparagus, right? What? The last sentence didn’t make sense? Don’t worry, there is probably some conversion tool that will make it useful – sadly enough you don’t have access to it right now, though. This is what you do when you use HTML to paint in the browser. You abstract away meaning and make it dependent on other technologies.

Semantic HTML means a few things, none of which are covered by exercises like that:

  • You deal in content. Semantic HTML describes content. It is not a tool to paint with. You could easily create an image using a table with a cell with a background colour as each pixel. It wouldn’t make sense though as a table is meant to give tabular data its structure and describe the relationship of the data parts to each other. Images do not have that need, what they need is an alternative text.
  • You give content meaning. A P tag around a block of text says that this is a paragraph. It says it to people, browsers and assistive technology. It even means it displays with whitespace around it when there is no CSS and it allows you to collapse it in editors. A DIV with a class of “paragraph” does the same for human readers, but only makes sense visually with CSS and none to assistive technology.
  • You increase maintainability. You keep everything that is to be changed when it comes to content in the HTML. You do not have text labels in JavaScript or generate textual information in CSS with pseudo content. That way people don’t have to wonder where a text on the screen came from when they need to change, translate or remove it. CMS have no issue separating content from presentation to make it easy for people to edit pages when you used semantic HTML. When all you use is DIVs with classes, CMS editors will choke.
  • Semantic HTML is a sign of quality and future thinking – it is true: browsers do not care a bit if an element is a DIV or a P. Maintainers do though. And browsers and rendering software or marked up content comes and goes. Semantic HTML is there for humans, computers, search engines, conversion tools and many other things. You can create incredibly terse and nonsensical code and browsers will still do something with it. What you sacrifice though is readability. Sometimes in order to make things easier to understand, you need to write more. That is not a waste, it means you care about what you do and don’t leave it to machines to translate for you for other machines to display.

In order to reap the rewards of clean and semantic markup, you need to think about meaning first and then about code or markup. Writing intelligent, beneficial HTML is an exercise in organising and describing; you could say labeling. It is not about using HTML as the tool to create things that look impressive.

So next time you feel like showing off that you can do things “in plain HTML”, consider the consequences. Think if what you did in HTML really gives the content meaning or if you just painted with tags. We won’t succeed in promoting open technologies as the obvious and better alternative if we abuse them to reach a goal they were not meant for. This is especially important in terms of performance. Every DOM access, every reflow is costly. Let’s use them sparingly.

What we need is more rewards for doing the right thing. That’s why articles like Heydon Pickering’s “Semantic CSS With Intelligent Selectors” are so important. They don’t wave a flag for semantic HTML – instead they make it beneficial to do the right thing. We need more of those, giving people rewards for learning and understanding HTML before they apply it. What we don’t need is more experiments proving things can be done in a technology that wasn’t meant for them. These can be inspiring and are fun to do, but they don’t help the cause in the long run.

View full post on Christian Heilmann

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

Mobile Solutions Day – Firefox OS:supercharged HTML5

Yesterday I did a one-day round-trip to Frankfurt, Germany to speak at T-Mobile’s Mobile Solutions Day about Firefox OS and what it means for app developers. The slides are available here and I recorded a screencast with not-that-amazing-but-does-the-job audio here.

The whole conference was also streamed on the internet and the raw stream recording is available. My talk starts at 02:29:00 onwards. That said, there were some amazing other talks. I especially enjoyed the Ford presentation on making smartphones and smartphone apps controllable by voice and by hardware available in cars like buttons in the steering wheel.

All in all the mobile solutions day was an interesting first round of innovation showcasing inside Deutsche Telekom. More will come soon.

View full post on Christian Heilmann

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

Mobile App or a Mobile Website – Interview with Jason Summerfield, Human Service Solutions

In this twelve minute interview with Jason Summerfield, Principle, Human Service Solutions a Web Development and Application development agency based in Framingham, MA we learn his perspective regarding a recent article he wrote entitled, “What’s the Difference Between a Mobile Website and an App?”

Specifically we learn Jason’s thoughts on:

Which is Better – an App or a Mobile Website?

According to Jason, when it comes to deciding whether to build a native app or a mobile website, the most appropriate choice really depends on your end goals. If you are developing an interactive game an app is probably going to be your best option. But if your goal is to offer mobile-friendly content to the widest possible audience then a mobile website is probably the way to go. In some cases you may decide you need both a mobile website and a mobile app, but it’s pretty safe to say that it rarely makes sense to build an app without already having a mobile website in place.

Advantages of a Mobile Website vs. Native Apps

If your goals are primarily related to marketing or public communications, a mobile website is almost always going to make sense as a practical first step in your mobile outreach strategy. This is because a mobile website has a number of inherent advantages over apps, including broader accessibility, compatibility and cost-effectiveness.

* Compatibility – Mobile Websites are Compatible Across Devices
* Upgradability – Mobile Websites Can Be Updated Instantly
* Findability – Mobile Websites Can be Found Easily
* Shareability – Mobile Websites Can be Shared Easily by Publishers, and Between Users
* Reach – Mobile Websites Have Broader Reach
* LifeCycle – Mobile Websites Can’t be Deleted
* A Mobile Website Can be an App!
* Time and Cost – Mobile Websites are Easier and Less Expensive
* Support and Sustainability
* When Does an App Make Sense?

For additional details, the complete article and additional information on Jason’s organization and offerings follow the links below.

Mobile Website vs. Mobile App: Which is best for Your Organization?

Qfuse Mobile Website Builder and QR Code Generator
Human Service Solutions Web Services
Jason Summerfield on LinkedIn

View full post on Web Professional Minute

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)