Have Your Say about the Future of HTML

By Molly E. Holzschlag | November 7th, 2006 | Filed in HTML/XHTML, Opinion, W3C/Standards Documentation, Web Standards (general)

Skip to comment form

This article has been written on behalf of the Web Hypertext Application Technology Working Group (WHATWG) and has been cross posted on The Web Standards Project, Lachy’s Log, Molly.com and 456 Berea Street.

There’s been a lot of discussion about the W3C’s recent decision to continue the development of HTML around the web lately. Blog posts, and messages that have been sent to mailing lists or posted on forums, revealed many questions and misconceptions about the future of HTML (including HTML 5 and XHTML 2), the WHATWG and the W3C’s new HTML Working Group.

Some people asked for new features; others were wondering if formerly deprecated elements would return; some had comments and criticisms about the decision itself, the WHATWG or W3C process; and a few raised concerns about the WHATWG and W3C ignoring the needs of particular groups. The WHATWG, who are in the process of developing the next version of HTML (called HTML 5), feel that it’s important to not only listen to all of this feedback, but to actively seek it out and respond so that we can develop a language that meets your needs.

There are many ways in which you can participate. The most direct approach is to make your voice heard by subscribing to the mailing list. However, not everyone has the time to participate, or keep up with the high volume of messages sent to that list. Some people feel that the current drafts of HTML 5 (Web Applications and Web Forms) are rather daunting. Others feel that because they can’t afford the substantial W3C membership fees, they wouldn’t be listened to anyway.

If, for any reason, you feel that you either cannot participate, or would be uncomfortable in doing so, that certainly doesn’t mean you shouldn’t be heard. The WHATWG needs to hear from you and wants to know what you think about HTML.

Are there any limitations with HTML that you would like to see fixed?
Do you have any ideas for new features?
Is there anything you can do now in HTML, but would like to see improved?
Do you have any concerns about the development process?
Do you have any feedback about the new features in the current drafts?
Do you have any questions about HTML 5?

Any questions, comments, criticisms, complaints or feature requests are welcome. Now is the time to speak up. No comment is too dumb; no question is too hard or too simple; no criticism is too harsh. If you have anything at all to say, we are listening.

Please leave a comment or post a link to an article that you have written. You will be heard and we will try to respond.

Update: This post has been translated into the following languages. This list will be updated as translations become available. Feel free to comment in the language you’re most comfortable with.

Your Replies

#1 On November 7th, 2006 2:19 pm have your say about the future of HTML · igoo replied:

[...] This article has been written on behalf of the Web Hypertext Application Technology Working Group (WHATWG) and has been cross posted on The Web Standards Project, Lachy’s Log, Molly.com, 456 Berea Street. and igoo [...]

#2 On November 7th, 2006 2:51 pm Henrique Costa Pereira replied:

My article written days ago: http://www.revolucao.etc.br/archives/reinventando-o-html-o-futuro-da-linguagem-de-hypertexto/

#3 On November 7th, 2006 4:57 pm zeropointnine replied:

[...] (The original request was cross posted on The Web Standards Project, Lachy’s Log, Molly.com and 456 Berea Street.) [...]

#4 On November 8th, 2006 3:21 am Slashnet replied:

I don’t get it.
HTML 5 and XHTML 2 will be the beginning of two separate languages to make websites?
Why? Because people isn’t adopting XHTML fast enough?
If so, W3C should realize that XHTML doesn’t bring anything new cool feature, that would make the average developer switch. XHTML just brings more rules, and therefor more work.
I know a lot of people what uses HTML4 over XHTML, because “they can do the same things, XHTML is just harder”.

#5 On November 8th, 2006 3:31 am Webkrauts » Beteiligen Sie sich an der Zukunft von HTML replied:

[...] Dieser Artikel wurde im Auftrag der Web Hypertext Application Technology Working Group (WHATWG) geschrieben und ist in gleicher Form beim Web Standards Project, Molly.com, 456 Berea Street und Lachy’s Log veröffentlicht worden.(Anm. d. Übers.: Um möglichst viele Interessierte zu erreichen und dem deutschsprachigen Fachpublikum die Teilnahme zu ermöglichen veröffentlichen wir diesen Text hier in einer deutschen Übersetzung. Wenn Sie Kommentare und Anregungen zur Weiterentwicklung von HTML haben können Sie diese in Englisch bei den oben genannten Sites machen. Wenn sie lieber in Deutsch kommentieren können Sie dies gerne hier tun – wir kümmern uns um die Übersetzung und Weiterleitung, versprochen.) [...]

#6 On November 8th, 2006 4:16 am Tomas Caspers replied:

Manual Trackback for my take: »Gehen Sie zurück auf Los«

#7 On November 8th, 2006 5:42 am Blog Posible » Blog Archive » W3C desarrollará de forma paralela HTML: HTML 4.x, XHTML 2… replied:

[...] Me temo que no sabré explicar adecuadamente las palabras de Tim Berners-Lee en su artículo Reinventing HTML. Igualmente me produce bastante confusión el artículo publicado conjuntamente por The Web Standards Project, Lachy’s Log, Molly.com y 456 Berea Street, titulado Have your say about the future of HTML en favor de The Web Hypertext Application Technology Working Group. En dos o tres artículos, intentaré desarrollar estos asuntos (o al menos lo intentaré). Porque la sensación que me queda tras leer los dos artículos es la de confusión, y no saber muy bien hacia donde se dirige la Web: un medio que utilizamos millones de personas y que esperemos disfruten sin censura muchos más (señal de que hay más libertad en el mundo y menos desigualdades sociales). [...]

#8 On November 8th, 2006 8:51 am Matthias replied:

In the past, it was simple to make a site. You could make a site without having to surf to a website to copy some text. E.g. when you don’t care about standards, you just type and you start making a site. If you are a little more concerned about standards, you have to go to w3c’s site to copy the doctype declaration (or you need an editor who can do this for you).
I think it’s very important to have standards, because I would like my site to look the same in every browser. But why do we need (such a long) doctype, xmlns declaration …
I just want to open an editor and start writing…

#9 On November 8th, 2006 10:35 am figgy replied:

Why in the heck are we thinking about making a new version of HTML when we are already in the first version of XHTML?!

Having two different languages for marking up websites is just plain stupid.

I say we continue to move forward towards a semantic web with better use of XHTML and just forget that IE cannot interpret it.

IE is in its demise anyway, especially now that Adobe has donated Tamarin to Mozilla.

#10 On November 8th, 2006 11:01 am Standards.za.net » » The Future of HTML replied:

[...] Have Your Say about the Future of HTML – The Web Standards Project [...]

#11 On November 8th, 2006 12:31 pm molly.com » Have Your Say about the Future of HTML replied:

#12 On November 8th, 2006 1:26 pm Essen replied:

I don’t think HTML5 is a good idea. Because when we’ll have HTML5, why would people use XHTML? All the improvements should be done in XHTML2. XHTML1 was made for a smoother transition to XML, XHTML2 adds new features. People haven’t switched to XHTML yet? Too bad for them, they’ll switch the hard way.

However, the new features presented in Web Applications draft (and testable on Opera) are very promising. I look especially forward Canvas2d/3d, sound, and server-sent events. You could create interactive applications without using Flash, which is a good thing.

But please, no more HTML mess. If people find XHTML too hard, they should use an editor which helps them writing valid code. If there isn’t any such editor, it should be written.

That being said, I don’t really know the background of the WHATWG and exactly why there’s another W3C-like group, so my judgment may be somehow mistaken.

One other thing, if I’m not mistaken: an RSS feed that alert about changes done on the drafts would be very useful for people who don’t have that much time. Like posting a diff of what changed between the last version and the new one. With this people would be able to provide feedback as soon as they see something bad (for us or for everyone).

#13 On November 8th, 2006 2:02 pm Jeremy Walker replied:

What I’d really like to see from the next version of HTML is more basic data structures. Tags like:
* UL and LI
* DL, DD, and DT
* TABLE, TR, TD, TH, etc.
* DIV and SPAN
are the bread and butter of every modern standards-based designer, but there have been no real additions to these since HTML 3.

Organized data is what web pages are, and proper HTML is markup that organizes data (and does nothing else). Getting rid of garbage like B and FONT was half the battle; now let’s work on new, useful and semantically-meaningful markup options.

Also, I’d REALLY like to see a more unified/standardized alternative for non-text media. Right now we have IMG, OBJECT, EMBED, and probably a couple more obscure ones I’m not thinking of; what we need is one simple tag for this function.

Finally, I’d really like to see the ability to specify non-rectangular clickable areas. Currently the only way to accomplish this is with Flash, which is proprietary, or image maps, which are inaccessible and (I think) deprecated. This will almost certainly need to be done in conjunction with some sort of new CSS standard, but new HTML options may also be required (depending on how it’s implemented; it might be possible to do it by only adding new styles for A elements).

#14 On November 8th, 2006 2:24 pm Tripix.net » Blog Archive » Iniciativa por el HTML 5: que alquien me lo explique replied:

[...] A los pocos días en un post conjunto de The Web Standards Project, Lachy’s Log, Molly.com y 456 Berea Street piden opinión y ayuda a la comunidad en el proceso de desarrollo de la nueva versión de HTML que ya denominan como “HTML 5″. [...]

#15 On November 8th, 2006 6:47 pm Josh replied:

I like Jeremy Walker’s idea for a single MEDIA element. It will be a great way to make a website developer’s life easier.

I’m also confused about the need for two separate markup languages for the web. People claim that XHTML is hard or too strict. However, it’s more likely that it just doesn’t offer any compelling benefits. If HTML 5 and XHTML 2 are created side by side, including similar new features, we may never see those benefits, and developing for the web will continue to stay difficult because browser makers won’t have any reason to stop allowing bad markup.

I would definitely like to see new elements like headers and footers. If you’re looking for more, look at the way that people structure their websites or blogs. What sort of classes and ids are commonly placed on DIV elements? They say that in progamming languages, common design patterns make up for missing parts of the language. In HTML, common classes make up for missing parts of the markup.

#16 On November 8th, 2006 9:00 pm Dan Schulz replied:

I’m in the trenches every single day, and one thing I’ve noticed is that people often inter-mix HTML and XHTML syntax with their markup. I see it all the time on forums hosted by such respectable sites as SitePoint and WebDeveloper.

In my personal and professional opinion, we should use one or other, not both. If XHTML was to be the wave of the future, why are we still supporting HTML, when the W3C had decided (at the time) to discontinue development of it? I personally found XHTML to be a lot easier to use than HTML because of the rules. If I hadn’t learned (and I do mean learned the language properly) how to code using XHTML, I would probably be flipping burgers at Burger King or living on the street.

Reviving HTML while continuing support for XHTML will only cause confusion among developers and those who are cutting their teeth on computer programming (and Web development) on (X)HTML. Pick one or the other, and force Microsoft to finally include support for XHTML and XML. It’s a crying shame when a non-profit corporation (Mozilla) and a little known company from Norway (Opera), along with companies like Apple Computers can develop browsers that fully support XHTML and Web standards while the goliath of this industry flat out refuses to support the established standards, despite sitting on the W3C.

As for new elements and attributes, I’d like to see better support for the OBJECT element, while not completely removing IMG from XHTML 2.0 (depreciate it yes, but don’t flat out remove it just yet), footer elements to compliment header elements, and I’d also like to see Microsoft support the ABBR element.

And finally, (I know, like the ABBR and OBJECT elements, this doesn’t have anything to do with the specification per se) I’d like to see the browser manufacturers actually start enforcing the rules, rather than being so lax and letting anything go.

#17 On November 8th, 2006 9:25 pm HTML 2.0 at Punctilio replied:

[...] Worum geht es? This article has been written on behalf of the Web Hypertext Application Technology Working Group (WHATWG) and has been cross posted on The Web Standards Project, Lachy’s Log, Molly.com and 456 Berea Street. [...]

#18 On November 9th, 2006 12:20 am SitePoint Blogs » HTML’s Uncertain Future replied:

[...] Disappointingly (for the W3C), the WHAT WG has made the first meaningful move following Berners-Lee’s announcement, posting an invitation for web developers to share their ideas, needs, and questions about the future of HTML. Not wanting to get left out of the process, it seems the group is eager to demonstrate its willingness to involve the developer community at large—something the W3C has consistently failed to do. [...]

#19 On November 9th, 2006 3:40 am Michael Long replied:

One thing I’d like to see is a client-side “include” tag that would make it possible for sites to syndicate HTML snippets, content, lists, and so on, and for other sites to easily “include” them.

There’s no good way to do this currently. If you use an iframe the content isn’t really part of your page and can’t be styled to match your site.

You can use JavaScript, if it’s enabled, to “write” to the page or insert items into the DOM, but both methods are problematical and don’t always work, requires the syndicator to convert his content from simple HTML to JS, and again, the content isn’t really part of the page, visible to search engines and spiders.

#20 On November 9th, 2006 5:35 am Martin Bleck replied:

I am just a student of web design at the mo so probably out of my depth. However, I have an angle that should be worth considering. I have to study Java script (then AJAX), Perl (then CGI), PHP (then MySQL), and ofcourse HTML (then XHTML, then XML, then CSS), on top of all the server admin etc.

None of you have to imagine what this is like but as a student I wish to begin my career with the most current techniques. How is this ever going to be possible if the guys at the top are in such a hurry to tell us all the time to do things one way and then to do them another, meanwhile changing everything. Standards are a mess. CSS hasn’t even sorted itself out yet and now they want to change HTML! Rediculous.

Not only is HTML not broken, even when it is (HTML soup), it still works. It’s actually about the only thing on the internet that does actually work.

Java and Ajax only work if the user allows for it in their browser. CSS only works the same on two browsers (netscape and mozilla) and that’s because they are the same! Even the latest version of IE does it wrong and that’s with them actually trying to do it right.

Please, please please, don’t change the only thing that actually really does work. And to the big guys at the top, stop changing your minds and changing directions. Complete what you set out to do. Even if it isn’t as good as it could be, atleast everyone can work in the same direction. It’s meant to be the web we’re developing, no mass confusion.

If its not broke, don’t fix it. HTML stays.

#21 On November 9th, 2006 5:49 am Martin Bleck replied:

… one point that is being seriously overlooked is that it doesn’t matter a jot what the W3C decide or developers. Its what the users decide as a browser that counts and thats the bottom line. So if they choose IE, then its really IE that decides. If I were them I’d just blow the W3C out and do my own thing. Then folk could just design everything their way and learn one thing and life would be where it was before the W3C stuck its nose in. Simple. Things need to be made easier, not harder.

I also liked what Jeremy Walker said. The only thing I think we need, either in HTML or CSS is a tag.

#22 On November 9th, 2006 5:51 am Martin Bleck replied:

(….cont – some text disapeared)

HTML or CSS is corner a tag.

#23 On November 9th, 2006 6:08 am Richard Lord replied:

1. Please let’s not go back to HTML. XHTML is a significant improvement because it means web pages can be processed using XML tools. However, that doesn’t mean that XHTML2 is going in the right direction, just that having moved to strict XML syntax we should stay there.

2. One vital ingredient is an Object element that works across all browsers. Don’t know how we get there but it’s very much necessary.

3. More semantic markup for common web items – e.g. menu, header, footer, advert… Makes it easier for non-humans to read and understand the page (thinking of screen readers able to jump straight to the content and search bots analysing the page accordingly)

4. Moving designers to semantic markup requires that CSS be easier. I shouldn’t need clever tricks (no matter how common they are, they’re still tricks) to get a good three column liquid layout with header and footer, I should just indicate which column is on which side and the browser should work out the appropriate widths and positioning – just as it would if I (ab)used a table with 100% width. If css for such common web designs were easier then the switch to semantic XHTML would also be easier to achieve.

#24 On November 9th, 2006 10:20 am Mario Bourque replied:

Instead of looking at continuing along HTML and XHTML, I believe we should look at ways of developing a new framework for the eventual convergence of these languages. We’re moving away from traditional tools, and looking for faster and better ways to access information anywhere at any time. This is where I believe Adobe is focusing their efforts with Flash. It won’t matter what the interface is, the data will be the same. Code once, present many. I think XHTML is more complicated, but it also forces us to write better code. I agree with Martin Bleck when he says “It’s what the users decide as a browser that counts and that’s the bottom line.” Over 80% of the market uses IE. That in my opinion defines the standard, not that I agree with it. The market defines the product. I would love to hear other opinions on this matter.

#25 On November 9th, 2006 10:22 am Stinkbug.net » Blog Archive » The Future of HTML replied:

[...] A topic on the future of HTML has sprung up recently. In fact, there is a group that is planning on making a new version of HTML and they’re asking the developer community for their input. It’s not quite clear if this new group WHAT WG (Web Hypertext Application Technology Working Group) is going to be working with the W3C on this. According to the SitePoint article it will be years before we see the effects of these announcements, but it will be interesting to see what does happen. If you are interested in giving your input on the future of HTML you can find that information on the Web Standards Project site. Since they are claiming to be listening, I’m really going to have to think this through and see if there is any requests or improvement ideas that I have. [...]

#26 On November 9th, 2006 10:24 am mariobourque.com - Mario Bourque - Information Architect - Discussions on Information Architecture and User Experience. » Have Your Say about the Future of HTML (Article on Webstandards.org) replied:

[...] Have Your Say about the Future of HTML (Article on Webstandards.org) By Mario Bourque http://www.webstandards.org/2006/11/07/have-your-say-about-the-future-of-html/#comment-11338 [...]

#27 On November 9th, 2006 10:56 am WebStandard Korea » Blog Archive » HTML replied:

[...] This article was translated into Korean, Have Your Say about the Future of HTML by Channy Yun, a member of WaSP ILG. Channy Yun collects feedbacks by korean people and will send them to WHATWG. [...]

#28 On November 9th, 2006 1:15 pm Aaron replied:

I agree with Richard Lord on his third point. Instead of having to bend over backwards, stand on my head, and say supercalifragilisticexpialadotious three times fast backwards just to get a three column layout, why not make it easier by adding some kind of column tag and making css markup to specify widths and lengths and so forth.

#29 On November 9th, 2006 1:18 pm Aaron replied:

Correction, I meant his fourth point.

#30 On November 9th, 2006 2:44 pm Bridgette Seiberlich replied:

I agree with what many of the others have said. It would be nice if the doctypes were easier to remember. CSS needs to be streamlined so creating standard layouts are easier. There should not be an HTML5. Any changes should be a part of XHTML2.0. I think the following tags should be added to the XHTML2.0 specification: content, footer, and universal media.

#31 On November 9th, 2006 5:34 pm CSS3 . info - » Which will come first: CSS3 or HTML5? - Weblog replied:

[...] Anyway, potentially big news is that the WHATWG are asking for developer feedback on HTML5. [...]

#32 On November 9th, 2006 9:53 pm HTML’s Uncertain Future « Roz Web replied:

#33 On November 10th, 2006 12:13 am Craig Sharkie replied:

I’d like an element called “foot” that would reside in the document at the same level as “head” and “body”

It would be the nextSibling of “body” and would hold “head” style elements, most importantly creating a non-”body” area of the page at the close of the document.

This would then act as the logical location of the page to add any external script calls – limiting the impact of the external files on page load times and appearing at a point in the document that ensures any referenced in-code elements are already rendered.

This would thereby have the added benefit of removing the issues over cross browser onload events.

#34 On November 10th, 2006 2:44 am Jungshik Shin replied:

First and foremost, I’d like to see a platform-independent and browser-agnostic (as much as possible) way of web signing and conducting related tasks (private-public key pair generation, signing request, key renewal, key management, etc). This issue has been raised a couple of times in the WHATWG mailing list, but virtually nobody seems to be interested.

However, IMHO, this is really important as more and more financial institutions, governments and electronic commerce sites require web-signing of invidual transactions (in addition to transport level security offered by https).

At the moment, in many European countries,East Asia (Korea, Japan, Hokong, Taiwan, Singapore, etc) and Canada, proprieatary browser-add-ons are used to support web signing and key management. Some use Java signed applets, which may or may NOT be platform-independent while in some places (e.g. Korea), activex is exclusively used leading to the virtual lock-out of non-MS-IE users/non-Windows users from virtually all government services and banking services. Still others (e.g. Spanish government) use crypto.signText [1] for mozilla/firefox and CAPICOM for MS IE, but neither of them is supported by other browsers.

As for the keymanagement, gecko-browsers have keygen and MS IE has xenroll, but again neither of them is a part of any standard. [2] Therefore, different CAs resort to different methods with varying degree of ease of use. (try to get a certificate to use with S/MIME or SSL).

[1] http://docs.sun.com/source/816-6152-10/

[2] http://www.mail-archive.com/[email protected]/msg08063.html

#35 On November 10th, 2006 6:28 am sibrand hoekstra replied:

“adding some kind of column tag and making css markup to specify widths and lengths and so forth.”

divs will do the trick; your suggested column tag would be nothing more than a div that can only have divs next to it. This layout feature should be a css / render fix rather than a semantic one i think.

Instead, i’d go for Richard Lord’s 4th point too.

furthermore, i’d like a css fix to gain control over bullets in lists, and specifically positioning them. position: inside|outside just isn’t enough, this should work like positioning backgrounds [ie. 2px 4px]

#36 On November 10th, 2006 10:22 am Thom Patterson replied:

I agree with Richard Lord, as he has expressed what I am thinking. We should stick with xhtml, and if anything needs to be done, it should focus on semantics. In the meantime, we need to see CSS properly supported across all browsers.

I also think it is about time that a new client-side language comes along to replace JavaScript, but that is outside the scope of this discussion…

#37 On November 10th, 2006 11:41 am Biolizard89 replied:

There is no reason whatsoever why we should go back to HTML. If you don’t like the direction that XHTML2 is going, that’s perfectly fine, but at least make your alternative based on XHTML 1.1 rather than HTML 4.01.

Some people say that XHTML has been rejected by the web developer community. While I don’t believe this (I have used XHTML for all my Web projects for years), if it is true, it is not because XHTML is a bad idea, it is just because XHTML offers few new features over HTML, and all of the few new features are not supported by IE. You want compound XML documents? You’re restricted to developing for non-IE browsers. That’s not a fault of XHTML, it’s a fault of IE. XHTML is not harder than HTML; it’s roughly the same in terms of difficulty. Some people contend that XHTML is actually easier, because the rules are less complicated, and they may be right.

When XHTML starts offering new features that are useful to the majority of developers, and when those features are supported by most major browsers, people will learn XHTML. Attempting to develop HTML5 will only hurt this process, and is a bad idea.

Please, if you don’t like XHTML2, make extensions to XHTML 1.1, not HTML 4.01. Thanks for listening to my rambling.

#38 On November 10th, 2006 7:49 pm Bob replied:

HTML 5? I haven’t RTF Recommendation, but does it have the same code restrictions like lowercase tags, compulsory closing of elements/closing of empty tags? Would it add lots of new functionality or merely deprecate more elements?

I had thought that the reason we have XHTML was to transition from HTML X.x to Pure XHTML and then to XML. Why backtrack? Standard oare good, but not when they evolve faster than the engines that must render them, and surely not when the delelopers that use them have to continually learn new techniques. Perhaps we should hold off on ALL new markup development untill ALL browsers can do what they’re supposed to do. We keep coming up with new specifications, while the browser-makers struggle to implement full support for those specs. Then as soon as we have a somewhat-good implementation, the specs get updated and browsers have to catch up again. It’s like the virus makers and the antivirus groups–patch a hole, someone pokes us a new one. Fix that one, oops, aNOTHer one… ad infinitum …ad nauseam. I’m sorry; was that paragraph redundant? I mean, did I say the same thing twice?

It’s the Tower of Babel I tell you!

I work for a big manufacturing company with a huge, multi-language site. When I joined the team, I was (and still am) rather non-plussed about having to help them maintain non-standard code. Best practices are not really used and when I make suggestions for changing things, they say go ahead. and then I realize that we’re stuck in a quagmire. They redesigned the site last year and did it in a somewhat dirty way. Lot’s of things I’d like to change but I can’t singlehandedly repair the code in thousands of pages that are inconsistently interdependent (lot’s of include files–some shared some unique!) I can’t be sure that if I fix something, it won’t break a bunch of pages that I don’t know are using the code I just “fixed.”

Let’s just get XHTML 2 set up really solid, then get the browsers to standardize. The problem then is just to get all the code on the Web to be clean–a daunting task, but jeez, we have to have a spring cleaning one of these days to clean out oll the unclosed TD tags and add all the closing slashes to our line-breaks and stuff. Sure, pages that were built in 1996 might not be rederable then. But so what. At some point in time, we had to stop powering our cars with steam and switch to liquid hydrocarbon. Now we have to switch to alternative fuels… On the net right now there are horse and buggie sites, steam engine sites, diesel, gas, alcohol and solar powered sites all trying to share the same thoroughfares and interface with one another. We don’t need more coding methods. We neeeeed to have just one. XHTML.

#39 On November 10th, 2006 8:41 pm April Stanley replied:

I have a simple request for HTML. Some sort of TAB function. Either make one tab of a fixed width that can be repeated on a line (exactly the way the old typewriters did) or be able to specify a tab width. Something lilke to move over 10 pixels or to move 1% of the page…etc. If we could specify the tab markers in the css, this would be even cleaner. Either way, the addition of a “tab to this spot” would eliminate the need for some small tables and make general formatting much easier. Thank you. April

#40 On November 11th, 2006 3:00 am Philip Ashlock replied:

We need a more ambiguous and universal attribute for general metadata so that we don’t have to break the purpose of the class, title, and id attributes.

Anything to provide for more articulate and flexible semantic markup is a good thing. The microformats community has shown an incredible ability to develop standards for common forms of information using the existing capabilities of html. However, this has been done at the mercy of exploiting the class and title attributes for something they were not intended for and sometimes for purposes that these attributes really shouldn’t be used for. Many amazing innovations occur at the mercy of breaking the html spec in order to accomplish something that html should really be more open to allowing. The div and span tags are so ambiguously beautiful because they can be used to define elements and information that don’t have their own html tag. I think there should be an attribute which applies to all tags that can be used for many things – whether for miscellaneous metadata that isn’t covered by existing attributes or to effectively rename the meaning of a tag to act like more customizable XML, or even to assist with the processing of a form field, or something not yet imagined, something that evolves faster than a valid html spec.

#41 On November 11th, 2006 5:09 am Nicolas replied:

… and the Top 10 Reasons for HTML 5 are…

…drum roll…

10) We do not have enough partially implemented specs, so far.

9) Someone in the XML group has p**d off Tim BL.

8) Parsing HTML is fun.

7) Parsing XML is too easy.

6) …TBL s3z: ZOMGl33t!!!11!one HTML5 15 t0t411y c001, FTWLOLZ!!1!

5) The HTML group was bored.

4) Tim BL is writing a book and needs publicity.

3) The WASP just wanted to check if we were listening.

2) Someone who was not colorblind sued after being severely wounded to the eyes by the XHTML 2.0 working draft.

1) Widespread standard compliance will magically ensue from producing another version of a spec that was supposed dead, and will instead live in parallel with XHTML.

#42 On November 12th, 2006 8:11 am ppk replied:

I’d like an attribute that you can set on any visible HTML element and that means “the user can focus on this element, and activate it, too.” Sort of like tabindex, but that doesn’t seem to have the activation option.

focusable=”true” ?

#43 On November 12th, 2006 8:16 am A reação da reinvenção do HTML: Vamos fazer um pouco de pressão? » Revolução Etc - Web Standards em uma casca de noz! replied:

[...] Fazer pressão foi o termo mais apropriado que encontrei para um texto recente escrito pelo Roger Johansson, Molly E. Holzschlag, Lachlan Hunt e revisado pelo Ian Hickson e também publicado no Web Standards Project (você que não lê em inglês pode ter acesso a uma tradução aqui) em reação ao texto do Tim Berners-Lee e que eu escrevi algo sobre isto aqui. Em resumo o texto convida todo mundo a dar voz sugerindo novas features ao desenvolvimento do HTML 5 já iniciado pelo < a href=”http://www.whatwg.org/” rel=”external”>WHATWG. Esta é a mais forte apologia já feita pelo Web Standards Project a uma padronização que não tenha surgido de dentro da W3C. [...]

#44 On November 12th, 2006 9:26 am مدونة رضا البرازي » Blog Archive » شارك برأيك حول مستقبل الـ HTML replied:

[...] تمت كتابة هذه المقالة بالنيابة عن “مجموعة عمل تقنية تطبيقات الوب للنصوص التشعبية” (WHATWG) وتم نشرها أيضاً عبر موقع “مشروع المعايير القياسية للويب” ومواقع: لاشيز لوغ, مولي و 456 بيريا ستريت. [...]

#45 On November 12th, 2006 10:03 am Rida Al Barazi » Blog Archive » Have Your Say about the Future of HTML [Arabic Translation] replied:

[...] Few days ago the Web Hypertext Application Technology Working Group (WHATWG) announced an open discussion under the title “Have Your Say about the Future of HTML” as you can tell from the title it is to encourage web developers, designers and coders to participate in the development process of the next version of HTML (HTML 5) by expressing their opinion loudly and discuss it with each other. [...]

#46 On November 12th, 2006 5:43 pm Tino Zijdel replied:

What bothers me is that there still seems to be much misunderstanding about what XHTML(1.x) is and what it isn’t. Even from some comments here it seems that many webdesigners still think that XHTML(1.x) was meant to be the next version of HTML4 instead of just being the XML-serialization of it. I think WHATWG should emphasize that for HTML5 XML-serialization is also considered for those situations that require it.

I think WHATWG is doing a fine job recognizing the need for backwards compatibility and defined error-correction (and from own experience I would like to add that a parser that does error-correction is not much more complex or less performant compared to a parser that does draconic error-handling).

For those that still think that XHTML is the way to go because it ‘works’ I found this to be a good article: http://lachy.id.au/log/2005/12/xhtml-beginners
It boils down to the fact that XHTML ‘works’ today because HTML works (thanks to error-correction – even though not defined for HTML4) and because of the mere fact that browsers (contrary to validators) have not implemented the NET SHORTTAG feature of SGML (and probably never will because of XHTML sent as text/html). I believe that a large majority of pages on the web that claim to be XHTML by the DTD (but not by mime-type, which is almost all of them) will break when they would be sent as XHTML, so in that respect XHTML has failed to be the step-stone up to an XML-based markup language.

So yes, we definitely need to incrementally extend and improve HTML and I’ve always felt that WA1.0 is a good step in the right direction. Ofcourse browser-vendor support is an absolute necessity; besides specifications we need implementations and my main concern at that point is one certain browser-vendor that is still lagging behind with it’s support for current standards and specifications…

#47 On November 12th, 2006 8:16 pm Roy Soliño-Moreno replied:

Does webdevelopment really need HTML 5. Nah, I don’t think so. The XHTML 1.0 Transitional option is quite enough for all the “old” sites. It’s better to improve the XHTML 1.0 standard along with CSS to make it easier to create headers columns, footers and to cover/support all the interactive functions the modern use of internet requires. Regarding the browser issue it’s the webdeveloper them selves that kept e.g. IE6 alive with all kind of tricks and fixes. I wonder what would happend if webdevelopers let their customers see how funny and/or ugly even the best written site looks in IE6 and also IE7! No, it seems that the more and accurate the browser makers implement XHTML and CSS into their browsers the more users they’ll get. Opera vs IE6 shows just that and IE7 ain’t going to change the headlong flight to other, better browsers. I finaly like to urge the W3C to turn back to their original concept and work which was to provide webdevelopers with capable tools for the easy creation of both accessible and graphicly beautiful sites.

#48 On November 13th, 2006 10:58 am Blog Posible » Blog Archive » Qué dirías acerca del Futuro de HTML replied:

[...] Este artículo es una traducción de Have Your Say about the Future of HTML escrito por Molly E. Holzschlag. [...]

#49 On November 13th, 2006 6:29 pm Standardy sieciowe... replied:

[...] Plany to niewątpliwie ambitne – tyle tylko, czy aby na pewno kierunek prac nakreślony przez Tima Berners-Lee jest właściwy? Niemała grupa specjalistów przedstawiła nieco odmienne podejście. Znane poniekąd serwisy, jak np. Web Standards Project, Lachy’s Log, Molly.com , a także 456 Berea Street włączyły się w akcję zbierania komentarzy w związku z pracami nad HTML5. Chodzi tu o wciągniecie do dyskusji nad rozwojem Sieci większej społeczności internetowej, która na co dzień nie uczestniczy w pracach W3C, bądź też WHATWG. [...]

#50 On November 13th, 2006 9:43 pm The WHATWG Blog » Blog Archive » Welcome replied:

[...] This follows the success of the recent campaign to gather feedback from the wider community, via the announcements that were cross posted on on The Web Standards Project, Lachy’s Log, Molly.com and 456 Berea Street. Work is currently underway to develop an FAQ based on that feedback. [...]

#51 On November 14th, 2006 2:16 am Dean replied:

HTML 5? You must be mad!!!
Stick with XHTML, keep moving forward.

#52 On November 14th, 2006 2:01 pm boen_robot replied:

First, let me sum up all the comments I agree with:

1. No HTML5. XHTML2 is the way of the future.
Instead of updating old specifications, browser vendors (Microsoft mainly) should upgrade their products. And people not wanting to switch to XHTML? They will once IE supports it. How will backdraw compatability be done? Answer: What are server side scripting languages and server configurations for? Many sites use them to generate the XHTML anyway, so why not use that same language to also send the content with a proper MIME type? Some of you will say that they don’t “want” to maintain a single page across two MIME types. This is however easy if you just follow the compatability guidelines.

2. Add a “foot” element to XHTML.
The markup in it would execute after the page “body” has been rendered. There are many scripts today that use HTML’s “error handling behaviour” for placing scripts after the closing “html” tag just so they can be… transparent to the user. This element’s functioality may not be limited only by scripts though. Who knows… I mean, I can’t think of another use case right now, but there might be.

3. Make DTDs easier to remember.
The DTDs look horrible and unmemorable. That’s the unbareable truth. It’s a good thing there are editors to generate then automatically. But I think that instead of changing DTDs, standarts should use a tool they already posses: XML Schema. So,
Make future specifications (including XHTML 2) use XML Schema to show the valid syntax of the language. In order to reference a schema, all one needs is the Schema namespace + the schemaLocation attribute (taking URI as a value), which is far easier to remember, then a public identifier and yet does the same job.

That’s all. Not too much you say? The reason is that not much of the rest said is new. Let’s take the other pointers:

1. A single, standart universal multimedia insertion element.
There’s already such a standart element: “object”. It’s not the fault of the WG that Mozilla and Opera haven’t implemented it as much as Microsoft has.

2. An “include” element for client side inclusion of content.
There’s already a specification for that: XInclude. Again, it’s a problem of the browser vendors that they don’t support it. And they DEFINETLY should.

3. Better list bullets manipulation.
If one really need that much power, they can always turn the list item to a block and apply a background image on it, positioned as desired. Scince user agent bullets may vary in sizes and shapes, that’s probably the best approach anyway.

4. Less usage of browser hacks (no matter the language)
It’s the fault of the author to use them and also the fault of the browser vendor for a crappy implementation, not the specification, scince the specification DOES define a proper way. A recent draft at W3C, the DISelect specification is supposed to be the thing to solve the problem with different user-agents using the same content. It is supposed to provide the client with a choise as to what (not) to use, much like IEs conditional comments. At least, that’s what I understood it’s for.

And some things I somewhat agree on, but can’t really understand their point completely:

1. A universal attribute for “focusable and activeable” elements.
Shouldn’t the focusability and activateability be defined by the specification itself? I mean, how can a non-form-or-link element for example be focusable? Activateable, yes, but by script, which I think the XHTML specification should not care about (don’t get me wrong).

2. a platform-independent and browser-agnostic (as much as possible) way of web signing
Isn’t that the work of the network protocol (HTTP or whatever) itself? I mean, it doesn’t seem as a feature a markup language should include.

3. Resizable TAB
Sounds good, but there’s only one problem. Both HTML and XHTML(as far as I’m aware) kill space to up a single space when displayed on screen, unless there’s a “white-space: pre;” or if we’re talking about the “pre” element. It would be somehow weird to add a CSS property applicable only in the presenve of another property, yes apply it as a new module…. hm… “white-space-tab” module/property anyone?

——————–
Another point I would like to make is the wrong assumption that you need XML once you know XHTML and that you need it before CSS even. That is simply not true. XML is a set of rules for defining languages (among which is XHTML) and it doesn’t have to be used as a data storage. If you have valid XHTML documents, you have XML documents already and because of that, you can use XML tools over them, without the need for XML “knowledge”. “Knowledge” in this case is a strong word, because the concept of XML is harder to grasp then the syntax rules, which are almost identical to XHTML’s. What one needs more is XPath and XSLT knowledge, but that’s another thing.
———————
Here’s a new suggestion from me: Deprecate the ability to nest tables. That’s the only way to kill table based layouts. Current HTML4 and XHTML tables provide enough abilities for “real” tables to be as complicated as one could get. I would like to see a single case with an effect that can’t otherwise be done with… say “colspan” or “rowspan”.

#53 On November 15th, 2006 4:13 am Juan R. replied:

When Microsoft based its technology on HTML (+ VBscript + ASP), other as Mozilla claimed: no! future is XML and XHTML is a transition!

During many years Mozilla tried to do a good XML browser but failed, even XHTML support lacks still fundamental stuff as incremental rendering (available on MSIE).

In fact, Mozilla developers recommend you do not use XHTML (instead HTML) when you do not need MathML or other XML stuff because in that case XHTML is poor than HTML in Mozilla.

Now, after many years, Microsoft is ready to jump to a XML web, and next year they will present XAML (based on XML).

Whereas i am not a microsoft fan, i recognize that XAML is very superior technology over Mozilla XUL. Even Microsoft OMML is superior to W3C MathML in a number of ways (in others is poor).

Therefore it is not so strange that now Mozilla and friends want return to HTML. Guy simply they cannot compite!

#54 On November 15th, 2006 2:34 pm Robin Massart replied:

Nicolas’s (reply #41) point 1 says it all.

Although the real problem is CSS adoption rather than HTML. I see CSS 2.1 is still not a recommendation. Shouldn’t that get sorted out first???

#55 On November 15th, 2006 5:16 pm Tino Zijdel replied:

Robin Massart: CSS2(.0) is a recommendation. CSS2.1 is just a revision on that and it is therefor recommended to follow 2.1.
Besides, for a WD to become a recommendation actual fully compliant implementations are required. That means that browservendors are encouraged to implement such WD’s that are in the final stages.

#56 On November 16th, 2006 1:56 am Robin Massart replied:

Tino: Thanks for the clarification.

I was aware that CSS 2.1 was a revision. The thing is there is no obvious link to the CSS2 spec on the W3C site, so I imagine the idea is to implement CSS2.1. But since it’s not a recommendation, how can it be fully implemented?

But this just highlights the problem even further. CSS2 has been around since May 1998. That’s almost 10 years ago. Is IE7 fully compliant with this? I don’t think so, although I hope to be corrected.

“Besides, for a WD to become a recommendation actual fully compliant implementations are required. That means that browservendors are encouraged to implement such WD’s that are in the final stages.”

Is this true? It sounds very much like a chicken and egg situation to me…

#57 On November 16th, 2006 8:35 am Lachlan Hunt replied:

Robin, it’s not a chicken and egg situation at all. The current process requires at least 2 interoperable implementations of every feature in the spec before it can become a Recommendation. The aim is to ensure that the spec can actually be interoperably implemented before it’s finalised. Any feature that proves impossible to implement needs to be either revised so it can be implemented or removed from the spec.

Implementers actually need to try and implement the spec while it’s a draft, and then provide feedback to the working group who will then update the draft based on that feedback. It’s an iterative process that repeats again and again until the implementations successfully implement the spec, and the spec accurately reflects implementations.

In regards to Recommendations like HTMl 4.01 and CSS 2.0, the process was different back then. They reached the recommendation status before there were any full implementations. With the current process, neither of those specs would have become recommendations in their current state. In fact, CSS 2.0 should effectively be considered a Working Draft. CSS 2.1 is far more advanced and should be considered the authoritative version.

#58 On November 17th, 2006 1:40 am Rob Larkins replied:

My gut feeling is WHATWG is a good thing for the W3C becuase it gives them some competition. The original W3C specs were compromises between competing versions of HTML, and we benfited from the rivalry because we were able to take the best from each (and maybe more important, drop off the worst!). I’d like to think that the W3C and WHATWG efforts will merge together somewhere around xHTML3, and the xHMTL3 standard will be far better than it would have been otherwise.

However the other thing to remember is in the early 90s there were like 8 competing commercial web browsers, all of them except IE were premised on the promise of selling lisenses, and Microsoft was driving like mad to catch up. When MS decided to give their brower away fro free that changed things, but browser companies still expected to fund their browsers by selling HTML editors. Thanks to Dreamweaver’s overwhelming success and a plenthera of free HTML IDEs, that’s just not going to happen now.

Right now we have 4- Opera, Safari, IE, and Gecko-based. None of them expect to make much money off the desktop browsers, and 2 of them
are OSS and largely hacked by volunteers. There just isn’t a whole lot of profit incentive to make the best browser… for anyone. That means people aren’t putting money into it.

Despite their flaws I think W3C is still putting together mostly quality specs (with a few exceptions, and some of them like the various schema languages are a matter of taste/cirumstance). People will bicker about details, but the specs are far more powerful than the technologies they’d be replacing. But without the browser vendors implementing full specifications they can only do so much. For example someone said there should be a way to transclude xHTML inside other XHTML documents. boen_robot replied that you can do this in Xinclude but it isn’t implemented anywhere. But you don’t need a recentish W3C standard like Xinclude. You can do this with the older XLinks standard. Or you can do this with basic xHTML with the object tag. Heck, you don’t even need xHTML- you can do this with plain XML with external parsed general entities! Only one problem. Absolutely none of these are implemented in any major browser! This is such a basic, majorly important feature that W3C felt the need to implement it at every stage in from basic XML on up, and no one’s ever gotten around to implementing it! Even very basic things like the coords attribute in anchor tags go unimplemented for obscene amounts of time. And when specs are only implemented partially in ALL the browsers, people tend to consider the specifications themselves broken.

End rant.

So anyway, now that you know what I think are really causing the problems for HTML you can read about my detailed opinions about what everyone else has been posting. I obviously had nothing better to do for the past 5 hours than scour all the opinions I could find, posted here and elsewhere, summarize them and list them as either good ideas or bad ideas. I posted it at my blog.

I may post again after I ruminate some more, if I think I can come up with anything worthwhile to add.

#59 On November 17th, 2006 11:46 am La domo de karotoj » Nova eldono de HTML replied:

[...] Mi antaŭe blogis pri la disigo inter la W3C XHTML kaj la WHATWG projektoj, sed ŝajnas, ke la W3C nun volas daŭrigi HTML-on por ke oni malrapide ŝanĝiĝu al XHTML. Nekrebela! [...]

#60 On November 18th, 2006 12:46 pm Anthony replied:

HTML5/XHTML2 need to look at existing websites and look at the hacks that are currently in use. Tags that mark the document up more meaningfully or allow simpler, more reliable markup would be a godsend. Example tags that would be very useful:

* The aside, nav, article, and footer tags already proposed (especially “aside”)

* A reliable way of doing dropdown/pullout menus (e.g., >ul dropdown="horizontal"<)

* XForms

* Formal, accessible method of replacing text with an image

* Inherent understanding of dynamic page elements (e.g., an online auction page might have a section that updates the current bid price automatically every 20 seconds)

* Inherent rearrangement of content (as opposed to today’s half-baked float method) – really something for CSS, I know, but still worthwhile mentioning :)

#61 On November 21st, 2006 2:48 am Olav Bringedal replied:

Even if is less and less used, I’d like to have an improvement to colspan and rowspan. Id like them to take the value “*” to fill the rest of the table.

lets say we got a table with 6 cols

[td][td][td][td][td][td]

the a spanned row for this would be colspan=6. But much simpler would be to put in * instead, especially if you got a dynamically generated table.

#62 On November 21st, 2006 5:43 am Thomas Tallyce replied:

The existence of a element or attribute to an image would be very helpful. At present the only way to get a caption reliably under an image to exactly the same width is to wrap both in a table and create two rows. Using a div means having to respecify the width, which is painful when implementing.

#63 On November 21st, 2006 10:57 am Michael Havard replied:

It still sounds to me like the vast majority of problems don’t come from the specs but from the implementors. “IE doesn’t do this…”, “Mozilla doesn’t do that…”, “Safari does it this way…”

Maybe a small portion of this is caused by unclear specs, but for the most part the blame rests on the companies and individuals developing the renderer. There’s no incentive for them to comply with the spec, there are no certifications to brag about (or be forced to take on), and there is no outcry from the user base to do anything differently. Lastly, pride in their work is based on things like market share, adoption rate, and speed of delivery (except Microsoft) versus quality and comprehensiveness of the output.

It also surprises me how people are asking for more presentation level markup in the specs e.g. ul dropdown=”", nav, footer, etc. So many elements on a page can be considered navigable and IF (big if) all things were equal it would be trivial to implement drop down menus using presentational specs like CSS and standard lists.

I mean what’s the difference between and except that maybe the developer expects the renderer to handle all of the visual styling sans CSS or JS?

#64 On November 21st, 2006 2:20 pm Thomas Tallyce replied:

[Repeat submission as entities not converted in posting #62.]

The existence of a caption element or attribute to an image would be very helpful. At present the only way to get a caption reliably under an image to exactly the same width is to wrap both in a table and create two rows. Using a div means having to respecify the width, which is painful when implementing.

#65 On November 22nd, 2006 10:55 am Anthony replied:

In links, it would be useful to provide a normative link for a URI as well as the href.

For example, a newspaper might have: <a href="story/article.html?from=frontpage" norm="story/article.html">Read story</a>. A user who had already visited story/article.html would see the link as a visited link, even though the actual URI was different.

Another use could be to provide permalinks for sites which use sessions. For example, searchresults.php?Session=1234567890 is probably going to expire. But the normative link coud be searchredirect.php?Query=Your+search+terms.

A related idea could be the use of form-like submission with a link. So for the newspaper example, the code could be something like: <a href="story/article.html" switches="from=frontpage">Read story</a>, where the page would actually be submitted as a form but with the switches as form fields.

#66 On November 22nd, 2006 10:26 pm James Robinson replied:

So many of these suggestions seem to reflect issues that should (or have) been addressed by CSS. I’m not convinced that there are a raft of new structural elements that need to be defined by another specification of X/HTML. Introducing columns, for instance, is ill conceived since passing layout control to the markup, rather than the stylesheet, would cause implementation issues for different media such as handheld devices. The use of a tab, unless I’ve misunderstood, is another issue that can be dealt with by CSS. Similarly the use of shapes.

As others here have already pointed out, much of this is going to depend upon browser support and IMHO pushing for support of CSS standards in the major browsers is preferable to the addition of further tags.

#67 On November 23rd, 2006 12:43 am Alice Pretchet » Have Your Say about the Future of HTML replied:

[...] Have Your Say about the Future of HTML [...]

#68 On November 23rd, 2006 4:59 am Simon Proctor replied:

This may have been mentioned before but I would like a way of being able to submit a form using an ‘A’ element. Without requiring scripting or some such.

It would be much easier to get across the idea that GET methods should be reusable without causing data changes but POST methods should not if this was the case. Being able to POST from a link would be great and the easiest way would be to allow submitting from ‘A’ elements.

Either that or ensure all browsers all full styling of submit buttons, but then if CSS is turned of you still have the issue.

#69 On November 23rd, 2006 6:07 am William Wedin replied:

I do hope that XHTML 2.0′s “l” element makes it into the spec. It would be especially useful for marking up poetry and addresses. I’d never need a br again.

#70 On November 23rd, 2006 10:55 pm HTML 的未來，需要你的意見| HappyDesigner replied:

[...] （原文發表在WaSP的“Have Your Say about the Future of HTML”） [...]

#71 On November 26th, 2006 3:10 am D. E. Evans replied:

For those complaining about HTML 5, have any of you noticed that HTML 5 is an XML document, and is essentially XHTML?

As other XML based standards enhance and support the growing XHTML makeup, so will HTML 5. I’m not in the least worried that HTML 5 is going back to old HTML. XML is no longer the future: it is the present.

The greatest difficulties for XML/XHTML adoption is incorrect xhtml+xml support, and content developers who harmfully send XHTML to everyone as text/html, thus promoting the former (use content negotiation for older user agents, and send text or HTML4 alternatives as the W3C recommends). As for IE, though they should have done it ages ago, at least they are starting the process of gearing up towards XHTML by properly supporting CSS2 in IE7. Hopefully, XHTML support is not ages on, but if it is, IE may find itself left in the dust. Either way, I’m not too worried.

#72 On November 26th, 2006 6:36 pm Cursory examination replied:

Where do we start?

Why can’t ‘web-apps’ be a strict subset of XML, validating parsers are a good thing and we all want to see better code out there.

Why must XML documents not be served as text/html, that’s just Hixie being a kook. XHTML1 has this right, it allows the transition to XML without excluding legacy and text-mode UA’s.

Why use document.write instead of innerHTML at all? Also document.write() is listed for dynamic markup insertion in XML when it cannot be used (edit: correctly noted in 2.5.3 but not preceeding).

Conversely noscript is listed as “must not be used” for XML when it should be handled by layout and not modify the parse tree at all. noscript elements are fine in XHTML1 strict.

Some of the new semantic elements are interesting but there are too many.

datagrid? Hmmmm.

The global storage object is presumably an attempt to sanitize viewstate. Both equally ill advised IMHO.

canvas should be a seperate spec.

The TCPConnection() and P2P stuff should be moved to a seperate spec and require explicit user permission per domain group.

Does the audio interface cruft require browser vendors to provide player functionality or just embed a plugin for playback? What formats? Why would UA’s be required to waste bandwidth downloading audio content they are incapable of playing?

There’s all the stuff about honouring author specified MIME types. It was Hixie who once declared “Content-Type is dead” and advocated content sniffing. There’s huge inconsistency here, either the author knows best or browsers stop overriding MIME types.

I see they renamed it ‘web-apps’ which is cute because this sure ‘aint no markup language. I think XHTML and XForms are better specs. I’m one of those folks that browses with script disabled and sometimes uses lynx. For me this spec is a step backwards, so I’ll just leave a big resounding “NO THANK YOU”.

#73 On November 27th, 2006 1:45 pm HTML/XHTML 5 « Library Technology in Texas replied:

[...] WHATWG is asking for comments from you: [...]

#74 On November 27th, 2006 3:04 pm CMSBlog » Blog Archive » Webstandards: Diskussion um neue HTML-Versionen replied:

[...] Webstandards: Diskussion um neue HTML-Versionen Nun sollen neue HTML-Versionen öffentlich diskutiert werden. Zur Debatte stehen HTML 5, XHTML 5 und XHTML 2. Wie üblich findet die Dikussion vorwiegend auf englisch statt, und zwar auf The Web Standards Project. Eine deutsche Übersetzungen gibt es bei den Webkrauts. [...]

#75 On November 28th, 2006 6:23 pm Anthony replied:

An inherent understanding of tabs would be fantastic. Tabs are a major aid to usability. It would be great if we could do:

<form ...>


         ...
      ...

      ...

</form>

#76 On November 28th, 2006 6:36 pm Anthony replied:

Sorry, forgot to escape my code… So redoing…

An inherent understanding of tabs would be fantastic. Tabs are a major aid to usability. It would be great if we could do:

<form ...> <tabs> <tab id="tab_1"> ... <input type="next_tab" value="Next" /> </tab> <tab id="tab_2">...</tab> <tab id="tab_3">...</tab> </tabs> <input type="submit" /> </form>

#77 On November 29th, 2006 1:16 am nobody important replied:

I would like to see this spec come with a well-advertised, set of stress test pages published stressing every conceivable feature of the specification, within practical reason (so that it is as difficult as possible for a user agent to pass all of them that does not implement the specification correctly). The spec would state that a correct implementation of this specification passes each of these stress cases without any errors. Each of these tests would have a well-defined expected result, making it as easy as possible to spot compliance failures (perhaps many of them could have a top half and a bottom half, implemented very differently, but should present themselves identically or clearly indicate what variations are permitted). This would encourage better compliance by helping spot problems with various implementations, and encourage them to be compliant by advertising their compliance failures to their end users.

I realize that developing a really good set of stress pages is more challenging than some might realize, but the more we can do the merrier, and would work to address the most common complaints expressed herein.

#78 On November 29th, 2006 2:36 am Thomas Broyer replied:

There’s a (re)starting discussion on autodiscovery on the AtomPub WG’s mailing-list. Many members pointed to HTML5′s rel=”feed” and rel=”alternate”. Here’s what I have to say about it:
http://www.imc.org/atom-syntax/mail-archive/msg19100.html
http://www.imc.org/atom-syntax/mail-archive/msg19107.html

Thanks for taking it into account.

Please also note that, wrt autodiscovery of feeds, I’d be happy if current implementations could change.
More on this here: http://www.imc.org/atom-syntax/mail-archive/msg19166.html

#79 On November 30th, 2006 7:04 pm Depricate the address element? » AlastairC replied:

[...] The first is annoying, the second unlikely. Still, might be worth asking about regarding the future of HTML. [...]

#80 On December 2nd, 2006 8:50 pm Stephen Paul Weber replied:

I quite simply do not understand continuing the old HTML/SGML strain. XHTML is cleaner, tighter, and just plain nicer to develop with. HTML5 will just encourage people not to adopt and make our lives more difficult.

#81 On December 11th, 2006 5:31 pm Have Your Say about the Future of HTML - Lachy’s Log replied:

[...] This article has been written on behalf of the Web Hypertext Application Technology Working Group (WHATWG) and has been cross posted on The Web Standards Project, Molly.com and 456 Berea Street. [...]

#82 On December 13th, 2006 1:11 pm Lickspittle replied:

About acid-2: (since I can’t find comment section for that, these seemed closest) WTF.

1. No deliberation body.
2. The XHTML source. What a joke. no-break-spaces, tables, divs. It is as if someone got in the habit of writing crappy XHTML because of using a crappy browser and then wanted to make all browsers render the same, rather than start from the beginning with truly clean XHTML.
3. Badly formed CSS to make sure that browsers properly render the bad CSS? What exactly do you think got us into this mess in the first place????

Your effort is much appreciated and much needed, but maybe a little misplaced.

#83 On December 18th, 2006 4:17 am notime replied:

How about just stricter syntax. I don’t care about entity errors, but all else should be doable just fine…

I think what we need is an update for the most popular server-side applications/servers/environments in order to work with the DOM to create websites rather than constructing them from string literals and variables. The same applies for input; once input is forced into a DOM structure, output can’t do much harm anymore. Modules/bindings for JSP/PHP that become popular (as in USED) would do part of the job.
With that, it would be easy to avoid entity errors, of course.

Also a nice XHTML-validator that actually helps instead of throwing nonsensial error messages at you would be most useful. Do you know how difficult it is to convince people to use a validator if the messages make no sense to them? Do you have to have that extra knowledge, that makes you able to guess what the validator is complaining about? Well, you shouldn’t.

Oh, and I guess besides my wish of the Web moving to XHTML2.0 I think (X)HTML5 adressed all remaining issues. Thereby… addressing far too many issues of too many people that I think it is bloated, unusable and unimplementable. And it is still tagsoup and cAsEmIxEd and anyhow… you just lost at the battle.

HTML5, for me, is a way of saying, “Guys, we are losers. Let’s finally do something we can actually succeed with”.

If you really want to convince me you are going to improve anything then don’t do it by introducing thousands and thousands of new tag names, because what makes them more morally acceptable than [applet] or [layer]? “Semantics”? Damnit, you’re dealing with tag soup, how are you going to define semantics in tagsoup.

Not to say that the W3C with all its useless regulations noone even inside their obscure consortium follows is too much better than that. It just so happens that they are obvoiusly being stupid, highlighted by WHATWG enthusiasts everyday, so there’s no real name in highlighting all that idiocy.
One advice for those though; maybe you should check all your commitee sites regularly if they comply with standards set forth in the W3C or at least make sure that they don’t break in a certain selection of browsers in certain strategic places where people are too ignorant to come out of their own favorite browser’s corner.

Okay, that was it. You asked for it.

#84 On December 30th, 2006 9:25 am Carsten replied:

Mathematical expressions:

I don’t like a high number of additional standards – For example in XHTML: XForms for Forms, MathML for mathematical expressions, and so on.

One of my wishes for HTML 5 is the built-in ability for mathematical expressions (without using a separate standard like MathML).

It would be nice to have a -Tag, that contains mathematical expressions. In this math-Tag there should be used tags for mathematical expressions, e.g. for roots, integrals, …….

Who don’t use mathematical expressions, could overread this chapter of the specification, but for others who nead mathematical expressions it would be very good, if this would be no separate standard, but one part of HTML 5.

Best wishes for work at HTML 5,
Carsten

#85 On January 1st, 2007 10:16 am Jonas Burtscheid replied:

It would be nice, if WebForms 2.0 would be integrated in HTML5.

Because that is the biggest problem of XHTML: you need many additional things to XHTML – like in post #84 is said: you need XHTML + XForms + XFrames + MathML + ……

Many webdesigners expect it the classical way (and I think, this is the best way): only one standard for markup / structure (HTML 5) and one for design (CSS).

Additional standards would always have difficulties to receive attention besides the classic ones HTML and CSS.

(And there is yet another benefit: if I search for standard-compliant browsers I only have to ask “Does it support HTML and CSS and in which versions?” and not “Does it support XHTML 2 and XForms and XFrames and MathML and ……”)

These are the reasons why HTML 5 should be *one* standard (including WebForms 2.0) and not with additional standards, that only confuse most users.

#86 On January 7th, 2007 6:32 pm Tony Dwyer replied:

I agree with several of the posts above in that I see no reason for two standards. HTML should be discontinued and XHTML/CSS should be the standard for the future.

Also, working in the tertiary education field, I think that there should be a method in XHTML for the display of equations.

A single standard for embedding Flash movies, QuickTime etc would also be helpful. I like Jeremy Walker’s (8 November above) idea for a single MEDIA element.

#87 On January 12th, 2007 2:51 am Philip Ashlock replied:

Just to answer my own request (http://www.webstandards.org/2006/11/07/have-your-say-about-the-future-of-html/#comment-11646) it looks like these issue will largely be resolved by the universal property and content attributes in XHTML2:

http://www.w3.org/TR/2006/WD-xhtml2-20060726/mod-metaAttributes.html#adef_metaAttributes_content
http://www.w3.org/TR/2006/WD-xhtml2-20060726/mod-metaAttributes.html#adef_metaAttributes_property

#88 On January 14th, 2007 8:19 pm Akaash Maharaj replied:

Given the near universal scepticism about HTML5, I realise that my views swim against the current, but nevertheless I feel that it is a desirable step.

The HTML4 standards and prior were created in the context of MSIE dominance so great that the defacto standards would always be whatever MS chose, including its attempts to grapple with its browser’s flaws and quirks.

The rise of Firefox et al means that there is now a real opportunity to create genuine industry standards that are not the child of any one organisation.

~ Akaash

_____

Site
Blog
RSS

#89 On January 15th, 2007 9:55 am Marina replied:

XHTML was the right step for the future of the web and to end all those miserable things from “classic” HTML.

Therefore, I don’t like this decision, but now HTML 5 is under development, I only wish one central thing of XHTML 2 in HTML 5 too:

HTML 5 should be (similar to XHTML 2) only for the structure of the document. All visible / style / design things should be done with CSS, that is not only better for these things, but also makes smaller and clearer files. And the strict separation of structure and design is better for accesibility (Screenreader, alternative Stylesheets for visual impaired, …), mobile devices, and for search engines.

Therefore the separation of structure and design should be in HTML 5 too and HTML 5 should only be for structure (like XHTML 2) and use CSS for style.

That’s essential for the future of the web!

#90 On January 19th, 2007 7:11 am Marc replied:

I agree, that the separation of structure (HTML) and Style / Design / Layout (CSS) is very important for the future of the web.

And there is a second very important thing: HTML 5 should use XML-Syntax. E.g. that all tags must be closed and inner tags before outer tags. That makes code better readable and is better for the interpretation through browsers, that have to guess less, how it was meant.

These 2 things (that both are in XHTML 2) are very important and if the WhatWG develops a new standard instead of help making XHTML 2 better and spread it in browsers and authoring software, at least this 2 very good things should be in HTML5: separation of structure and style and XML-syntax.

#91 On January 26th, 2007 8:12 am Blog Posible » Blog Archive » Lo que está pasando con la futura versión de HTML replied:

[...] Antecedentes: El 27 de Octubre del año 2006, Tim Bernes-Lee, director del W3C, escribe el artículo Reinventing HTML. El título de lo que escribí por aquel entonces W3C desarrollará de forma paralela HTML: HTML 4.x, XHTML 2… es bastante explicito con los planes del W3C en el futuro (si quieres, te lo puedes leer ). Además, había una crítica implícita al éxito de XHTML e incluso a la forma de trabajar del W3C. Esta noticia, desde mi punto de vista con una gran trascendencia, generó bastantes artículos en muchos e importantes blogs de gente muy respetada en este mundillo, yo destaco el que publicó A list apart titulado Have Your Say about the Future of HTML (y si quieres, puedes leer su traducción, publicada aquí mismo: Qué dirías acerca del Futuro de HTML), y aquí aparece en escena un “actor” importante de esta “película”: WHATWG, una especie de “consorcio” paralelo del que forman parte Mozilla, Opera y Apple (es decir, los navegadores Firefox, Seamonkey, Camino,… Opera y Safari) y cuyo objetivo es desarrollar aplicaciones webs más sencillas usando las actuales tecnologías. Su trabajo actual es Web Applications 1.0, también conocido por HTML5 ó XHTML5. [...]

#92 On January 31st, 2007 7:58 am Aukcje replied:

Where I would can find whole list HTML 5? I think that it was good solution to addition several things from CSS.
Example:

Every cell and row would have own appearance.
Particularly it walks about appearance commanding “border”.
Please do somethink with this.

Thanks

#93 On February 3rd, 2007 9:35 am Meble replied:

What do you think about introduction of something like writing circle?
This will be fantastic! None of languages not have something like this.
Example:
circle border=0 cellpadding=1 ….

It is this excellent idea. Please think about this.

#94 On February 7th, 2007 4:57 pm Shannon Miller replied:

#95 On February 22nd, 2007 2:13 pm Biustonosze replied:

I don’t see a point in HTML5. I think only XHTML should be developed, next versions of HTML are just for those, who are to lazy to learn XHTML.

#96 On February 22nd, 2007 7:46 pm Sabine Korizyak replied:

I didn’t meant the XML form of Patrick, I meant the SGML version. Read Sending XHTML as text/html Considered Harmful for an example. (So browsers never supported that part of HTML, which is based on SGML and the WHATWG updates that to state that the BR element written in such form doesn’t mean anything special anymore.)

Introducing new elements will not cause much harm, since they will basically be ignored. At least, they will be specified in a way that older browsers won’t have trouble with it. Like it always has been done with new HTML versions. (The Q element breaks a bit with that though; hence the QM element.)

#97 On March 5th, 2007 6:56 am Michael Finger replied:

Der Text spricht mir aus der Seele. Aber die Webmaster werden nur folgen, wenn sie einen Nutzen sehen und im Moment sieht die Masse keinen Nutzen darin, dem W3C zu folgen. Die meisten Seiten sind immer noch mit Tabellen gebaut und zum teil mit sehr schlechtem CSS und nicht sehr schönen html /xhtml. Von daher müßte es den Webmastern mehr ans Herz gelegt werden Standardkomform zu bauen. Mir persönlich fehlt ein html Element das eine Übersetzung kennzeichnet, so das man erkennt das es eine Übersetzung von einer Software ist und nicht von dem der es geschrieben hat. So haben auch Menschen die Möglichkeit etwas beizutragen, wenn sie nicht der anderen Sprache Mächtig sind.

englisch>The text speaks me from the soul. But the Web masters will follow only if they see and for the moment see a use the mass no use in following the W3C. Most sides are still built and partially with tables with very bad CSS and not very beautiful HTML /xhtml. It would have to be put by therefore it the Webmastern to more to the heart Standardkomform to build. To me personally a HTML element is missing a translation marks, so which one recognizes that it a translation from a software is and from that that it did not write. So also humans have to contribute the possibility somewhat, if they are not the other language powerful.

#98 On March 5th, 2007 7:54 am Markus replied:

Ich denke, dass es eine Zukunft für HTML gibt. Die Webseiten sind aber nicht alle mit gleichen Programmen erstellt und daher folgen auch nicht alle dem W3C. Ich werde wieterhin HTML verwenden und mich dafür einsetzen, dass diese “einfache” und gute Programmiersprache erhalten bleibt.

Gruß,
Markus

#99 On March 9th, 2007 2:24 am Kai replied:

Es ist doch sehr gut, dass das W3C die Evolution des Web unterstützt. Es hat sich eine Menge getan seit Festlegung der letzten Standards und dieses durch Weiterentwicklungen der HTML-Standars zu stützen ist die richtige und wegweisende Idee.

#100 On March 9th, 2007 5:42 am Tanie linie lotnicze replied:

People use CSS2 all the time, and they even already use parts of WHATWG HTML5 (like the CANVAS element, or contentEditable).
I do not believe that the W3C HTML WG will complete recommendation status by 2008; and neither do I believe that that WG shall be disbanded late 2010.
Specification are usable before being finished but not before those parts are incorporated into User Agents, e.g., browsers. Safari, Mozilla and Opera (since they’re the copyright holders) may be the first to include HTML5 elements and attributes once they become stable, Right?

#101 On March 9th, 2007 10:55 am Adam replied:

I see many people complaining about that xhtml should be developed further and standard html should be discontinued.

But as I understand html5 and xhtml5 are developed in parallel. So why don`t let the user decide what he wants to use ?

It was hard work for many not so technical freaks to learn html, don`t force them to go to school again.

#102 On March 10th, 2007 12:20 am Have Your Say about the Future of HTML (from Digg) « My digg’n blog replied:

[...] read more | digg story [...]

#103 On March 10th, 2007 5:24 am Joe Shmo replied:

Why web standards may not be such a good idea?

I am an advocate of universal web standards. Man it would be nice to be able to code and get the exact same results on every single browser.

Food for thought nothing more:
What if “most” of the internet was all written and very similar? They all pretty much have the same strict tags. – otherwise you get an error. Conformity. What could possibly go wrong with this?

For one it’s a hackers dream. Malicious code could be written in Robots and programs could scower the internet with less coding. Pages could be parsed with ease. Browser hijackers have no problem reading web compliant documents = your transaction is not secure. Everything from “fusebox” applications to the way things are “suppose to be structured” is highly predictable. = grounds for robotic type coding disaster with no hang up or trips. Internet data is becoming more transparent. Simple DOM scripts can parse compliant web pages with ease (already).

The question is:
Are “web standards” and fusebox coding making the internet less secure?

Again – I let the web standards idea. I’d just like to here a pro web developer’s response.

#104 On March 13th, 2007 10:20 am MisterWong-Blog » Blog Archiv » От Вас зависит будующее HTML replied:

[...] Эта статья была написана от имени Web Hypertext Application Technology Working Group (WHATWG) и была размещена на нескольких блогах The Web Standards Project, Lachy’s Log, Molly.com и 456 Berea Street [...]

#105 On March 13th, 2007 10:42 am Sergey replied:

Dear Molly and Team,

I’ve translated your blog article with questions about the future of HTML ( http://www.webstandards.org/2006/11/07/have-your-say-about-the-future-of-html/ ) in Russian and placed it in our blog:

It would be great, if you could link it, so the russian speaking community will know about this translation.
http://blog.mister-wong.ru/%d0%be%d1%82-%d0%b2%d0%b0%d1%81-%d0%b7%d0%b0%d0%b2%d0%b8%d1%81%d0%b8%d1%82-%d0%b1%d1%83%d0%b4%d1%83%d1%8e%d1%89%d0%b5%d0%b5-html/2007/03/13/

Thank you very much,
Sergey

#106 On March 19th, 2007 4:07 am Henry replied:

First of all, please take everything I say here not as harshly as it might sound. I’ve swung way back and forth on the purist side and the soup, and then I’ve swung way out into a third dimension wherein the whole thing was a mess not worth fixing, and I’m still not entirely sure of the whole thing.

I know I’m long winded. Sorry. Skimming it should work pretty well.

In some cases, worse is better, particularly for humans; our languages (I mean regular human ones, like English) are incredibly redundant, arbitrary, and idiomatic, yet this is precisely why they work so well. Computers, on the other hand, do not adapt well to these kinds of ideas.

This is why I feel the semantic web push is a starry-eyed endeavor doomed to — not extinction — but failure. It can’t reach its goals _all the way_. The extreme of trying to reach these goals would be individual tags for verbs, nouns etc. A not-so-far-fetched vision is a sentence tag, rather than using periods for this (not also this only scales to most some languages).

The problem is that by this point we would have become so entrenched… so nit-picky… in the computer’s vision of our ideas that we would lose sight of them, and we still wouldn’t have a true, full representation of our ideas. Confusion and incorrect transmission of information from human to human is a natural part of life and innovation, like parasitic species in an ecosystem. We may not like them, and might try to exterminate them, but find they are necessary, even beneficial.

Some level of semantics is beneficial, but going beyond that (and it’s not a point, it’s a fog) will detriment the ability of our already developed and tuned writing systems to get the point across. Too high of a level of tag soup is also detrimental; especially originally semantic tags converted into presentational markup.

We also need error recovery; a typo in a truly XHTML document (with correct mime type and doctype) will throw a truly conforming user agent into a validation error page. Major publications and books publish typos, or forget a period. Not only these, however are what we have to worry about — they have teams of proofreaders and lots of money to get by with. There are also those smaller players that the web has been good to; you shouldn’t need to understand the technicalities to make a simple web page. Currently, if you don’t understand the technicalities, you write tag soup, because you can’t possibly write a web document the _correct_ way. We need a loss of distinct strict and loose modes. We need a looser strict mode, and a stricter loose mode.

One possible address to this is using authoring tools to automatically produce the required technicalities. However, I feel this is coming in from the wrong angle. This is the angle, as I mentioned in the beginning paragraphs, in which computers do not do well with worse is better; do not do well with redundancy, arbitrariness, and idioms. Instead, we should come in from the angle of humans: the formats themselves (somewhat dead as compared to programming languages) need to reflect our arbitrariness, while the programming of user agents will reflect this back to us, as faithfully as possible.

Note this spiel would have ended with the word ‘possible’ if it were not for this noting of such. This is the whole idea; to do what’s possible.

Return to top

Post a Reply

Comments are closed.

Working together for standards The Web Standards Project