Welcome to WebmasterWorld Guest from 22.214.171.124
Forum Moderators: incrediBILL
The plan is to charter a completely new HTML group. Unlike the previous one, this one will be chartered to do incremental improvements to HTML, as also in parallel xHTML. It will have a different chair and staff contact. It will work on HTML and xHTML together. We have strong support for this group, from many people we have talked to, including browser makers.
There will also be work on forms... The plan is, informed by [WHATWG's] Webforms, to extend HTML forms.
There is also a plan for a separate group to work on the XHTML2 work which the old "HTML working group" was working on. There will be no dependency of HTML work on the XHTML2 work.
(My emphasis). Great news for web standards, the web, and the w3c.
Read the whole thing...
timBL's Blog: Reinventing HTML [dig.csail.mit.edu]
Some things are clearer with hindsight of several years. It is necessary to evolve HTML incrementally. The attempt to get the world to switch to XML, including quotes around attribute values and slashes in empty tags and namespaces all at once didn't work. The large HTML-generating public did not move, largely because the browsers didn't complain. Some large communities did shift and are enjoying the fruits of well-formed systems, but not all. It is important to maintain HTML incrementally, as well as continuing a transition to well-formed world, and developing more power in that world.
Whilst the W3C is not actually abandoning XHTML development, this is a 180-degree turnaround which will put the emphasis back on the tool of choice for 99% of web developers. HTML is back!
Earlier related threads:
Unlike the previous one, this one will be chartered to do incremental improvements to HTML, as also in parallel xHTML. It will have a different chair and staff contact. It will work on HTML and xHTML together.
xHTML ain't dead yet ... although it may become disused for simple web page creation.
emphasis added by le_gber
I'd like to see:
2. More options in forms for boxes like: email input box, url input box etc. So there will be automatic client validation of proper email or proper url. It won't remove the need for server validation but for security, but it will help make sure your customer type things write in the first place.
I use DIVs to display scrolling product lists (if too long). If the page is reloaded the position in the list is lost. Would be cool to have something like an <a> tag inside a scrolling DIV so I can re-display the list at the right position.
something like: mypage.com##divname->a2##divname2->a5
A rich text editing control that works on all major browsers and handles css. Should be possible to configure editor functions, uploads, etc.
My early perception of this is that it not only puts a drag on progress but encourages the use of HTML over XHTML. The timing of this directly after the release of IE7 also suggests that this will be a ripe excuse for Microsoft to not support XHTML (by adding support for the application/xhtml+xml mime) in Internet Explorer 8 which I have heard rumors (but unable to personally confirm myself) to be released 18 months after IE7.
This is really only a victory for sites such as Target that use programs instead of programmers.
We set the bar too high and we're going to lower it because people are too dumb to add a space and slash at the end of an element.
Why do you say that? Because html will be extended at the same time xhtml is also improved?
I really see things differently. The issue is creating ever more effective tools to get the job done. And what that job is, exactly, is different in different situations. The tool needs to fit the application, and not the other way around.
As I see it, it's the movement to strict mark-up that matters the most, rather than requiring everyone to use a form of xml, which is overkill in many situations.
In terms of this thread, improving what mark-up offers means extending the tools that delineate semantic clarity in both the html AND xhtml worlds -- which should be understood as different spaces with different requirements.
If there was any particular past error, I feel it was the creation of transitional xhtml. XHTML should have been more rigorous right out of the starting gate. Transitional xhtml allowed people to close a few elements and still keep their fuzzy, ambiguous and presentational approach mark-up.
What's the problem with XHTML? It's great. And if people are using WYSIWYG programs to create their web pages then can't they set the output as XHTML instead of HTML4? OK, dreamweaver does a pants job of xhtml last time I looked at it, so maybe not...
I hope this move doesn't see the W3C's commitment to XHTML 1.0 falter. In concept it's a *good* thing, despite IE's continued lack of support.
Am I the only one who fears 'incremental improvements'? The wildly differing support for the varying increments of CSS has proven that incremental standards have an ugly flip-side.
And is it just me, or shouldn't most of the "missing features" of HTML be done with some kind of programming language in the first place?
It is astonishing that either of these should be missing from html but that both are missing is just plain crazy.
NOTE TO BROWSER DESIGNERS