homepage Welcome to WebmasterWorld Guest from 54.163.91.250
register, free tools, login, search, pro membership, help, library, announcements, recent posts, open posts,
Become a Pro Member

Home / Forums Index / Code, Content, and Presentation / HTML
Forum Library, Charter, Moderators: incrediBILL

HTML Forum

This 31 message thread spans 2 pages: 31 ( [1] 2 > >     
What do you want to see in HTML 5?
21st century HTML
encyclo




msg:579934
 1:03 am on Apr 5, 2006 (gmt 0)

Following on from the discussion the current thread Why most of us should NOT use XHTML [webmasterworld.com], it is clear now that XHTML as defined by the W3C has an uncertain future, and as the W3C abandoned development of HTML the specification we are still using today (HTML 4.01) dates from 1999 - an eternity in web years. It is seriously out-of-date, and is missing many features that could help build the much more complex, interactive websites we are seeing today.

However, that's not to say that there is nothing new happening in the markup world. The effort has switched from the W3C to a new group called WHATWG [whatwg.org], or the Web Hypertext Application Technology Working Group. The group is backed by all the major players (apart from Microsoft), including the Mozilla Foundation, Opera Software, Apple inc. and Google inc.

The current work done at WHAT-WG is the Web Applications 1.0 specification [whatwg.org], otherwise known as HTML 5. The aim of HTML 5 is to become a direct successor to HTML 4.01, and remain compatible with the older standard. HTML 5 will introduce new features, but the markup should function (with extra scripting) or degrade gracefully in legacy browsers, including IE6. One primary aim for HTML 5 is in relation to web applications such as ecommerce sites. For example, the Web Forms 2.0 [whatwg.org] subsection is a significant extension of HTML 4 forms:

Web Forms 2.0 (...) provides new strongly-typed input fields, new attributes for defining constraints, a repeating model for declarative repeating of form sections, new DOM interfaces, new DOM events for validation and dependency tracking, and XML submission and initialization of forms.

You can view the draft specification (very much a work-in-progress) of the Web Applications 1.0 here:

[whatwg.org...]

You can also check out some of the demos [whatwg.org] of some of the features in Web Forms 2.0.

HTML 5 could represent a revolution in building modern, interactive websites, where advanced controls and complex forms will become extremely useful tools for website development. But as the specification is very much a work in progress, why not have your say?

So, you're a web developer, you build ecommerce sites, forums, blogs, ... You have a blank canvas, no special knowledge is required to post your ideas. :) What do you want to do with HTML that you can't do now?

What features do you want to see in "HTML 5"?

 

kaled




msg:579935
 2:25 am on Apr 5, 2006 (gmt 0)

The two most blatantly obvious missing features are, I would say,
1) Client-side include of text (we can share pictures, so why not text?)
2) Native html menus (so you don't have to fart about with complex css and/or js to achieve basic functionality).

How either of these were omitted from earlier specifications completely baffles me!

Kaled.

DrDoc




msg:579936
 4:01 am on Apr 5, 2006 (gmt 0)

Can you expand on what you mean by "client-side include of text"?

Clinton Labombard




msg:579937
 4:22 am on Apr 5, 2006 (gmt 0)

'Client-side text includes' sounds a lot like iframes, but what about just inlining text from an offsite source? Perhaps using an XML document, or as straight text, or even HTML? In other words: without a frame, just the text included like you would javascript.

I would expect an industry standard DOM that isn't just well-documented, but documented in a way that makes it very easy to understand and highly desirable to any browser manufacturer.

Greater standard resolutions, 16M possible colors, and full support of vector graphics sounds really good. Screw flash, I want to be able to use that stuff without having to script flash.

pinterface




msg:579938
 8:34 am on Apr 5, 2006 (gmt 0)

Client-side include of text is already possible, at least theoretically, if you have the time and patience to dig into XML's external entities [w3.org] and can mandate all your users use a validating XML parser (sadly, mozilla wasn't last I checked); though even once you get past those caveats, it's still more complicated than, say, iframes. :'(

kaled




msg:579939
 11:14 am on Apr 5, 2006 (gmt 0)

>Can you expand on what you mean by "client-side include of text"?

There are many ways this could be done, but the simplest would be <div src="fragment.html">. However, there is no reason to restrict the src attribute to <div>. I think it could reasonably be applied to any (block-level) element, but perhaps <td> is the only other obvious candidate for common usage.

However, backward compatibility is a big problem with adding any new features. Webmasters won't use new features until they are widely supported unless there is a built-in safety net. It's hard to see how that can be achieved for text-includes. Of course, if <iframes> could be automatically resized according to content, we wouldn't have a problem - crazy.

Kaled.

Allan Rasmussen




msg:579940
 12:00 pm on Apr 5, 2006 (gmt 0)

Following on from the discussion the current thread Why most of us should NOT use XHTML, it is clear now that XHTML as defined by the W3C has an uncertain future, and as the W3C abandoned development of HTML the specification we are still using today (HTML 4.01) dates from 1999 - an eternity in web years. It is seriously out-of-date, and is missing many features that could help build the much more complex, interactive websites we are seeing today.

However, that's not to say that there is nothing new happening in the markup world. The effort has switched from the W3C to a new group called WHATWG, or the Web Hypertext Application Technology Working Group. The group is backed by all the major players (apart from Microsoft), including the Mozilla Foundation, Opera Software, Apple inc. and Google inc.


A rather biased view, isn't it? XHTML 2.0 is backed by same players, and many more (though with switched roles for Microsoft and Google). And I don't see how you ever reached the conclusion that XHTML's future is uncertain? HTML5 may cover a current lack of functionality in web applications, and some of its work will be useful for XHTML as well, but it's not without reason the W3C abandoned the Tag Soup; in practice it simply limits the possibilities of what's possible, much more than what XHTML does.

What I wish the most from (X)HTML5 is that it improves the current CSS 3.0 WD. I don't need the rest -- though I'll surely love some of it. But XHTML 2.0 & CSS 3.0 are getting mature enough to satisfy my needs, except for the column functionality (which is way too incomplete IMO).

I'm afraid the most notable effect of (X)HTML5 will be the postponement of the inevitable deprecation of HTML.
(Sure, my view is biased as well. ;-))

pageoneresults




msg:579941
 12:47 pm on Apr 5, 2006 (gmt 0)

Great topic! I'm assuming there are many newcomers to the web design community who are reading these topics with glazed eyes.

For the beginning webmaster, stick to the basics of HTML for now. Yes, understanding the future of our development environments is important. But when it comes to the nitty gritty of it all, you're going to need to know the basics first.

This topic is more for the advanced developer. I like to consider myself one of those advanced developers. But, you know what, after reading for an hour on this proposed specification, I too have glazed eyes. It will probably take me another 2-3 years to understand what is going on there!

As the specification evolves, these conformance requirements will most likely be moved to more appropriate places. For now it's not clear where they should go.

I sure hope they did a little more pre-planning than that. Once the specification has been approved and becomes official, and the documents are in their permanent home, I'll start bookmarking and reading more. ;)

Read the spec, send your feedback! We guarentee that all feedback will be responded to before the spec is considered "done".

P.S. No news in one year? 2005-04-11. Did they lose steam?

encyclo




msg:579942
 3:52 pm on Apr 5, 2006 (gmt 0)

The WHATWG specifications are still in the early stages - much more work needs to be done before a solid draft specification is published. Nothing in the current proposals can safely be used at the moment, and certainly for all current websites you should stick to published standards like HTML 4.01.

But because the work is in the early stages, it is a good time to think about what we as developers want from HTML 5. Following kaled's suggestion about an "include" system for external files, I would like to see an aspect of the proposed XHTML 2.0 specification to make it to HTML 5. I would like to be able to add a hyperlink anywhere, not just on an anchor. For example:

<div href="page.html">this block element is linked</div>

Same for table cells, list items, etc. This could be "back-fitted" to work in current browsers with some scripting.

incrediBILL




msg:579943
 3:35 am on Apr 6, 2006 (gmt 0)

Hate to go OT, but I'd like to see all the browsers properly support HTML 4.0 before going off on the next tangent.

As a matter of fact, I'd like to see an independent testing and certification authority established that has a series of tests to verify that each browser properly implements and supports all tags and CSS and they can't claim 4.0 certification until they pass those tests.

Then we can discuss 5.0 ;)

swa66




msg:579944
 11:07 am on Apr 6, 2006 (gmt 0)

Let's first get propper and full CSS support in all browsers before we worry about yet another HTML standard.

The death of xhtml is far from a reality. xhtml ain't that bad at all. Just because some don't like it doesn't mean it can't be made to work. There is no need to have html5 competing with xhtml.

johncory




msg:579945
 2:07 pm on Apr 6, 2006 (gmt 0)

Let's first get propper and full CSS support in all browsers before we worry about yet another HTML standard.

I completely agree. Just because everyone's going all Web 2.0 crazy doesn't mean that web design has become unfettered and ready for new confusion.

Now if some nice Soprano would go and off IE and Netscape 4ever, maybe we could we could see it through. ;)

Filipe




msg:579946
 8:19 pm on Apr 6, 2006 (gmt 0)

As a matter of fact, I'd like to see an independent testing and certification authority established that has a series of tests to verify that each browser properly implements and supports all tags and CSS and they can't claim 4.0 certification until they pass those tests.

The Web Standards Project attempts to do this with their ACID2 test. I think Opera is the only major browser to pass so far.

[webstandards.org...]

httpwebwitch




msg:579947
 11:08 pm on Apr 6, 2006 (gmt 0)

I'd like to see HTML entities for multi-column flowing. That is, defined columns where text flows wrapping down column one, then continues in column two.

bedlam




msg:579948
 11:31 pm on Apr 6, 2006 (gmt 0)

I'd like to see HTML entities for multi-column flowing.

I'm curious: why html and not css [w3.org] for this purpose (since we're looking to the future in any case)?

-b

netchicken1




msg:579949
 11:40 pm on Apr 6, 2006 (gmt 0)

There are a lot of features in css and javascript that could be done in html.

Considering that html is about STRUCTURE rather than DESIGN features such as:

mouse events (onclick, mouseover, etc )
menus
animation structures (show/hide.)
placement on the page (absolute / relative etc)

When I learned html I reached the end of the book and thought ..."Is that it? Where are all the interesting toys?"

Instead of having to delve into arcane javascript, or nut out css (which I like)some of those common tools could easily become html structures.

BLINK and I think MARQUEE were the only form of animation html did.

encyclo




msg:579950
 12:28 am on Apr 7, 2006 (gmt 0)

Where are all the interesting toys?

Well, a good example of the new markup making its way into the HTML 5 specification is the [b]canvas[/b] element - it's not a completely new element as it was developed and implemented by Apple for the Mac OSX "Dashboard". The current definition is:

[whatwg.org...]
Dynamic graphics: The bitmap canvas
The
canvas element represents a resolution-dependent bitmap canvas, which can be used for rendering graphs, game graphics, or other visual images on the fly. (...)

Firefox 1.5 (as well as Safari) already has canvas support, and there is a good tutorial at the Mozilla Developer Center:

[developer.mozilla.org...]

netchicken1




msg:579951
 12:33 am on Apr 7, 2006 (gmt 0)

Now thats a great idea encyclo, all we need is Microsoft to support it (BTW firefox is now 30% of my hits, so there is hope on the horizon).

encyclo




msg:579952
 12:42 am on Apr 7, 2006 (gmt 0)

all we need is Microsoft to support it

Sure, it's a chicken-and-egg situation (or should that be a netchicken-and- ... nevermind... ;) Browsers won't support the spec until it is written, and as others have said even now seven years after HTML 4.01 came out, there are some browsers which still don't support it fully.

It all depends how easy it is to use scripting to cajole older browsers into rendering the new markup in a reasonable way. An example is the original "IE7" scripting project by Dean Edwards (who is a WHATWG contributor). Now that MS is back to actively developing its browser, it may well be interested in HTML 5, especially as they wouldn't want Firefox to be seen to be taking the standards lead again after all the effort MS are putting in to building a more standards-compliant IE7 browser.

pentascape




msg:579953
 1:57 am on Apr 7, 2006 (gmt 0)

do away with the <a> element and instead introduce extra href properties to everything else.

eg
instead of
<a href="link.htm"><img src="image.jpg"/></a>
youd have
<img src="image.jpg href="link.htm"/>

as for styling
a:active,link,hover,visited would work directly with the element, eg in the above case

img:link { style:here; }

if they could improve css at the same time to offer more than 3 levels of 'cascading'
eg at the moment there is element, class and id each getting more specific as you go down obviously with each level inheriting properties.

I have often been developing sites where I have had to make different stylesheets and change the <link> according to page.

maybe classes could have sub classes
eg
<div class="body.top">
css:
div.body.top { applies:only; to:subclass }
.body.top { can:be; put:anywhere; like:normal; classes; }
..top { double:dots; to:specify; any:element; or:class; with:that; sub:class; }

MatthewHSE




msg:579954
 2:15 pm on Apr 7, 2006 (gmt 0)

There are many ways this could be done, but the simplest would be <div src="fragment.html">. However, there is no reason to restrict the src attribute to <div>. I think it could reasonably be applied to any (block-level) element, but perhaps <td> is the only other obvious candidate for common usage.

Personally I'd like to see this functionality for any element that can contain text, even if they're inline elements such as <span>.

do away with the <a> element and instead introduce extra href properties to everything else.

That's another great idea too, although I can foresee all kinds of cross-browser rendering differences with something like this. For instance, you assign a href attribute to an entire paragraph - is the text itself clickable, or the element, meaning, does anything get underlined by default, color changed, etc.? Or what if you assign href to nested elements - what gets priority?

Not that standards couldn't (or wouldn't) be developed for this, but it's an interesting can of worms.

A suggestion I would have would be the ability to have simple if-else programming. Obviously it wouldn't need to be nearly as robust as PHP or Perl, but being able to present different blocks of HTML depending on a few external factors (browser, is a cookie set, etc.) without having to resort to serverside programming would be nice sometimes.

It should be noted that we already have at least three simple methods of doing this type of thing: <noframes>, <noscript> and <!--[if ie]>. In each case, the content only gets displayed if a certain condition is met. I'm just suggesting some very simple additions to this type of existing functionality.

You obviously wouldn't use this for mission-critical kind of stuff, or for anything where security was an issue, since all the code would still be visible by viewing the page source.

kaled




msg:579955
 4:29 pm on Apr 7, 2006 (gmt 0)

I'd like to see <style> allowed in the <body> not just the head. For instance, if a <style> were located in a <div>, its scope would be only that div. If located at the outermost level, the scope of the <style> would extend to the end of the <body>.

Expanding on the <div src="fragment.html> suggestion, the <head> (and doctype) if present in fragment.html, should be ignored entirely. This would allow the same file to be used both as an include and as a standalone file. If this were implemented, two new conditional tags should be defined being <IFINCLUDED> and <IFNOTINCLUDED> for use in the fragment.html file.

ADDED
There is a structural reason for limiting the use of src="url" - inline elements cannot contain block elements. Also, some block elements (such as headings) cannot contain other block elements. So src should be limited to those elements that could contain all the content of the <body> of the fragment.html file.

Kaled.

MatthewHSE




msg:579956
 4:56 pm on Apr 7, 2006 (gmt 0)

Another great idea, kaled, I love that <style> concept!

There is a structural reason for limiting the use of src="url" - inline elements cannot contain block elements. Also, some block elements (such as headings) cannot contain other block elements. So src should be limited to those elements that could contain all the content of the <body> of the fragment.html file.

What about times you don't want to insert any markup at all, just text? That's what I was thinking about with allowing the src="url" thing in inline elements.

JAB Creations




msg:579957
 9:06 pm on Apr 7, 2006 (gmt 0)

Who are these people mimicking Microsoft? Start something (XHTML/MSNBC) and then loose interest and walk away?

Only people who do not know how to code would desire to extend legacy languages instead of using current standards.

XHTML, CSS, SVG, JavaScript will all fulfill your clientside needs. With application/xhtml+xml that no one wants to touch you can use your own XML. For those giddy for HTML5 I suggest reading about XML.

CSS3 will eventually arrive and there is SVG for vector based graphics.

From what I have read you can already do all the things proposed in this proposed spec with most of the current standards.

As DrDoc pointed out in the previous thread IE can technically support application/xml since 5.0.

Really have people become that lazy? If I had my way I'd wave my hand and have everyone be using Gecko and or Opera based browsers all the websites that exist be served as XHTML 1.1 with application/xhtml+xml mime. No one's site would work because they're not properly coded! We all know what regular programming and bad code sum up to: crashes, lockups, and bluescreens. Support for anything and everything but standards is the reason why the money to be made legitimately off the web in regards to clientside is an abysmal joke.

I'd like to see <style> allowed in the <body> not just the head. For instance, if a <style> were located in a <div>, its scope would be only that div. If located at the outermost level, the scope of the <style> would extend to the end of the <body>.
- kaled

RE: Advanced CSS Selectors.
div.body div.content ul.menu li.menu ul.submenu li span

------
I'd like to see HTML entities for multi-column flowing. That is, defined columns where text flows wrapping down column one, then continues in column two.
- httpwebwitch

RE: CSS3
Plus Mozilla already has proprietary means of achieving this.

------
<div href="page.html">this block element is linked</div>
- encyclo

<a href="#" style="display: block;">anchor</a>

------
resolution-dependent bitmap canvas
- [whatwg.org...]

RE: SVG (Vector graphics)

------
<div href="#"><div href="#"><div href="#"></div></div></div>

RE: ...

By mixing defined elements you have to consider what happens when you mix their now shared attributes and values.

I was extremely unimpressed with how the direction the last thread was headed. I know the people on this forum are much more able and capable then that! I'm hoping that the posts in this thread are casual concepts taken with very little or no weight. It's simply unacceptable with how much dragging of feet people do. Want an example?

Huron invented a steam engine minus the gears in ancient Eygpt. But no one saw what it could really be used for. The industrial revolution should have happened thousands of years ago, not hundreds. Where are the flying cars? I could ask the same about where are the properly coded websites! The standards of tommorow are taking their time because hardly anyone has bothered to take advantage of the standards of yesterday.

John

kaled




msg:579958
 11:47 pm on Apr 7, 2006 (gmt 0)

The subject of this thread is "What features do you want to see in HTML 5?".

As a general concept, I would like to see a more consistent html definition with fewer silly restrictions (like not placing <style> in the <body> and not placing <noscript> in the <head>). I can see the attraction for <div href="page.html"> however, the issue of nested links would have to be sorted out.

Kaled.

mattur




msg:579959
 11:55 pm on Apr 7, 2006 (gmt 0)

XHTML, CSS, SVG, JavaScript will all fulfill your clientside needs...

Plus XForms, of course. Which requires XML Schema, XPath, XTeaTray and a whole bunch of other stuff.

Some WHATers think the W3C are working on unpractical specifications. [annevankesteren.nl] Others think the W3C technologies are very good but many years from implementation, and support the WHAT effort as an interim upgrade.

Only people who do not know how to code would desire to extend legacy languages instead of using current standards.

Agreed, the latest W3C standards are probably too hard for most people. [annevankesteren.nl]

Don_Hoagie




msg:579960
 12:56 pm on Apr 8, 2006 (gmt 0)

You know what I want to see in HTML5?

<helper type="monkey" throw="feces">inserts into your page a helper monkey who throws things... in this case, feces, unfortunately.</helper>

hk995




msg:579961
 2:35 pm on Apr 16, 2006 (gmt 0)

where can i find out more about HTML5? a website that will explain it in simple words?

JAB Creations




msg:579962
 4:08 pm on Apr 16, 2006 (gmt 0)

There is nor will be any such thing as HTML 5.

While it is one thing to ponder what it would be like it also confuses and falsely excites less informed people. This does not benefit them.

What needs to be done at this point in time for the web is better tutorials on XHTML served as application/xhtml+xml with some serverside tutorials on how to serve the 1.0 Strict DocType to allow backwards computability with legacy browsers such as IE7 that do not support the correct mimetype.

In addition people should continue to help people without any common computer sense to stop using IE, Outlook, and other programs that lead to problems and keep people stuck at those problems.

The concept of HTML 5 is seems born out of the concept that Microsoft can create stagnation for the internet and get away with it. Standards are great but multiple standards serve no purpose when all things people want to do can already be achieved.

encyclo




msg:579963
 4:43 pm on Apr 16, 2006 (gmt 0)

There is nor will be any such thing as HTML 5.

Agreed, in the sense that "HTML 5" is just an informal name for the Web Applications 1.0 draft specification. There is no "easy" documentation at the moment as it is still in development. The best place to read about it is here:

[whatwg.org...]

The concept of HTML 5 is seems born out of the concept that Microsoft can create stagnation for the internet and get away with it.

But Microsoft are not part of the WHATWG team, so it has very little to do with them. There are in fact three divergent opinions on the future, roughly categorized into the W3C, WHATWG (Opera, Mozilla, Apple, etc.) and Microsoft.

The W3C approach is XHTML 1.0 leading to XHTML 2.0 (still in draft stage), ultra-strict error-handling with markup specifications based on XML. The WHATWG approach takes earlier formalised W3C work (when the W3C created HTML 3.2 and 4 as a sanitized representation of the de facto standards prevailing at the time), continues the gradual approach based on approving and extending browser-makers' HTML extensions and combining it with other formalised (W3C-backed) specifications such as ECMAScript and CSS.

The Microsoft approach is entirely different - the key components being XAML and "Avalon", which in sum represent a closed, proprietary approach to web content, eschewing the open approach until now prevalent in markup and standards development.

The issue remains contentious, but between the flawed approach of the W3C and the proprietary approach of Microsoft, WHATWG's gradual approach seems to have the best chance of wide adoption. It is hard, of course, to predict the future, as our recent thread about XHTML [webmasterworld.com] shows. It is all a matter of opinion, and there is nothing stopping anyone chosing any of the paths as their preferred choice.

This 31 message thread spans 2 pages: 31 ( [1] 2 > >
Global Options:
 top home search open messages active posts  
 

Home / Forums Index / Code, Content, and Presentation / HTML
rss feed

All trademarks and copyrights held by respective owners. Member comments are owned by the poster.
Home ¦ Free Tools ¦ Terms of Service ¦ Privacy Policy ¦ Report Problem ¦ About ¦ Library ¦ Newsletter
WebmasterWorld is a Developer Shed Community owned by Jim Boykin.
© Webmaster World 1996-2014 all rights reserved