TL;DR version

When your eye looks around a scene, it will automatically adapt to the differences in brightness. In photographic terms, your eye creates many ‘exposures’ as you look around a scene.

When you take a photograph at one exposure, it isn’t as adaptable so the contrast in a dark and bright scene is very harsh.

Therefore, an HDR pictures (multiple exposure combined into one) is more like what you would see than the ‘normal’ pictures.

However, like any effect, it can be taken too far.

Example

Wondering around Bristol last weekend, a saw the sun behind the main Cathedral, which is a pretty impressive building.

The ‘normal’ shot looks like this:

Ok, but nothing special. By normal, I just mean that I set the aperture to F5, and the camera took an average reading of the scene and decided on the exposure time. A lot of the time that means the sky gets washed out to white, as shown above. You can’t actually see the clouds that were there.

In this case, I took a bracketed shot, where you set the camera up to take three (or 5) shots. The first is the standard one, and then it takes an under-exposed version, and then an over-exposed version.

Those shots look like this, and you can see the sky properly in the middle one:

You then stick those shots into a programme like Photomatix or Photoshop and it blends them together to even out the exposure.

A lot of HDR looks rather fake, but the default isn’t necessarily unnatural looking:

The sky is a bit blue and the clouds a bit yellow, but you could handle that with any photo-editor.

You can also go mental with it, and you’ll see a few shots like this around:

However, if you aren’t so heavy handed, I quite like this version, especially at full size (click through for that):

For me, that is closer to what I was seeing, because at the time, my eye would flick to the building and I could see the details, and then flick to the sky and not see a washed-out white thing.

People, sky and water are not easy to capture with HDR, but it has found a place in my arsenal. If you are interested in HDR photography, I recommend checking out Trey Ratcliff’s StuckinCustoms. Apart from using Pixelmator instead of Photoshop (which I can’t use to save my life), I learned about HDR from his site.

To show the effect, take a recent responsive design such as the Boston Globe and zoom in. In Firefox, Internet Explorer or Opera and it behaves how I expected, the media-queries trigger and the layout adapts:

However, when you try the same thing with Chrome or Safari, the zoom works (text and images get bigger), but all within the same layout:

NB: I think it is around 200% zoom, but it may be a little off.

It gets even more obvious when you scroll down, as you have huge text in narrow columns.

Accessibility

It looks like a bug, but you might be asking what effect that has on accessibility? The main impact is on people with mild to moderate visual impairment who use browser controls to increase the visibility of websites.

The browser landscape has changed a lot in the last few years, including how browsers zoom. In ye-olde days most browsers allowed you to increase the text size. Now the default method across virtually all browsers is to “zoom”, which increases the size of everything.

Zoom works well for people who need things a bit bigger unless you immediately get horizontal scrolling. That is why responsive designs (which re-flows the layout at smaller resolutions) work well for zooming, because the layout adapts to the available width.

What is a zoomed pixel?

I don’t know what the root cause is, however, from a front-end development point of view it is as though Firefox and Internet Explorer increase the effective pixel size, so when you zoom in there are less pixels in the same area. Webkit does not seem to take the same approach.

It is not event-related, as reloading the page does not trigger the media queries (except the edge-case described below). Overall it is very odd, because the reported pixel size of the window does change, at least for JavaScript (test example).

Mobile Webkit uses a different style of zooming, as when you ‘zoom in’ the window stays the same, but your view zooms in without affecting the layout. I wonder if this is a conflicting method?

Another oddity is the difference when using EMs. I created a simple test case of max-width media queries in pixels and EMs. If you zoom in so the page reports less than 500px of width, neither triggers. However, if you then refresh the page, the EM based query (only) does trigger. Bizarre, but another facet to the bug(s).

I suspect that Google is aware of some issues to do with this, otherwise you wouldn’t get a red-banner warning if you zoom in on a Google Doc:

It might not affect many people at the moment (although that is debatable), but Chrome is rapidly gathering market share, so either it will affect people or it reduces Webkit browsers usefulness on the desktop.

I’m not in the Webkit browser world, so my question is: where’s the best place to report this?

Good points, and I certainly agree with not using HTML5 as the umbrella term.

However, I’m not sure Jeremy’s point that we didn’t need a catch-all term for “HTML4.01 plus JavaScript” is going to help. (We did have DHTML as an umbrella term. Ok, that is a tarnished example, but my point is that people still remember the acronym.).

Presumably the aim of the logo is to let (non-developers) know that a site is built with a certain set of technologies?

So the next question is: What should the umbrella term be?

I believe Eric Meyer has been using “Open web stack”, which is accurate and works with developers. However, I think we need something a little shorter and snappier (preferably an acronym of 6 letters or less that can be pronounced easily. Like AJAX.).

Something that combines W3C, open, web… the WOW stack? Maybe not, any other ideas?

We need something else, or HTML5 will become entrenched as the umbrella term.

I can agree with almost all of Duff’s points, and it’s covered so well I didn’t feel I needed to check the source material (although I will). But as is the nature of blogging, there is something I’d like to disagree with:
The comparison with HTML.

Duff knows a great deal more than I do about PDF standards and technologies, however, I’m pretty strong on the web-standards side of things, so it’s a useful discussion around the intersection of these areas.

I’d not heard it put in this way, but it is an excellent point:

PDF creation is democratic, HTML is centralized

…most people don’t write HTML, so most don’t author documents with any attention to semantics. Since PDFs may be created and posted without the benefit of a content management professional, it’s harder to impose authoring standards outside of specific organizations.

I agree with the point made, but there is a good reason why HTML websites are more likely to be accessible than PDFs in this context: the interface.

Interface lockdown

When you setup the editor in a Content Management System, you can lock it down to only allow semantic elements. You can even make the inclusion of style-oriented elements look wrong by adding certain CSS.

The key thing is that the available options are accessible, and the inaccessible ones have been removed (e.g. font/background colours). There are other things to do, but that problem is solved once, and then works for that website ongoing. If the CMS is sufficiently usable, you can even extend the number of contributors without worrying about the accessibility.

Theoretically, you can also lock down Word templates so that you can only use Word’s styles (I’m not sure about InDesign?). However, it’s a pain to implement, and I’ve not come across an organisation prepared to do so.

How organisations typically publish documents

In a typical medium/large organisation that publishes web content, it is generally non-technical people updating web pages and uploading documents. When I’ve run courses teaching people how to make accessible PDFs, it is generally people on a web team that attend (government, private and charity sector organisations). Not coders, content authors and managers.

The web team are usually happy with the web pages, but they are sent inaccessible PDFs to publish, often without access to the source documents. The central team simply doesn’t have the resource to repeat the same accessibility fixes on every document they are sent.

I’m not blaming PDF for this situation, I’m even reluctant to blame Microsoft (where the interface matters most), it’s the people buying software that aren’t aware of the issue.

Pressure from organisational procurement (on Microsoft and Adobe) to provide a good option to use a locked down interface (and enforce it’s use) would prevent most of the accessibility problems we see. Oh, not to mention some more competition in the PDF-tagging software space.

Therefore, I agree with Duff that the report is likely to lead to an ineffective policy, even though I have a different perspective on why.

I’d glanced through the requirements, which were relatively good for a Council, but obviously include everything and the kitchen sink. The presentation gave a brief outline, these are some key slides for the requirements:

Apologies for the picture quality, check out the full presentations on Bristol City Council’s blog. (Some of it is available on Connecting Bristol in video.)

I think these requirements will lead the Council down just the same path they are trying to escape. Particularly:

• Using Java or Microsoft (internally support technologies)
• Having a 5 Year roadmap
• Over-arching requirements that affect all other functionality; such as being multi-lingual, personalised, and accessible. Assuming that each of the specific functionalities (e.g. forum) has to meet those over-arching requirements (which is implied), they create an enormous overhead. Not that they are unachievable, but the chances of a traditional CMS being able to meet them across all the specific functionalities are non-existant.

Although not in the slides, there are two implicit requirements:

• BCC do not want to be trapped using a niche product with limited suppliers.
• The ‘solution’ would be a single product

Unfortunately there isn’t a solution that will meet those requirements.

Java

NB: There was no-mention of Microsoft ‘solutions’ at the meeting, so I’m assuming BCC don’t believe one would be open or cheap enough.

I would ditch this requirement for several reasons:

It assumes people unfamiliar with the website’s development will edit it.

Even if a Java CMS were used, why would Council staff mess with the CMS? Perhaps if the internal staff are involved in the development work it would be ok. But then, why use an external supplier at all? Assuming that the Council physically host it then they can and should administer the system, but it doesn’t need to be in Java for that. I would separate the development from the (hosting) administration, and have a contract with the developers for support for the application(s).

Another option would be to hand-off the hosting to the company developing the website (or their hosting partner).

Java isn’t used by people creating modern websites.

I have nothing against Java, and it is eminently suitable for many purposes. Unfortunately quick development of a modern website is not one of them. I recently looked around for a Java framework that produced good, clean, accessible HTML. There are some promising developments (e.g. Grails), but as a general rule Java developers/development doesn’t tend to care about the front-end. For example, a client was considering the Java Icefaces framework, who’s knowledge of accessibility is years behind current thinking.

How future proof is Java?

Another count against Java (especially in a 5 year time frame) is whether it will be open. Since Oracle bought Sun, and especially since they sued Google over Java, Java’s future direction is in doubt. Not that I think BCC would have a legal issue, but Java could be a legacy technology in 5 years.

Java is inherently a heavy technology.

We used to use Java for our CMS, and using the JVM plus database and webserver is a lot for a server. Compared to a LAMP stack (or our preferred Linux/Nginx/Postgres/Python) you won’t get a lot of bang for your buck. A modern website tends to integrate multiple streams (e.g. RSS), databases of things, and related components, and if you look at the big players (Yahoo, Facebook etc.) they aren’t using Java as their primary technology. Neither are the products catering to small players (e.g. WordPress & Drupal)

5 year roadmap

This requirement is inherently going to discriminate against open source solutions. The nature of open source development is distributed and reactive, there isn’t a “guy in marketing” who will draw up a customer friendly roadmap.

You need to either to find a partner company with a good track record who looks like they will be around in 5 years, or go into the initial development assuming that you’ll have to be able to move off the solution with a 1 year turn-around.

I also don’t think that proprietary solutions are realistically better here, it’s just as likely they’ll get bought out or go under. The difference between an open source CMS dying out (like APLAWS) and a proprietary one going under is negligible, you’d have to migrate in both cases.

Overarching Requirements

These are useful and necessary requirements (e.g. accessibility), I’m not suggesting they are ditched, just that combined with the desired functionality, the Council should not be looking at one product.

Start at a lower level

Council (in fact most) procurement starts with the assumption that you can draw up a list of requirements, and assess a series of products and see how well they match. CMS products (commercial and open source) are built to meet these tick-lists.

The thing is, the more boxes a product can tick, the less likely it is going to do it well. You know that joke about consultants? They can be quick, good, cheap: pick any two.

There is a similar ‘law’ of content management systems, pick two out of:

• Quick to implement
• Flexible functionality
• Have an easy to use interface

Take WordPress as a well known example, it’s got a reasonably good interface, and it can be very quick to implement. However, it isn’t going to be flexible enough for the Council’s requirements (e.g. changing the workflow).

Drupal can be quick to implement (for sites which have the same assumptions that Drupal makes), it is quite flexible, but it’s a pig to use for non-technical authors. (You can modify the interface, but then it’s not quick to implement.)

Having done some Reddot development, that is fairly quick to implement a site, and the interface for authors is ok, but extending it can be a nightmare.

New assumptions

So what to do? The most important change in assumptions are:

• The website will be highly customised and that a traditional CMS is not going to meet the council’s requirements.
• Start with only the core requirements to provide the most important services, and a roadmap.

I’ve done a lot of user-research with local authorities, and if you don’t get the basics right (easy access to core services) all the fancy ‘Web 2.0′ style functionality is wasted.

My recommendation for technical direction would be to use a framework based approach. Use a lower-level framework like Django, Ruby on Rails or MS MVC. These were created as toolsets for creating modern web sites / applications. Some companies have CMS type products that provide an easy-to-use interface that sit on top, just be careful they retain the flexibility of the underlying framework. The key is that you start with a core website and build exactly what you need.

Another approach would be to assume the use of several technologies. For example, use Drupal as the main tool for the website, but assume that there will be an extended development time for customisation, and other products will be used, skinned and customised.

I prefer the framework approach, as you spend less time working around the assumptions of the CMS, but it depends on the situation. Let’s hope the Council can get past the standard thinking.

---

My biases

I think everyone at the meeting has some inherent bias or agenda, I’ll make mine explicit:
I work for a company (Nomensa) that does work with local authorities (and others) in the area of user-research, web design and content management. The usual disclaimer that these are my words applies.

So in experience terms, I’ve run or seen lots of usability testing, Information Architecture sessions, and focus groups of citizens/customers for local authorities. I’ve also been involved with many CMS-migration / redesign projects at local authorities (and other markets).

I’ve also spearheaded development of our (DJango based) Content Management System Defacto (website updating soon), which was born out of frustration with inflexible and inaccessible CMS products.

However, what I’ve written above is my honest assessment, we haven’t bid for the website and I don’t have any commercial interest at this time, just a Bristonian’s interest!

]]> http://alastairc.ac/2010/09/bristol-council-cms-discussion/feed/ 9 http://alastairc.ac/2010/09/send-to-my-fridge/ http://alastairc.ac/2010/09/send-to-my-fridge/#comments Wed, 08 Sep 2010 23:37:35 +0000 AlastairC http://alastairc.ac/?p=688 I've noticed a trend in how I use the internet now, where I use different aspects of it in different contexts. In my browser there is a set of bookmarks in a folder called "Send to", which allows me to direct resources to different places.]]> I’ve noticed a trend in how I use the internet now, where I use different aspects of it in different contexts. In my browser there is a set of bookmarks in a folder called “Send to”, which allows me to direct resources to different places.

Admittedly I’m on the geeky side; I’ve got lots of gadgets. However, I’m have very lazy/efficient habits and would rather spend several hours setting something up if it saves me time in the long run. The main things I have setup are:

• Delicious
• Instapaper
• Huffduffer
• Boxee

What that actually equates to is that I use those resources on my:

• Laptop (working)
• iPad (reading)
• iPod (listening)
• TV (watching)

The key is that it is easy, and largely automated. If I see an audio file on a webpage, I can use a bookmarklet to ‘huffduff’ it. iTunes will then download it automatically and it appears on my iPod the next time I sync.

Boxee and Instapaper are even quicker, as external services they sync over wireless. For example, a friend sends me a funny YouTube video whilst I’m at work, I hit “send to Boxee”.

Next time I’m lounging on the sofa, I open up Boxee on the television (via the Mac Mini) and up pops the funny video in my list. (I do recommend watching the James Galea card trick by the way.)



The key is not the device per-se, it’s the situation. I can read/watch/listen on my laptop, but I’d rather send funny videos to my living room, and read long articles away from my computer.

Where will it go from here?

I can only see this type of functionality becoming more widespread. Google has already added ‘Send to mobile’ to the Chrome browser for sending to an Android phone. It feels like when Jack Bower (in 24) says Send it to my screen!, but more fun.

I picked on fridges for the title of this post because it is the household appliance that was always touted as being internet enabled someday, but could this be useful soon?

Apply the “send to” principle to e-commerce and I could see something online and order it to my fridge. That doesn’t sound very practical. This example would be better the other way around, so that when I am at my fridge, I’d know I’ve run out of something and it has a “send to” feature that goes straight to a shopping list on my computer, or even to the supermarket.

If you are creating an online service, the simplest implementation at the moment is to create bookmarklets for people to ‘send to’ your service. You can win over a lot of users by not making them think, now you can also enable them to use the most appropriate device for their context.

]]> http://alastairc.ac/2010/09/send-to-my-fridge/feed/ 1 http://alastairc.ac/2010/05/are-browser-updates-a-thing-of-the-past/ http://alastairc.ac/2010/05/are-browser-updates-a-thing-of-the-past/#comments Wed, 05 May 2010 23:07:38 +0000 AlastairC http://alastairc.ac/?p=649 I noticed something in the browser stats before I noticed it on my laptop - Google's Chrome doesn't ask you about updates. I knew, almost subconsciously, that there was a Google updater programme running. However, I didn't realise the impact it could have on web development, and potentially users as well.]]> I noticed something in the browser stats before I noticed it on my laptop – Google’s Chrome doesn’t ask you about updates. I knew, almost subconsciously, that there was a Google updater programme running. However, I didn’t realise the impact it could have on web development, and potentially users as well.

A small part of StatCounter’s Global statistics for browser versions caught my eye:


You might remember from Jacob Neilson’s Alert Box that we were stuck with old browsers for three years:



With IE6′s plateau, it seemed like things were getting worse. Even Firefox (with more tech-savvy users, we assume) is taking the better part of a year to drop under 5% from the release of a new version.

The Google Way

But now there is a new browser in town, with a web application perspective. Let’s zoom in on Chrome, when it updated from Chrome 3 to 4. Light green is 3, dark green is 4:



In a month, Chrome 3 virtually disappeared (5% down to 0.3%), and Chrome 4 took off.

As a web developer: This is fantastic! No more waiting for users to download, they don’t even need to think about it. I don’t need to worry about having multiple browsers installed, because the general population can’t use old versions.

As a user: It’s great… until it breaks. Taking the choice away about when to update a program strikes me as dangerous.

The potential danger is very limited at the moment because Chrome is not bursting with pluggins and isn’t relied on by anything else. However, pluggins are becoming more popular, and upgrades that break web-apps could be a new problem.

We know how well Microsofts upgrades are received when they break things, if Chrome carries on gaining market-share, is it risking the same issues without even giving people the choice of when to update?

Update (August 2010)

This is a consistent approach from Google, the update from 4 to 5 happened just as quickly:



The line that chrome overtakes in July is IE6 by the way, so Chrome 5 is more popular than IE6 now.

]]> http://alastairc.ac/2010/05/are-browser-updates-a-thing-of-the-past/feed/ 0 http://alastairc.ac/2010/04/accessibility-and-html5/ http://alastairc.ac/2010/04/accessibility-and-html5/#comments Sun, 11 Apr 2010 13:41:04 +0000 AlastairC http://alastairc.ac/?p=229 I’ve recently been struck by a parallel: the differences between usability and accessibility are very similar to the differences between writing the HTML5 spec and covering accessibility requirements.

Creating the HTML5 spec is like usability practice

I haven’t been following the HTML5 progress very closely (how much time does that take?!), but skimming the surface, the friction between developers in the ‘accessibility community’ and some of the core group developing HTML5 is obvious.

Usability tries to optimise for the majority. Techniques such as usability testing (with a representative sample) are oriented around getting the best results for the least expense. The changes to the interface based on usability testing should be kept simple and consistent for the majority of people.
I would guess that writing a spec is also an exercise in trying to keep things simple and coherent.

Accessibility overlaps a lot with usability, and historically web-standards + usability = accessibility.

However, there can be a few things missing, such as alt-text and making sure the keyboard focus is visible. These don’t get noticed by the majority of people, but are needed for people with particular requirements.

During the creation of HTML5 there have been several arguments around what is needed for accessibility, such as whether to make alt text required, and whether table headers are needed.

I completely understand that it’s very difficult to create an understandable, cohesive spec for HTML, so everything possible has to be done to minimise the complexity. However, accessibility is something that has to be included in such as way that developers and authors can create all their content in a way that is accessible.

For example, although complex tables are rare, it is necessary that they can be created in a way that works for everyone. Otherwise Governments and Financial institutions that have to publish content accessibly will have to go elsewhere. (Such as PDF.)

Jeremy Keith summed this up well in 2007:

I am more than a little concerned at the way that studying existing behaviour is being held up as a make-or-break point in discussions around HTML5… By their very nature, accessibility concerns are not going to affect the majority of users.

So yes, it’s useful to pave the cowpaths when you know the common ground, but sometimes you also add another path for those that need it.

WAI-ARIA

There is an argument brewing about whether HTML5 makes WAI-ARIA redundant, and a plea for clean mark-up.

I agree that simpler markup is better, and that native controls tend to work best. I wouldn’t want to use something that creates front-end code based on Java people have written. However, some people (at rather large companies) do, and so you get the lowest common-denominator crap code that Steve Falkner pointed out.

So yes: it would be better if people like Google used cleaner code. However, even if browsers improve the styling of elements so that Google doesn’t feel the need to use krufty code, and HTML5 arrives, we are not there yet.

Working only on a future spec where the native controls don’t exist yet is kind of like saying to people with disabilities: “Don’t worry about your internet access for now, you can have intermittent dial-up for the moment, and we’ll get you broadband in a few years.” That doesn’t cut it.

There are several reasons why WAI-ARIAis needed:

• It bridges a gap highlighted by modern web apps.
• It can be added now without causing compatibility issues.
• It can be added at a function level (e.g. to GWT and JavaScript libraries).

There is another important reason though: It should help simplify the HTML5 spec.

Should HTML5 cover all the elements in WAI-ARIA? For example, should there be a ‘tab’ element that HTML authors need to know about?

There isn’t, and I think that’s ok.

I’ve been reading into this more, and would like to modify my stance. The trigger was this: Semantics are best expressed at the semantic layer (HTML), not at the presentation layer (CSS) or the accessibility layer (ARIA), and the realisation that this is the built-in approach, where as WAI-ARIA is the bolt-on approach.

One thing I’m not clear on though, is what approach JavaScript libraries should take. Historically, people creating (web) applications have been really, really awful at using the limited HTML 4.01 semantics properly. Is adding more elements going to help that? Something like WAI-ARIA can probably be built into a Library more easily than adjusting elements dynamically.

]]> http://alastairc.ac/2010/04/accessibility-and-html5/feed/ 3 http://alastairc.ac/2010/03/detecting-touch-based-browsing/ http://alastairc.ac/2010/03/detecting-touch-based-browsing/#comments Tue, 30 Mar 2010 17:39:17 +0000 AlastairC http://alastairc.ac/?p=614 I came across a situation recently where a JavaScript widget didn't 'work' on the iPhone. It did technically work, but without knowing about two-fingered scrolling (and when you need to use it), it didn't appear to work. So how do you differentiate the iPhone (and other touch based devices) from a regular browser?]]> Please note, the method I outlined used ontouchmove, which was also picked up by Google Chrome 6. I changed it to use ongesturestart, which excluded Chrome 6. Now Chrome 7 (windows) does not pick up ontouchmove or ongesturestart.

I came across a situation recently where a JavaScript widget didn’t ‘work’ on the iPhone. It did technically work, but without knowing about two-fingered scrolling (and when you need to use it), it didn’t appear to work. So how do you differentiate the iPhone (and other touch based devices) from a regular browser?
Well, we all know object detection beats browser detection, but what object would you detect?

The issue in this case was with the Stylish Select jQuery pluggin. It replaces a standard drop-down with a nicer looking one. It is reasonably accessible as well, supporting keyboard use.

However, it creates a div with overflow of auto and a fixed height, which in desktop browsers creates a scroll bar. In the iPhone, it looks as though you can only select the ones that are initially visible, because there is no scroll bar.

In this case there is a nice fall-back: the select box that the JavaScript is replacing. The iPhone (and I assume other mobile browsers) show this in a system-native way.

So the question becomes how do you detect that a touch-based device is in use?

The solution came from this article on Detecting event support without browser sniffing, however, it does more than I was looking for, and wasn’t aimed at touch based detection.

I put together a little script that so far, seems to do what I’d like:

function isTouchDevice() {
   var el = document.createElement('div');
   el.setAttribute('ongesturestart', 'return;');
   if(typeof el.ongesturestart == "function"){
      return true;
   }else {
      return false
   }
}

Currently this script gives good results for:

• IE8 / Win (no event detected)
• FF 3.6 / Win (no)
• Chrome / Win (no)
• iPhone 4.0 (yes)

I originally picked ontouchmove as a fairly advanced touch event, but Google’s Chrome started firing for that event. I’ve moved to ongesturestart which works for now, but may also be used in Chrome later.

If you have another device or browser, please try the test page and let me know the results.

]]> http://alastairc.ac/2010/03/detecting-touch-based-browsing/feed/ 5 http://alastairc.ac/2010/03/removing-emtpy-html-tags-from-tinymce/ http://alastairc.ac/2010/03/removing-emtpy-html-tags-from-tinymce/#comments Mon, 29 Mar 2010 14:53:24 +0000 AlastairC http://alastairc.ac/?p=609 A little post for those that run into the same problem I had with TinyMCE and blank instances not quite being blank. I created a little configuration to remove empty HTML tags.

If you have an editable box with TinyMCE, and that box will appear on the website if it contains content, sometimes you can get a ‘blank’ box. When a user deletes content from the box, they might not delete everything in the box, leaving some blank HTML tags.

For example, if there was a list of links, and you use the mouse to select the list, and press delete, it can leave either <ul></ul>, or <ul><li></li></ul> depending on the browser.

In our CMS, when that went through to the front-end page the HTML content meant the box was displayed, but without visible content.

I messed around with some of the TinyMCE API events, ruling out onSaveContent and onSubmit.

The key event was onPostProcess, which allows you to run a script on the content before it is submitted.

Combine that with a little script from Stackoverflow to strip HTML from text with JavaScript, and you get:

tinyMCE.init({
   ... // other settings here
    setup : function(ed) {
    // If there is no text content, return nothing.
    //   NB: Image-only content would get swallowed.
      ed.onPostProcess.add(function(ed, o) {
            var text = "";
            var tmp = document.createElement("DIV");

            tmp.innerHTML = o.content;
            //console.debug("inner html=" + tmp.innerHTML);

            if (tmp.innerHTML) {
               text = tmp.textContent||tmp.innerText||"";
               text = text.replace(/\n/gi, "");
               text = text.replace(/\s/g, "");
               text = text.replace(/\t/g, "");
               //console.debug("if content, text=" + text);
            } else {
                text = "";
                //console.debug("else no content, and typeof =" + typeof(text));
            }
            if (text == "") {
                o.content = text;
                //console.debug("content set, possibly, get content = " + o.content);
            }

      });
   } // add comma here if there's another thing in the list
});

The only weakness I know of in that, is that something containing only an image but no text would return a blank box. I left the console logging in (but commented) if you’d like to see what happens though Firebug.

Free free to use this or to feedback any improvements below.

]]> http://alastairc.ac/2010/03/removing-emtpy-html-tags-from-tinymce/feed/ 0