molly.com

Bob Dylan Meets HTML5

Molly — Tue, 05 Jan 2010 21:22:30 +0000

Inspired by Shelley Powers who quipped “HTML5, it is a changing” on Twitter, I in turn said I was gonna write a Dylanesque song about HTML5. Of course, between that time and the time I got to the next available WiFi point, Jeff Allen wrote the song.

We offer it up here for your enjoyment, and encourage you to post your own creative take on HTML5, which of course, is a spec that is in fact changing.

Update! Friend and colleague Daniel Davis (@ourmaninjapan), Web evangelist and ukelele player extraordinaire, provides this rendition so we can all sing along!

HTML5 – It is a Changin’

by Jeffrey G. Allen

Come gather ’round coders
wherever you roam
And admit that internet
Around you has grown
And accept that soon
A new spec will stand on its own.
If your skills to you
Are worth savin’
Then you better starting learnin’
Or you’ll sink like a stone
For HTML5 it is a-changin’.

Come designers and developers
who prophesize with your blog
And keep your mind wide
this chance won’t come again
And don’t speak to soon
For the spec is still in spin
And there’s no telling who
will be recodin’.
For the early adopter now
Will be later to win
For HTML5 it is a-changin’.

Come senators, congressmen
Please heed the call
Don’t sit on your thumbs
In the gathering hall
for he that gets lost
will be he who has stalled
There’s a spec in the works
And it’s changin’.
It’ll soon trim down your code
And add meanin’
For HTML 5 it is a-changin’.

Come mothers and fathers
Throughout the land
Learn to use content filters
And help to fight spam
Your sons and your daughters
Have gone mobile
And you’re old ways of surfing
is rapidly changin’.
Please get off the new one
If you can’t understand
For HTML 5 it is a changin’.

The spec it is out
It is Working Draft
The current one now
will later be past
As the new one
will venture to last
The spec is
rapidly changin’
And the current one now
will later be last
for HTML5 it is a changin’.

Shine On, Brad

Molly — Tue, 05 Jan 2010 07:42:36 +0000

Broke Brad with Bread, originally uploaded by mollyeh11.

After six years of hosting the Breaking Bread with Brad parties at SxSW, I was joking with him in 2006 and asked if anyone had ever literally broken bread with him. It turned out NO one ever properly broke bread with Brad! So of course I seized the moment and had the great pleasure of doing literally that.

Who knew it would be one of the memories I will now hold very close for the rest of my life, for Brad Graham has passed on, far too young, at age 41.

Rest in peace, dear friend. I will remember you always. You were one of the most magnanimous people I’ve ever known – great in mind and heart.

Czech Interview Published as I Journey to Prague

Molly — Tue, 13 Oct 2009 03:33:49 +0000

I’ve just finished a visit with the wonderful Paris-Web group. What a fun time! I’ll be making my way from Paris to Prague, and wanted to share an interview done back in March and just now published on a Czech magazine site.

The interview provides some insights into education and evangelism as a career, as well as describing my journey from wee Web person in 1993 to my current work as a Web Evangelist for Opera Software.

There is a Czech version and an English version too. I hope you enjoy the interview, and if you’ll be in Prague for Web Expo, please come see me and say hello!

Why Bottom Posting Sucks

Molly — Tue, 29 Sep 2009 17:24:17 +0000

Throughout the years, posting styles in email lists and in forums have been a point of contention. Essentially, there are three types of posting styles.

Inline posting. In this style, the responder answers queries or provides insight throughout the document.
Top posting. The responder writes his thoughts at the top of the previous discussion. This particular method has long been frowned upon because the dialog is out of order.
Bottom posting. The responder writes at the very bottom of the discussion, leaving the previous dialog intact and creates a sequential order for the discussion.

At first glance, both inline and bottom posting make sense. The logic of each is maintained. In the first case you have essentially an actual dialog. He writes, she responds, the conversation goes back and forth. In bottom-posting, you have all the sequential context of the dialog available.

There is also the issue of what gets clipped out, or doesn’t. But let’s save that rant for another day. The issues with these styles have only been based on preference within the group or organization, and it’s daunting to think how much people argue about something so seemingly simple.

Because I personally find inline posting to make sense, as I am a verbal person and think in dialog anyway, let’s set that one aside. It’s fairly neutral overall. Most people won’t freak out if you use inline posting. Although I’m sure there are some of you out there!

Top-posting puts the sequence out of order. So why am I advocating it over bottom-posting? There are several reasons, all of which have their own logic. First, we’re becoming extremely used to backward sequencing. Blogs do this automatically. Twitter does too. Think of any social network and the way your posts are ordered. They are essentially top-posted.

Not only are we becoming accustomed to this behavior and perhaps prefer it in certain situations, but a second point also reigns true. We have many tools now so as to retrieve and save threads. IMAP, for one. Gmail provides archives. All current, popular mail clients allow some sort of filtering and thread views.

A third and important reason bottom-posting needs to die a fast death is the increasing access of email on small devices. It becomes absolutely senseless to have an entire novel sent when the message is simply “yup, I’m on the task” or what have you.

The final reason that bottom-posting sucks is that long emails that require a user to scroll through what is sometimes pages and pages of information is physically damaging and actually very difficult to do for those of us whose wrists and fingers tire easily. If someone with mobility impairments has to scroll through so much data just to get to “yup, I’m on the task” it just becomes an insult to that user, who suffers through the inconvenience to get to the message.

Two words: Not Accessible.

If there is any reason for everyone to abandon bottom-posting at this point in our evolution, I have to say it’s that alone. And if you’re young and strong and able-bodied and think I’m nuts, that’s okay. I’m probably older than your mother and sticking around to hear you grow up and say “Mom, you were right” will be my goal!

Bottom posting sucks. Let’s abolish it now and get on with the day.

The Painter, The Shoemaker

Molly — Tue, 29 Sep 2009 07:28:31 +0000

I am a painter, but my house has no paint.
I am a shoemaker, but I cannot make shoes.
I am a web designer, but I cannot design.
I am a software engineer, but my start-ups often stop.

A painter has paint
A shoemaker makes shoes
I am painting my shoes
and shoe-ing my paint

All for the sake

of loving you.

Welcome Guest Blogger, Attorney Claire Wudowsky

Molly — Mon, 31 Aug 2009 16:35:43 +0000

So my blog’s been suffering from needs a refresh, needs my attention, needs content syndrome, and I’ve been feeling really guilty about that. Fortunately, my good friend and IP attorney Claire Wudowsky has offered to step in from time to time with articles related to IP issues and the Web.

An area that clearly needs attention, here’s what Claire has been thinking:

“Hi, I’m Claire Wudowsky, Mols and I have spoken about me guest blogging on her site for a while, but every time I get started, something holds me back and I cannot finish. Maybe I am over thinking this, I do not know.

I am an Intellectual Property attorney and I have a pretty strong background in computers and online issues and technology – as Molly and I have been working online since before Al Gore invented the Internet (around 1989 or 1990). Do you remember GEnie? It was a bulletin board service (yes a BBS) operated by GE. It was a consumer service that piggy backed on their b-2-b service. Molly and I both ran forums on GEnie (we were called “Sysops” and the forums were called “Roundtables”) – in fact, that is where we met.

Molly helped me set up a site where I could blog about legal issues: Wudowsky.com. However, I got spooked after going to a CLE (Continuing Legal Education) program, where they warned us about the legal liability inherent in the blogging culture. It seems legal malpractice insurers worry that blog readers develop personal relationships with the blogger and the readers might not realize that the blogger isn’t speaking directly to each of them. So, when the reader reads a blog, he/she might rely on the legal information within and will not heed the warning that the following is not legal advise and further that the reader and the blogger have not entered into a lawyer/client relationship. This then leads to the reader relying to his/her detriment on a legal blog – which results in him/her feeling indignant and suing the legal blogger.

This caused me to become quite conflicted. I enjoy writing and reading blogs (I have one for a charity program run by a friend and I) and I believe blogging would definitely help me to grow my practice, but every time I tried to write a legal blog post, I worried that someone would sue me for it! I think you can all see how this might lead to some severe writers block.

I have decided, however, that readers of Molly’s blog a) have a relationship with her, not with me and b) are more intelligent and realistic than the average blog reader. So – I am dipping my big toe into this part of the blogosphere and offering up this post as my first guest post for Molly (furthermore, I am pretty sure no one can sue me for this one )

As I said earlier, I am an Intellectual Property attorney. I practice in the areas of trademark, copyright, computer (including open source) and online law. However, I am not a Patent attorney so I cannot really speak to the many current computer patent issues.

My next post here will be an IP law related post. If any of you have an issue you would like me to discuss, post your suggestions here.

And now, back to Mols.”

So there you have it! Got questions? Suggestions, the comment floor is yours!

HTML5 & XHTML5: MIME is The Answer

Molly — Tue, 14 Jul 2009 04:18:15 +0000

Currently, all the HTML5 / XML “serialization” stuff simply boils down to two straight-forward rules:

If HTML5 using HTML syntax is served with MIME type text/html This is HTML serialization.
If HTML5 using XML syntax is served with MIME type application/xhtml+xml then this is XML.

Disclaimer on all things series 5: I might be wrong now. Then again, I might be right in five minutes.

HTML5: Best of the Minute

Molly — Tue, 30 Jun 2009 01:48:32 +0000

Damn, you cannot please all the browsers all the time. Funny, those browser beasts. They do stuff, then they do it again and change it. Or, they do it and you can’t talk about it.

If my Baloney has a first name, it’s HTML5! This is the best I can do at the moment, please and thank you.

Some sort of realistic support charts on a few HTML5 things I think are interesting.

Just remember, I didn’t lie and tell you I was right. Because as I quoted from Cowboy Wisdom in my #atmedia talk recently:

Never trust a man who agrees with you. He’s probably wrong.

Comment at will.

The Real “Why XHTML” Discussion

Molly — Tue, 02 Jun 2009 15:10:42 +0000

The previous post was a document on XHTML2, sent in error. I noticed that Steven’s document didn’t match our conversation, but I made an honest mistake thinking what he sent in error was what he wanted to use to address the concerns.

So, I’ve left the other post up, but please know that this is the real discussion, and has lots more detail and insight than the other document, which is more of an overview of XHTML2 core principles.

Forgive me, and readers, Behold! It’s the real “Why XHTML” overview!

The following information is kindly provided courtesy of Steven Pemberton, CWI, Amsterdam, and W3C.

Why XHTML

Molly Holzschlag asked me if I’d try and clearly and simply explain why XML parsing is advantageous and why XHTML still is relevant. This was my answer.

Firstly, some background. I sometimes give talks on why books are doomed. I think books are doomed for the same reasons that I used to think that the VCR was doomed, or film cameras were doomed. People present at the talks make the mistake of thinking that because I think books are doomed, I want them to be doomed, and get very cross with me. Very cross. But in fact, I love books, have thousands of them … and think they are doomed.

Similarly, people make the mistake of thinking that because I am the voice behind XHTML, that I therefore think that XML is totally perfect and the answer to all the world’s problem, etc.

I don’t think that, but

I was chartered to create XHTML, and so I did
XML is not perfect; in fact I think the designers were too print-oriented and failed to anticipate properly its use for applications. As Tim Bray said “You know, the people who invented XML were a bunch of publishing technology geeks, and we really thought we were doing the smart document format for the future. Little did we know that it was going to be used for syndicated news feeds and purchase orders.”
I have often tried to get some of XML’s worst errors fixed (not always successfully).
I believe that you should row with the oars you have, and not wish that you had some other oars.
XML is there, there are loads of tools for it, it is interoperable, and it really does solve some of the world’s problems.

Parsing

So, parsing. Everyone has grown up with HTML’s lax parsing and got used to it. It is meant to be user friendly. “Grandma’s markup” is what I call it in talks. But there is an underlying problem that is often swept under the carpet: there is a sort of contract between you and the browser; you supply markup, it processes it. Now, if you get the markup wrong, it tries to second-guess what you really meant and fixes it up. But then the contract is not fully honoured.

If the page doesn’t work properly, it is your fault, but you may not know it (especially if you are grandma) and since different browsers fix up in different ways you are forced to try it in every browser to make sure it works properly everywhere. In other words, interoperability gets forced back to being the user’s responsibility. (This is the same for the C programming language by the way, for similar but different reasons.)

Now, if HTML had never had a lax parser, but had always been strict, there wouldn’t be an incorrect (syntax-wise) HTML page in the planet, because everyone uses a ’suck it and see’ approach:

Write your page
Look at it in the browser, if there is a problem, fix it, and look again.
Is it ok? Then I’m done

and thus keeps iterating their page until it (looks) right. If that interation also included getting the syntax right, no one would have complained. No one complains that compilers report syntax errors, but in the web world there is no feedback that it has an error or has been fixed up.

It was tried once with programming languages actually. PL/I had the property of being lax, and many programs did something other than what the programmer intended, and the programmer just didn’t know. Luckily other programming languages haven’t followed its example.

For programming languages laxness is a disaster, for HTML pages it is an inconvenience, though with Ajax, it would be better if your really knew that the DOM was what you thought it was.

So the designers said for XML “Let us not make that mistake a second time” and if everyone had stuck to the agreement, it would have worked out fine. But in the web world, as soon as one player doesn’t honour the agreement, you get an arms race, and everyone starts being lax again. So the chance was lost.

But, still, being told that your page is wrong, even if the processor goes on to fix it up for you, is better than not knowing. And I believe that draconian error handling doesn’t have to be as draconian as some people would like us to think it is. I would like to know, without having to go to the extra lengths that I have to nowadays.

So I am a moderate supporter of strict parsing, just as I am with programming languages. I want the browsers to tell me when my pages are wrong, and to fix up other people’s wrong pages, which I have no control over, so I can still see them.

There is one other thing on parsing. The world isn’t only browsers. XML parsing is really easy. It is rather trivial to write an XML parser. HTML parsing is less easy because of all the junk HTML out there that you have to deal with, so that if you are going to write a tool to do something with HTML,
you have to go to a lot of work to get it right (as I saw from a research project I watched some people struggling with).

Let me tell a story. I was once editor-in-chief of a periodical, and we accepted articles in just about any format, because we had filters that transformed the input into the publishing package we used. One of the formats we accepted was HTML, and the filter of course fixed up wrong input as it had to. Once we had published the paper version of the periodical, we would then transform the articles from the publishing package into a website. One of the authors complained that the links in his article on the website weren’t working, and asked me to fix them. The problem turned out that his HTML was incorrect, the input filters were fixing it up, but in a slightly different way to how his browser had been doing it. And I had to put work in to deal with this problem.

Another example was in a publishing pipeline where one of the programs in the pipeline was producing HTML that was being fixed up but in a way that broke the pipeline later on. Our only option was to break open the pipeline, feed the output into a file, edit the file by hand, and feed it into the second part of the pipeline.

Usability is where you try to make people’s lives better by easing their task: make the task quicker, error-free, and enjoyable. By this definition, the HTML attempt to be more usable completely failed me in this case.

XHTML

The relevance of XHTML also starts with the statement that not everything is a browser. Because a lot of the producers of XHTML do it because they have a long XML-based tool pipeline, that spits out XHTML at the end, because it is an XML pipeline. Their databases talk XML, their production line produces and validates XML and at the end, out comes XML, in the form of XHTML. They just want to browsers to render their XHTML, since that is what they produce. That is why I believe it is perfectly acceptable to send XHTML to a browser using the media type text/html. All I want is to render the document, and with care there is nothing in XHTML that breaks the HTML processing model.

But there is more. The design of XML is to allow distributed markup design. Each bit of the markup story can be designed by domain experts in that area: graphics experts, maths experts, multi-media experts, forms experts and so on, and there is an architecture that allows these parts to be plugged together.

SVG, MathML, SMIL, XForms etc are the results of that distributed design, and if anyone else has a niche that they need a markup language for, they are free to do it. It is a truly open process, and there are simple, open, well-defined ways that they can integrate their markup in the existing markups.(One of the problems with the current HTML5 process is that it is being designed as a monolithic lump, by people who are not experts in the areas they need to be experts in.)

So anyway, the reason behind the need for XHTML is that the XML architecture needs the hypertext bit to plug in. It was a misunderstanding by many that XHTML 1.* offered next to no new functionality. The new functionality was SVG, SMIL, MathML and so on.

And my poster child for that architecture was Joost (alas no longer available) which combined whole bunches of those technologies to make an extremely functional IP TV player and you just didn’t realise it was actually running in a browser (Mozilla in that case).

Anyway, out on the intranets, there are loads of companies using that architecture to do their work and having then to do extra work to push the results out to the world’s browsers by making the results monolithic again.

What I anticipate is that we will see the emergence of XML javascrip libraries that will allow you to push your XML documents to the browsers, which are then just used as shells supplying javascript processors and renderers, which will process the XML, and make it visible. HTML will become the assembly language of the web. HTML is just not addressing the use cases of the real world any more. We need higher-levels of markup.

So in brief, XHTML is needed because 1) XML pipelines produce it; 2) there really are people taking advantage of the XML architecture.

W3C’s Steven Pemberton on XHTML2

Molly — Tue, 02 Jun 2009 13:28:49 +0000

Please note that the XHTML2 document was sent in error. The correct document has been forwarded along and Steven’s response to my query is now published as The Real “Why XHTML” Discussion.

With all the fuss about HTML5 at Google I/O last week, the question of “what about XHTML2?” keeps coming up in conversation. In an effort to better understand the answer to that question, I asked Steven Pemberton, W3c Chair of HTML and Forms Working Groups, who graciously took the time to chat with me about it and who then provided this overview to answer the question for the Web designer and developer public.

The following information is kindly provided courtesy of Steven Pemberton, CWI, Amsterdam, and W3C.

Why XHTML2?

Based on the experience we have with HTML, XHTML 2 is an attempt to fix many of the extant problems.

The areas that are being addressed include:

Make it as generic XML as possible

Advantages:

All the ones that you can imagine, because XML is a Good Thing (tools,
interoperability, etc).
If XHTML 2 gets accepted it will draw the web community further into
the XML world.
Much of XHTML 2 works on most existing browsers already (as an example
see http://w3future.com/weblog/gems/xhtml2.xml).

Less presentation, more structure

Make documents more semantically meaningful; make CSS responsible for the presentation, not HTML.

Author advantages:

Easier to write your documents
Easier to change your documents
Easy to change the look of your documents
Access to professional designs
CSS gives more presentational possibilities than plain HTML
Supports single-authoring: write your document once, supply different
stylesheets for different devices or purposes
Your documents are smaller
Visible on more devices
Visible to more people

Webmaster advantages:

Separation of concerns: authors write the text, graphic designers
design the look
Simpler HTML, less training
Cheaper to produce, easier to manage
Easy to change house style, without changing your documents
More control over the look of your site
Reach more people
Search engines find your stuff easier
Visible on more devices

Reader (Surfer) advantages:

Faster download (one of the top 4 reasons for liking a site)
Easier to find information
You can actually read the information if you are sight-impaired
Information more accessible
You can use more devices

More accessibility

The design should be as inclusive as possible. This includes finding a replacement for the unsuccessful longdesc and making forms more accessible. Device independence and increased structure help here too.

Better internationalization

It is a World Wide Web.

More device independence

New devices becoming available, such as telephones, PDAs, tablets, printers, televisions and so on mean that it is imperative to have a design that allows you to author once and render in different ways on different devices, rather than authoring new versions of the document for each type of device, or limiting your design to a single type of device. This includes creating a more flexible event handling system to allow for new sorts of events that new devices might generate.

More usability

Try to make the language easy to write, and make the resulting documents easy to use. According to research, usability is the second most important property of a website (after good content), so it is important that the technology supports this. This includes:

observing how people currently write HTML documents, and designing content-models around these needs
finding a better approach to frames than the current one. Usability experts advise authors not to use frames (http://www.useit.com/alertbox/9612.html); yet frames clearly have a useful functionality. Problems of frames include:
- The [back] button works unintuitively in many cases.
- You cannot bookmark a collection of documents in a frameset.
- If you do a [reload], the result may be different to what you had.
- [page up] and [page down] are often hard to do.
- You can get trapped in a frameset.
- Search engines find HTML pages, not Framed pages, so search results usually give you pages without the navigation context that they were intended to be in.
- Since you can’t content negotiatiate,