Slashdot Mirror

This website is so universal LOL
/sarcasm

...for example, [ISP caches] damage web hosts by messing up server statistics

Go read up on caching in HTTP and learn how to work with web caches instead of against them. Do it properly and you save bandwidth and server load while getting the non-cacheable requests you need/want.

Does it validate w3? The answer is no ;) Seriously however, robots.txt could have solved this issue. Oddly enough the site says I am not able to save/copy/print on their "help" page. I tried all the above on the main page and it worked. Shoddy protection to say the least.

Isn't there web standards and pratices that are done as a part of how the web operates? There is a way to post no robots or spiders in the HTML code that will stop everything from indexing their site.

This is like going to the tlelphone company, ordering some phone service, telling you friend you don't want a published number then suing the phone company for publishing the number.

There is a process and proceedure in place. I don't see how it could be anyones elses problem if you ignore that process or proceedure. There are standards and set policies about the web that anyone wanting to know can find out with reletive ease. I just did a quick google search for "stopping search engines from listing my site" and a ton of relevent answers poped up. A notable answer was this one from the W3.org describing the robots.txt standard and what you can do in adittion to it dating from 1996. It has around for that long.

It isn't anyones fault but hers if someone indexed her site because she didn't follow the proper proceedure to do so. Posting a warning in writing that she knows a spider/robot will read or understand is this girls way of invinting a lawsuit. She ignored proceedure and process with the implicit intent to trick someone into a lawsuit. And she used the shrinkwrap style license to do so. If anything was ever frivilous, this is.

I hope the fact that standard and rules that were in place before she decided to join the club were ignored helps invalidate sneakily placed information in shrink wrap licenses. I also hope it goes to show this as being a frivilous lawsuite and she gets punished as a result.

More information on this subject, including a detailed discussion of why content segregation is dangerous, can be found in RFC3675. It suggests an actual workable solution: PICS tags.

PICS Labels (Platform for Internet Content Selection) is a generalized system for providing "ratings" for Internet accessible material. The PICS documents should be consulted for details. In general, PICS assumes an arbitrarily large number of rating services and rating systems. Each service and system is identified by a URL.

It would be quite reasonable to have multiple PICS services that, in the aggregate, provided 300 bits of label information or more. There could be a PICS service for every community of interest. This sort of technology is really the only reasonable way to make categorizations or labelings of material available in a diverse and dynamic world.

While such PICS label services could be used to distribute government promulgated censorship categories, for example, it is not clear how this is any worse than government censorship via national firewalls.

A PICS rating system is essentially a definition of one or more dimensions and the numeric range of the values that can be assigned in each dimension to a rated object. A service is a source of labels where a label includes actual ratings. Ratings are either specific or generic. A specific rating applies only to the material at a particular URL [RFC 2396] and does not cover anything referenced from it, even included image files. A generic rating applies to the specified URL and to all URLs for which the stated URL is a prefix.

This seems like very much the "right" way of doing it. It:

1. Doesn't break any existing systems,
2. Is plenty flexible enough to be used for flagging pr0n as such, but also could be used by services like del.icio.us to suggest similar content to the current page,
3. And gracefully degrades to support systems that are unaware of it.

Also, unlike their proposed port breakage, it can easily be turned off if you don't care about it.

This has actually been discussed to some extent for years. One method is to only allow domains to be registered or displayed in a single language character set, such that a domain name can use latin characters or greek characters, but not both. This can be enforced at registration or when displayed in the browser (the browser can highlight improper URLs). This does not prevent attacks where the entire spelling of the domain is available in an alternate character set. One solution is for the browser to somehow tell the user what language a URL is written in.

Here is a detailed description of how IE handles this, and also a w3c page discussing general techniques and different browsers. An interesting note is the possible use of the fraction slash to add fake urls to a domain name. Of course, at the end of the day, standard phishing protection applies to domains which slip through the net.

Standards without a method of enforcement are called "suggestions".

HTML5 doesn't say things like "render like Opera 7 does"

Opera just fast-tracked their "HTML5" proposal with W3C: http://lists.w3.org/Archives/Public/www-forms/2007 Mar/0019.html

They're in Alignment, font styles, and horizontal rules : Fonts : Font style elements: the TT, I, B, BIG, SMALL, STRIKE, S, and U elements.

They're in Alignment, font styles, and horizontal rules : Fonts : Font style elements: the TT, I, B, BIG, SMALL, STRIKE, S, and U elements.

They're in Alignment, font styles, and horizontal rules : Fonts : Font style elements: the TT, I, B, BIG, SMALL, STRIKE, S, and U elements.

<i> tags aren't allowed in HTML strict, the DTD used for<nobr> <wbr></nobr>/. <em> tags are.

<!ENTITY % fontstyle
  "TT | I | B | BIG | SMALL">

<i> tags aren't allowed in HTML strict, the DTD used for<nobr> <wbr></nobr>/. <em> tags are.

<!ENTITY % fontstyle
  "TT | I | B | BIG | SMALL">

Take a look at the Web Accessibility roadmap from the W3C, and in particular the section on intent-based markup.

More on IE support for columns:

http://ln.hixie.ch/?count=1&start=1070385285

More on IE support for columns:

http://ln.hixie.ch/?count=1&start=1070385285

The W3C's technical architecture group (TAG) has published a document exploring the tradeoffs in creating Web content using imperative languages, such as JavaScript, vs. declarative languages such as HTML. See The Rule of Least Power, edited by Tim Berners-Lee and Noah Mendelsohn (yours truly).

From that document:

While it's not impossible that Google or other search engines would use some heuristic to extract information from the JavaScript source, actually running the program would involve many complexities, some of which have been mentioned by other commentors. Not the least of these relates to the famous halting problem. As paraphrased for the purposes of the TAG finding:

Whatever happened to the <noscript> element?

I don't use Mozilla/Firefox because of weird HTML bugs in valid HTML 4.x Strict pages.

There's something wrong when Firefox renders something incorrectly that IE gets right. Particularly for a 9 year old standard (published 18 December 1997).

I don't use Mozilla/Firefox because of weird HTML bugs in valid HTML 4.x Strict pages.

There's something wrong when Firefox renders something incorrectly that IE gets right. Particularly for a 9 year old standard (published 18 December 1997).

"PNG restarts the compression on each row"

That is absolutely not true, and would be madness if it were. From the specification, section 4.5.5:

The sequence of filtered scanlines in the pass or passes of the PNG image is compressed (see figure 4.10) by one of the defined compression methods. The concatenated filtered scanlines form the input to the compression stage. The output from the compression stage is a single compressed datastream.

Google's main page doesn't validate, and we all know how simple it is:
http://validator.w3.org/check?uri=http%3A%2F%2Fwww .google.com

Yahoo!'s main page doesn't validate, either:
http://validator.w3.org/check?uri=http%3A%2F%2Fwww .yahoo.com

Unexpectedly, MSN's front page is valid XHTML 1.0 Strict:
http://validator.w3.org/check?uri=http%3A%2F%2Fwww .msn.com

Google's main page doesn't validate, and we all know how simple it is:
http://validator.w3.org/check?uri=http%3A%2F%2Fwww .google.com

Yahoo!'s main page doesn't validate, either:
http://validator.w3.org/check?uri=http%3A%2F%2Fwww .yahoo.com

Unexpectedly, MSN's front page is valid XHTML 1.0 Strict:
http://validator.w3.org/check?uri=http%3A%2F%2Fwww .msn.com

Google's main page doesn't validate, and we all know how simple it is:
http://validator.w3.org/check?uri=http%3A%2F%2Fwww .google.com

Yahoo!'s main page doesn't validate, either:
http://validator.w3.org/check?uri=http%3A%2F%2Fwww .yahoo.com

Unexpectedly, MSN's front page is valid XHTML 1.0 Strict:
http://validator.w3.org/check?uri=http%3A%2F%2Fwww .msn.com

How it validates
They have more errors than they do lines of HTML.

http://validator.w3.org/check?uri=http%3A%2F%2Fwww .xcerion.com%2F

Those guys can't even put down proper HTML, I'm not sure i'd trust them to write a whole web-based "OS" in XML

Browsers are still playing catchup to full XHTML/CSS compliance.

'Javascript' is a moving target, with incompatible dialects in each browser. ECMA standardized the language some years back but vendors keep adding new features that aren't available in other browsers yet.

It would be nice if web designers could at least use a baseline of available web standards of 2006 and know that all the major browsers would support them correctly. i.e. CSS2.x, ECMA-262 v3 and E4X.

Sadly, today's web applications tend to implement workarounds specific to IE and firefox (gmail for example), leaving other browsers as unsupported.

So it's not about designing websites to run with any browser that will ever exist in the future but a battle creating ones that run using the standards of today. :( IE 6 is 5 1/2 years old and should be regarded as a legacy platform.

>
> Since when is XHTML2 going to be backwards compatible?
>

Yeah, but you forgot about HTML 4.5 ^_^;

http://dig.csail.mit.edu/breadcrumbs/node/166

I don't even have the energy to quote you some "morceaux choisis"...

There is all this stuff about how using quotes for attributes, using "xml:lang" or closed empty elements being such a huge forward step than most people are so confused they are mixing HTML 4.01 and XHTML 1.0 without a care... and I'm not even talking about XML in general... God...

So, chaired by some Microsoft guy (some guy who "likes standards", it seems), they created some workgroup to create something like HTML 4.5, as a transition...

Enjoy. ... doh, I just saw they published my comment on http://www.w3.org/QA/2006/10/reinventing_html_disc uss.html#c016916 ^_^; At least, they are relatively transparent (which does not change much, though). Really, this is what they are doing, knowingly: `Do you feel the web developer/master job is still too easy? I mean, "let's make it a bit harder, so we won't lose our job because everyone would otherwise be able to do it"... is this it?`.

This is what Web 2.0 is all about... but they are adding yet a bit more of mud, with this HTML 4.5, which they will never ever use themselves...

Nice try, but XML and HTML are subsets of SGML. See the abstract in the spec document.

You pushed too hard again, didn't you? Now we all have to suffer.

Hey slashdot, fix your RSS feed!

Many things which people might want to do on a website, and which are easily accomplished using standard code, simply don't work on IE... Thus, many sites deviate from the standards to support IE users, since there are rather too many of them out there. The alternative, is sticking to the subset of the standard that IE does support, and having a reduced site.
Look at the CSS homepage - http://www.w3.org/Style/CSS and select the blue shadow style, that used to be the default, but because it gets completely mangled by IE6 (not tried 7) they changed it because people thought the site was broken.

You're typing any of this stuff by hand? You're kidding right?

JSON and XML are appropriate as a wire protocol for app 2 app communication. JSON is appropriate only when the receiving application is written in java script. There are only two scenarios that I can think off right off the bat that I might hand type XML. One is a configuration file (e.g. WEB-INF\web.xml) and the other is a GRDDL style personal vanity site which isn't going to be that much more typing than HTML.

Typing lots of content using any markup language just doesn't scale.

With regards to JSON vs XML in AJAX apps, I am currently reading a Christian Gross book called Ajax Patterns and Best Practices. He prefers XML over JSON because of the man-in-the-middle code injection vulnerability with JSON. In order to convert the JSON formatted string to a java script object hierarchy, you must evaluate it. You always use an XML parser on XML. I really prefer JSON because java script that calls the XML DOM is a lot more complicated than java script that just references another java script object hierarchy. If you are really concerned about this rare form of intrusion, then scan the input string for injection markers before passing it to eval.

I would be interested in other developer's opinions on this.

You're typing any of this stuff by hand? You're kidding right?

JSON and XML are appropriate as a wire protocol for app 2 app communication. JSON is appropriate only when the receiving application is written in java script. There are only two scenarios that I can think off right off the bat that I might hand type XML. One is a configuration file (e.g. WEB-INF\web.xml) and the other is a GRDDL style personal vanity site which isn't going to be that much more typing than HTML.

Typing lots of content using any markup language just doesn't scale.

With regards to JSON vs XML in AJAX apps, I am currently reading a Christian Gross book called Ajax Patterns and Best Practices. He prefers XML over JSON because of the man-in-the-middle code injection vulnerability with JSON. In order to convert the JSON formatted string to a java script object hierarchy, you must evaluate it. You always use an XML parser on XML. I really prefer JSON because java script that calls the XML DOM is a lot more complicated than java script that just references another java script object hierarchy. If you are really concerned about this rare form of intrusion, then scan the input string for injection markers before passing it to eval.

I would be interested in other developer's opinions on this.

• It has <section>-elements that can be used to specify chapters
• Elements can have a "src"-attribute, that can include content
• Headers/footers/pages can be defined using CSS3

Start with clean code: Trent Lucier

gewg_

Although we (W3C) are in fact working on more efficient binary encodings (www.w3.org/XML/EXI) this misses the point a little.

The good thing about XML is that it isn't good for anything, but is mediocre for everything :-)

The main original use case were not "INI files" or other configuration stuff, but computer documentation, and transcriptions of texts. Mixed content, such as paragraphs of running text in which certain items are marked, or tagged, in some way, was the primary goal. We really didn't predict things like Web services!

XML is here, though. Almost every XML expert (myself included, and no irony here) would like to see XML be slightly different in some way, but we all also understand that the importance that every XML tool can have a stab at doing something useful with just about any XML document. And yes, there are people who like using emacs/vi/textedit/eclipse/wordpad/whatever in addition to tools like oxygen or Stylus Studio.

Liam

I disagree with an age tag. Who's to say what's appropriate for a 12 year old or a 17 year old?

What I'd like to see is something similar to PICS. There are different categories. For example (from ICRA):

languagesexual, languageprofanity, languagemildexpletives, nuditygraphic, nuditymalegraphic, nudityfemalegraphic, nuditytopless, nuditybottoms, nuditysexualacts, nudityobscuredsexualacts, nuditysexualtouching, nuditykissing, nudityartistic, nudityeducational, nuditymedical, drugstobacco, drugsalcohol, drugsuse, gambling, weaponuse, intolerance, badexample, pgmaterial, violencerape, violencetohumans, violencetoanimals, violencetofantasy, violencekillinghumans, violencekillinganimals, violencekillingfantasy, violenceinjuryhumans, violenceinjuryanimals, violenceinjuryfantasy, violenceartisitic, violenceeducational, violencemedical, violencesports, violenceobjects

What could then be done is have the client (ie, the TV) have preconfigured settings based on the above ratings. Similar to G, PG, PG-13, R, NC-17, etc. However, the user would also be able to customize the settings to however they wish. That's the important difference. Ie, if they believe that "nuditysexualacts" and is fine for their 13 year old but not "violencerape", they could configure it that way.

<xml><I><am><so><damn>Web 2.0</damn></so></am></I></xml>

Your markup is invalid. Any element or attribute name beginning with the string "xml" is reserved by the spec.

(This is actually a simplification of the truth, see http://www.w3.org/TR/REC-xml/#dt-name for details.)

First,you only need one disenfranchised user to sue you. For example, if you are operating a Web site in the US (or in many cases the EU or Canada) anti-discrimination laws mean you'd better make your site accessible. And that means accessible to someone using a text-based browser such as Lynx, as well as a text reader. See the American Disabilities Act and the "508" laws.

Second, yes, you can make a Web site more cheaply that's aimed at, say, IE 6. Or IE 7. or maybe you could choose Mosaic 1.5, or Netscape 0.96, as some other sites did. And in a few years you might have to redo everything when that particular browser is no longer available.

Third, you could optimize your site for a particular screen size. For example, 640x480 pixels or even 800x600 are popular choices. Of course, you can't actually buy a desktop PC with a 640x480 pixel screen very easily today. Mine is 1680x1050, but sizes vary widely, mostly because of the emerging popularity of watching DVDs on a computer. But, right now a surprising number of people in some parts of the world (Europe and Japan mostly I think) seem to browse the Web on a mobile phone, and those often have 320x240 pixel screens.

The point of the World Wide Web is that it's for everyone, everywhere, regardless of language, culture, ability, special needs or even computing platform. Do the right thing. Make your site work on as many platforms as you can, by sticking to standards, avoiding platform-specific tricks, and testing.

[disclaimer: I work for the World Wide Web Consortium, although in this area my opinions expressed here also match those of my empolyer!]

Why would anyone use camel case function names in a language that doesn't support case sensitivity in function names?

camelCase is used for method names for a reason (hint) and global functions should use underscores.

register globals - has anyone in the last four years ever located a PHP installation that uses this? Agreed this was a horribly bad idea, but long since been fixed

Fixed into $HTTP_*_VARS, $_GET, $_SERVER, $_POST, $_COOKIE, $_SESSION, $_FILES, $_ENV, $_REQUEST and $GLOBALS superglobals yet idiots still print_r() unvalidated input!

confusion about escaped quotes - so the programmer can get confused, therefore the language isn't good enough?

In SQL quotes are escaped with another quote so 'foo' becomes ''foo''. Magic quotes was a stupid MySQLism that caused real pain moving code between servers.

native unicode support - okay, this could be legitimate, but most languages since the dawn time (1970) haven't had unicode support, and the world got by just fine using multibyte strings without direct unicode support

Sorry, I was under the impression PHP was a specialist language for the web? How long has javascript had unicode support again?

variables can be used before they are defined - ok, C does that too, I always compile -Wall C, and I always use E_NOTICE on PHP

PHP has variable variables for self modifying code etc.

namespace support - (you already mentioned, I guess no shortage is actually 6) You shouldn't be writing enterprise wide databases in PHP, you should be designing dynamic HTML ages in PHP, You shouldn't have conflicting function names.

Was that an admission PHP is useless for large scale projects without namespaces?

I must conclude that absence of namespaces is not sufficient grounds to want to punch myself in the balls.

Try writing something more complex than a homepage or forum and it just might!

Whatever happens to standards?
http://validator.w3.org/

You can make anything you like available on a web server. If someone complains, and it follows the standards, then it's their fault. If it doesn't, then it's yours.

Javascript is netscape's (and now mozilla's) implementation of ECMAScript. If you want to become a master of the language then reading the ECMAScript's spec is an excellent way of doing it since both Javascript and JScript (explorer's implementation of ECMAScript) will follow the EMCAScript spec more than less...

http://en.wikipedia.org/wiki/JavaScript (first line)

The really difficult thing with javascript (I really mean ECMAScript but meh. It's common usage to say javascript when really talking about EMCAScript since ECMAScript is a pain in the ass to say) is the DOM. The DOM spec is maintained by these guys: http://www.w3.org/DOM/.. The two major browsers actually implement most of the DOM and implement it the same way. So you can write to the spec on the w3's web site and not worry about (too much) about compatibility.. Well, some things aren't very well supported, like events, but most of the official DOM spec is supported by both major web browsers anyways..

No one should be modding up the parent. It is offtopic!

> But metadata is hard to convey over the internet.
> HTTP doesn't have a standard mechanism for telling me what's really in the file

Of course it does.
http://www.w3.org/Protocols/rfc2616/rfc2616-sec14. html
> 14.1. ACCEPT
> The Accept request-header field can be used to specify certain media types which are acceptable for the response.

>14.17 Content-Type
>The Content-Type entity-header field indicates the media type of the entity-body sent to the recipient or, in the case of the HEAD method, the media type that would have been sent had the request been a GET.

So it has both a method for the client to specify what he wants and a method for the server to specify what the client will/would get.

MIME Types are derivable, so you can just derive custom mime types. I.e. "application/x-xpi" subclass of "application/zip".

Use "video/x-theora" or specify attributes ON the mime type, e.g.
"application/ogg; video=theora"

(Interesting how the filename ending stuff is prevalent and drains out any of the more advanced typing mechanisms - guess that's the advantage of being in-the-way, in-your-face: you don't ever forget it)

> and webservers usually determine the MIME type by looking at the extension.

Some do, some don't. Irrelevant anyway. They can determine media type by throwing rocks over the water and see which goes furthest for all that matters.

> Of course the latter could be rectified by scanning the file, but that would take up much more resources than just looking at the file name.

{sarcasm}Especially since CPU resources are so rare nowadays.{/sarcasm}

Or you could use any modern operating system that can store metadata (whether they call it "Extended Attributes", "Pseudo Files", "Streams", use a relational database like WinFS or whatever).

One day the endless dumbing-down-for-a-1Mhz-computer-who-cares-if-it-l ooks-like-horse-shit-to-the-user should stop on desktop machines.

Formulas allow calculations to be performed within table cells. Every formula should begin with a namespace prefix specifying the syntax and semantics used within the formula. Typically, the formula itself begins with an equal (=) sign and can include the following components:

  Numbers.

  Text.

  Named ranges.

  Operators.

  Logical operators.

  Function calls.

  Addresses of cells that contain numbers. The addresses can be relative or absolute, see section 8.3.1. Addresses in formulas start with a "[" and end with a "]". See sections 8.3.1 and 8.3.1 for information about how to address a cell or cell range.

The following is an example of a simple formula:

=sum([.A1:.A5])

This formula calculates the sum of the values of all cells in the range ".A1:.A5". The function is "sum". The parameters are marked by a "(" at the start and a ")" at the end. If a function contains more than one parameter, the parameters are separated by a ";".

Since HTML 4, frames have not been part of the standard HTML DTD. You have to use the frameset DTDs, which include all the deprecated elements including frames. As of XHTML 1.1, iframe has been dropped entirely.

http://www.w3.org/TR/html4/struct/global.html#vers ion-info
http://www.w3.org/TR/xhtml11/doctype.html

Since HTML 4, frames have not been part of the standard HTML DTD. You have to use the frameset DTDs, which include all the deprecated elements including frames. As of XHTML 1.1, iframe has been dropped entirely.

http://www.w3.org/TR/html4/struct/global.html#vers ion-info
http://www.w3.org/TR/xhtml11/doctype.html

What the heck are you talking about? What is it that you're saying you should be able to do with this HTML that you can't do with frames in the same amount of code?

But besides the first point's incomprehensibility, the second point:

But no sir! They even had to remove the target attribute from XHTML Strict! Notice how my code would have been XHTML+CSS valid without this restriction that makes me write more hacks (rel="external" and an ugly JS to add the target attributes on page load).

...is ridiculous. If you need the target attribute so badly, use HTML 4.0 Transitional or xhtml 1.0 Transitional. No problems. Better yet, if you're using frames, why not use the right doctype in the first place? iframes and target attributes are alive and well in xhtml 1.0 Frameset...