Meet other developers and web creators to discuss creating websites to web standards.

LWS June: HTML5 and Flash: where are we now? (Live Blog)

Posted: June 7th, 2010 | Author: Jason Grant | Filed under: Live Blog | No Comments »

Joe Lanman takes the stage for a general introduction of the topic.

Thanks to our sponsor EMC Consulting.

Our next event will be Andy Budd talking about User Experience on 12th July. August will see a summer social (some time in the 3rd week). In September we will have Michael Mahemoff talking about HTML5.

If you know of a good venue for London Web Standards – bigger one than Square Pig, please recommend it to us.

This talk is going to be about Flash vs. HTML5 alternatives for doing common things in HTML5 as opposed to using Flash.

[19:15] Jeff Van Campen takes the stage

Multiple file uploads was missing when Jeff tried to live a few weeks without using Flash and was badly missing multiple file uploads feature on some sites. WordPress is a good example where multiple file uploads is used.

Drag and drop is one of the interesting features which is also commonly used and cool feature along with file uploads.

GMail now (if you are using Chrome) allows you to drag and drop files into GMail to send them as attachments.

This stuff works in Chrome and Firefox – should work in Safari (which is a bit weird), but should work in WebKit night build.

You can attach multiple files to GMail by using shift and selecting multiple files and then clicking on ‘Open’ to attach more than one file to GMail at once.

The way FireFox handles the multiple file uploads is not terribly user friendly as it bungs everything into the file upload field.

GMail allows a drag and drop of multiple files onto the interface to do the same thing of attaching multiple files.

Jeff demonstrated a UI which enables desktop dragging of files onto the browser and the respective web page showing those files as dropped onto the target area.

Jeff mentions PPK article about why drag and drop is terrible mess at the moment.

It’s not really possible to drag a picture from desktop to ‘upload your files here’ area under current implementations.

There is no keyboard accessibility solution for this problem currently – Gez Lemon is doing some work on speccing something out for this.

If you are going to need multiple uploads you are probably going to need a Flash fall-back in order for this to work.

Flash is still the only way for this to work in Opera and IE.

FaceBook handles multiple file uploads through a Java applet of some sort.

The fall back solution is to offer multiple file upload boxes in straight HTML.

[19:30] Nick Smith takes the stage to talk about fonts

Ol’ skool font replacement solutions are Cufon, sIFR, image replacement under the current state of the web.

With CSS3 and @font-face we are downloading fonts from the server.

Cufon wraps words in < span > tags and the words end up being broken up by this tag.

Now Cufon uses < canvas > which is good and is moving towards future.

Cufon can embed links and can protect your fonts (sort of).

Cufon is kind of accessible.

sIFR (Scalable Inman Flash Replacement) is:

  • Well developed
  • Handles any font format
  • Good to protect your font
  • Can be resized
  • Can embed links
  • Accessible

but it is also:

  • Slow to load
  • Don’t handle Flash blockers

This is what Jeff pointed out – there is a group of people who are saying ‘no’ to Flash, and they are left in no-man’s land.

Nick Smith’s site still uses Flash and he demoed an example what happens on it if Flash is disabled or blocked – not very good.

@font-face & CSS3 solution has the following pros and cons:

  • Supports Internet Explorer 6
  • Live text
  • No JavaScript required
  • Accessible

There are also following cons:

Nick demos a font changing example from Apple Developer web site to show the power of CSS3 on the fly.

Kornel shouts from the back rows saying that this is ‘not HTML5′ – discussion starts on whether this is or is not HTML5.

This is CSS3 rather HTML5 – some people thought that Google Pacman logo was HTML5 because it worked on iPhone and it was HTML4 and JavaScript.

Nick says he constantly has the problem with designers that certain fonts cannot be used within web pages, so he has to regularly instruct them that those fonts cannot be used within the context of web pages.

Someone (a visual designer) makes a remark from the audience that majority of CSS3 fonts don’t look as good for Windows users while sIFR and Cufon look much better and as intended by the visual designer.

Audience member says: It seems as though currently you are required to download entire font definition from the web with @font-face which seems to be massive for some languages like Chinese.

Much discussion takes place around fonts on the web and HTML5, downloading it, using it, performance issues and display issues. Many people seem to have an opinion about this particular topic and are commenting extensively about their experience and thoughts about this.

How long until we see ‘HTML5 loading screens’ like we have been seeing on Flash sites?

Does anyone know why aren’t the really big font foundries signing up to distribute their fonts through this. Kornel replies that the same thing happened with music industry. Pirating debate kicks off with a lot of comments again.

You can go to almost every font library and download individual types of fonts, but it is not cheap.

Majority of clients want to pay for the font and its use on a web site.

Kids on MySpace are likely to pirate fonts, but …

Would clients pay for image from Getty Images, so why not pay for fonts also?

[20:24] Edd Sowden about CSS transitions and live streaming

HTTP live streaming

OSMF – Open Source Media Framework can be used as one of the solutions (this is an Adobe solution)

JW Player (from v4.6) supports this feature

Demo shows a live example of video player switching on the fly from low quality content to high quality video without stopping

This works by chunking up files – Apples implementation uses tools which come with Snow Leopard, but only works in Safari under Snow Leopard OS.

ISS Smooth Streaming is Microsoft’s implementation of this live streaming solution.

Looks like its Apple vs. Flash.

On YouTube we currently have the manual process of users having to switch the video up a notch to get the better quality on their browsers.

[Audience question] Is there going to be a native streaming within the browsers implemented any time soon?

I haven’t seen anyone try it other than Apple on Safari with Snow Leopard, but this can be done in Flash.

[20:42] Joe Lanman on stage talking about Vector Graphics

Flash is used quite widely for vector graphics – for practical things like graphing.

A lot of the issues around various solutions are to do with the fact that Internet Explorer does not support it.

Raphael JS is a useful library which allows use of SVG in Internet Explorer by converting stuff to VML.

SVG is more ‘webby’ as it is within the DOM (SVG is XML based) so its pretty cool in that respect.

Joe takes us to Raphael JS web site to show us some examples of what is possible with this library.

The output of a graph in code terms is SVG code which can be styled with CSS in the same way we do it with HTML. This is theoretically more accessible as assistive technologies can read the graph.

Its great that data is there within the DOM so it can be accessed – it is also possible to apply JavaScript to this to add some behaviours.

Its a little bit weird in that it doesn’t support everything so animation via JS won’t work.

Kornel throws in a comment that SVG support animation elements, so animations can be done natively using SVG coding.

Downsides of this method?

This solution is good for graphing but not necessarily for animations which Flash is really easy to create with.

Android browser does not support SVG because ‘SVG adds 1MB to the overall download size’.

There is a JavaScript graphing library based on Raphael JavaScript library. http://g.raphaeljs.com/

[Audience comment] This graphing library does not handle many data points very well. FireFox also tends to halt when there is a big amount of SVG data within a page.

Many audience comments about this topic once again. Flash vs. these SVG diagrams look very similar and not much different at all.

[21:03] Talk is formally finished and informal conversation starts

BBC Homepage uses canvas with Flash fall back on the homepage.

[Audience question] Does it really matter that something is HTML5 as opposed to Flash now?

The BBC clock on the homepage works on an iPhone as well.

Excellent audience discussion about why using open technologies instead of Flash is a good idea.

Joe Lanman closes the night off thanking everyone for participating.

LWS March: JavaScript – The events that get left behind & Pro-bunfighting (live blog)

Posted: March 31st, 2010 | Author: Jeff Van Campen | Filed under: Live Blog | 1 Comment »

Warning: This is a live blog post.  I’ll be typing as it happens.  Expect typos, mistakes and my own distinctive interpretation of the night’s events.

Pro-bunfighting

Frances Berriman will be discussing testing, and group hugs.

She works on the BBC Glow JavaScript Library, which is Open Source.

Small team, with various issues.

Issues

3 people on the team. 2/3rds live in london.

Quite a lot for the three of them to do, but not a lot of face-to-face time.

Problem 1: Communicating what to make

Miscommunication is the source of most project woes. Issues arise when a specification has been misunderstood. Someone does work, but the response is, “That’s nice, but it’s not what I wanted.”

Need to communicate accurately over email.

The unwrap() method

People skim prose.

All communication of requirements is done in code in JSDoc.

Empty source files are created in their repository with JSDoc, then they commit them. Makes it easier to follow than email.

The bun-fight

Locking themselves in a room and have a fight. Go through the docs line-by-line.

Everyone has to read it. Everyone has to understand it.

Bits get removed. Bits that aren’t really needed, so no one wastes time coding it.

Then someone goes away and codes it.

Because they are using JSDoc, they get free documentation.

Problem 2: Checking what we’ve made actually works

Unit testing. The first thing you should think about doing is turing examples from you docs into unit tests.

They use Qunit. setup and teardown are really useful, but don’t seem to be documented.

Sanity checking & code reviews

Notorious at the BBC. Some people may have cried.

Somebody stands over you shoulder and tells you what is wrong.

They make sure it doesn’t read like a W3C standard because nobody can read a W3C standards.

Also check punctuation and make sure it’s understandable by an external user.

Conflict resolution

We fall out, and there is no resolution.

But debate is good. No one holds a grudge.

Problem 3: checking what we’ve made is fast

How do we know what is we made is fast? We benchmark in Woosh.

Live demo of Woosh, comparing Glow to other libraries.

The headlines

  • Treat writing documentation like writing code
  • There’s no such thing as too many unit tests
  • Benchmark regularly if you want to go fast

Events left behind

Jake Archibald

Used Photoshop CS5 content fill to generate his notes.

He likes cycling. He doesn’t do it too often, but when he does it he thinks, I should do that more often. And he notices improvements, i.e. disk brakes are better than whatever went before. One thing hasn’t changed — the chain & gear system still clunks and breaks. Browser events are the chains and gears of the JavaScript world.

Making an application work off of the keyboard is more complicated than you’d think it was.

We need to be abele to be able to track more than one event (polyphony).

Key actions. Key repeating – this differs between operating systems and depending on user settings.

Key actions are monophonic.

Mouse events are pretty well documented in the W3C DOM 2 specs.

What about keyboard events? No a lot.

What do the browsers do?

keypress – The exceptions in Internet Explorer and Webkit actually make more sense. Only keys that generate characters generate a keypress event. Exceptions are more random in Opera and Firefox.

Should keydown really repeat?

Is there a way we can normalise the event order?

The plan for for Glow 2:

  • Event order is keydown, keypress, keyup
  • keypress is the only event that repeats
  • keypress always fires
  • (missed it)

Problem with fixin keypress: it isn’t always fired. We need to fake a keypress event when needed. Need to decide this. And to do this, we need browser detection. :(

Keycodes on various television remotes aren’t the same. There’s no spec to tell them what the keycodes should be.

Opera doesn’t distinguish number pad number keys from other number keys, so this behaviour is repeated in Glow (lowest common denominator).

Great photo of the messy cupboard in the search to find an American keyboard.

Unfortunate closeup of a keyboard found in the messy cupboard.

keys x keyboards x browsers x operating systems = Archibald’s constant of misery

The good news: Erm, no good news, but there will be soon. DOM Level 3 Events covers keyboard events in detail (though the spec is volatile).

IE uses key instead of keyIdentifier and location instead of keyLocation.

Wrapping up:

  • Keyboard events are awful
  • They’re going to get less awful