Slashdot Mirror

I will forsake my moderations done so far in this article to respond to this. There are multiple patents in the patent pools covering HTML, XML, CSS, JavaScript and similar open standards. The main difference is that W3C licenses its patents royalty free. See for example: http://www.w3.org/Consortium/Patent-Policy/ and http://www.w3.org/2001/05/23/SMIL-IPR-statements

(OT why do I have to use <em> tags instead of <i> tags?)

I am not sure why slashdot is enforcing the deprecation of <i> when I do not think it is deprecated by the W3C. I just found this interesting wiki which discusses the situations where <i> should be used. It encourages users to consider whether <em> or <dfn> would be more appropriate. The second one was interesting and new to me: it is used for a page's defining instance of a term. So, italics are used for at least two semantically-distinct purposes: stress emphasis and term definition. Instead of having one tag fulfill both roles, they have separated them out.

I can see this being useful for translation and automatic processing. If you were making an index or glossary, for instance, you would be interested in <dfn> but not <em>. On the other hand, if you were feeding the document into a speech synthesizer, perhaps for the deaf, you might have the computer's voice stress the <em>s but speak the <dfn>s normally.

But of course, this is the argument for the tags in HTML, not on slashdot: in my first paragraph, "stress emphasis" and "term definition" are both surrounded by <dfn> tags, but they are not rendered that way. Perhaps this will be implemented at the same time as unicode support.

(OT why do I have to use <em> tags instead of <i> tags?)

I am not sure why slashdot is enforcing the deprecation of <i> when I do not think it is deprecated by the W3C. I just found this interesting wiki which discusses the situations where <i> should be used. It encourages users to consider whether <em> or <dfn> would be more appropriate. The second one was interesting and new to me: it is used for a page's defining instance of a term. So, italics are used for at least two semantically-distinct purposes: stress emphasis and term definition. Instead of having one tag fulfill both roles, they have separated them out.

I can see this being useful for translation and automatic processing. If you were making an index or glossary, for instance, you would be interested in <dfn> but not <em>. On the other hand, if you were feeding the document into a speech synthesizer, perhaps for the deaf, you might have the computer's voice stress the <em>s but speak the <dfn>s normally.

But of course, this is the argument for the tags in HTML, not on slashdot: in my first paragraph, "stress emphasis" and "term definition" are both surrounded by <dfn> tags, but they are not rendered that way. Perhaps this will be implemented at the same time as unicode support.

No. Unconstrained user input will be. If you're not already checking the user input before passing it along, you're a fucking idiot and this bug is the LEAST of your worries.

There are a few niche cases, like calculators and spreadsheets, where the constrained input could validly include the input. The assertion in comments to the article that quality values in HTTP headers cause this problem do not come into this category, as the standard says that only three digits after the decimal should be sent.

Thanks for the info, though you could have been nicer about it. We're here to find the truth, and no-one is the font of knowledge on everything. I hope people have found my other points helpful.

Mobile Safari would rely on HTML5 to access the microphone and the camera. Can anyone provide a summary of the extent to which this is currently implemented, and the extent to which a website would be able do what a native app can? It looks like HTML5 has some deficiencies compared to Flash and Silverlight, both for reading and playback.

Mobile Safari supports the W3C Geolocation API, and support for the DeviceOrientation API was added in the recently-released iOS 4.2 update. Standard support is good news.

There is some commonality between JavaScript touch support on Android and iOS, I hope this can be standardized.

Perhaps there's a chance for the Web to fight back against native apps.

Thanks for the info, though you could have been nicer about it. We're here to find the truth, and no-one is the font of knowledge on everything. I hope people have found my other points helpful.

Mobile Safari would rely on HTML5 to access the microphone and the camera. Can anyone provide a summary of the extent to which this is currently implemented, and the extent to which a website would be able do what a native app can? It looks like HTML5 has some deficiencies compared to Flash and Silverlight, both for reading and playback.

Mobile Safari supports the W3C Geolocation API, and support for the DeviceOrientation API was added in the recently-released iOS 4.2 update. Standard support is good news.

There is some commonality between JavaScript touch support on Android and iOS, I hope this can be standardized.

Perhaps there's a chance for the Web to fight back against native apps.

So, tell me again why you would pay for that instead of just making a web page

Because popular web browsers' CSS engines still have crap support for paged media, or at least they have such a reputation.

http://www.w3.org/TR/html5/offline.html
http://diveintohtml5.org/offline.html

To be fair, Google has done that (in a much bigger way) for IE.

Except that there's a critical difference between the two plugins. Chrome Frame was an attempt to bring standards-compliant CSS and fast Javascript to websites that still have IE6 users. Even if it became ubiquitous, it would only relieve Web developers from having to support IE's broken rendering engine. On the other hand, Microsoft's plugin exists to shift the de-facto meaning of the <video> element in the HTML5 draft to support only the H.264 format instead of WebM. Microsoft's plugin is insidious if you care about the freedom to implement Web browsers and tools.

The underlying question is, should a company or open-source project be able to implement a Web browser from scratch without having to purchase patent licenses? The academics at the W3C think the answer is emphatically yes. This goes back to the beginning, when Tim Berners-Lee and CERN decided not to demand royalties for HTTP and HTML. But commercial OS vendors such as Microsoft and Apple would prefer <video>s in H.264, since forcing H.264 would give their OSes an advantage over open-source OSes and other underdogs that can't afford the licenses.

H.264 is the standard. Browsers should play it.

Yeah, you're right: the W3C says video elements should be H.264. Oh, wait, no it doesn't.

You mean a "Host:" header right? I believe that's actually optional too.

Ah yes, you're right, it is the Host field, although it is not optional, it is mandatory (from http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html Section 14.23)

A client MUST include a Host header field in all HTTP/1.1 request messages . If the requested URI does not include an Internet host name for the service being requested, then the Host header field MUST be given with an empty value. An HTTP/1.1 proxy MUST ensure that any request message it forwards does contain an appropriate Host header field that identifies the service being requested by the proxy. All Internet-based HTTP/1.1 servers MUST respond with a 400 (Bad Request) status code to any HTTP/1.1 request message which lacks a Host header field.

Yes, it is a requirement. When you serve xhtml with content type text/html, you're simply exploiting a bug in browsers that makes them ignore xhtml constructs that aren't legal html.

Perhaps you should reread what I said. I said it wasn't required for supporting xhtml *syntax*. This is a very important distinction that you completely ignored.

[...] or mathml syntax for that matter.

Mathml is not a separate syntax.

Yes, it is. Note section 2.4 of the MathML specification titled "MathML Syntax and Grammar"

The rest of your comments show even more ignorance of the issues surrounding changing the parsing engine of a browser. I mean, if you can't even get something as simple as MathML having a syntax... there's no hope for you.

Hah yeah except for the huge stupid hack you have to use for IE ;-)

http://www.w3.org/MarkUp/2004/xhtml-faq#ie

Not long ago (within the past year) I've seen people *strongly* recommend targeting HTML 4.01, the most widely set of tags currently supported.

XHTML never really seemed to live up to the hype for me. Sure, it's easier to parse XHTML than HTML. But who cares? You should not be parsing web pages, it's the road to madness ;-) Always look for an API or a feed first.

Last I checked, anyone could submit ideas, corrections, feature requests *RIGHT THERE ON THE HTML5 WORKING DRAFT*. "Feedback Comments" right at the top of http://www.w3.org/TR/html5/

Now, if they ignore your idea, that's almost certainly because it sucks and is badly written. No really, it does suck. Follow the instructions there *carefully*, really think about this feature or tag or whatever you're requesting, and your ideas will get consideration.

You don't have to nitpick because you are wrong.

Browsers do have a quirks mode, but it's not really based on HTML version. It's based on a heuristic, which buckets some HTML4 doctypes into quirks mode and others into standards mode.

Browsers also have no plans to add any more mode switches (except for MSIE, of course), so adding more versioning information isn't exactly useful in that regard.

> Let's hear them.

I was going to summarize, but just found the link to the original post that sums up the argument. See http://lists.w3.org/Archives/Public/public-html/2007Apr/0279.html

Note that that's where we are right now with IE; IE8 ships with at least two different layout engines (like separate codebases, last I checked) to handle "IE5" mode and "IE7" mode. And the new "IE8 standards" mode it has is implemented as a set of changes to the IE7 engine, I _think_.

Now Microsoft is OK with this: they have near-unlimited manpower (e.g. for IE9 their JS team is about 25% of the number of total engineers working at Mozilla) and don't have to worry about download size or size of testing matrix (thousands of test systems available easily) or silly things like that.

But forcing this sort of complexity on new market entrants will just entrench the existing players and be bad for the web. We _want_ people to create new web browsers!

Generally, having two different standards for doing the same thing on the web is bad for the web. It leads to UA bloat, author confusion, more complexity in the web platform, and more potential for UA bugs.

In the case of SVG fonts, there is the further issue that as specified in full they're not really compatible with HTML, and as implemented in some UAs just to pass ACID3 they're not at all per spec. So all the spec + test there are managing to do is encourage broken implementations.

Robert O'Callahan has described most of the issues here, I think, over the course of a bunch of posts to www-svg@w3.org (archived at http://lists.w3.org/Archives/Public/www-svg/ ) but I'm not sure anyone has collected them up into a single document (which would be long and somewhat technical, since the issues are fundamentally technical incompatibilities between how HTML rendering works and what SVG fonts require if you try to implement them as specified).... I agree that it would be nice if someone had time to do said collecting, but I doubt the result would be all that useful to someone who is not pretty familiar with SVG fonts already.

So, basically, what you are saying here, is that HTML5 isn't done yet?

Mozilla has image-rendering: -moz-crisp-edges;
IE has -ms-interpolation-mode: nearest-neighbor;
Chrome has an open bug about it and it's in discussion on the w3 mailing list
How come Opera isn't an early implementer of this?

Minor nitpick: WorldWideWeb.app, by Tim Berners-Lee himself, was the first GUI web browser.

Google can't serve you ads if you're not online.

Of course it can. It can download the advertisements to localStorage whenever you sync your data between your device and the Internet.

So, it's a dumb-terminal that requires me to have constant access to the internet, can't store files, can't have actual programs installed on it.

Please catch up. It is not what you think.

It's not a dumb terminal, it doesn't require you to have constant access to the Internet (some apps require it, others don't), it can store data locally, and you can install programs. They're registered in the cloud, and if you log in and one is missing, it's quickly synchronized to the local device.

http://www.w3.org/TR/html5/offline.html
http://dev.w3.org/html5/webstorage/
http://www.html5rocks.com/tutorials/offline/storage/
http://code.google.com/chrome/apps/

Understanding the significance of ChromeOS requires that you abandon some old ways of thinking about how a computer should act. Yes, you're "losing" the desktop and the file folders. You're also losing slow boot times, viruses, the risk of losing your data in hard drive crashes or device theft, and the occasional maddening discovery that you left a critically important file on a hard drive at home|school|work.

This may not be the device for you, but it may be the device for a lot of people. It's worth pointing out that over half a million people buy smartphones every day that also walk away from a mountain of desktop-computer annoyances.

So, it's a dumb-terminal that requires me to have constant access to the internet, can't store files, can't have actual programs installed on it.

Please catch up. It is not what you think.

It's not a dumb terminal, it doesn't require you to have constant access to the Internet (some apps require it, others don't), it can store data locally, and you can install programs. They're registered in the cloud, and if you log in and one is missing, it's quickly synchronized to the local device.

http://www.w3.org/TR/html5/offline.html
http://dev.w3.org/html5/webstorage/
http://www.html5rocks.com/tutorials/offline/storage/
http://code.google.com/chrome/apps/

Understanding the significance of ChromeOS requires that you abandon some old ways of thinking about how a computer should act. Yes, you're "losing" the desktop and the file folders. You're also losing slow boot times, viruses, the risk of losing your data in hard drive crashes or device theft, and the occasional maddening discovery that you left a critically important file on a hard drive at home|school|work.

This may not be the device for you, but it may be the device for a lot of people. It's worth pointing out that over half a million people buy smartphones every day that also walk away from a mountain of desktop-computer annoyances.

Safari doesn't block their website so I don't buy it.

But how much localStorage and how much space for files listed in CACHE MANIFEST will Safari allocate for offline use of a web site? Some iPad products lack a cellular radio.

Safari doesn't block their website so I don't buy it.

But how much localStorage and how much space for files listed in CACHE MANIFEST will Safari allocate for offline use of a web site? Some iPad products lack a cellular radio.

Sound? Browser. Movies? Browser. Movies with sound? Browser.

I imagine that the iPad browser won't cache files this large for offline use, even if the web page specifies a CACHE MANIFEST.

Board games? Browser.

More complex graphics made with DHTML or Canvas? It'll likely run as a slideshow. WebGL? Nope.

Programs such as Photoshop or Visual Studio would download every time instead of run immediately?

No they won't necessarily. BTW, yelvington's above link (installable web apps) covers hosted and packages apps... most apps will be hosted (a hosted .crx app only contains icons, metadata, et cetera-- not HTML).

There could be other factors like reduced need for local storage

Chrome OS runs web applications, and web applications that can work offline must make heavy use of CACHE MANIFEST and localStorage, both of which can be big if someone tries to implement photo management (from your Android-powered camera?) as an offline web app.

There could be other factors like reduced need for local storage

Chrome OS runs web applications, and web applications that can work offline must make heavy use of CACHE MANIFEST and localStorage, both of which can be big if someone tries to implement photo management (from your Android-powered camera?) as an offline web app.

The only thing surprising here is that this surprises you. The site is a steaming pile.
That fact that it renders well in *any* browser is a complete fluke.
http://validator.w3.org/check?uri=http://www.ottawacitizen.com/
442 Errors
You can suspect that it was built for and "checked" with Internet Exploder.

gewg_

P3P

The Platform for Privacy Preferences Project (P3P) enables Websites to express their privacy practices in a standard format that can be retrieved automatically and interpreted easily by user agents. P3P user agents will allow users to be informed of site practices (in both machine- and human-readable formats) and to automate decision-making based on these practices when appropriate. Thus users need not read the privacy policies at every site they visit.

RDFa is still around, there are a few sites that still use it, but my Firefox add-ons that would pull semantic data .from RDFa statements embedded in HTML are obsolete and gathering dust. Instead a lot of people put microformats into their HTML, especially hCard, because it's more HTML-like and less verbose. Google's Rich Snippets (starred reviews, etc.) will parse either form of structured data markup, but supposedly 94% of the info they parse is in microformat not RDFa. HTML5/WHATWG has a concept called microdata that seems to allow indicating the scope of microformat information, AIUI using new itemscope and itemprop attributes rather than overloading class attributes. But that seems to have no support for RDFa.

Google could parse a lot more structured data so we could tell them what the hell our web pages are about. I'm convinced the reason they don't do this is the most diligent users of ANY and ALL such techniques will be spammers and SEO bastards. This comment is really is about person:Angelina Jolie body_part:breasts last_updated:today!, despite all its links to cheap inkjet cartridges and online betting.

And FOAF+SSL support in every blog platform (and others).

If the developer opportunities are good, i'm in. Problem is, calling something an App Store doesn't really change things much if you're just giving people access to a web site. Maybe they're going to focus on local apps written in html+css+js?

What you're looking for are called W3C Widgets. W3C Widgets currently run on Opera, and Vodafone, while T-Mobile and the Nokia S60 have have near standard W3C Widget implementations. It looks like Android is working on it, but Apple is doing everything in their power to fight this (all while touting how great HTML5 is).

The Internet is more than just a protocol, but we already have found the next protocol: IPv6

Hyper Text Transfer Protocol, know it? It's what you eat for breakfast every day. Don't change the subject. Not to mention IPv6 will remove your privacy and that is also a violation of your enjoyment of the interwebs.

I believe that it is the Corporations and Government Agencies that are making poor choices for the masses re: The Internet (against our will, I might add). They are the ones we struggle against to win our freedoms of information exchange.

Well, if you read the comment correctly that is the whole problem. If the masses are being driven to the slaughter then you must slaughter them. You hoped to vote the problem out but it's getting worse. Your financial choices are driving a larger portion of wealth to internet monopolies. Unedited, this will continue for 10 years before anyone blinks.

Nope, they must not die. Scaled down versions and detailed technical documentation must be preserved in order to fashion better networks to succeed them. Why throw away research and backup systems?

You're going to scale down Google? NSA? The cat already ate the mouse, his wife, kids, and his pet mousedog. The illusion of web must be destroyed, not the concept of web.

Yeah, no. Hopefully new generations will be able to access their predecessors knowledge and build upon it and their infrastructures a new and better system of idea and culture exchange (wasting less time re-implementing & rebuilding everything required for advancement beyond the current state).

Nope, right now we're looking at the next step, but are impeded by the Corporate Greed and ancient copyright and patent laws our Government's enforce.

Technology has no place in extinction; Old laws, beliefs and socio-political environments maybe, but certainly not technology... One can only re-invent the wheel so many times before realization that it's better to just build upon previous ideas and technological advancements than to invent them all over again.

The sheeple can't hear you until you threaten them with fear. The government and corporations won't respond until you scream bloody murder. Cooperation is merely personal greed. You can't win a war you've lost with technical charts and analysis.

It's like the Matrix, we're powering it with our queries and addiction to information. Me included, right now as I type away on the / and expect love and rewards, I am feeding the beast. The corps and agencies that are growing as a result of this behavior will eventually start eating us, our rights, our independence, our freedoms. Find a way out and I'll support it but you're offering nothing. Fight the power!

...and AA compliance is really not difficult, unless you ignore accessibility until after you've finished designing a site.

So what you're saying is that compliance will be difficult for any site that was designed before the new rules (which will come out in a year or two) go into effect.

You can't ignore what doesn't currently exist, you can only ignore it after it exists.

If any of the sites I run falls under these requirements, they will probably have to come down, since I don't have time to go back and redo everything that has already been done. That means that people who can't currently get to my content still won't be able to, and those who can will lose it. That sounds like a lose-lose situation to me.

WCAG 2.0 has been out for two years. The revision to Section 508 will be based on it. http://www.w3.org/TR/WCAG20/

...but I don't think most businesses (or most people, generally) have anything to object to here. What's likely to make people anxious about changes to the ADA is uncertainty over what those changes will involve.

As a web developer, my main concern is just knowing what I'll have to do or do differently. It would be helpful if articles like this -- or their summaries -- provided links to the proposed guidelines. Personally, I'd prefer to get a head start on this so that my clients and I don't end up rushing to implement changes as the last moment.

Here you go: http://www.w3.org/TR/WCAG20/ WCAG 2.0 is what the upcoming revision to Section 508 is being based on.

Here's the quick ref for WCAG 2.0. I'm helping a client to become conformant. It's a pain just to read through the quick ref. It's a lot more than just alt tags.

Its has only 7 errors... http://validator.w3.org/check?uri=http%3A%2F%2Fwww.websense.com%2Fcontent%2Fthreat-report-2010-introduction.aspx&charset=(detect+automatically)&doctype=HTML5&group=0&user-agent=W3C_Validator%2F1.1

What ever's triggering the video popup (not the decoding) is borked for me. Presents a blank frame. In addition to that is the fact that ASP.NET does a whole lotta this.

To anyone from the Royal Navy in charge of the website: http://validator.w3.org/.

It's only one of the many tools that you will need in order to keep your job. The first step is to throw away your "HTML 3.2 for Dummies" book in the trash and learn to separate content (HTML) from presentation (CSS).

Both sound and client-side data storage are features of HTML5.

I've heard of the HTML5 <audio> element. But as I understand it, it's designed for playing pre-recorded audio, not audio synthesized in real time as would be necessary for an emulator. The only reference that the page linked from "sound" makes to synthesis is in the context of text-to-speech for a textual description track. Even if you generate .wav into a data: URI, I know of no way within this spec to link multiple data: URIs to play gaplessly.

Both sound and client-side data storage are features of HTML5.

I've heard of the HTML5 <audio> element. But as I understand it, it's designed for playing pre-recorded audio, not audio synthesized in real time as would be necessary for an emulator. The only reference that the page linked from "sound" makes to synthesis is in the context of text-to-speech for a textual description track. Even if you generate .wav into a data: URI, I know of no way within this spec to link multiple data: URIs to play gaplessly.

Both sound and client-side data storage are features of HTML5.

Both sound and client-side data storage are features of HTML5.

"if JQuery were integrated with the browsers"

if you mean, if features from jquery (and similair frameworks) were included in the browser, then that has already happend.

It is called the document.querySelectorAll

http://www.w3.org/TR/selectors-api/

First we had webdevelopers who wanted to better seperate content, behaviour and style. And they started to implement that, they asked the browser developers to make such an API because it would be a lot faster if browser did that. The browserdevelopers didn't do so, because it would be slow. Then people create frameworks which did that too and a lot of people started using it. Then browserdevelopers said, let's make a spec and implement it, if people are using it anyway, might as well try to make it as fast as possible.

Every time there's a Slashdot post about ChromeOS there's immediately a rush of posts complaining that it won't work offline.

Slashdot is supposed to be news for nerds, not recent history for nerds ... but SOME OF YOU GUYS ARE NOT PAYING ATTENTION. Listen up.
This is not 1999. You can come out of your bunker now.

Google introduced offline Web functionality in in 2007. Google Docs supported Google Gears, which made it possible to use the Google word processor on an airplane with no network connection at all. I've done it. It worked fine. When I reconnected, everything synchronized with the cloud.

This concept has been reworked and is a part of the HTML5 standard. See http://www.w3.org/TR/offline-webapps/

In 2010-2011, you can write highly functional applications using HTML5 and Javascript, make them installable on your web browser, and have them work offline. Please stop assuming the Web is as it was when you were in junior high.

Typo in the link. Specifically, an extra dot. Try here.

This page has a discussion in the comments about MS being a major contributor, if not the major contributor, for these tests.

W3C would like to thank Microsoft who donated the server that allows us to run this service.

Well at least they appear to be running Debian on it.