Slashdot Mirror

Oh, I'm not saying that Silverlight is great. As AKAImBatman would point out, before you implement Silverlight, you should really read the WHATWG specs, which are being developed in a truly open process, vs. Silverlight and Moonlight, which are nothing more than implementations of some spec developed for some proprietary crap.

Editor of HTML5 conducted large scale (Google-scale) study of pages and concluded that 93% pages on the net contain syntax errors.

You can't tell browser vendors to stop displaying 93% pages on the web. Creating a new XML-only language won't make it go away either. In fact, W3C already tried that and it failed.

So these "idiots" have already done what you're fuming about, learned that it will not work, and already found a new way of solving this problem. HTML5 defines, in gory details, how to parse tag soup, so every browser can read it the same way.

XHTML V2 and related modules are officially supported by the W3C, and the related modules are becoming key ingredients for other XML specifications that the W3C maintains. Unfortunately, official W3C approval is no guarantee of support by major Web browsers.

It wouldn't be the first time browser vendors were ahead of official recommendations.

The FAQ doesn't even try to give a serious answer about the expected date of approval

Current browsers support both HTML V4 and XHTML V1.

Similarly, future browsers might support both HTML V5 and XHTML V2.

• Safari: For a long time, the HTML standards process has been moribund; the W3C's HTML Working Group has focused almost exclusively on XHTML2, a new standard that was highly incompatible with existing practice. The people working on the major browsers have largely abandoned the HTML Working Group.
• Opera: So, I don't think XHTML is a realistic option for the masses. HTML5 is it.
• Mozilla: In the near term, only Mozilla-based browsers come close to having all the integrated infrastructure needed by XHTML 2, and not all bundled by default. There is no sign of XHTML 2 support from Microsoft, Apple, and Opera.

MPEG is commercial and contains patents

MPEG is the name of a working group. Some of the formats they have standardised contain patented technology. It's not accurate to say "MPEG contains patents".

so has the same issue as including any other patented technology

In Hickson explained Apple's situation quite well:

Certain companies (Nokia and Apple among them) have reported that they still fear that undisclosed patents may exist that cover the relevant codecs, as they might exist for other formats like MPEG4/H.264. The difference is that while Apple (for example) have already assumed the risk of submarine patents with H.264, they currently have taken no risks with respect to the aforementioned codecs, and they do not wish to take on that risk. Given the extremely large sums of money that are awarded for patent violations (cf. Microsoft's recent settlements), it is understandable that companies with the high profile of Apple and Nokia would not wish to take on such risks.

While many codecs are patent-encumbered, it doesn't necessarily follow that it is equally risky to implement them for any particular organisation.

HTML doesn't want to use patented tech

HTML hates anthropomorphism.

Nobody is saying that the HTML 5 specification should recommend a patented codec. They are saying that it shouldn't recommend any particular codec.

gif was free until UNISYS bought Compuserv and started enforcing Lev-Zempel and jpeg was free until a patent troll bought a related patent.

No, they were always patent-encumbered, it's just that people didn't know about it until UNISYS started cracking down on infringers.

I can see Apple wanting to fight ogg-vorbis, as they have a heavy investment in AAC and Quicktime and I'm sure they would rather see that tech in.

I'm sure they would, but this isn't about picking Quicktime over Ogg. You can't win this argument by saying how bad Quicktime, MPEG or anything else might be, because the alternative people are proposing is no recommendation, not a recommendation for competing formats.

Just to point out what it currently happening, here is the mail from Ian Hickson from this morning:

"I've temporarily removed the requirements on video codecs from the HTML5
spec, since the current text isn't helping us come to a useful
interoperable conclusion. When a codec is found that is mutually
acceptable to all major parties I will update the spec to require that
instead and then reply to all the pending feedback on video codecs.

    http://www.whatwg.org/issues/#graphics-video-codec
"

The title of the news is a bit misleading :) In other words "temporarily removed until a consensus has been found".

I especially like the "module" concept

Seeing as you seem to be involved with the HTML 5 proposal, could you explain this line from the FAQ to me:

When will HTML 5 be finished?
It is estimated that HTML5 will reach a W3C recommendation in the year 2022 or later. This will be approximately 18-20 years of development, since beginning in mid-2004.

http://wiki.whatwg.org/wiki/FAQ#When_will_HTML_5_be_finished.3F

That seems like a really long time for something like this to go through, even for something as massive as the web standard.

EA already has a combination Java/Javascript version of the game online here: http://simcity.ea.com/play/simcity_classic.php

The game lends itself well to semi-fixed graphics that update on a slower basis. So making the jump from Java/Javascript to 100% DHTML would be far less of a jump than going from the original code to Python.

And don't worry about the saved games. It would be a perfect opportunity to put the Storage API (implemented in recent FireFox and SeaMonkey builds) to good use:

http://www.whatwg.org/specs/web-apps/current-work/#storage

Downloading and installing a plug-in ahead of time is a surprisingly heavy burden for users, so for now there's still a significant barrier. A lot of what Google Gears provides really ought to be standardized and built into the browser imho.

WHATWG's HTML5 working draft includes a specification for a client-side SQL database. Webkit's feature branch already has it implemented, and it works a lot like the local-storage part of Google Gears.

I'm hoping that once that bit of HTML5 gets finalized and built into mainstream browsers, a lot more web apps will be built to automatically fall back to cached local data when they can't reach their servers.

But that's likely to take a while, and at least for now there's a simple HTML5-GoogleGears bridge for people who want to write their local storage code for HTML5 and have it work on most platforms and browsers, even if it requires a plug-in.

Data storage is not a new concept; it's part of the HTML5 specification (a.k.a. Web Apps 1.0) [Note: that URL seems to have some script issues...] and it is already implemented in the recent WebKit nightly builds.

1. mozilla.org is adding "content handling" which should ddress this http://wiki.mozilla.org/Firefox3/Product_Requirements_Document#Content_handling
2. webrunner solves this, http://wiki.mozilla.org/WebRunner
3. googlegears, http://gears.google.com/ or whatwg's offline support http://www.whatwg.org/specs/web-apps/current-work/#offline will provide some stuff for this. there's also some discussion on whatwg of adding general local file apis (although i think it's generally assumed to be for reading/importing, not for storage/exporting, but i haven't checked carefully)
4. this is mostly a function of 3. as it happens, in theory for very large attachments the reverse is also true, if you get lots of large attachments you don't want, you have to wait for them to download before you can get your mail, whereas a good web mail client can incrementally transfer attachment content (see gmail integration w/ docs.google)

5. you clearly trust your ISP, its neighbors, etc.
6. hrm, you must have found a really good email client, which one? most of the real clients I've found have bad UE in various areas. Certainly I can easily name problems w/ Outlook, Outlook Express, Eudora (classic), Mail.app, Evolution, M2. If your client isn't one of these, find me, and let me try it. I have a mailbox I haven't been able to open for a couple of years (it's literally too big, the UE for any client that fails to open this is well,... generally not impressive... that's my executive summary :). Oh, Thunderbird/Eudora/SeaMonkey, I used SeaMonkey until it stopped being able to open the mailbox, I can certainly come up w/ UE gaps for them if necessary (although I haven't used Eudora yet).

Opera supports Server Sent Events.

In browsers that support the HTML 5 audio element this will be possible.

I concur.

Repititon allows you to repeat elements

There don't seem to be any; a <date> and <time> would be nice, at least.

<td/>'s content model: Zero or more block-level elements, or inline-level content (but not both).

I like this bit.

That's up to you.

I concur.

Repititon allows you to repeat elements

There don't seem to be any; a <date> and <time> would be nice, at least.

<td/>'s content model: Zero or more block-level elements, or inline-level content (but not both).

I like this bit.

That's up to you.

I concur.

Repititon allows you to repeat elements

There don't seem to be any; a <date> and <time> would be nice, at least.

<td/>'s content model: Zero or more block-level elements, or inline-level content (but not both).

I like this bit.

That's up to you.

I concur.

Repititon allows you to repeat elements

There don't seem to be any; a <date> and <time> would be nice, at least.

<td/>'s content model: Zero or more block-level elements, or inline-level content (but not both).

I like this bit.

That's up to you.

It sucks as a markup language in that it lacks hardly any description of data at all.

It doesn't work very well for layout--hence the cell based table design hacks that used images (IMAGES!!!) to set table heights an widths.

HTML's built in form objects have not been improved upon since its inception!

Could we not get at least some validation of data that is built in!?! Opposed to using a myriad of Javascript code?

It sucks as a markup language in that it lacks hardly any description of data at all.

It doesn't work very well for layout--hence the cell based table design hacks that used images (IMAGES!!!) to set table heights an widths.

HTML's built in form objects have not been improved upon since its inception!

Could we not get at least some validation of data that is built in!?! Opposed to using a myriad of Javascript code?

Content and presentation have been slowly merging over the course of the web. Adding these semantic tags appears to be an attempt to separate the presentation from the content.

Do you have any evidence to back up this sweeping statement? In my opinion this was the case from the early days of the web, through the original browser wars and for a period afterwards (until maybe '01-02) at which point people started realising that contaminating the markup with presentational cruft was a good way to create maintainability nightmares, and made major redesigns of medium to large sites a frustrating and time-consuming (thus costly) process.

The trouble is that nobody will add the new tags until a majority of browsers support HTML5. And nobody will be interested in upgrading until the major sites require it (or until the format is slowly merged in during users normal upgrade schedules).

This is, of course, very true (and I forsee Internet Explorer lagging behind the other 'major' browser vendors), however this can be said about any new web specifications (the XHTML 1.0 spec was released as a recommendation in January 2000, and IE doesn't support it in any way, shape or form*).

Add that to the fact that the current generation of browsers don't agree on implementations within HTML4, and I suspect that this will not really help us web developers.

Nowadays, the commonly used browsers (>IE6, Gecko based browsers, Konq, Safari, Opera) all implement a large subset of the HTML 4 spec, although you are right that there are some presentational issues (mostly due to the fact that the spec is vague in places) these can be eliminated with a judicious application of CSS rules.

Personally i'm glad that the w3 have taken the helm wrt the HTML5 spec - I had major problems with the direction that WHATWG were going with it. A specific example is their introduction of the presentational font element; their note that it should only be used by WYSIWIG tools and to be syntactically valid said tool must add a special meta element is laughably nieve. As the font element has no semantic meaning and no benefit over the equally semantically meaningless span element with a suitable styling via CSS - sure you could argue it offers backwards compatibility with legacy documents, however I would assume that a document that is not syntactically valid HTML4 would need major work to be cleaned up to be valid HTML5 anyway (plus, that would be disobeying the spirit of the spec, being as such content would not be generated by a WYSIWIG editor).

Another worry is that they're integrating DOM stuff into the same spec, although it does make sense in some ways it seems like there is the distinct potential of losing focus by covering too diverse a set of problems. However, it is still early days yet and I will withhold judgement until we start seeing near-finalised drafts and browsers start implementing some of the new features.

* However, it can (mostly) deal with it if you (incorrectly, IMO, despite appendix C) send the mime-type as text/html and skip the XML prologue by parsing it as 'tag soup'.

Just use XHTML5

http://www.whatwg.org/specs/web-apps/current-work/ #html-vs
http://blog.whatwg.org/faq/#html-namespaces

Just use XHTML5

http://www.whatwg.org/specs/web-apps/current-work/ #html-vs
http://blog.whatwg.org/faq/#html-namespaces

HTML 5 currently says

User agents may support any audio codecs and container formats. User agents must support the WAVE container format with audio encoded using the PCM format.

(Bit-rate, bit-depth and number of channels (and maybe other aspects?) are undefined - I assume the specification may end up adding some restrictions on what support is required, depending on what implementors suggest.)

3.9.4. The dialog element

Block-level element.

Contexts in which this element may be used:
        Where block-level elements are expected.
Content model:
        Zero or more pairs of dt and dd elements.
Element-specific attributes:
        None.
DOM interface:
        No difference from HTMLElement.

The dialog element represents a conversation.

Each part of the conversation must have an explicit talker (or speaker) given by a dt element, and a discourse (or quote) given by a dd element.

This example demonstrates this using an extract from Abbot and Costello's famous sketch, Who's on first:

<dialog>
  <dt> Costello
  <dd> Look, you gotta first baseman?
  <dt> Abbott
  <dd> Certainly.
  <dt> Costello
  <dd> Who's playing first?
  <dt> Abbott
  <dd> That's right.
  <dt> Costello
  <dd> When you pay off the first baseman every month, who gets the money?
  <dt> Abbott
  <dd> Every dollar of it.
</dialog>

Text in a dt element in a dialog element is implicitly the source of the text given in the following dd element, and the contents of the dd element are implicitly a quote from that speaker. There is thus no need to include cite, q, or blockquote elements in this markup. Indeed, a q element inside a dd element in a conversation would actually imply the person talking were themselves quoting someone else. See the cite, q, and blockquote elements for other ways to cite or quote.

For the text, email, url, date-related, time-related, and numeric types of the input element, a new attribute list is introduced to point to a list of values that the UA should offer to the user in addition to allowing the user to pick an arbitrary value.

The min and max attributes apply to file upload controls (input elements of type file) and specify (using non-negative integers) how many files must be attached for the control to be valid.

Yes. Kind of.

There are currently to Working Groups in the W3C working on markup -- the XHTML working group, and the HTML working group. These are separate entities with separate memberships and separate processes.

XHTML was originally intended to be the successor to HTML. But a couple of things that happened after XHTML1 "shipped" caused that to be re-evaluated:

• The whole point of XHTML was that moving to XML syntax would open up new possibilities for user-agents: not just browsers (whose lives would be simplified by not having to deal with "tag soup" anymore"), but applications that would take advantage of already knowing XML to do cool stuff with the web. Only that never really happened; and because Microsoft wasn't on board, browser vendors still had to parse the "tag soup" anyway.
• The XHTML Working Group went off the deep end and announced that XHTML2 would handle errors the way XML parsers are supposed to: by shutting down and throwing up an "Non-conforming document" error. Needless to say, this is not how the Web works today, and it threw a scare into millions of Web publishers who incorporate third-party content that they have no control over (like, say, ads) in their sites. They also proposed major changes to the syntax of XHTML2 versus XHTML1 to clean it up and make it more logical; which sounds great until you realize that now you have to teach those millions of web publishers a whole new syntax or their sites break.

When it became clear that continuing down the XHTML path promised tons of heartburn for publishers and user-agent developers without much reward in return, people started thinking that maybe rebooting the HTML specification process wouldn't be such a bad thing. The W3C picked up the WHATWG's independent "HTML5" spec as a starting point, and that's where we are today: XHTML is for people who are comfortable with radical changes between versions of the spec and Draconian error processing; HTML is for people who want backwards compatibility and less strict parsing.

Yes. Kind of.

There are currently to Working Groups in the W3C working on markup -- the XHTML working group, and the HTML working group. These are separate entities with separate memberships and separate processes.

XHTML was originally intended to be the successor to HTML. But a couple of things that happened after XHTML1 "shipped" caused that to be re-evaluated:

• The whole point of XHTML was that moving to XML syntax would open up new possibilities for user-agents: not just browsers (whose lives would be simplified by not having to deal with "tag soup" anymore"), but applications that would take advantage of already knowing XML to do cool stuff with the web. Only that never really happened; and because Microsoft wasn't on board, browser vendors still had to parse the "tag soup" anyway.
• The XHTML Working Group went off the deep end and announced that XHTML2 would handle errors the way XML parsers are supposed to: by shutting down and throwing up an "Non-conforming document" error. Needless to say, this is not how the Web works today, and it threw a scare into millions of Web publishers who incorporate third-party content that they have no control over (like, say, ads) in their sites. They also proposed major changes to the syntax of XHTML2 versus XHTML1 to clean it up and make it more logical; which sounds great until you realize that now you have to teach those millions of web publishers a whole new syntax or their sites break.

When it became clear that continuing down the XHTML path promised tons of heartburn for publishers and user-agent developers without much reward in return, people started thinking that maybe rebooting the HTML specification process wouldn't be such a bad thing. The W3C picked up the WHATWG's independent "HTML5" spec as a starting point, and that's where we are today: XHTML is for people who are comfortable with radical changes between versions of the spec and Draconian error processing; HTML is for people who want backwards compatibility and less strict parsing.

Here's a link to the latest HTML 5 working draft (published today) for those who like their information first-hand.

http://www.whatwg.org/specs/web-apps/current-work/ multipage/section-parsing.html#parsing

Indeed, but web sites using deprecated features do not get updated and do not go away, so web browsers continue supporting those features forever, and almost nothing has ever been "phased out" in practice. (Browsers also have to continue supporting features that were never specified or documented at all – e.g. the front page of IMDB accidentally uses <image>, which still gets treated like <img> because nobody wants to write a browser that doesn't work with such sites). Since all the browsers implement those things, and any other HTML consumer ought to work the same if it's going to work as well as possible on the web, HTML5 does specify how things like plaintext are handled, and so it should continue to be supported correctly in the future.

It's still true that deprecated features are usually bad ideas and it's strongly suggested to not use them, and plaintext seems like a particularly bad idea, but the danger of them being phased out and no longer implemented is quite small.

There was some discussion about that on the WHATWG list here that may be interesting. (The list is open for anyone to subscribe and post to, if you have points to add to the discussion about this or other features.)

HTML 5.0 = HTML 4 with some new sugar + XHTML parser strictness.

That is incorrect: the HTML5 parsing algorithm never just stops and returns an error message (like in XML) - it specifies how every single stream of bytes is parsed into a DOM, with error-correction where necessary, in a way that tries hard to be compatible with the ~10^11 existing HTML pages on the web (which, in most cases, means being compatible with the behaviour of IE6).

Almost all the content on the web today is invalid HTML, and it's never going to go away, which is why the browser developers have been pushing for a specification that describes how to handle invalid content instead of pretending it's not important.

Who modded this informative? Suv4x4 is incorrect. The W3C came up with their HTML5 standard by taking a dump of the WHATWG HTML5 standard and putting the W3C colors on it. Which isn't surprising as most of the WHATWG members are also W3C members. It was always their intention to make their standard more "legitimate" by submitting it to the W3C once it was ready.

Don't believe me? Here are the two standards. Compare:

WHATWG HTML5
W3C HTML5

Save for some slight divergences as the WHATWG's standard is updated, they're exactly the same.

Or are the W3C just trying to justify their existence?

HTML 5 is also 'XHTML 5'. You can use well-formed XHTML style syntax, and deliver it with an application/xml or application/xhtml+xml mimetype, *or* you can format it HTML style and deliver it with a standard HTML mimetype.

http://blog.whatwg.org/html-vs-xhtml

No need, browsers are starting to incorporate the 'video' element.
http://www.whatwg.org/specs/web-apps/current-work/ #video
Play back will be built in to the browser (actually decoding will be delegated) which means no need to any stupid plugin just to play video. In addition you will most likely be able to take advantage of efficient external codec libraries and not have to endure the terrible decoding provided, for example, by Flash. It will also be much easier to play video in an external player of your choice. No more wacky 'hacks' in Firefox extensions needed to do this (ibid for saving the video).

We won't have to deal with this silly Flash-for-video crap much longer.

Email from Apple Senior Patent Counsel to WHATWG group:

Dear WHATWG and Mr. Hickson,

Apple Computer, Inc. ("Apple") believes it has intellectual property rights ("IP Rights") relative to WHATWG's Web Applications 1.0 Working Draft, dated March 24, 2005, Section 10.1, entitled "Graphics: The bitmap canvas". At this time, Apple reserves all rights in its IP Rights and makes no representations as to Apple's willingness or unwillingness to license these IP Rights. However, in the event that the Web Applications 1.0 Working Draft, dated March 24, 2005, becomes part of a formalized draft standard at W3C or IETF, for example, Apple is prepared to address the disclosure/licensing rules of such organizations.

Any questions regarding this communication should be directed to:

Director of Patents
Apple Computer, Inc.
1 Infinite Loop, MS 3-PAT
Cupertino, CA 95014-2084
Voice: (408) 974-9453
Fax: (408) 974-5436
E-mail: iplaw at apple.com

Sincerely,

Helene Plotka Workman
Senior Patent Counsel, Apple Computer, Inc.

The other browsers have been copying IE's behavior and bugs for several years now. The problem is that they can only do this by investing considerable time in reverse-engineering, because unlike the actual standards the behavior of IE is not documented outside of Microsoft and is liable to change from version to version.

However, WHATWG (now working alongside the W3C HTML WG) is currently working on writing a new version of the HTML specification that, as well as adding some new features, also includes a vastly more detailed description of what browsers must implement. The description of browser behavior is largely based on what Internet Explorer does, though that's by no means the rule. Their goal, as far as I can tell, is to write down the rules for rendering the content that's out on the web today, which includes lots of buggy crap that works okay in IE by mere coincidence.

The API is reminiscent of the WHATWG Storage Specification

The Database module is also reminiscent of the HTML5 Client-side database storage, which was added to the spec about a week ago. (Hmm, coincidence?)

The spec is currently very under-defined, but the intent is that some implementations (at least Firefox) will ship with it implemented using SQLite, and then people will start using it, so SQLite's dialect of SQL will become the de facto standard and everyone else has to implement it the same and then that will be specced.

Google Gears is using SQLite too, and the API is pretty similar, so it would be an interesting way to implement the HTML5 executeSql in older browsers.

So it looks like this is a browser plugin. Meaning that you'd need to install it with your web application. The API is reminiscent of the WHATWG Storage Specification, but appears to be a bit more sophisticated in its reach. If I'm reading this right, the biggest difference is auto-syncing of the data with a server (when you're online) rather than having to write your own synching software.

Thus this appears to be a competitor to Adobe Apollo, but without Google defining their own container format.

Interesting. I'm not quite sure what to make of it as it's not anything that hasn't been contemplated before. Personally, I'm hesitent to adopt anything that can't be used on a live webpage as well as downloadable "webapps". However, that may not stop others who have good ideas on how this might be used.

Apple asserts patents on the canvas tag, interestingly directly mirroring the concerns Microsoft IE developers expressed about WHATWG all along. So don't expect the canvas tag in IE ever.

In what way are other browsers, like Firefox, Safari, and Opera 'ignoring' another standard by implimenting canvas support? Canvas support is a widely support standard, Firefox, Safari and Opera both impliment it, Microsoft have something *similar* but of course it's not the same.

This is pretty typical, and a situation that arises a lot even when it's with a W3C standard - things like the ECMA script standard leave specifics untermined, and the other major browser developers have implimented complimentary systems, but Microsoft almost always does it's own thing.

Usually their implimentation has ultimately the same functionality, but it's typically more verbose to impliment and requires special if (browserIs.IE) { } kludges (and in the case of more complex apps, libraries to abstract the functions).

Umm, Firefox 3 will be using Cairo, but I have no idea where the "fully based on Vectors" comes from. (Also, Firefox 1.5.x is Gecko 1.8.0; Firefox 2.x is Gecko 1.8.1)

If there's native support for OpenID, I haven't seen it yet :)

And in the improving-the-web direction, you basically want to look at WHATWG anyway - at least Mozilla, Opera, and Apple are behind it, so even if IE isn't there the other major desktop players are. And the new-ish HTML WG at W3C...

To be honest I didn't read the spec (yet) but it appears the page is following HTML 4.01 strict but the doctype is incorrectly specified.

Well read the spec then. That's the HTML 5 doctype. The only reason they use a doctype at all is because otherwise it would trigger quirks mode.

I'm guessing mostly for mobile users. [if you've read TFA, you this won't be anything new] For example, imagine a calendar application - you could add an event to your calendar locally while you're offline (can't get a signal, don't have mobile internet, whatever), which I presume would be stored using DOM storage, then when you reconnect, it would synchronize with the calendar server. The other thing is that resources such as images, scripts, etc. can be marked for offline usage. I imagine if you're online, it will download a new version of the resource as usual, but if not, it will use the last version it had.