molly.com
Tuesday 7 November 2006
Have Your Say about the Future of HTML
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.
Filed under: policies, standards, web design and development, WaSP, w3c, announcement, browsers, innovation, accessibility, whatwg
Posted by: Molly | 7:03 am |
November 7th, 2006 at 8:30 am
The link to the Web Standards Project is not correct.
November 7th, 2006 at 8:34 am
I would like to see several semantic elements added that would help for footnotes and references. It’s certainly helpful to have link elements to refer to an index or glossary, but sometimes I would rather have them inside a given page.
Maybe there could be a subset of the “section” element that would be able to store references, footnotes, etc.? I guess it could be named “appendix”.
Now, for the wishful thinking. It would be great to have an automatic table of contents element that could read the DOM and create links to sections based on headers (which of course could be customized). It would also be helpful if that could point to another page so that it could be stored as a separate file, if desired. Maybe that’s something that should be left for a user agent to implement, rather than as a definition in HTML, I don’t know.
Most of the stuff that bothers me about HTML now is due to forms, but it seems like “HTML5″ is taking care of most of that.
November 7th, 2006 at 8:42 am
Jules, the WaSP URI is correct, Molly just hasn’t got around to publishing it there yet, I’m sure she will soon (I hope!).
Jordan, thanks for your feedback.
November 7th, 2006 at 9:21 am
Very nice initiative of opening this channel of communication.
I agree with Jordan’s suggestions and, going a step further, I’d say that several publishing/content managing tools would be handy.
I remember years ago when CSS was still something obscure and used only in specific pages for specific purposes.
I used to write in LaTeX and produce PDFs that I published on my page, because text on the web just wasn’t good enough (at least not handy enough) for big texts.
I think that markup to handle pullouts, chapters, sidenotes, etc (beside Jordan’s suggestions) would be a great addition.
That would allow people with very limited Web Development knowledge to manage big structured texts about their areas of expertise.
These days you can do all that by adding a little (or a lot) of Javascript and/or CSS. It would be nice that the HTML itself could handle those aspects of a text content.
November 7th, 2006 at 9:57 am
I would like to see the q element deprecated; I don’t feel it serves any useful purpose over standard quote characters (I went through a purist period which involved scripting support for q in IE and then realised what a waste of time that was.
From 456 Berea St I agree with:
Additional attributes to aid validation
caption element
Stricter syntax
This is all off the top of my head. I will ponder and maybe post another comment.
Oh, it’s not very important but it would be nice to allow the id attribute on the html element… for “tagging” an incarnation of your site so people can easily make customisations in a user stylesheet… I forget what that was dubbed as. Anyway, they added it in XHTML.
November 7th, 2006 at 10:07 am
I found a reference a long time ago to a title element for the DL. I jumped with joy at the concept of having the ability to give my lovely dl’s a header without using an h3… Until I discovered this was a deprecated element. I can’t remember if it was a label, title, legend, or something else. Now that we are using definition lists on a regular basis, this would be a great feature to re-instate.
November 7th, 2006 at 10:42 am
More (and better) elements to markup:
- Navigation elements (instead of the misused for everyting ul-tag). Nav elements could have some serious good browser implementations for any kind of boundary experienced by all kinds of users.
- Better ways to describe dialogue
- Better ways to include side and footnotes (browsers could render them as links, as textballons, as whatever).
More important than any wishlist, I would like that any future version of HTML would have precise descritions of how they have to be rendered, so no browser maker ever would be able to say so-and-so spec is open to interpretation and have their own way.
If they have their own way, it would be very clear to point out and name and shame them.
November 7th, 2006 at 10:42 am
Captions for images is my number 1 request. Perhaps deprecate the IMG element and only have OBJECT
November 7th, 2006 at 11:43 am
[…] 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 BereaStreet. […]
November 7th, 2006 at 12:19 pm
[…] 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 […]
November 7th, 2006 at 12:47 pm
My text, written days ago: http://www.revolucao.etc.br/archives/reinventando-o-html-o-futuro-da-linguagem-de-hypertexto/
November 7th, 2006 at 2:32 pm
How about some way to markup Frequently Asked Questions pages?
November 7th, 2006 at 2:55 pm
A backwards compatible (and therefore generally accessible) HTML that takes the strengths of XHTML would be great. I’d love to see the end of the HTML vs. XHTML arguments and have one unified language the serves the purpose of making documents.
-Chasen
November 7th, 2006 at 2:57 pm
[…] (The original request was cross posted on The Web Standards Project, Lachy’s Log, Molly.com and 456 Berea Street.) […]
November 7th, 2006 at 4:11 pm
This is mostly where I see Microformats taking off because they’ve taken existing html elements, and just used class names to represent a semantical meaning.
I’m really not sure what else I’d want out of html… HTML 4.01 seems good as is.
It would perhaps be great to finally get the ‘object’ element supported - but it looks as though that’s already headed on its way into the new spec. So, deprecating ‘img’ is all I can think of in favor of <object src=”img.jpg” />
November 7th, 2006 at 6:39 pm
We could really do with a decent way of marking up dialogue. q and blockquote are cumbersome when you’ve got multiple people saying different things or you’re trying to do inline quotes where part of the text isn’t quoted such as:
John, scratching his head, smiled suddenly. “I thought it might be something like that.”
None of q, blockquote, or dl seem suitable here… really we want to use an inline q with an id and have a cite with a for.
e.g.
<cite for="john2">John<cite/>, scratching his head, smiled suddenly. <q id="john2">I thought it might be something like that.</q>
…I’m not sure if we’d need anything else, but maybe an aural stylesheet good then get John, Tony and Vera (and the narrator) each read out with different voices…
November 7th, 2006 at 6:42 pm
…actually, maybe it would be better to have it the other way around…
<q citeid="john">
…then you only need to give the person once (presumably the citeid= will look for element with an id that matches) and the quote will automatically associate it with the right person. That way the aural stylesheet only needs to be referenced once, in the original “john” item…
November 7th, 2006 at 8:05 pm
Like several people have said above, I think that the addition of the “nav” element to HTML5 will be nice for semantic layout.
However, I have a question; what will the nav element contain, exactly? Just a series of links, or will it end up just being a semantic container of the ul element?
November 8th, 2006 at 1:32 am
[…] 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.) […]
November 8th, 2006 at 3:43 am
[…] 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). […]
November 8th, 2006 at 4:36 am
Take on the best bits of XHTML2. Such as being able to make any element a hyperlink. And useful elements such as NL (for navigation lists) and L (for styling individual lines). Did you know there was once a MENU element? It got deprecated. Maybe time to reinstate it.
For more advanced usage, such as marking up poetry or prose, surely this was the whole idea behind reformatting HTML in XML as XHTML? That you could then extend the language to suit your needs. Each user probably has a different range of elements they would like to use. Won’t HTML always be a compromise, limited by the inclusion of only elements deemed suitable for the majority? Or is any language (PHP, C++ etc) always a fixed list by its nature anyway?
Personally, I’d love to see the verbose BLOCKQUOTE replaced by something easier to type. You could have just QUOTE and an attribute to say if it was inline or block. (Thus replacing the Q element as well.)
“Do you have any concerns about the development process?”
Way too slow. And specs are too complex for the user to fathom out. The pages should be much shorter. No more circular links either, that take you to another part that doesn’t explain any better about an element. There may be a link for more information, then another, but it takes you back to where you came from!
We need very clear real world examples for every element, with illustrations of what the result should look like. Plus what not to do explained in clear English. The W3Schools site is a shining example.
Will HTML5 require yet another doctype? Maybe it is also time to consider doing away with doctypes altogether. If the document starts with the HTML element, then it is HTML! Since browsers cope with all manner of mangled code thesedays, what difference does the doctype really have? I can even open a page of code that has no HTML or BODY elements at all, and it displays fine. Even now, there are too many confusing doctypes to choose from. Another one for HTML5 will not help.
We need columns. Ones that allow the content to flow between them. Amazingly, Netscape 3 had columns with the MULTICOL element. I know you can now do them in CSS, but only in Firefox I believe. We must bring HTML closer to the standard of desktop publishing packages.
How about CIRCLE and POLYGON elements? Could be useful. (Yes, I know about SVG.) Text would flow inside to fit the edges.
Allow more than six headers (H1 to H6 at present). Perhaps a generic H element like XHTML2.
Deprecate odd elements like SAMP. Just use CODE for that.
Deprecate ACRONYM. Just use ABBR. To hell with IE6.
How about a voting system where everyone can choose the best new elements to add? Or a blog where you can suggest new elements, or add comments as the draft spec is being written? If Microsoft can do it with IE7…
November 8th, 2006 at 7:00 am
I’ve put some rough thoughts together over at http://weblog.200ok.com.au/2006/11/thoughts-about-html.html
There really is a ton more to think and talk about though, but it’s a start
November 8th, 2006 at 8:02 am
Proper markup for dates and times, along the lines of the , , and elements in TEI.
Also, some standardised attribute for storing machine-readable string data (eg. the machine-readable version of a date) in a HTML tag.
November 8th, 2006 at 8:03 am
Bollocks, the comment form ate my tags! I meant <date>, <time>, <dateRange> and <timeRange> from TEI.
November 8th, 2006 at 9:01 am
[…] molly.com » Have Your Say about the Future of HTML […]
November 8th, 2006 at 10:03 am
A lot of my sentiment just echoes what various other (more notable) people have said, but I’ll pitch in anyhow.
Bring back b and i. Especially i. There are times when I want italics without implying emphasis, and it is syntactically relevant. That is, unless you want to include elements for the myriad reasons I might want italics.
There has got to be a decent way to mark up conversation. dl/dt/dd works, at least don’t tell people not to use it. They are going to, unless you provide a viable alternative.
href attribute for everything. Sometimes an entire block level item should be a link. List items come immediately to mind, and headers. Not just the contents of it, but the whole element.
Please stop taking away elements unless you can completely replace it. The em vs i issue is an example there.
Make steps that bridge the html/xml gap. Standardize capitalization of elements and attributes. Require close tags for things like p and li. Little things.
I’ve seen a lot of things that I like in the spec drafts I’ve looked at. The biggest flaw in my eyes is not accounting for the ways that different people use the web.
But honestly, I’m in no place to talk.
November 8th, 2006 at 12:25 pm
[…] 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″. […]
November 8th, 2006 at 7:25 pm
[…] 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. […]
November 9th, 2006 at 1:34 am
I don’t know if this is in xforms but a from slider element would be nice to have, so that you can pick a value from 1-10 or 1-100.
Also some kind of alert or message element that would display messages like warnings, form validations errors etc. this would help screen reader users so that they can instantly see what was wrong with their form and might be a handy solution for ajax as you could add an alert element to the page to say that something changed, that would solve the whole non accessible ajax problem.
November 9th, 2006 at 1:36 am
Oh and maybe the author element, I know we have the address element but maybe that could be used for real addresses.
November 9th, 2006 at 5:06 am
Reading through the various postings it’s interesting to see how much of what people want is covered in XHTML2 and other technologies, but chipping in with my 2p…
I’d love to see more form controls. I know those at present can be manipulated with JS to provide comboboxes etc. the things we take for granted in programming application UIs. I know complex forms don’t sit comfortably in the document metaphor that makes HTML, but HTML has gone passed being just about documents.
Looking at other comments:
@ Dave : emphasis is not italics, strong is not bold. B and I are purely visual, if you want bold, but it’s not strong then class it. CSS is for visuals, HTML isn’t.
@ Those that want greater ability to mark-up data, check out Microformats. If piece of data 1 gets an element, then what about piece of data 2, 3, 4 … it goes on and on. Part of the beauty of HTML is the limited tag set. Although I do like the idea of having an attribute for alternative computer parsed data, I always feel a little dirty sticking dtstart / end into title attributes.
@ Those that want closer alignment to publishing. It’s HTML, it’s not pixel perfect, it’s not intended to be and since it’s going to be going out over a plethora of devices it shouldn’t be. If you want mark-up for publishing then use XSL-FO
Whichever way things go I hope that those deciding on the standards do not lose the principle of doing one thing, doing it well and being open to talk to other standards to do theirs. The last thing that’s needed is for a mish-mash of ideas to start entering the standard that shouldn’t really be there ( font anyone? whoever thought that was a good idea! )
November 9th, 2006 at 5:36 am
I just feel so dirty using span class=”*” for things that are semantically relevant. I’m aware of markup/presentation separation. I just don’t think there are enough markup solutions. Why does emphasis get an element, but not literary titles?
I’ve never had any luck at all styling things with non-standard tags, properly namespaced or no. UA issue, to be sure, but if microformats are the answer, lets see better UA support written into the spec (which WHATWG is doing, I know).
November 9th, 2006 at 6:01 am
Where would you use a book title outside of as a book title though?
HTML elements should be atomic in nature allowing them to be used again and again for a variety of different purposes. If we have an element for a book title, why not a CD title, car model, etc. suddenly the list of elements becomes huge.
November 9th, 2006 at 10:32 am
I’d like for HTML to include elements and attributes for describing flow charts. Flow charts, in my opinion, are as fundamental a data structure as tables, lists, and forms, and are an excellent vehicle for conveying complex relationships. Yet, Web designers/authors do not have a semantic language in which to describe flow charts. Yes, we can post pictures of flow charts in various formats (images, SVG, PDF, SWF) but none of those formats are really accessible. In addition, a semantic flow chart standard for HTML would benefit Web designers/authors in the actual creation and maintenance of websites (i.e., we could use “Flow Chart HTML” as an information architecture language for describing our projects — a sort of recursive benefit).
November 9th, 2006 at 2:39 pm
Why then do we have code and kbd, when pre class=”" would work just as well? How atomic are they, really? They are really only applicable when dealing in limited realms. I’m convinced that i isn’t the right answer, but I don’t know what is.
This is just a question, only semi-related. If i is wrong, is tt right? If so, why?
November 9th, 2006 at 3:44 pm
This may come off as terribly naive, and if so then I apologize, but it has always seemed to me that the CLASS and ID attributes are treated (generally) as purely hooks for CSS.
It is my opinion that these attributes can (and should) specify meaning before style. For instance, if browsers recognize an element with a “navigation” attribute, then the browser chrome can actually begin to take a role in providing a standard and accessible navigation outside the browser’s viewport. Additinally, this provides a much more comprehensive way for non-visual means of access (e.g. screen readers) to extract context from a document.
I don’t think that adding elements is the key to a more flexible language. Rather I think that eliminating elements and broadening the scope of existing elements will lead to a simpler and more powerful means of publishing content.
Where I do think that the language could use some beefing up is in the overall framework of document description. We have a HEAD and BODY, but why don’t we have a FOOTER? If one takes a look at the various types of printed content that could be re-purposed for the web, there are a number of general structural elements that could not only enhance document meaning, but could be used by clever designers to do some really whiz-bang stuff.
November 9th, 2006 at 7:33 pm
Before I make any comments, what is the point of a section tag? From what I’ve read it just seems like bloat when a div can be used.
November 9th, 2006 at 11:17 pm
It seems useful for more a more semantical tamarkup to have the P tag extended with P1, P2, P3, etc. Rather than having to reside to a suggested SIDE tag. And possibly deprecate BLOCKQUOTE.
November 10th, 2006 at 12:38 am
You know, HTML and xHTML are fine as they are.
I agree, it’d be nice not to have to type ‘blockquote’, when ‘bq’ would suffice, and similarly ‘acronym’, when ‘acro’ would do. So why all the clamour to deprecate ‘img’ in favour of the longer ‘object’?
And I really dislike typing ’strong’. It would have been nice to give more semantic meaning to ‘b’. Yeah, I get it, ‘b’ is visual, ’strong’ is semantic.
It seems silly to have to create a span class=”underline” to replace ‘u’ for a client who is mad about underlined text. More junk markup because someone, somewhere decreed that ‘u’ has no place on the web (Strict DOCTYPEs of course). So I can’t have standards-compliant mode with my underlined text unless I want to junk it up? I have to settle for quirks mode if I want the simple ‘u’? Yes Jakob, I know about the evils of underlining text on the web. The client doesn’t care.
No, it’s not so much that HTML needs improving, although a ‘foot’ element would be nice, and I really like ‘q’. We need an inline quote element, and ‘q’ made sense.
I’m really not keen on ‘p1′, ‘p2′, etc, because folks don’t know how to use ‘h’ elements to maximum benefit as it is. Numbered ‘p’ tags? God, I don’t know.
A ‘pq’ tag (pullquote) would be keen.
Here’s something… how about a Strict DOCTYPE that triggers browsers to drop support for deprecated elements, and simply not display elements when tags are incorrectly nested or malformed, as clients or newbies typically do. So when a client writes his/her own copy and writes…
’strong'’em’ some text here ‘/strong'’/em’
…nothing happens at all, and they get a visual clue that there’s a problem. Forget to close an ‘li’? Whoops, no list item displays. Forget to close a ‘p’… whoops, it’s gone!
Or if a client uses something abhorrent, like a ‘marquee’, or ‘blink’ tag. Nothing happens.
In programming, if you omit a semi-colon, or a close brace, your app dies. But browsers will display just about any hoary old markup. That is why there was no uptake on well-formed markup, be it HTML or XHTML–no cost for failure.
We don’t need better html as badly as we need better, smarter browsers. To hell with legacy markup. Old sites deserve to die.
Yeah, I think a Strict DOCTYPE with a malformed markup filter would be swell.
Thanks for listening.
November 10th, 2006 at 12:58 am
HTML is going to fade away.
November 10th, 2006 at 2:45 am
The CITE element is what you are looking for.
This can be achieved with the LINK element. Browsers like Opera will then display coded links in its Navigation bar. These may include links for previous/next pages, copyright, home and so on. Of course browser support is minimal.
A great idea, which could be bettered by displaying the content, but perhaps showing it in a style to indicate a problem. Ie: a red border round it, or show the text in red on yellow. This would force the designer to recode it properly!
Two responses to this:
1. To be replaced by what?
2. Then so will millions of old pages.
November 10th, 2006 at 9:25 am
Chris, thanks. I thought about letting deprecated code display with hilite, or color, but here’s the danger in that: some marketing jackass will abuse markup for effect because he can. Trust me on this one.
Best if it breaks content outright. Also, Google can then write the same sandbox algorithms they use to detect the black-hat ‘SEO’ scam of invisible text to drop page rank on malformed pages. You know, so it can’t be abused. Because there will always be some group of asshats who bend broken markup to their ends–gaming the system for enhanced visibility, and then selling e-books or ‘consulting’ teaching people how to ruin markup to ‘capture more eye-balls’.
I want a Web where non-compliance means dead content. I want a Web with a higher barrier to entry–a Web where not just any old markup will display reasonably well.
Until I get my cruft-killer DOCTYPE my attention to detail, my handcrafted HTML, my passion for doing it right will be of little consequence to the client, the client who insists on breaking rules for the sake of effect.
Here’s something, a cruft-killer DOCTYPE could be used by CMS and Blog tools to right the wrongs of bloggers and content managers. A cruft-killer DOCTYPE could be used to automatically correct poorly nested HTML (a la Wordpress) and to suggest, to the author, possible fixes.
It could be used for real-time validation: An advice console that gently prods the user for a trailing slash, or ALT text, or maybe that ‘link-break-link-break’ be marked up as a list. Or that ‘blockquote’ be given a ‘cite’ attribute.
What’s a Web Standard without a penalty for failure? It’s a building code without an inspector.
“HTML is going to fade away”. No wonder the W3C is ineffective. When they solicit input they have to sift through steaming pant loads of nonsense. I want a Web where people don’t say things they wouldn’t say in the office meeting, in front of the CEO.
This comment thread is remarkably free of this, in compared to the abuse piling up at WASP’s cross-published post. That’s a credit to Molly’s readership.
Oh, and Andrew, the Class and ID also server as hooks for DOM manipulation. It never used to make sense to me why an element with a specific ID (say ID=”content”) could only appear once on a page and Class was re-usable until I began to explore the DOM. It appeared to me as one of those rules that were made up ‘just because’.
There’s an awful lot about why certain markup exists and certain elements have been deprecated that I don’t fully appreciate. So it is with the Web. Plenty of basics on how to ‘author’ HTML but not so much on the finer points. A lot of ‘do this–don’t do that’ with reasons that basically don’t fly for the average Web newbie, until they have to work with a programmer in a templated environment. Then those arcane best-practices rapidly begin to make sense.
November 10th, 2006 at 9:37 am
Indeed people do not know how to use ‘h’ elements to their maximum benifits. The thing is here that the ‘h’ elements started out as presentational markup (I speculate) it turned into a semantic thing, which primarily seem to benifit search engines. Which is a very valid point.
Numbered ‘p’ elements would eliminate quite a few divs and spans, would add an importance to various portions of text, which in turn also would help search engines, but also text-readers.
Typically a blog these days has three columns; a ‘p1′ element for the main-content and ‘p2′ & ‘p3″ elements for additional content can be very helpful.
Blockquotes are often not quotes, and thus semantically incorrect, but very often have a different visual presentation within a text. Which would make a case to give them a ‘p2′ tag in case of additional info or a ‘p1′ tag in case they present a summary of the txt it accompanies. (in which case the main text would be a ‘p2′ or lesser element.
Of course one could also reside to the incremental counters as proposed in css 3.
However, an expansion on html would lessen the need for some css-constructions and possibly thereby lowering part of the learning-curve and thus give way to a greater adaptation of semantically correct web.
(The wish probably being the mother of the thought)
November 10th, 2006 at 3:47 pm
OK Ron, I’d be open to numbered P elements. You make a good case. Simpler, more obvious containers help both the new and the savvy developer create a more meaningful document. What’s obvious to you in this example is not quite so clear for me. And that’s the real challenge in creating markup for the working group.
While we’re wishing and hoping:
I’d like an element I can drop onto a document that vertically and horizontally aligns its content to the center of a screen. And element like ‘pictureframe’ or ‘deadcenter’ for photography or art sites.
I miss the simplicity of the ‘center’ tag. Now we have div class=”center”. Or we assign a div a width, a margin of ‘0 auto’ and then absolutely position it with negative margins of half its width and all that complicated CSS hoo-ha. That’s the kind of stuff trolls like John Dvorak can’t wrap their heads around. “CSS is too hard”, “CSS is broken”. Pah.
Today you still need a table to drop something dead center in a viewport. But the browser would at least know what to do with that… And while ‘center’ is presentational (or is it?) ‘deadcenter’ could be conceived of as structural.
So I say to the working group, give be some markup that does what real people want to do. We’d at least be able to avoid lengthy CSS workarounds and your job authoring the next spec of CSS would be (theoretically) simpler.
November 10th, 2006 at 3:49 pm
Give be… Give me. Sorry.
November 10th, 2006 at 4:13 pm
@Ray: Using an xml prolog and sending documents as application/xhtml+xml on xhtml documents will prevent unclosedness and misnestedness, and a couple other annoyances. The only problem is UA support for xhtml as xml. Still doesn’t solve your problem of marquee and blink and other uglies, but it at least forces people to check their code.
Yeah, I probably opened a whole can of worms on the application/xhtml+xml thing.
November 11th, 2006 at 2:54 am
A new HTML?!?!
Ah, and, uh, we need this, because…
1) …we do not have enough partially implemented specs, so far?
2) …someone in the XML group has p**d off Tim BL?
3) …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?
4) …parsing HTML is fun?
5) …parsing XML is too easy?
6) …the HTML group was bored?
7) …Tim BL is writing a book and needs publicity?
8) …you just wanted to check if we were listening?
9) …someone who was not colorblind sued after being severely wounded to the eyes by the XHTML2.0 working draft?
10) …TBL s3z: ZOMGl33t!!!11!one HTML5 15 t0t411y c001, FTWLOLZ!!1!
November 11th, 2006 at 8:56 am
@Ray: Whether numbered P elements are the ultimate solution, I’m not sure. That was a flash of thought while commenting on this article.
We do need a mechanism to distinguish between various P sections and if we can do away with classes and id’s, divs and spans to achieve this, that would greatly help. And these mechanisms lack a semantic approach.
Similar cases could be brought in for the re-introduced ‘menu’ element. In practice we do find primary, secondary and tertiary menu’s. Adding importance to them and can be meaningful and gives the opportunity for better css markup, thereby trying to extinguish ‘divizitus” and similar diseases.
Take all this a step further and we could make a case for numbered ‘em’ & ’strong’ elements. And possibly some others as well.
All the above of course makes a good case for the use of XML, but that right now seems a whole different discussion all together.
November 11th, 2006 at 2:14 pm
I like the idea of vanishing deprecated tags. Also helpful would be some way to specify which tags are illegal in your own document and have the parser strip them out.
HTML seems to have the idea of a “document” (as if it were somebody’s doctoral dissertation in a library somewhere) as the central organizing principle. I don’t believe the current array of tags suits the navigational elements or the layout structure very well. To me, a web page has as much in common with a software application as a page in a book.
November 12th, 2006 at 6:16 am
[…] 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. […]
November 12th, 2006 at 7:26 am
[…] تمت كتابة هذه المقالة بالنيابة عن “مجموعة عمل تقنية تطبيقات الوب للنصوص التشعبية” (WHATWG) وتم نشرها أيضاً عبر موقع “مشروع المعايير القياسية للويب” ومواقع: لاشيز لوغ, مولي و 456 بيريا ستريت. […]
November 12th, 2006 at 11:00 am
Nicolas expresses the frustration of Web developers quite neatly.
I want my cruft-killing DOCTYPE before I want a new HTML.
And yet, I’d like to have some nifty new HTML elements that either make more sense of things like navigation lists vs content lists (thanks Diane) and perhaps some structural elements like my aforementioned middle-of-the-viewport element (cause I really prefer to use tables for tabular data). And lets call that element ‘vhmiddle’ instead of ‘deadcneter’ or ‘pictureframe’, those were kinda dumb, I admit it.
But yeah, Nick, I’d like some enhancements. How about an inline list that fit’s withing a paragraph? That way I don’t have to un-intuitively end a paragraph mid-sentence with a colon:
then begin a list
as a block level element
because writers don’t grasp that
and it’s semantically flawed
html should make sense to users
and not just the web geeks who mark it up. That would be nice. So yeah, a re-working of arbitrary and somewhat limiting HTML so we can provide more meaning to content in an understandable format, and drop a few dozen spans along the way. And not just because it’s ‘t0t411y c001′.
Dude.
November 12th, 2006 at 12:57 pm
To be honest, I feel a little dissapointed at the thought of HTML5 when we still do not hve consistent implementation of HTML4.01 and CSS yet! We need to walk before running and, in areas, we are still at a crawl.
If there is one thing I would wish to see it would be a formalisation of browser detection. Conditional comments certainly have their use. This would make it far easier to tweak for inconsistencies.
November 13th, 2006 at 3:30 am
Ray,
* Nobody says the current specs do not need improvements.
* Any improvements should be part of an XHTML spec. NOT HTML.
Dude.
Nice photos, by the way.
November 13th, 2006 at 6:35 am
The problem is that dead tags never die. Browsers have to still support them because of older pages. So some authors carry on using them because they still work! But if the tags were turned off in the browser, then thousands of pages would no longer render as they did. The user would then blame the browser for not doing its job. So it’s a difficult situation. I’m not sure what the solution is.
November 13th, 2006 at 8:58 am
[…] Este artículo se ha escrito en favor de Web Hypertext Application Technology Working Group (WHATWG) y se ha publicado conjuntamente en The Web Standards Project, Lachy’s Log, Molly.com y 456 Berea Street. […]
November 13th, 2006 at 3:20 pm
@Chris: I think the solution is to let the browser flounder if it can’t display markup properly. In no other case do consumers so completely tolerate fundamentally broken software as in the web browser arena. I think the solution is to let users know that if the page doesn’t render properly, then get another browser.
Yes, that’s militant and impractical, but it doesn’t make it any more true. The longer we cater to broken software, the worse the situation will get.
(This was rather off-topic. Sorry. It’s a pet peeve of mine.)
November 13th, 2006 at 4:29 pm
[…] 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. […]
November 13th, 2006 at 7:43 pm
[…] 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. […]
November 14th, 2006 at 3:45 pm
It just occurred to me that what I’d really like to see is the death of (X)HTML in general. That may seem to be a radical concept, but with all the power and flexibility of XML, and its ability to be styled with CSS, I don’t see a need to use (X)HTML except for the looming demons of browser support.
Were future browser releases targeted more towards pure XML, then it becomes a relatively simple matter to use whatever kind of nomenclature for elements and attributes you want, because you can define them any way you want.
Yes, to be a truly effective XML developer (in this model), you would need to be conversant with some different technologies, but the power and flexibility offered make it all worthwhile to me.
November 15th, 2006 at 2:30 am
Even more radical thought. Just have only elements that are rendered differently, and leave it to the user to style them. There can’t be more than 4 or 5 basic elements, can there? You’ve a block level area, an inline area, and so on. Create a generic name for each of these and you’re done. Then use XML as suggested above to add custom elements at will. The browser will style the generic elements for you. (You’d need some way of assigning these to newly named elements. Perhaps using attributes?) Eg: here are the basic building blocks you can use:
this acts the same way as a paragraph or a div might
this acts like a span, bold, italic, etc
and so on
I’m thinking aloud here, so let me know if this is complete rubbish or not. So here’s your customised XML version:
My Site
Welcome! Hope you like it!
You could use CSS of course, but the page would need to work without it, hence the type attribute to give the browser a basic style to use.
November 15th, 2006 at 2:33 am
Oh f…. all my tags were destroyed. Try again:
Replace the brackets with chevrons!
- - -
(block)this acts the same way as a paragraph or a div might(/block)
(inline)this acts like a span, bold, italic, etc(/inline)
(list)and so on(/list)
I’m thinking aloud here, so let me know if this is complete rubbish or not. So here’s your customised XML version:
(header type=”block”)My Site(/header)
(blurb type=”block”)Welcome!(comment type=”inline”)Hope you like it!(/comment)(/blurb)
You could use CSS of course, but the page would need to work without it, hence the type attribute to give the browser a basic style to use.
November 16th, 2006 at 8:35 am
I second the Navigation element suggestion (NL, NAV, etc) very much so.
November 16th, 2006 at 8:59 am
hi Molly!
Wish: an html structure semantically dedicated to navigation. somethingg alongside ul, dl or ol: a nl: navigationList, maybe ? Only one would be allowed on a page, so as to force it to be an internal navigation.
November 17th, 2006 at 3:07 am
You might require more than one navigation list on a page. Some sites have two running across the top. Others might have separate sections on one page, each requiring a navigation list. Why not allow for an infinite number of them? Let’s not hold HTML back by limiting it.
November 17th, 2006 at 9:19 pm
“Nice photos by the way…”
Thanks Nicolas! Anyway, I agree, why do we need another HTML, when xHTML is the way forward?
I think HTML4.01 is a fine spec as is. Let’s nudge closer to a semantic web with xHTML. Makes perfect sense.
November 18th, 2006 at 8:24 am
I want to be able to escape quotes in attributes:
stuff
And what about clientside webpage-inclusion?
November 20th, 2006 at 6:21 am
why do we need another HTML, when xHTML is the way forward?
XHTML is not the way forward, that’s the whole point. However, as XHTML1.0 as a serialisation of HTML4.01 proved, and TBL suggests, both can be taken forward, with XHTML5 being a serialisation of HTML5 etc.
Let’s nudge closer to a semantic web with xHTML. Makes perfect sense.
The Semantic Web uses OWL and RDF, not XHTML, and is also questionable as an ongoing w3c project in itself.
November 22nd, 2006 at 10:43 pm
[…] 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. […]
November 23rd, 2006 at 6:47 am
[…] Actualización del 23 de noviembre de 2006: Molly E. Holzschlag también lo comenta. […]
November 23rd, 2006 at 8:28 am
How about adding an attribute to hyperlinks that allows the designer to let the user know what type of document the link points to i.e. PDF. And (brainstorming now) maybe the ability to communicate the size of the file? I’ve seen workarounds for showing the type of doc - e.g. My Document (PDF), but I’ve not found anything that works without having to enter the type of document into the main flow of text, or anything that works with CSS switched off. Is my example bad practice? Does an attribute with this function already exist?
November 23rd, 2006 at 8:55 pm
[…] 本文是應網頁超文本技術工作小組(Web Hypertext Application Technology Working Group, WHATWG)邀請而撰寫，並且同時發表在The Web Standards Project、Lachy’s Log、Molly.com和456 Berea Street。 […]
November 27th, 2006 at 3:33 am
There’s currently no way of styling form buttons independently from form fields without either incorporating something extra into the code (e.g. a class name) or using CSS techniques which currently have poor support. And I’ve yet to come across a situation where my form fields and buttons need to look identical. So should form buttons be an element, or should they have their own element type such as or . And while I’m on the subject, shouldn’t be an ? It struggle to see the logic of the current system.
November 27th, 2006 at 3:34 am
Arhhh - bad UI Molly - your comment form ate my HTML tags.
November 27th, 2006 at 5:06 am
It should have said…
should form buttons be an <input> element, or should they have their own element
type such as <submit> or <button>. And while I’m on the subject,
shouldn’t
<textarea> be an <input type="textarea">? I’ve always struggled to see the
logic of the current system.
November 27th, 2006 at 6:39 am
Steven Tew, there is already a button element.
December 2nd, 2006 at 6:49 pm
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.
December 5th, 2006 at 11:28 am
How about either:
1) modifying the TEXTAREA element so that you can style/manipulate it on a character-by-character basis (or maybe creating a separate CODEAREA element, or…
2) creating a SYNTAX form element that has an attribute ‘language’ so that you can type out Javascript (or some other language/markup), it appears like a TEXTAREA element with escaped HTML, but it’s also evaluated into a line-by-line structure so that you can identify the code and style it appropriately.
I pretty much just want a native syntax highlightable TEXTAREA element since you see so much of it on the net these days anyway.
December 5th, 2006 at 10:35 pm
o for the love of god just give me the ability to set height at 100% without any bugs and workarounds!
December 8th, 2006 at 10:04 am
Historical and physical atlas of Europe. Maps of mountains, rivers, cities and countries. Pictures of towns and landscapes. Antique Europe maps. Illustrated European history. Digital maps and softwares.
December 11th, 2006 at 3:31 pm
[…] 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. […]
December 11th, 2006 at 10:08 pm
Here’s another one:
Ever get annoyed that you can’t wrap a TR inside of a FORM? (Or maybe a TD for that matter)
How about either making a FORM > TR valid, or creating a Frankenstein tag out of the two and invent a tag called TF, TFORM, TABLEFORM, TRFORM, or some other name? It would basically be a Table Row that could submit data like a FORM does. I could be missing some important reason why this isn’t already available, but I’m just throwing the problem out there.
December 13th, 2006 at 2:27 pm
side effects of topamax
http://myblog.es/topamax/
December 14th, 2006 at 11:15 am
Tera Patrick Anal
http://myblog.es/tera-patrick
December 19th, 2006 at 6:36 am
It would be nice to replicate some of the layout niceties that are lost in the transition to divs, such as:
- multiple cells in a row evenly fitting a percentage width, even when the window width changes, and all having equal height that matches the tallest content (perhaps divs could size relevant to a container div and use fraction widths rather than decimal percentages);
- and easy on the eye form layouts without excessive divs or spans.
Improved styling for form elements (which I think might already be coming) would also make life easier, not to make them completely unrecognisable, but it would be great to be able to adjust margins, padding, and colours (and have it fully browser supported!)
And the ability to set rounded corners!!! (maybe even blunted/angled corners) for tables, borders, scrollbars, form elements, etc.
Some of this might be more CSS than HTML, but it’s all got to work together - and it’s just my inexpert 2 pence worth of first thoughts.
December 21st, 2006 at 8:37 am
Label tags… they are useful in forms to join a textual (or graphical) label to a form field. Why not extend this to outside forms? Simply by having a label tag that you can attribute to an object you could have lots more usable relationships on a page.
- An image has a piece of text linked to it, so has to have extended alt text that are visibile to visual users and placed where the author wants them, while maintaining implicit linking semantically and for screenreader users.
- Value pairs decribed within a page without bastardising definition lists to do so.
Equally, this isn’t a additional tag, people already have them and use them, this is just a broadening of the spec, and obviously the implications to browsers / screenreaders to recognise.
December 23rd, 2006 at 11:08 am
Hi, A great source of some reallly usefull information, Thanks I’ve added you to my favourites.
January 25th, 2007 at 10:01 am
ibfjddztn
January 30th, 2007 at 2:41 pm
Sweet
February 6th, 2007 at 10:28 am
Thanks for this very good article … Can i translate this and insert on my site in Poland? … Thanks
February 15th, 2007 at 12:01 am
[…] There’s been some broo-ha-ha over the future of HTML. To say the least it’s been going on a while and has caused no small amount of disagreement in the web world. However a concensus seems to be on the horizon that HTML5 is the way forward, thanks mainly to the WHATWG. […]
February 27th, 2007 at 10:38 am
That’s really a pretty good article, I wonder what the outcome will be and what implications the web2.0 idea will bring…
March 6th, 2007 at 10:45 am
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.
March 6th, 2007 at 10:22 pm
[…] Have your say about the future of HTML, englische Version von Molly Holzschlag […]
March 9th, 2007 at 7:35 am
The new and evolved HTML should also be the right choice for developing mobile applications…
March 13th, 2007 at 3:20 pm
[…] Эта статья была написана от имени Web Hypertext Application Technology Working Group (WHATWG) и была размещена на нескольких блогах The Web Standards Project, Lachy’s Log, Molly.com и 456 Berea Street […]
March 17th, 2007 at 4:43 am
Thanks for this article … Can i translate this and insert on my site in German?
March 17th, 2007 at 4:44 am
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.
March 19th, 2007 at 10:40 am
It’s a good article. I’m really interested in it. We will see what implications the web 2.0 come to the future.
March 21st, 2007 at 10:13 am
Further to some of the previous posts on and marking up dialogues etc I’d like some generic elements for binding keys to values. Something like:
What I’m up to this week
Monday
I’m going to do very little
Tuesday
I’m going to do even less than Monday
Then have an early night
That would make me very happy. And stop people misusing s.
Ask…
March 21st, 2007 at 10:18 am
Grrr… I’ll try that again…
<h3>What I’m up to this week</h3>
<ol>
<li>
<kvp>
<k>Monday</k>
<v>I’m going to do very little</v>
</kvp>
</li>
<li>
<kvp>
<k>Tuesday</k>
<v>
<ul>
<li>
I’m going to do even less than Monday
</li>
<li>
Then have an early night
</li>
</ul>
</v>
</kvp>
</li>
</ol>
March 23rd, 2007 at 12:40 pm
Great article. I like new web2.0 projects based on ajax.
March 24th, 2007 at 12:09 pm
This is very good article. I be fascinated because, we will seeing one another what implication they net 2.0 come to future.
March 27th, 2007 at 4:43 am
Many greetings from Germany. So exactly I did not regard that yet. An extremely interesting article, as I find. All property
March 29th, 2007 at 10:59 pm
Super article. I read something similar recently also in the NY Times.
March 29th, 2007 at 11:12 pm
Hello people, if you like to have some journey to germany or a trip all over the world you can visit my website. greetings from germany dear sebastian
March 30th, 2007 at 8:18 am
I would have a simple tag to insert XML-Data.
April 1st, 2007 at 3:10 pm
Captions for images - that’s the great idea I think. Perhaps deprecate the IMG element and only have OBJECT would be also cute?
April 3rd, 2007 at 5:12 am
HTML is a very important language and concept for the future. And XML/XSL supports HTML in an strong way.
April 3rd, 2007 at 8:20 am
many things whatwg are already very promising. I wish yourself before a fast published standard, so that one can convert it immediately.
Like my previous speaker already said, HTML with xml is already a good thing.
April 6th, 2007 at 4:05 am
Super Articel, but I believes it still another whole time will last to itself to WHATWG will intersperse.
April 6th, 2007 at 11:16 am
A backwards compatible (and therefore generally accessible) HTML that takes the strengths of XHTML would be great. I’d love to see the end of the HTML vs. XHTML arguments and have one unified language the serves the purpose of making documents.
April 7th, 2007 at 6:41 am
Thanks for this article. That’s really a pretty good article
April 9th, 2007 at 10:56 pm
Dem Beitrag von Herrn Bilda möchte ich mich anschließen. Für die meisten Webmaster ist HTML4 ausreichend. Eine Abwärtskompatibilität würde zu einem gemeinsamen Standard führen. Einen abgleich mit den wichtigsten W3C Standards würde ich als gut empfinden.
April 10th, 2007 at 8:48 am
Auch ich möchte mich Heinz Bilda anschließen. Es wäre sehr schade, wenn diese allgemein verständliche HTML Struktur nicht mehr in dieser Form mit anderen Webstandards kompatibel wäre.
April 11th, 2007 at 10:02 am
I think in the most cases the current version of html is total sufficient in order to represent everything the writer wants to say or show.
@ Molly: greetings freom Germany - Your last name may have its origin from here, it looks typical german.
@ Heinz Bilda: Deinem Beitrag ist wirklich nichts hinzuzufügen! Ich schließe mich Deinen Ausführungen auch an!
April 13th, 2007 at 2:41 am
Fantastic text. May I translate this in Poland and insert on my site ?
I think it would be a great help for many people !
April 13th, 2007 at 9:40 am
Sehr interessant. Meiner Meinung nach ist die Abwärtskompatibilität ein sehr wichtiger Faktor. Als Webdesigner kann man mit den aktuellen Standards wunderbar arbeiten. Ich halte es nicht für unbedingt notwendig immer mehr Standards zu entwickeln, wo der Grossteil der Webdesigner noch nicht einmal mit den aktuellen Standards arbeitet. Erstelle ich eine Webseite laufe ich immer Gefahr irgendwann von meinem Kunden verklagt zu werden, weil sie nicht nach den “supertollenneuen Standards” erstellt wurde. Vielleicht sehe ich die Sache auch zu pessimistisch, aber wenn ich die Zeit sehe die ich benötige um neue Kundn zu gewinnen, Webseiten zu erstellen und mich um meine eigenen Projekte zu kümmern, dann bleibt mir nicht soviel um mich noch mit neuen Standards zu beschäftigen.
April 14th, 2007 at 12:01 am
Ich wünsche mir in erster Linie einen schnell veröffentlichten Standard, der abwärtskompatibel ist, so dass ich und andere diesen sofort umsetzen können.
XHTML2 ist doch keine ernsthaft realistische Möglichkeit für die Mehrheit der Webmaster und Webdesigner. Mit HTML5 wird sicher jeder soweit wieder sehr gut zurechtkommen!
April 15th, 2007 at 2:27 am
Hi, natürlich wird es immer eine Weiterentwicklung geben auch im Webdesign, nur sind doch viele heute noch mit Frames am Werke:)Ein direktes Umdenken darin gibt es nur langsam.
April 16th, 2007 at 3:20 am
Was wäre das Web ohne die Möglichkeit der Abwärtskompatibilität. Neues kann nur so an die Masse kommen.
April 16th, 2007 at 11:21 am
Viele verstehen doch heute noch nicht mal css, wie soll man dann Abwärtskompatibilität erklären und das für breite Massen klar machen.
April 19th, 2007 at 6:16 am
titcotekewyve
exsitacaneke
April 23rd, 2007 at 8:30 am
Hallo,
Millionen von Webseiten sind doch nach dem “Alten” HTML Standart erstellt worden.
Es wäre doch eine Katastrophe sollte dieser bald nicht mehr gültig sein.
Aber so ist es heute im Internet. Ständig was neues. Wer da mithalten will hat was zu tun.
Zumal der Mensch doch ein “Gewohnheitstier” ist. Sich ständig an was neues zu gewöhnen fällt nicht leicht. Aber mir als Webmaster wird wohl nichts anderes übrig bleiben und mit der Zeit zu gehen.
April 24th, 2007 at 2:52 pm
HTML 4 ist eine einfache Möglichkeit auch für Anfänfger mit nur einer Sprache Internet-Seiten zu erstellen, eine Sprache, in der man sowohl Text auszeichnen als auch Text und Elemente formatieren kann. Das sollte auf jeden Fall so bleiben.
April 25th, 2007 at 2:21 pm
Ds vorhandene HTML genügt in Verbindung mit CSS vollkommen, um ansprechende Webseiten zu erstellen. Viel wichtiger wäre meines Erachtens, dass die zig verschiedenen Browser-Entwickler sich endlich auf einen Standard einigen.
April 26th, 2007 at 5:52 am
Ich kann Kraemer nur beipflichten. Es wäre schlimm, wenn das “alte” HTML irgendwann nicht mehr gueltig sein sollte.
Zig meiner Webseiten müssten neu aufgebaut werden…
April 29th, 2007 at 6:38 pm
Nice and well written article.
But a burning question is whether browser companies will follow the W3C standards. Mozilall has already stated that they wont be following W3C standards. It would be rally interesting to see the future of HTML. Will it be driven by standards or will it be at mercy of browsers.
April 30th, 2007 at 5:06 am
Ich denke ja nicht, das es einen komplett neuen Standard geben wird.
Wie soll das denn gehen?? Alle Webseiten neu schreiben??
Im Leben nicht.
Viele Grüße
Roger
May 2nd, 2007 at 5:57 am
Why then do we have code and kbd, when pre class=”” would work just as well? How atomic are they, really? They are really only applicable when dealing in limited realms. I’m convinced that i isn’t the right answer, but I don’t know what is…
May 2nd, 2007 at 5:58 am
So, Where would you use a book title outside of as a book title though?
HTML elements should be atomic in nature allowing them to be used again and again for a variety of different purposes. If we have an element for a book title, why not a CD title, car model, etc. suddenly the list of elements becomes huge.
May 2nd, 2007 at 5:58 am
This is mostly where I see Microformats taking off because they’ve taken existing html elements, and just used class names to represent a semantical meaning.
May 2nd, 2007 at 2:49 pm
Its hard to say wha is future of HTML but I think that we have to remember it for a long, long time.
May 4th, 2007 at 2:26 am
HTML ist und bleibt immer ein Teil der Webseitenprogrammierung.
Denn auch im PHP Script sind einzelne HTML Teile nicht wegzudenken.
Zumindest momentan und auch in naher Zukunft nicht…
May 4th, 2007 at 1:00 pm
HTML is quite nice. In times of CSS and the nice possibilities HTML is losing more and more. Better search engine optimization - on the page - is possible through css. We left the HTML way where we can.
May 7th, 2007 at 10:50 am
HTML und PHP wird bereits von W3C erweitert und soll auch in Zukunft mehr bieten!
May 9th, 2007 at 3:12 am
perhaps it will be a better standard of the language web
May 10th, 2007 at 5:29 am
Wie soll das denn gehen? Alle Webseiten die in HTML geschrieben sind neuschreiben? Das wird ein langer schleichender Prozess…
May 10th, 2007 at 1:48 pm
@Andreas SEO
PHP wird vom W3C erweitert? ach du lieber gott… nene, mit php haben die wenig zu tun
May 12th, 2007 at 11:10 pm
It’s all good… but there are still things that you can’t do with CSS but can with tables…
May 13th, 2007 at 12:50 pm
Hi, A great source of some reallly usefull information, Thanks I’ve added you to my favourites.
May 14th, 2007 at 3:54 am
Hello!
Great idea. Thanks for.
Best regards
May 14th, 2007 at 9:14 am
great site with very good look and perfect information…i like it
May 15th, 2007 at 6:31 am
HTML 4 ist eine einfache Möglichkeit auch für Anfänfger mit nur einer Sprache Internet-Seiten zu erstellen, eine Sprache, in der man sowohl Text auszeichnen als auch Text und Elemente formatieren kann. Das sollte auf jeden Fall so bleiben.
May 15th, 2007 at 6:31 am
This is mostly where I see Microformats taking off because they’ve taken existing html elements, and just used class names to represent a semantical meaning.
I’m really not sure what else I’d want out of html… HTML 4.01 seems good as is.
May 15th, 2007 at 6:48 am
To be honest, I feel a little dissapointed at the thought of HTML5 when we still do not hve consistent implementation of HTML4.01 and CSS yet! We need to walk before running and, in areas, we are still at a crawl.
May 15th, 2007 at 1:51 pm
Ich kann Kraemer nur beipflichten. Es wäre schlimm, wenn das “alte” HTML irgendwann nicht mehr gueltig sein sollte.
Zig meiner Webseiten müssten neu aufgebaut werden…
May 16th, 2007 at 3:14 am
Das alte 4.01 HTML ist derzeit wirklich noch, meiner Meinung nach, völlig ausreichend. Mit den neuen Technologien wie Web2.0, sprich Ajax, lässt sich ein riesiger Funktionsumfang ausschöpfen.
May 16th, 2007 at 3:16 am
Mit Ajax lassen sich sogar richtige Anwendungen, wie man sie aus der Windows-Welt kennt, umsetzen! Klar, die Anforderungen werden immer wachsen und damit auch die entsprechende Seitenbeschreibungssprache. Im Moment ist dies, meiner Ansicht nach, aber noch nicht notwendig.
May 16th, 2007 at 5:01 am
Re: kody do gier von 15.05
Man stellt doch heutzutage keine Seiten mit HTML. Natürlich die HTML- Kenntnisse sind wichtig, man kann mit HTML sowohl Text auszeichnen als auch Text und Elemente formatieren und das sollte auf jeden Fall so bleiben.
MfG
May 17th, 2007 at 3:13 am
We are talking about new standards and implementation of new features in HTML5. As a web developer i am getting sick (daily) in the interpretation of current standards using FF & IE. Shouldn’t that matter before launching the new one?
May 17th, 2007 at 8:38 am
Jules, the WaSP URI is correct, Molly just hasn’t got around to publishing it there yet, I’m sure she will soon (I hope!).
Jordan, thanks for your feedback.
May 18th, 2007 at 5:10 pm
In vielen Fällen und für eine große Anzahl von Menschen ist der Gebrauch dieser Sprache vollkommen ausreichend. Durch die überschaubare Komplexität sind eine große Anzahl von Menschen in der Lage die Grundbegriffe dieser Auszeichnungssprache zu erlernen. Auch ich zähle mich zu dieser Mehrheit. Mein Interesse liegt nicht in der Handhabung einer Programiersprache sondern in der Erlernbarkeit einer Technik zur Veröffentlichung von Inhalten auf meiner Website. Mit HTML4 kann ich bereits sehr viel anfangen. Dafür bin ich dankbar und zufrieden. Daß diese einfache Technik den begabteren und auf diesem Gebiet sehr tüchtigen Menschen nicht genügen kann verstehe ich. Ich plädiere daher an die Abwärtskompatibilität der neuen Webstandarts zu HTML4.
May 20th, 2007 at 12:25 pm
Its hard to say wha is future of HTML but I think that we have to remember it for a long, long time.
May 21st, 2007 at 9:08 am
Ich schließe mich meiner Vorgängerin an, wenn gesagt wird, dass der “Gebrauch dieser Sprache vollkommen ausreichend” ist. Auch ich bin alles andere als ein Profi was das Programmieren angeht. Es ist vor allem wichtig, für welchen Zweck eine Programmiersprache verwendet wird… Da reichen manchmal auch “primitive” Kenntnisse bzw. Features, um seinen Besuchern das zu bieten, was sie suchen.
May 23rd, 2007 at 5:13 am
There seems no need to develop a language when there are a lot of additional languages to compense a lack. Thinking of php for example which allows more dynamic.
Regards
mig
May 23rd, 2007 at 11:02 am
xhtml rules!!!
May 24th, 2007 at 11:35 pm
Jordan, thanks for your feedback.
May 28th, 2007 at 5:31 am
Great and excellent article it’s realy helpful. Thanks again. Good work. Greatings
May 28th, 2007 at 11:19 am
Thanks so very much for taking your time to create this very useful and informative site. I have learned a lot from your site. Thanks!!
May 29th, 2007 at 2:23 am
I think these blog is really useful for new comers and Excellent resource list. It´s a very interesting Blog and simple answer of many questions.Keep up the good work!
Thanks it helps me a lot…
May 30th, 2007 at 1:02 pm
Thanks for good article - good work. It very interesting for me. Greatings
May 31st, 2007 at 2:56 pm
Thanks for very interesting article. I really enjoyed reading all of this posts. Greetings