Slashdot Mirror

I guess it is mirrored here:

http://www.w3.org/History/19921103-hypertext/hyper text/WWW/TheProject.html

You can still see a version of TheProject.html at

http://www.w3.org/History/19921103-hypertext/hyper text/WWW/TheProject.html

although I'm not certain how outdated it is, the 1992-11-03 seems to be encouraging.

While looking through the help to see whether Microsoft can spell RDF[1] or FOAF[2] (they don't appear to), I came across this[3]:

    "Why do I need to use Passport?"
    "We chose Passport in order to help you consolidate the number of logins you have to manage."

*sigh* here was me thinking passport was dead.

[1] http://www.w3.org/RDF/
[2] http://xmlns.com/foaf/0.1/
[3] http://aggreg8.net/Aggreg8_Help_Pages.htm#registra tion_passport

- Why isn't there more transparency about MoFo/Co's finances - why can't you publish where you get money from, how much, and what you do with it?
- Is it not in fact the case that the Mozilla project is now mostly controlled by Google, which provides the overwhelming majority of funds?
- How much money does Google make due to FF/SM's choice of Google as the default search engine, and how much of that money goes back into Mozilla development?
- It seems to an outsider that very little effort is devoted to Mail&News / TB compared to FF. Is this true?
- How do you see the future of Mail&News/ TB development, considering the conflicting interest Google has in the matter (GMail)?

And unrelated, technical questions:

- Why does Gecko continue not to support significant aspects of CSS2 properly? Example: bug 5016.
- How does FF2 / Geck trunk measure up in the W3C CSS testsuite?
- Why is Gecko, and FF/SM/TB, not multi-threaded (these are two questions!) ?
- Why does Firefox' memory footprint balloon up to hundreds of megabytes so often?
- Why don't Firefox and Thunderbird share most of their memory, the 'engine' part?

Im sure disability-discrimination laws exist in the European Union too

Yes, there are accessibility laws in countries all over the world.

"It's a shameless...site"

Your missing a proper DOCTYPE in your HTML... shame

Sorry m8, but you don't know what the fuck you are talking about either. Wikipedia is full of bad information. Don't be a wikihead.
From the W3C Spec Document at http://www.w3.org/TR/XMLHttpRequest/:
--------------
Special thanks to the Microsoft employees who first implemented the XMLHttpRequest interface, which was first widely deployed by the Windows Internet Explorer browser

Special thanks also to the WHATWG for drafting a first version of this specification in their Web Applications 1.0 document.

Thanks also to all those who have helped to improve this specification by sending suggestions and corrections. (Please, keep bugging us with your issues!)
--------------
once again, wikipedia is full of shit.

it said:
The XMLHttpRequest concept was originally developed by Microsoft as part of Outlook Web Access 2000.

While you are right about microsoft being first, you are wrong because you don't really know this, you are just spewing wikishit verbatim 8) Technically, you don't know what you are talking about because the wiki is doing the talking... Before mouthing off with info you get there, you should check your source's accuracy.

-AC

>>Second problem is:

That's not what no-cache means. No-cache means that the caching client cannot use its cache to handle any subsequent requests without revalidfating with the server, so any further request to the same URI must be checked against the server. If the rtesponse from the server effectively says "your cache is valid" then it *can* use the cache.

See http://www.w3.org/Protocols/rfc2616/rfc2616-sec14. html#sec14.9.1

no-store is the directive that is *supposed* to prevent storage of the response.

What are Mozilla's intentions now with respect to SVG? One can not ignore that the specification of SVG with respect to Adobe's Flash product. To my thinking, SVG, or its spawn, is the direction of future web developement.

http://validator.w3.org/check?uri=www.google.com

The ADA became law on July 26 1990, a couple of months before TBL started non-conceptual work on the WWW in October 1990. The physical argument is moot, as servers physically exist... the means to access and interact with them is the paradigm shift.

Note: I was the AC for that comment - I had thought I was logged in but evidently I was not.

Please note I explicitly said caching agents which includes caching proxys and your browser amongst other things, but even with respect to only the browser as you seem to have (mis)interpreted the thrust of my point and you're incorrect in your assertion that they should cache everything - browsers too must (and do in my experience, with a few fun bugs) follow the instructions in the headers with regards to caching. I kindly point you to RFC2616 (HTTP 1.1 spec) section 14.9 (Cache-Control):

The Cache-Control general-header field is used to specify directives that MUST be obeyed by all caching mechanisms along the request/response chain.

That is besides the point however, my point was that although GET requests can be used to generate dynamic content specific to the user this is very often not the case - for example most sites which have some form of news entrys will use get requests with some form of unique identifier to pull the article from the database and format it correctly. In this situation the developer of the application almost certainly wants the generated article cached in multiple stages to minimise load on the server (for example squid between the web and the application so that every time a person visits the page it does not need to be generated again, by the users ISP and by the users browser). Further, we all know that the contents of a URI in no way relate to what is actually happening server-side - tools such as mod_rewrite can be used to great effect and hide those pesky question marks, ampersands and verbose key and value pairs.

My point is this, as a skilled software engineer focused on web development I can make static pages look dynamic and dynamic pages look static trivially and so can anybody else - the URI was never intended to give any information about the resource it is identifying beyond it's location, it is misinterpretation and flawed analogys which give most people the impression that the URIs have intrinsic meaning; so making assumptions with regards to the cacheability of a resource based on it's URI if at best foolish (and hence isn't done). Instead implementation of (for example) the Vary field should be considered by the developer of 'dynamic' pages so that caching agents are aware that it is dynamic, and know which value in a request changes it and so can cache the variations of the page based on this.

Note: I was the AC for that comment - I had thought I was logged in but evidently I was not.

Please note I explicitly said caching agents which includes caching proxys and your browser amongst other things, but even with respect to only the browser as you seem to have (mis)interpreted the thrust of my point and you're incorrect in your assertion that they should cache everything - browsers too must (and do in my experience, with a few fun bugs) follow the instructions in the headers with regards to caching. I kindly point you to RFC2616 (HTTP 1.1 spec) section 14.9 (Cache-Control):

The Cache-Control general-header field is used to specify directives that MUST be obeyed by all caching mechanisms along the request/response chain.

That is besides the point however, my point was that although GET requests can be used to generate dynamic content specific to the user this is very often not the case - for example most sites which have some form of news entrys will use get requests with some form of unique identifier to pull the article from the database and format it correctly. In this situation the developer of the application almost certainly wants the generated article cached in multiple stages to minimise load on the server (for example squid between the web and the application so that every time a person visits the page it does not need to be generated again, by the users ISP and by the users browser). Further, we all know that the contents of a URI in no way relate to what is actually happening server-side - tools such as mod_rewrite can be used to great effect and hide those pesky question marks, ampersands and verbose key and value pairs.

My point is this, as a skilled software engineer focused on web development I can make static pages look dynamic and dynamic pages look static trivially and so can anybody else - the URI was never intended to give any information about the resource it is identifying beyond it's location, it is misinterpretation and flawed analogys which give most people the impression that the URIs have intrinsic meaning; so making assumptions with regards to the cacheability of a resource based on it's URI if at best foolish (and hence isn't done). Instead implementation of (for example) the Vary field should be considered by the developer of 'dynamic' pages so that caching agents are aware that it is dynamic, and know which value in a request changes it and so can cache the variations of the page based on this.

I'm not completely sure, but it seems that the W3C is also implicated. Sounds almost like the end of Snow Crash...

it's also extraordinarily difficult to use for low-vision people. Making your website inaccessible to people is not usually a good idea.

It's also easily breakable - there are scripts out there that can decode the common CAPTCHAs with >90% success.

This doesn't even include social engineering CAPTCHA breakers which are also known to exist e.g. spammer sets up a (say) fake porn site, hotlinks the CAPTCHA image of the site they want to spam. When someone comes along to fake porn site, it tells the user to enter the CAPTCHA. Once the user does this, they're shown some boobies, whilst the site fires off a spam to the site the CAPTCHA came from.

Don't get me wrong - CAPTCHAs are a useful tool, but not necessarily the best solution.

Thanks for the clarification. I had been trusting the information on this page to be accurate...glad I didn't actually go a head with implementing it.

It's no wonder that U Tube looses customers. A Google search for "U Tube" or search for "utube"doesn't yield Universal Tube's homepage as any of the first 100 results. Why is this? Well, here's one reason. Another one is that the web page uses completely non-semantic markup without a single H1 element in the source code. Non-semantic code is basically just jibberish for search engines, so they could just as well have riddled their pages with googlygook. The search results would be the same.

Yet another reason is that "utube" or "u tube" is mentioned nowhere on their pages. The design is built with endless amounts of nested tables. The markup-to-content ratio is sky-high. And they're using JavaScript as the main means for navigation. It almost looks like they're actively blocking users and search engines from making any sence of their web pages. A redesign with a solid implementation of semantic and accessible markup, would increase the searchability and usability of their pages by an order of magnitude and they would both get happier customers and less reason to go to court.

But it's of course much easier to just sue YouTube for their own incompetence. Or ignorance. Or both.

I thought the idea behind the XXX domain was this : a website registers under that domain. 'Parental Filters' (there is a bad band name in the wings) block all XXX domains. The children are protected and the porn site owners have now made a reasonable attempt to exclude minors from viewing their site. That sounds like an inexpensive way to buy a reasonable amount of protection without resorting to laws or regulations.

Content providers can already use metadata to label HTML pages. Nothing stops porn webmasters from self-labelling their own webpages, and thus helping them be filtered accurately for the benefit of those people who wish to use web filters.

The schemes are generally compatible with all major filtering software. It's better than the proposed XXX domain, since that is at best a one-bit piece of information. For contrast, look at ICRA's label generator to see the better control that can be provided with the already-existing standards.

Anyway, this stuff has been around since the 1990s, and it's dead easy to use. If porn sites aren't already using it (and very few are), then there's no way they are going to voluntarily get rid of their own domain names in favor of xxx.

Well, your statement is correct for HTTP/1.0 and also would be correct for HTTP/1.1 if:

• establishing (and also destroying) of TCP connection required 0 (read zero) packets
• HTTP Keep-Alive and HTTP Pipelining did not deploy the concept of "connection reuse" to speed up download

Please take a look for example at HTTP/1.1 Connections and HTTP/1.1 Pipelining FAQ and also maybe some TCP/IP RFCs.

To sum the above: Keep-alive reuses one TCP connection to download multiple objects from the server thus saving you the time and resources to send extra packets needed to close current connection and establish new one.
Pipelining is helping you to reduce the latency by taking this concept a little bit further and issuing your next request before the response for previous request has been fully received.

http://www.w3.org/Amaya/

SOAP is not! the semantic web!

If you don't know that, then I suggest you turn the lights on before you eat stuff lying around you [...]

RDF is more RESTful than plain xml in many ways, since the terms in the language are URLS and so you can get their meaning. It is also very compatible with Atom. I am on the Atom Protocol list and my name is on the Atom Spec. So I know the debate well. I have a small AtomOwl ontology with XQuery transform, so you can transform andy atom document into XML. (ouch! xml. Damn people here find that too difficult! Are the people here your friends?) Think of RDF as databases + URIs. Take a plain old vanilla mysql database, add a RDF mapping, and you can query it with sparql. I know, I have done this for the Roller Blog database. (you know, the database that publishes atom feeds)

SOAP is not! the semantic web!

If you don't know that, then I suggest you turn the lights on before you eat stuff lying around you [...]

RDF is more RESTful than plain xml in many ways, since the terms in the language are URLS and so you can get their meaning. It is also very compatible with Atom. I am on the Atom Protocol list and my name is on the Atom Spec. So I know the debate well. I have a small AtomOwl ontology with XQuery transform, so you can transform andy atom document into XML. (ouch! xml. Damn people here find that too difficult! Are the people here your friends?) Think of RDF as databases + URIs. Take a plain old vanilla mysql database, add a RDF mapping, and you can query it with sparql. I know, I have done this for the Roller Blog database. (you know, the database that publishes atom feeds)

Well, there are more options than Internet Explorer or Firefox. Opera for instance. I myself hate the fact that if you specify firefox to always open links in a new tab, and not a new instance, it still now and then opens up a new browserwindow.
Amaya is a browser made by the w3consortium. I haven't tried it yet, but a browser made by them, well I'd expect it to adhere all the standards :)
You've also still got Netscape but that browser hasn't been a serious competitor for a while now'but it's still available if someone'd like to try :)

I'm afraid I'm still an opera fanboy. Like the looks, like the usage, like that it's crossplatform, like that it had tabbed browsing back in 1999.
If I had the time I would've tried amaya and would have written something more like a review, but I'm afraid I'm quite short on time at the moment.

You're probably not as smart as you think.

Every day I see websites, blogs, wikis, forums, and other such software all claiming "XHTML compliance". And sure, for the most part, many of them are well formed and run throught the w3 parser just fine.

HOWEVER, the vast majority of them are _not_ compliant!

Why is this? While the _markup_ is fine, the content is not being sent with the correct _mime type_, invalidating the document before parsing can even begin.

You see, the vast majority of XHTML documents are sent with the text/html header. Think of the mime type as being like an envelope that the document is sent inside.* The browser, when it gets the envelope, decides what parser it is going to use to process the contents inside. And it sees text/html, and sends it straight off to the tag soup parser, the _HTML_ parser, NOT the XHTML one.

The relevant standards show that unless you are serving "HTML compatible" XHTML (this is XHTML 1.0 transitional), you are in violation of the standards by serving XHTML as text/html. And since everyone's favourite web browser, IE6 (and 7), do not support proper XHTML mime types, you're stuck with at most XHTML 1.0 transitional.

And then, given the problems outlined with serving XHTML as HTML anyway, you may as well just use HTML 4 strict or transitional (if you want iframes).

So what does this have to do with this issue? Well, sure the vast majority of websites on the 'net do not use XHTML. But maybe that's partly because the user agent space simply isn't ready for it. Fix the user agents, then the supposed XHTML software out there can become compliant, and from there you may see more people make the transition.

Note: I'm not in any way defending _all_ of the websites out there that don't use XHTML. Just some of them :)

* With apologies to Martyn Smith, whom I borrowed the analogy from :)

http://validator.w3.org/check?uri=http%3A%2F%2Fwww .google.com Ah yes, I see your point.

Try reading the recc or RFC 3236 sometime. There's no problem serving XHTML to clients advertising the appropriate MIME string via accept. It's treated as XML otherwise it's served as text/html and treated as HTML.

That's the way XHTML was designed, the only problem here exists within Hixies head.

I believe that this is a response to the actions of the WHATWG (Web Hypertext Application Technology Working Group) (X)HTML 5 and to Bjoern Hoehrmann leaving the W3C QA.

So it's not a new pie-in-the-sky idea like XForms or XHTML2, but something much more likely to be useful to web developers that need to work in a world where IE is (still) the biggest fish.

You know, that's a good idea

http://validator.w3.org/check says Result: Failed validation

Yes, I would tend to agree

Yeah, that site is crap and displays signs of amateur web design. The colours are all wrong and make the text difficult to read. It doesn't even pass W3C validation.

What a joke.

Vastu doesn't include validation I guess.
http://validator.w3.org/check?verbose=1&uri=http%3 A%2F%2Fwww.webvastu.com%2F/

http://validator.w3.org/check says Result: Failed validation

If you can't get that right you've got no chance.

"display: inline-block" is NOT CSS 2, it's CSS 2.1, and CSS 2.1 is still only a Working Draft.

"display: inline-block" is NOT CSS 2, it's CSS 2.1, and CSS 2.1 is still only a Working Draft.

"display: inline-block" is NOT CSS 2, it's CSS 2.1, and CSS 2.1 is still only a Working Draft.

You may not have any idea about this one, but I figure I'll ask anyways. In IE6, a tag was required in the html to enable standards-compliant mode (which still wasn't, but that's beside the point). Why was this not enabled by default?

What you're talking about is the DOCTYPE declaration. If you want to write standards-compliant code, you should be testing it with the W3C Validator, which will give you a warning (with a link to an explanation) if you fail to include a DOCTYPE declaration.

If you don't want to write standards-compliant code, you probably want your site to look the same as it did in IE4, which means you don't want the browser to behave in a standards-compliant way. So, IE7 and IE6 and Firefox will all fall back to a "quirks mode" which attempts to guess what the HTML author meant, instead of following the standards. If this didn't happen, the majority of web sites would break, and users would blame the browser, not the web site.

While I agree that missing the Events module is definitely the BIGGEST problem, it's certainly not the ONLY problem, which is mostly what I was trying to get out. Also, I'm a fucktard and didn't preview my comment before posting (it's the only time I've ever not previewed a comment on Slashdot, I swear ;)) and Slashcode wiped out a bunch of what I was saying.

What I MEANT to write was:
* Tables that are created dynamically will not appear unless elements are added to <tbody> -- in other words, using DOM to write <table><tr><td>content</td><tr><table> does not display anything, even though <tbody> is optional.
* getElementsByTagName('object').item(0).getElements ByTagName('param') returns EVERY <param> IN THE ENTIRE DOCUMENT, not just ones under the requested object. Yikes!

As far as the navigator.plugins is concerned, it's definitely possible that it's a fragment of the browser wars, but that would be rather weird (except as an intentional attempt to sabotage Netscape Plugins API in order to push ActiveX -- something I find much more plausible than "fixing Netscape-only sites"). An empty nagivator.plugins would be just as easy to detect as one that didn't exist, and if something depended on it being there so that it could find a plugin, the site still wouldn't work in IE.

As an aside, between my last post and now, I ran some JavaScript unit tests from the W3C Compatibility Test Suite.

http://www.w3.org/2003/02/06-dom-support.html

DOM Conformance Test Suites
==========
DOM Core 1
----------
Internet Explorer 7 (37.95% failure)
Tests: 224
Errors: 4
Failures: 85

Opera 9.02 (11.34% failure)
Tests: 238
Errors: 12
Failures: 27

Firefox 1.5.0.7 (5.88% failure)
Tests: 238
Errors: 15
Failures: 14
==========
DOM Core 2
----------
Internet Explorer 7 (45.45% failure)
Tests: 11
Errors: 2
Failures: 5

Opera 9.02 (36.36% failure)
Tests: 11
Errors: 0
Failures: 4

Firefox 1.5.0.7 (18.18% failure)
Tests: 11
Errors: 0
Failures: 2
==========
DOM HTML 2
----------
Internet Explorer 7 (8.47% failure)
Tests: 685
Errors: 16
Failures: 58

Firefox 1.5.0.7 (1.31% failure)
Tests: 685
Errors: 0
Failures: 9

Opera 9.02
I tried about 20 times to get Opera to
complete this test, and it would constantly
fail to load files and Retry did nothing.
Oh, well. I'd guesstimate the failures are
probably around 2-3%.

I'd say there's a pretty serious fucking problem when nearly 38% of DOM Core 1 functionality is BROKEN.

Tables that are created dynamically will not appear unless elements are added to -- in other words, using DOM to write content does not display anything, even though is optional.

The TBODY start tag is always required except when the table contains only one table body and no table head or foot sections. The TBODY end tag may always be safely omitted.

You're writing HTML. You don't "support" any browser. Browsers support what you write.

There are these things called "standards", if you didn't know. From what I hear from "web developers", most do not. Look them up. Here, I'll even give you a URL: http://www.w3.org/

Now stop coding "for a browser" with overly complex garbage and code for standards. If it breaks a browser, that's the browser's goddamn problem. Tell your users to go where the standard lies, which is, generally, the latest Firefox.

I hate to respond as AC but this is admittedly a trollish response. However, it has to be this way because I'm really tired of "web developers" griping about how different browsers do things differently. Code to the standards and let the browsers come to you, not the other way around.

And the winner is: w3.org. The CSS section is probably the most useful part of it, but the whole thing is heartily recommended. To test you level of optimization there is an automated tool for HTML markup as well as one for CSS.

And the winner is: w3.org. The CSS section is probably the most useful part of it, but the whole thing is heartily recommended. To test you level of optimization there is an automated tool for HTML markup as well as one for CSS.

And the winner is: w3.org. The CSS section is probably the most useful part of it, but the whole thing is heartily recommended. To test you level of optimization there is an automated tool for HTML markup as well as one for CSS.

And the winner is: w3.org. The CSS section is probably the most useful part of it, but the whole thing is heartily recommended. To test you level of optimization there is an automated tool for HTML markup as well as one for CSS.

So if the guestbook posting form has no preview or confirmation page, then the spambot would leave a message simply by following this link! My guestbooks and message boards have a preview page, which is probably why I hadn't had any of this.

>>> It will only affect web developers who code to non-standards. Most of us code
>>> to a set of standards so that all our code can work well in ALL browsers not
>>> just IE.
>>
>> You've obviously never coded a page that had to display correctly on IE.
>
> Well you should tell that to Amazon and let them know just how their website doesn't work in IE.

Which standard does amazon.com code to then?

A nice simple online guide reference would be nice if any one knows one.

Here's one, from those who should know best.

http://www.w3.org/MarkUp/Forms/2003/xforms-for-htm l-authors.html

Is "select1" in that document an error?

The spec appears to have featureitis and I remember thinking xforms verbose when I played with the first mozilla release. Not quite XSLT verbose but not something that anyone is going to want to jump right into either.

xforms might be a good fit for an intranet app in the pipeline. Is there a better guide that explains what needs to happen on the server for replace="instance" etc?

Try AJAX with markup only, no hand-written JavaScript, by using the W3C's XForms standard. There are a number of implementations such as the Servlet-based Chiba (which fronts for Dojo and other packages), FormFaces written entirely in JavaScript (no server-side component), entire server-side pipeline systems such as Orbeon, and full client implementations such as the Mozilla/Firefox XForms Extension (just type "xforms" into your Firefox extensions finder), FormsPlayer IE Plugin, or cell-phone capable implementations such as PicoForms and SolidForms.

I wrote an entire webmail reader using PHP for the back end and XForms for the client. It runs in the Mozilla XForms implementation but could easily be made to work in any of the above, which differ mostly in how the CSS works. xmlmail

And for completness, I was an editor of an earlier version of the W3C XForms recommendation.

I make all my slide shows using XHTML. It sure takes a lot longer than PowerPoint, but it makes me feel all warm inside and that is all any of us are after.

Since when has internet access even been part of the equation?

• One.
• Two.
• Three.
• Four.
• Five.
• Six.
• Seven.

I'm sure many people can think of many other reasons why some OSes are more equal than others wrt internet and common usages of them now and particularly in the future