Authoring HTML 5 - A Call to Web Professionals
Author(s) and publish date
- By:
-
-
Karl Dubost
-
- Published:
Robert recently published his thoughts on HTML 5. In his post, he gives a reference to a post by Roger giving another look at HTML 5. They are both addressing two issues of the work done on HTML:
- Attitude
- HTML 5 and Authoring
Attitude
I'm the current staff contact for the HTML WG as defined by the charter and when something is wrong in the way the Working Group operates, I feel personally concerned. On this matter, arrogance and disdain are no way to work. Developing agreement around a technology is first a social process and it is why it takes so much time. Online communications make it sometimes difficult to have a sensible behavior. Each time I feel someone overstepped, I invite this person to speak with more considerations. Humor, Jokes, Blunt statements are very difficult in an online cross-cultural context. So to everyone in the community, I apologize if it happens sometimes, but I encourage you to continue to work with the Working Group.
Robert and Roger have something in common, they are Web professionals. It means people who are at the end of the business food chain. Those who are making a living of creating Web sites, of maintaining code, of dealing with broken CMS or browsers. When someone blew it up higher in the food chain, they have to handle it, because they have a customer who pays them money. We need you.
HTML 5 and Authoring
There is a real need for Web Designers and Web Developers working in Web agencies, making an actual business of the Web to participate to the work of HTML 5. You need to speak up. There are more effective ways of speaking up with this very open group, diverse in terms of competences and focus. I will come back to it later.
HTML 4 was really oriented toward the authors and was at this time almost the only document of reference for authoring HTML. Books had been written, but when you wanted the final answer on a question. You had two choices: validator and the HTML 4.01 specification. Time have changed. Around 95% of the Web is invalid, but it is not broken. We still have to read it, we still can read it, most of the time.
Oh yes… it is far to be perfect, but everywhere I look around me, I don't see perfection, I see things working with more or less flexibility. Sometimes your subway ticket will fail, but most of the time it works. Why? Because in our daily life, there are ways to deal with broken behaviors, broken materials, broken processes. It's a feature.
The HTML 5 specification, still in development, contains a broader audience than HTML 4 one, or more exactly, many audiences. It makes the document difficult to read for some people. We like light bulb jokes. A light bulb can be seen as a way to give you light, as a piece of physics, as a way to make money, as an object of design. HTML 5 tries to answer many issues at once.
- Parsing the Web
- Defining the semantics of HTML
- Handling the user interaction
- Making Web applications possible
Yes. It is strange to see a font element in the document, but still there are millions of documents out there using it. You still have to know how to handle it when you are a browser developer. This doesn't match the author perspective, specifically those like Roger and Robert whom business is based more on producing (authoring) HTML more than consuming HTML (reading/browsers).
In their business, the code has to be simple, clean, not having too many ways of writing the same thing. They want to be able to share documents without to be like a browser, handling many different cases. Humans are good at understanding errors but they not very effective at making repetitive stuff all the time like browsers. It is time consuming to have many ways to writing things (with or without quotes, end tags or not). Only one way of writing is beneficial for the authors in a business context.
An indecent proposal
What I would like from Roger, Robert and others, maybe in a small group gathering the Web professionals.
- Review the HTML 5 Specification, editors draft, specifically the part 3. Semantics and structure of HTML elements and the part 8.1. Writing HTML documents.
- Clearly define what is missing part by part
- Suggest what is missing for understanding
- Suggest authoring best practices on public-evangelist@w3.org
- Define a correct way of writing html selecting correct elements, attributes and syntax rules
It would be a positive step in defining how we should author our pages. At the same time, we are currently defining how we should read old pages.
Your proposal isn't indecent at all, but instead really the correct path to take from here. I wrote my post for a couple of reasons:
I would love to do everything that you suggest, but I just don't have the time and opportunity to do that. And trust me, I know, it's very weak to criticize something and then not constructively taking part in making it better.
Therefore, I tried humbly to express in my post that I haven't read every line of the draft thoroughly, and instead just give a couple of suggestions to the team, from the place I stand.
I definitely understand that another important perspective is the web browser vendor one, and it is indeed a delicate balance to implement what should be there, and at the same time cover up for lots of documents already existing on the web.
Given time, I will do my best to contribute through the channels above.
I think we need some WYSIWYG program editors, we have Daniel Glazman, but NVU hasn't the same commercial force than Abode... A big problem is the code made by these programs, I'm sure they can produce something really better, with a good configuration. A lot of programs will be used by people, not especially web developers.
@Robert : Your post is good, I think we (web developers) need to ask our community about HTML5, not especially invite them to join the WG. It takes a lot of time and sometimes it is too technical. But using our blogs we can touch a lot of web developers and have good feedbacks.
First of all, let me say that the new spec is impressive as it stands. It looks like a lot of thought has been put into the issues of the current spec. Particularly that of HTML being an interface templating language for web based applications.
That being said, Here are a few things I think should be considered/reconsidered:
The irrelevant attribute. It is not clearly defined just how the element is rendered. Consider the common use of style.visibility = 'hidden', and style.display = 'none'. Both achieve a similar goal but in a different way. The rendering is different. In which way should a browser render irrelevant? And in that case, should there be two attributes for this? Say, `irrelevant` and `cloaked` (or something of the like) representing the two methods.
IFrames. A common issue I run across is a need to display the contents of another domain in an iframe. An issue with this is if the size of the src content is variable, there is no way to resize the iframe dynamically if the author does not wish to have scroll bars present, without the use of ECMAscript. Cross domain policies make this very difficult to achieve (if not impossible) When a domain of a different origin is used as the src.
I propose the addition of an `autoresize` attribute that, when set to true, should automatically resize the iframe to fit the content.
Additionally, there should be a way to specify a set of enumeration values that allows the autoresize to happen vertically, horizontally, or both.
Karl,
The first part about of your posting, regarding attitude, is appropriate if under-developed.
For the past few weeks (June), I've pretty much given up on the process that is/was the public discussion list. The dismissive attitude offered by some of the authors surrounding issues such as using @class for semantic signaling (remember the class=copyright posts?), and the fiasco that is/was the table headers/id "debate" left me so angered and incensed that I felt that any contributions being offered (not only by myself, but other people whom I've known and respected for some time in the web accessibility field) were automatically dismissed out of hand; frankly, my personal anger at the "attitude" I (and they) were receiving was starting to cloud my responses - rather than remaining calm and cohesive I started to vent: clearly an unproductive position to be in.
And so, I simply wish to add that "attitude" is a two way street. I hope to be able to return to the discussion with a calmer attitude, and it is my hope that the authors have also had an opportunity to adjust their attitude, so that together we can all move forward - listening and respecting different perspectives. Like many others in the web accessibility field, I need and want the next generation authoring language to be better, more useful, and ultimately more valuable - not just for the majority, but for all (including the minority).
JF
John Foliot
My very first thought at the formation of the group was "why?". I mean, HTML 4.0x is a mess as the OP has already stated. Can it be fixed? Good question. To date, no one follows the spec well. Then came XHTML onto the scene off the heels of XML v1.0. XHTML is leaps and bounds greater than HTML clearly separating content (and structure) from presentation while having facilities available to create presentation for the content (or structure) via XSLT or CSS. So my original question stands: why do we need HTML5? Why not just have browser developers implement XML as the native browser language. I thought that was what XHTML was about--transitioning HTML to an XML-based syntax so that eventually, the Web would be XML based in entirety. XML is much more flexible than HTML as well as much more programmable. CSS (or XSLT) can be used to describe to a browser how any XML document element should be rendered. HTML has far outlived its usefulness and we should focus our efforts on not another new [HTML] standard, but on paving the way for the true Web 2.0 that is XML-based. To me, HTML5 is a lot of wasted effort and time that should be refocused to transitioning the web to XML. The HTML5 draft says XML is newer and therefore not as mature. Well then why not concentrate on making XML the mature language it needs to be for the web if the authors of the HTML5 draft feel that it is not mature?
@Craig S:
XHTML 1.0 separates content from presentation no more then HTML 4.01 did, its just represented in XML rather than SGML which has little impact other than syntax issues.
HTML5 is going to have an XML serialization anyway.
CSS might allow you to describe how an XML document should be rendered, but the semantics expressed in known languages are useful, and not all documents are exclusively rendered on a screen (screen readers spring to mind).
XML is a starting point (for building languages with useful semantics on) not the destination.
@Craig S:
I agree with your assessment, but at the same time, I think this disagreement is what causes most of the attitude problems above. Fortunately, we are being given multiple standards that, for the most part, are able to co-exist. Let the HTML5 people have their update, and let the others focus on maturing XML. If we have two standards, so be it.
The real push needs to be getting the browser makers to adopt the various standards. I realize that agreeing on one standard would make their lives easier, but considering that we have so few standards for the entire world to use is pretty amazing.
Some would say this approach is short-sighted, but really, we have no idea what will pop up to be the next big thing. If we really want standards, why do we keep developing and learning new languages? If we really wanted a standard, we should just say everything should be written in C and be done with multiple programming languages, as well as agreeing on one version of (X)HTML. Pick your poison and then just be so good at it that everyone copies you. Then we'll have a standard. :)
Removing frames from HTML and recommending the use of iframes instead is a bad idea. While frames are a legal and often used technique to bring a page in a fixed strukture and to allow for defined function to run in a frame (a specific location on the page), iframes are an invitation to criminals and are often used for phishing. A good example using frames is phpMyAdmin which locates function like the menu or the table-data with frames.
It is much more clean to write only on function 'show menue()' and to call it into one frame than to mix the whole content in in a table.
It would be better to not allow to run code on the visitors computer where it can distribute viruses or download other malware.
A website should be composed on the server and the served to the visitors viewer (browser) where it is shown. This would allow for saver browsing and allow to check the transported page content for malware.