Slashdot Mirror

A W3C project did something similar to this back in 2001. There was even a Firefox (then Mozilla) plugin.

http://en.wikipedia.org/wiki/Annotea

``I can't wait until the major video sites default to HTML5 and we can finally say goodbye to Flash.''

and then we will finally be where we could have been, had people just used HTML4's object element.

"Why the 'F does the page have to reload when I hit the back button"

Because a lot of web pages (including slashdot) are served with HTTP headers that tell the browser not to cache them, and the browser follows that directive. Yes, it's annoying. I use tabs for that reason too.

The HTTP specification explicitly says that caching headers are not to affect history traversal:

13.13 History Lists

User agents often have history mechanisms, such as "Back" buttons and history lists, which can be used to redisplay an entity retrieved earlier in a session.

History mechanisms and caches are different. In particular history mechanisms SHOULD NOT try to show a semantically transparent view of the current state of a resource. Rather, a history mechanism is meant to show exactly what the user saw at the time when the resource was retrieved.

By default, an expiration time does not apply to history mechanisms. If the entity is still in storage, a history mechanism SHOULD display it even if the entity has expired, unless the user has specifically configured the agent to refresh expired history documents.

This is not to be construed to prohibit the history mechanism from telling the user that a view might be stale.

Note: if history list mechanisms unnecessarily prevent users from viewing stale resources, this will tend to force service authors to avoid using HTTP expiration controls and cache controls when they would otherwise like to. Service authors may consider it important that users not be presented with error messages or warning messages when they use navigation controls (such as BACK) to view previously fetched resources. Even though sometimes such resources ought not to cached, or ought to expire quickly, user interface considerations may force service authors to resort to other means of preventing caching (e.g. "once-only" URLs) in order not to suffer the effects of improperly functioning history mechanisms.

So no. The reason is because the browser doesn't want to cache all the necessary info, e.g., for memory usage reasons. Complain to your browser vendor if history navigation is too slow.

I really should have said HTML5 and CSS. CSS drop-down menus, transparency and the like also some great shadow and border features etc and even different developments in CSS animationwill hopefully replace flash and javascript.New HTML tags for embedding content or applications will go a long way to making flash redundant also. I hope.

CSS is used for easy and consistent page formatting across a site...

Well, yes that is ONE use for CSS, but please remember that it is Cascading Style Sheets. Style information can be embedded in the HTML itself, or in an external file. Style information in the page itself will be prioritized over CSS in an external document. This adds flexibility. HTML is about data. CSS is about presenting that data. Flash is doing what HTML and CSS should do and will soon.

Uncanny insight? Lisa? NeXT? Let's not try to rewrite history here...

The Lisa was the competitor (internally at Apple) to Jobs' baby, the Macintosh. I think we all know which one won that battle.

Wikipedia has the following to say on NeXT's impact : "Despite NeXT's limited commercial success, the company had a profound impact on the computer industry. Object-oriented programming and graphical user interfaces became more common after the 1988 release of the NeXTcube and NeXTSTEP, when other companies started to emulate NeXT's object-oriented system."

There's a reason why the first browser was written on a NeXT cube you know. Berners-Lee says : "I wrote the program using a NeXT computer. This had the advantage that there were some great tools available -it was a great computing environment in general. In fact, I could do in a couple of months what would take more like a year on other platforms, because on the NeXT, a lot of it was done for me already. There was an application builder to make all the menus as quickly as you could dream them up. there were all the software parts to make a wysiwyg (what you see is what you get - in other words direct manipulation of text on screen as on the printed - or browsed page) word processor. I just had to add hypertext, (by subclassing the Text object)"

Aren't IDNs already available via Puncode encoding? (For example the ones at http://www.w3.org/2003/Talks/0425-duerst-idniri/slide12-0.html) Or am I missing something?

It appears not to be compliant with present-day web-standards, just a quick run through an online HTML validator brings up some errors.

I mean, I'm all for choice, but why so many? Why, in particular, are a few manufacturers in particular releasing so many models? Half of the phones (25 out of 51) come from just three companies--HTC (9), Motorola (9), and Samsung (7). I can see why a manufacturer would want some variety in general--slider, bar, flip; big with good battery life or small and thin and light--but aren't all Android phones big, touchscreen smartphones? I don't want to start googling every name (hasn't wiseandroid.com ever heard of links?) so can anyone clue me in on the differences?

I like Apple's stuff and you might call me a "fanboi" but you have to admit they've made some good decisions in the past decade, especially with regard to simplifying their product lines. The stereotypical Slashdotter hates having their choices limited but everyone in sales, marketing, and product development should know about the disadvantages to offering too many options. Make one phone with as many or as few features as you care to cram into it and the choice becomes a simple one--take it or leave it. Start offering them with minor differences--this one has WiFi but no GPS, this one has GPS but no WiFi, etc.--and people will start to say "screw it, what else is there?" Plus every time you offer more models you're increasing the cost of your R&D but with less and less improvement in sales.

If anything, we should see more Android devices--Android technology without the phone, like the iPod touch. Clearly there's a market there, and you get around the whole pesky "tied to the carrier you hate" issue.

You have no idea what you're talking about, yet you just butt in the discussion like the OP. There are things like design patterns, test driven development, usability testing, etc. that make up a great application that looks and feels nice and is easy to use.

What about accessibility? If your website is not usable with Lynx, most likely it is not usable with a screen reader. That means blind people can't use it.

Actually W3C guidelines say

http://www.w3.org/TR/WCAG10/#gl-new-technologies

Ensure that pages are accessible even when newer technologies are not supported or are turned off.

Although content developers are encouraged to use new technologies that solve problems raised by existing technologies, they should know how to make their pages still work with older browsers and people who choose to turn off features.

Checkpoints:

6.1 Organize documents so they may be read without style sheets. For example, when an HTML document is rendered without associated style sheets, it must still be possible to read the document. [Priority 1]
When content is organized logically, it will be rendered in a meaningful order when style sheets are turned off or not supported.

6.2 Ensure that equivalents for dynamic content are updated when the dynamic content changes. [Priority 1]

6.3 Ensure that pages are usable when scripts, applets, or other programmatic objects are turned off or not supported. If this is not possible, provide equivalent information on an alternative accessible page. [Priority 1]
For example, ensure that links that trigger scripts work when scripts are turned off or not supported (e.g., do not use "javascript:" as the link target). If it is not possible to make the page usable without scripts, provide a text equivalent with the NOSCRIPT element, or use a server-side script instead of a client-side script, or provide an alternative accessible page as per checkpoint 11.4. Refer also to guideline 1.

6.4 For scripts and applets, ensure that event handlers are input device-independent. [Priority 2]
Refer to the definition of device independence.

6.5 Ensure that dynamic content is accessible or provide an alternative presentation or page. [Priority 2]

For example, in HTML, use NOFRAMES at the end of each frameset. For some applications, server-side scripts may be more accessible than client-side scripts.

This is an important debate, but Neil McAllister's article suffers from a number of problems. For example, it references the recently popular Webkit Comparison Table along with Peter-Paul Koch's claim that there is no “WebKit on Mobile”. The article didn't point out that some people like Alex Russel have dug deeper and have found that the facts don't support PPK's conclusions as strongly as one might think. Yes, if you include lots of older devices, there's quite a divergence in Webkit deployments, but what PPK and Neil McAllister don't say is that compatibility is much better on devices that ship recent versions, it's especially good for core features, and it's improving all the time.

McAllister also implies that the mobile Web is in trouble because "On my BlackBerry, JavaScript performance is abysmal". Using that argument, I can prove that Windows will never be successful, because I could in the early days show you PC's that ran it with abysmal performance. The potential of technologies like Javascript needs to be evaluated using the best implementation you can find; that shows what's possible. He does go on to say: "And even when a handset vendor does improve JavaScript performance, as Apple did with iPhone OS 3.0, it's a relative increase." Aren't they all? "You're still dealing with a poky handheld processor (and in Apple's case, one that developers speculate is too feeble for Flash or Java)." Uh, so now the reason that the HTML and Javascript will fail is that ARM processors are too slow to run Java? What's the connection I'm missing? The fact is, that there are some pretty good AJAX sites for mobile, so we know the ARM processors are good enough to run that Javascript. Try, for example, going to http://www.gmail.com using Safari on your iPhone. Not a usable experience? Even works offline using HTML 5 local storage (not Gears). Also, even if Javascript performance were somehow related to Java performance, I bet the Android folks would like to hear that Java doesn't run right on ARM processors, since the entire upper level infrastructure of Android, including user applications, is built on just that combination (as optimized using the Dalvik VM).

Unfortunately, articles like this can do real damage. Many people who are not expert in these things are struggling to figure out which mobile application development models are going to be workable. I happen to believe that the Mobile Web will, like the desktop embodiment of the Web, grow as disruptive technologies tend to: from something that's a bit shaky at first to the model that dominates? Why? Because unlike Mr. McAllister, I believe that the underlying processors and system technologies are capable of running it, and the value of a model that is fully cross-platform, can support zero install operation (you might want to install a mapping application to find a restaurant, but you almost surely don't want to install the restaurant's application to read menus or get discount coupons), can also scale to support installable applications (Widgets) and offline operation, is compelling. Furthermore, as has been the case for years, the Web has the unique value of allowing you to link to the over 1 trillion Web pages, without jumping out from some proprietary application container to a Web browser. Whether I'm right about the likely success of the mobile Web or not, this whole question deserves a much more careful analysis than McAllister's article provides. Unfortunately, there will be many people who read it and jump to the conclusion that the mobile Web is failing. A shame.

How do you think download accelerators work? They use the Range header to tell the server they only want a chunk of the file. Then, they ask for multiple chunks, each one using a different TCP connection.

In conclusion, what you're saying can already be done using HTTP 1.1, as long as you make a download manager that uses each connection in a round-robin fashion.

I have to say that now I regret that the syntax is so clumsy. I would like http://www.example.com/foo/bar/baz to be just written http:com/example/foo/bar/baz where the client would figure out that www.example.com existed and was the server to contact.

Heavens, NO! Explicitly and visibly separating the hostname from the rest of the URL is essential! Just think of all how much phishing would explode if you can't tell whether you're accessing example.com/foo/bar/baz or foo.example.com/bar/baz or bar.foo.example.com/baz! At the very least, the dot would have to be retained, as in http:com.example/foo/bar/bax.

I have to say that now I regret that the syntax is so clumsy. I would like http://www.example.com/foo/bar/baz to be just written http:com/example/foo/bar/baz where the client would figure out that www.example.com existed and was the server to contact. But it is too late now. It turned out the shorthand "//www.example.com/foo/bar/baz" is rarely used and so we could dispense with the "//".

I would also like to add that protocol relative URI are useful. I'm sure some of you are familar with the hideous JavaScript Google recommend using for embedding Analytics into your HTML. It would make much more sense to source the file with a protocol-relative URI.

What I wonder is why the designers of DNS put the name in reverse?

Berners-Lee regrets that as well, from back in 2000...

I have to say that now I regret that the syntax is so clumsy. I would like http://www.example.com/foo/bar/baz to be just written http:com/example/foo/bar/baz where the client would figure out that www.example.com existed and was the server to contact. But it is too late now. It turned out the shorthand "//www.example.com/foo/bar/baz" is rarely used and so we could dispense with the "//".

Any actual published material? If yes, please tell the w3c (public-web-plugins@w3.org).

See the W3C FAQ on the topic. It seems old, but they still need more convincing examples of prior art to fight the EOLAS case.

Any actual published material? If yes, please tell the w3c (public-web-plugins@w3.org).

See the W3C FAQ on the topic. It seems old, but they still need more convincing examples of prior art to fight the EOLAS case.

"But my customers want it to work in their browser!" is not an argument when better browsers are freely available.

Really? When your customers contact you about this or that not working right in IE, all you tell them is to use a different browser? Don't you think that's a bit lazy?

No, it's the mirror image of "This site is best viewed^W^Wonly works in IE." What's sauce for the goose is sauce for the gander. Simply tell the customer to search for "Internet explorer is a steaming pile of crap" and that, while Microsoft is working towards a version that is standards-compliant (or at least standards-compatible - NOT the same thing), they still have a ways to go.

How "standard" is a "standard" if people aren't following it?

People ARE following them - then having to rewrite/bloat/break their code for ONE browser. The standards are listed at w3.org.

Oddly enough, the exact reason I don't have to spend a considerable amount of time debugging IE is because I use a library that is cross-browser compatible, because of things like browser sniffing. My time spent debugging problems in IE has dropped significantly since starting with ExtJS.

... and if you code only to the standard, your time spend debugging problems in IE will be zero. At the very least, dropping support for anything prior to IE8 (and especially ignoring IE6) is sensible.

Also, there's the dual issues of bloat and customization: bloat because these libraries are BIG, and customization, because now any custom js extensions you write are dependent on interactions with both the browser and the library, which just adds another potential set of corner cases to test for.

http://validator.w3.org/check?uri=http%3A%2F%2Fwww.recovery.gov%2FPages%2Fhome.aspx&charset=(detect+automatically)&doctype=Inline&group=0

You don't really know what you're talking about here.

IE hasn't caught up to existing, published, finished standards- that's well before we even start talking about initial implementations of things from the in-progress HTML 5 standard. It's the worst browser in the bunch for CSS compatibility- with finished, published standards.

You don't really know what you're talking about here.

No relevant CSS standard beyond CSS1 (or CSS2 if you call that relevant) has reached Recommendation status (i.e., is "finished"). CSS2.1 (which IE8 has excellent support for) is a Candidate Recommendation. CSS3 is a collection of mostly unrelated standards, and the most advanced of those is also CR. Some of the most important, useful, widely-implemented CSS3 standards aren't even CR – Selectors is only Last Call, and AFAIK it has multiple full implementations.

HTML5, on the other hand, is a Working Draft as far as the W3C is concerned – just like most of CSS3. It's expected to reach Last Call by October. So there's really no serious difference here. (Leaving aside the fact that HTML5 is primarily published by the WHATWG, not the W3C, and the Working Draft version is an outdated and mostly useless snapshot that exists only for bureaucratic and political reasons, and which everyone ignores. That's beside the point.)

You don't really know what you're talking about here.

IE hasn't caught up to existing, published, finished standards- that's well before we even start talking about initial implementations of things from the in-progress HTML 5 standard. It's the worst browser in the bunch for CSS compatibility- with finished, published standards.

You don't really know what you're talking about here.

No relevant CSS standard beyond CSS1 (or CSS2 if you call that relevant) has reached Recommendation status (i.e., is "finished"). CSS2.1 (which IE8 has excellent support for) is a Candidate Recommendation. CSS3 is a collection of mostly unrelated standards, and the most advanced of those is also CR. Some of the most important, useful, widely-implemented CSS3 standards aren't even CR – Selectors is only Last Call, and AFAIK it has multiple full implementations.

HTML5, on the other hand, is a Working Draft as far as the W3C is concerned – just like most of CSS3. It's expected to reach Last Call by October. So there's really no serious difference here. (Leaving aside the fact that HTML5 is primarily published by the WHATWG, not the W3C, and the Working Draft version is an outdated and mostly useless snapshot that exists only for bureaucratic and political reasons, and which everyone ignores. That's beside the point.)

I wish it weren't so, really. It's an abomination and we knew it when the thing was released, but there it is. Friends don't let friends use IE6. It's common and more reasonably secure browsers aren't supported on sites that require IE6. Enterprises need IE6 for intranet sites and they can't afford to or aren't able to rewrite sites to adhere to standards.

They could choose to fix this problem by requiring their development teams to adhere to standards, but that's not the direction they're going -- instead the job ads are full of requirements that for successive iterations of Microsoft deprecated versions of .net. The persistence of stupidity is remarkable, but that's a different topic.

This paradigm is inherently flawed: the network is not a trusted environment and in that environment a Windows server should be the least trusted element. Microsoft themselves admit this when they force you to choose between the latest version of their server operating system or the latest version of their mail server, but not both, putting you in the position of choosing either an OS that's currently as secure as it can be, or a mailserver that is, but not both.

So what can you do? The Google solution actually looks like a good answer at first, but then realize that it enables and empowers people to continue using a browser that's known to be bad. If a server is on the intranet it's presumed to be safe (itself a different problem), if a server self-identifies as being OK for Chrome the user gets a secured sandboxed environment. But on the Internet, where users will go, if a server doesn't self-identify as preferring Chrome the user is browsing a site with a browser that's known to be insecure. So by enabling users to browse in a secure environment when the server offers it, Google is actually enabling people to not update to a more secure browser.

It's a clever hack, but the premise is fatally flawed.

http://www.w3.org/QA/2009/05/_watching_the_google_io.html

http://validator.w3.org/ ------ Sorry! This document can not be checked

You can validate the validator if you use its IP address instead of the normal URL.

There are standards for HTML? Who knew?

FWIW, as of this morning, the W3C Validator [http://validator.w3.org] reports

www.google.com ------------ 39 Errors, 2 warning(s)
www.microsoft.com -------- 300 Errors, 31 warning(s)
www.apple.com -------------- 6 Errors, 1 warning(s)
www.bing.com -------------- 12 Errors
http://validator.w3.org/ ------ Sorry! This document can not be checked
www.slashdot.org ---------- 64 Errors, 2 warning(s)

And don't those web page designers who are "dancing for joy" deserve a bit of credit for this shambles? I'd like to believe that they won't immediately start using features that work in chrome, but not IE because "all the user has to do is download a plugin." But if past experience is any guide, that is exactly what many of them will do.

HTML 5 is not done yet by any means. I wouldn't even say they have what you might call a working draft.

"The publication of this document by the W3C as a W3C Working Draft ...".

(And the first public working draft was published Jan 2008).

Microsoft isn't necessarily behind so much as they are not working off the Mozilla and Apple webkit mailing lists when they implement features to their browser.

I don't work off these lists either, but I'm aware of a numer of high profile parts of it, say, the Canvas element. I'm sure Microsoft is too.

IE still has a very enterprise-oriented development cycle

Is this what we call their six year hiatus from actually working on their product?

In the late 1990s they showed they were quite capable of aggressively expanding IE's features, including new if raggedly incomplete support for emerging standards, when they decided it was in their interest to do it.

the bleeding edge feature explosion we see in most open source browsers.

A lot of the features discussed for HTML 5 have had visible implementations for 3-4 years. You could call them bleeding edge in 2006, maybe 2007. 2009? Not without looking pretty silly.

I don't think IE needs to catch up so much as Microsoft simply needs to release an unstable browser in addition to their platform browser if they want to compete with the rest of the non-standard "standards" cult.

The competing products seem to do just fine at keeping a comparable level of stability along with the pushing the envelope. In fact, given how much Opera, Mozilla, and Safari, have been able to do with resources that are orders of magnitude smaller, there's really no excuse.

Except of course if you're talking about CSS 2.1, where it is the best.

Can you defend this claim? Because based on my experiences *using* CSS over the last 7 years, there hasn't been a time when any version of IE could even claim they weren't maddeningly, brokenly worse.

HTML 5 is not done yet by any means. I wouldn't even say they have what you might call a working draft.

In Firefox, this page shows "W3C Working Draft" along the left side.

Microsoft isn't necessarily behind so much as they are not working off the Mozilla and Apple webkit mailing lists when they implement features to their browser.

A lot of the features that Acid3 tests aren't new proposals in any sense; they've been around for years. WebKit (basis for Chrome and Safari), Gecko (Firefox and SeaMonkey), and Presto (Opera) all score above 90/100, which handily beats IE 8's 20/100.

Any large scale implementation of capcha is in breach of section 501 (which applies to google as they're a US company) due to its inaccessibility (w3c report for the interested ) - this kind of lawsuit has already happened in the past if the company had an important enough presence and problematic implementation enough (and no, having sound samples is not unproblematic) to add a significant barrier to access to internet utilities.

We'll just have to see how far and wide they go with it.

Go to http://validator.w3.org/ and type in "http://ebay.com". The latest time I tried it there were 253 errors on the home page alone. (Weirdly, it seems to vary; the first time I tried it 10 minutes ago there were 240 errors.)

It is surprising that the site works at all. I guess it's called "web page design by trial and error until it works most of the time in the developer's current browser version."

One might wonder what kind of impression such an error printout would make on a judge, in a dispute related to lost sales due to ebay's broken pages.

ebay is typical of a company losing market share. Blame everyone else.

I wrote a very specific letter to them describing how they could improve many things. I got a letter back which I've framed saying "they don't accept suggestions from outside ebay".

Brilliant! Bunch of geniuses. They must all have CO poisoning from car exhaust leaks. Maybe people leave cars running near ebay building air intakes.

One suggestion was that they upload their html to http://validator.w3.org/check before going live. Anyone ever look at the html? It's a nightmare.

I know this is slashdot and almost all of you LOVE your javascript, but you all know it's the single biggest security threat to 'net computing. I hope for the day that the US Interstate Commerce Commission and the Federal Trade Commission have strong technology divisions which would rule that sites like ebay may NOT use javascript or any other insecure technology, and that all webpages and data feeds are tested and approved by w3.org or some other standard setting entity.

Come on- can't a group of us start a competition to ebay? Someone come up with a good name- that's all you need. The code is trivial. Something closer to ebay, not cl. I'll do it- who's with me?

Honestly, who cares - they're both designed by people who know little about creating decent websites.

I don't know how you got away with this statement since it's just out-and-out wrong.

One of these sites exhibits nearly identical behavior with Javascript turned off (see other comments attached to this article for detail), bleeding edge technologies with graceful degradation, good semantic markup, good consistency in appearance and behavior across browsers, no detected accessibility errors, and an acceptance and embracing of open standards. It even comes extremely close to validating (those errors might even be explainable by the warning given on the page regarding "cutting edge technology"). The other? Not so close.

For some additional backup from the likes of webdesignerdepot.com and others

The Apple website is one of the best websites out there due to its ease of use, functionality and the beautiful environment that it creates.

In terms of web design, Apple.com is a very good exemple of clean semantic code and stunning graphics.

Admittedly, I'm an Apple fanboy, but come on. Even the most unabashed of Apple haters should be able to agree that there was a team of skilled and capable people behind its creation. It's by no means perfect, but there's a reason it's cited time and again as one of the best-designed sites on the Web, and it's not just because of the pretty pictures.

Honestly, who cares - they're both designed by people who know little about creating decent websites.

I don't know how you got away with this statement since it's just out-and-out wrong.

One of these sites exhibits nearly identical behavior with Javascript turned off (see other comments attached to this article for detail), bleeding edge technologies with graceful degradation, good semantic markup, good consistency in appearance and behavior across browsers, no detected accessibility errors, and an acceptance and embracing of open standards. It even comes extremely close to validating (those errors might even be explainable by the warning given on the page regarding "cutting edge technology"). The other? Not so close.

For some additional backup from the likes of webdesignerdepot.com and others

The Apple website is one of the best websites out there due to its ease of use, functionality and the beautiful environment that it creates.

In terms of web design, Apple.com is a very good exemple of clean semantic code and stunning graphics.

Admittedly, I'm an Apple fanboy, but come on. Even the most unabashed of Apple haters should be able to agree that there was a team of skilled and capable people behind its creation. It's by no means perfect, but there's a reason it's cited time and again as one of the best-designed sites on the Web, and it's not just because of the pretty pictures.

Web browsers essentially do four things: ask for pages (possibly when you click on a link), render pages, embed plugins, and run scripts.

HTTP, on the other hand, does eight things: OPTIONS, HEAD, GET, POST, PUT, DELETE, TRACE and CONNECT.

A complex modern browser could easily be split into separate http and renderer components (Konqueror may work this way), and possibly many simpler components than that.

I'm seeing a few posts here complaining that Microsoft won't implement the SVG 1.1 standard in Internet Explorer.

I would argue that as long as Microsoft continues to push Silverlight (which is just browser-safe WPF) as their form of a vector graphics applet for their web browser, any alternative approach within MS is going to stagnate. Silverlight is their attempt to build a Flash-alternative with a SVG programming framework, which is (to Microsoft) a "best" of both worlds. To the rest of us coming from the WinForms world, it's a so-so product that's really awkward to use. I known that MS is pushing Expression Blend as an alternative to Adobe CS3's UI, but really, why didn't they just integrate it into Visual Studio for native editing instead of all this back-and-forth multiwindow crap.

For example, SVG Shapes vs WPF Shapes. It's no accident that the syntax is almost exact. But why would Microsoft embrace SVG directly, with its Javascript code triggers, when they can go the Silverlight route with .Net triggers.. it's basic product bundling, to get you to use Microsoft's approach to everything.

I'm seeing a few posts here complaining that Microsoft won't implement the SVG 1.1 standard in Internet Explorer.

I would argue that as long as Microsoft continues to push Silverlight (which is just browser-safe WPF) as their form of a vector graphics applet for their web browser, any alternative approach within MS is going to stagnate. Silverlight is their attempt to build a Flash-alternative with a SVG programming framework, which is (to Microsoft) a "best" of both worlds. To the rest of us coming from the WinForms world, it's a so-so product that's really awkward to use. I known that MS is pushing Expression Blend as an alternative to Adobe CS3's UI, but really, why didn't they just integrate it into Visual Studio for native editing instead of all this back-and-forth multiwindow crap.

For example, SVG Shapes vs WPF Shapes. It's no accident that the syntax is almost exact. But why would Microsoft embrace SVG directly, with its Javascript code triggers, when they can go the Silverlight route with .Net triggers.. it's basic product bundling, to get you to use Microsoft's approach to everything.

ROFL....this your first time using the intertubes? Almost every page on the internet is loaded with errors. Try that shit with Amazon's home page: http://validator.w3.org/check?uri=http://www.amazon.com&charset=(detect+automatically)&doctype=Inline&group=0&user-agent=W3C_Validator/1.654

1153 errors.

Ebay: 253 errors

I could go on but what's the point.

Not to mention the 253 errors from the W3C Validation site.

Can you truly blame them, when Google main page, probably single the most visited page on the Net today, is showing 46 Errors?

As a side note, ironically, Bing has fewer - 12 - mostly because of improper use of P and DIV inside SPAN.

Not to mention the 253 errors from the W3C Validation site.

Can you truly blame them, when Google main page, probably single the most visited page on the Net today, is showing 46 Errors?

As a side note, ironically, Bing has fewer - 12 - mostly because of improper use of P and DIV inside SPAN.

Not to mention the 253 errors from the W3C Validation site.

Does it support the W3C standard for MVC markup yet, or is Opera still cherry-picking stanards that suit its business model more than those of its users?

...which is more than I can say of Microsoft.

No it's not

Someone doesn't know CSS.

A good HTML editor comes directly from the W3C, found here: Amaya.

Hi,
Firstly if you're looking for opensource app replacements you can always try www.osalt.com.

Personally I'd try:
Photoshop: GIMP or GIMPShop or Krita
Illustrator: Inkscape or XaraXtreme
InDesign: scribus
Dreamweaver: KompoZer or Aptana or seamonkey or Amaya or href="http://net2.com/nvu/">NVU

I also found this website which might help: www.thefreesuite.com

Here are the relevant OSalt links:
photoshop
illustrator
indesign
dreamweaver

This would be a good fit with the Ubiquity XForms implementation hosted on Google Code as well. It's aimed adding in-browser MVC (model-view-controller) support to IE, Firefox, Opera, and Safari, based on another W3C recommendation, XForms 1.1.

For example, see this tutorial on how to style hints on triggers (multi-modal word for "buttons") declaratively. (This is from the SVN trunk so it will load all the JavaScript implementation files individually rather than as a single library.)

Too late. Microsoft beat you to it. http://www.w3.org/Style/CSS/Disclosures

XML Provides Standardization for International Functionality between individuals and (within) businesses, governments.... XML Customization by Businesses, Governments, Individuals... altering recognized and accepted international XML Standards seek to hawk proprietary products and hook data/content novices into a blind and costly ally.

W3C XML http://www.w3.org/XML/
ODF XML ISO/IEC 26300:2006 http://www.iso.org/
ODF XML OASIS http://www.oasis-open.org/
OpenOffice XML http://www.openoffice.org/

The XML OpenDocument Format (ODF) standard, used by OpenOffice and others, is an open XML-based document file format for office applications to be used for documents containing text, spreadsheets, charts, and graphical elements. The file format makes transformations to other formats simple by leveraging and reusing existing standards wherever possible. As an open standard under the stewardship of OASIS, OpenDocument also creates the possibility for new types of applications and solutions to be developed other than traditional office productivity applications.

IMO Summary: If you fear long-term data/content cost/legal..., then... from Microsoft Office... RUN AWAY! RUN AWAY FAST!

In the patent:
"A system and method for separate manipulation of the architecture and content of a document particularly for data representation and transformations."

And how is this different from using XSL?

Like all software patents this is bullshit.

Don't welcome MS to 2001.

It gives them too much credit. They haven't even reached 2000 yet.

Adobe? What about Amaya's XML/XHTML editing feature?

It's nice to see such advances in standards.
Unluckily, implementations (all of them) will either be partial or buggy or even both.
There's still little support for a tag as old as the COL. We can imagine what will happen: more browser incompatibilities.
What if this wonderful standards committee would ask for some commitment from the (main) implementers?
Just see how much the standards are taken into account by authors:
The R.I.P.E.
MIcrosoft