Apparently it is not very clear what HTML5 is about. HTML5 is not just about introducing new features. 90% of HTML5 is about fixing existing standards. Indeed, HTML5 is mostly about fixing existing standards so they can be implemented interoperably by user agents. These standards include HTML4, XHTML1 and DOM Level 2 HTML as well as defacto standards such as innerHTML. The reason we are introducing new features as well is because we need to innovate the open web to keep it on a level where it can compete with proprietary technology. Focusing on both new features as well as trying to increase the level of interoperability is in my opinion perfectly feasible and also the right way to move forward.
Karl Dubost from the W3C made a series of posts about how you can help out. Please do!
in your previuos post i found example:
<input list=browsers> <datalist id=browsers> <option value="Safari"> <option value="Internet Explorer"> <option value="Opera"> <option value="Firefox"> </datalist>
Does it means that in html5 i can use attribute values without quotation marks (")?
What about <br /> syntax in html5? With this allowed even html documents can be processed by xml tools (like xml parsers)
Don't like innerHTML. its name is not good. What if someone want to convert html documents to xhtml(2) documents? Should he/she change all scripts? innerStructure / appendStructure or sth. like this is much better imo.
and will be there update to xhtml (xhtml1.5?) that will contain all changes to html4?
in your previuos post i found example:
<input list=browsers> <datalist id=browsers> <option value="Safari"> <option value="Internet Explorer"> <option value="Opera"> <option value="Firefox"> </datalist>Does it means that in html5 i can use attribute values without quotation marks (")?
Yes. Just like in all previous versions of HTML.
What about <br /> syntax in html5? With this allowed even html documents can be processed by xml tools (like xml parsers)
Theoretically, yes, if you're careful, but it won't result in the exact same DOM tree as if you used an HTML5 parser. Trying to use an XML parser to parse HTML is not a good idea. In due course, HTML5 parsers will be probably equally available as XML parsers are today.
Don't like innerHTML. its name is not good. What if someone want to convert html documents to xhtml(2) documents? Should he/she change all scripts? innerStructure / appendStructure or sth. like this is much better imo.
It's too late to change the name now. Also, innerHTML works in XML too.
and will be there update to xhtml (xhtml1.5?) that will contain all changes to html4?
Yes. It's called XHTML5.
I'm confused! All the Web gurus told me I should be using XHTML if I want the cool kids to like me. So I said a teary goodbye to HTML 4 and moved on.
Now I'm hearing about HTML5! Was XHTML 1 (and then XHTML 1.1) not good enough?
If I give my heart to HTML5, what happens when the W3C completes XHTML 2? And why is the W3C pushing both XHTML2 and HTML5? Are they really the spawn of Satan bent on destroying the Web?
And, finally, will any of this work on Safari for Windows? Should anyone care?
HTML sucks. Xhtml is the only solution.
Why waste time on developing SVG or MathML with HTML5 in the same time?
And XHTML5 - where is xhtml2 (and 3 and 4)?
it will be much better to develop xhtml3 and allow it to be send as text/html (for special-html-like-xml-parser).
And why i think HTML is not good idea
in my company we have website with about 300 subpages - all in xhtml4
I want to use php-tal template engine or XSLT based template engine. And now i have to change all [br] to [br /], all [meta] to [meta /] etc. In perfect world there will be no difference between languages. Only difference will be parser (xml or html) chosen with extension (xhtml, xml) or header.
@Tom think of it this way: XHTML still works for you if you're happy with it.
However, if you are using Microformats for more purposeful data, Javascript to create widgets for controls that don't exist (dialogs for example), or just want to stop writing validators for lots of simple datatypes (email, dates, etc.), consider HTML5, which has these things built-in.
In due course, HTML5 parsers will be probably equally available as XML parsers are today.
They are not mutually-exclusive. Even today, I'm using HTML5lib in a Wiki project that is XHTML served (out-of-the-box!) as application/xhtml+xml.
But, then, I've always been a little cutting-edge ...
I kinda doubt we'll ever really see MathML+SVG in HTML5. Even if we do, it's probably a decade away. So XHTML ain't going away (from my world, at least) any time soon.
I already suggested a interim arrangement meaning to encourage commitment and engagement to the current standards development, but to "stop" at least for a while once those are stable.
It's a very good thing to fix existing standards, define error handling and corner cases and so on. However HTML5 also contain some *major* new features like Canvas which is invented from scratch as an alternative to an existing standard, SVG, which is already implemented in several browsers.
SVG may have problems, but why not fix these as you are fixing HTML4?
The original inventor of canvas, Apple, claimed canvas was invented for use in OS-X-specific Dashboard Widgets, and the reason for not choosing SVG, was because of the release timeframe: In other words, in an ideal world where we had two years to craft Dashboard, maybe we could have used XHTML and SVG, but we aren't living in that ideal world.
(http://weblogs.mozillazine.org/hyatt/archives/2004_07.html#005928
Well, this quote is now precisely three years old.
@Olav: HTML5 is about interoperability. Given that multiple browsers have now implemented the canvas tag, there needs to be a spec for it to keep the browsers compatible. HTML5 just documents current practice and helps clear up corner cases.
Well, this quote is now precisely three years old.
And guess what? Three years later, Safari 3Beta was just released, with SVG support. Meanwhile, Leopard's Dashboard will support Web Clipping. Which, if you think about it, amounts to the ability to embed arbitrary tag soup from some foreign website (in an <iframe>?) in a Dashboard widget.
Try embedding arbitrary tag soup in XHTML(+SVG)! This is not a matter of any purported "defects" of SVG. It's a matter of designing something appropriate to the task at hand, and implementable in a reasonable time-frame. That other browsers have found it useful, and implemented it alongside their SVG implementations is a good thing, no?
Shouldn't we warn the UN or Amnesty since MS must have obviously tortured Molly to give such a statement?
Olav:
The <canvas> element is not intended to replace SVG. It's intended to be used in situations where a direct drawing API is faster to work with than manipulating the DOM. So <canvas> is really intended for situations where you need performance over features. Furthermore, new rendering contexts can be added to <canvas> to extend its capabilities. Opera and Mozilla are already working on a 3D context based on OpenGL ES.
Another issue is how much time it takes to implement <canvas> versus SVG. You will notice that <canvas> has been implemented for Safari, Opera, Mozilla, and even IE (with the use of DHTML and VML). By contrast, name one browser vendor who has natively implemented all of SVG. This is not to say that <canvas> is better than SVG. It's simply that it may not be optimal for situations where graphics needs are more modest and where issues such as performance and time to market are critical.
It's probably not very clear because when HTML5 is brought up in conversation or on blogs, it's most often for the purpose of talking about a new thing rather than talking about how something already existing is improved. On top of that, people's mentality is already set for the "new standard version means new functionality" since the older versions were all about new functionality each time. So HTML5 people should probably start focusing more on what's being fixed.
You know, I'm still not at all sold on microformats when XHTML+namespaces does it all perfectly well (hCard versus XML-vCard?) I've not (yet) looked at how HTML5 tackles microformats, though.
One nitpick with section 3 of the draft, though: in section 3.2.8, it states “Return the first element of type type that has an id or name attribute whose value case-insensitively matches s.”. What order of precedence is employed in the case where both name and id are used? Is it simply “whichever one comes first in the document”?
Yes, whichever comes first in the document.
So 90% of HTML5 is about fixing the web?
This is in fact quite slogan-ish rhetoric. A little empty.
What HTML5 really does is just 3 things. It
Clarifiying can be defined as «fixing». No doubt about that.
Removing redundant attributes - e.g. presentational ones, would that be fixing? It is a very logical cleaning up, yes. But what does it fix? The whole matter - the specs - becomes much more managable this way. But I don't see what it fixes. It is a quite neutral and natural thing - one should not expect many protetst - because it is in line with common sense and actually in the spirit of HTML4.
The removal of attributes and features which do not have a natural replacement, is another matter, and seems like the opposite of fixing: To remove accessibilty attributes, such as the longdesc, summary, headers and so on, is not fixing.
At minimum 33% of the none-presentational attributes which are proposed to be removed, are accessibilty attributes. Better accessibility was one of the achievments of HTML4. And their removal is not in line with HTML4.
Removing attributes is just part of language design and does not have anything to do with browser interoperability which is what everyone cares about in the end. (Browsers will still be required to support all those presentational attributes.)