Didn't MS introduce their own "standard" for stylesheets at one point?
You're probably thinking of JSSS, which was a stylesheet language based upon Javascript, introduced by Netscape 4, that competed with CSS. Internet Explorer has had a partial implementation of CSS since 3.0 (it was the first browser with CSS support).
I dislike CSS because it makes the most common layout formatting (columns) hard to implement
That's a common misconception. CSS has made that easy for seven years (display: table-cell), it's part of the CSS 2 specification.
The reason why nobody knows about it is because even though Safari, Mozilla, Opera, Konqueror, Firefox, Omniweb, etc. implement it, Internet Explorer doesn't, which means it might as well not exist.
This is why everybody is so keen for Microsoft to implement CSS 2. Or CSS 2.1, which is CSS 2.0 with the more difficult parts taken out and a couple of proprietary Internet Explorer properties thrown in.
It's not "CSS making it hard", it's "CSS making it easy and Microsoft making it hard".
I also dislike that it has no inheritance.
For most purposes, grouping selectors is more than enough. The example you gave is a bit odd, because CSS lets you do that easily:
Now, lets look at some fairly popular languages that have been open-source since the beginning: perl, python, tcl, ruby. Gee, not one of them has shown the faintest sign of forking.
Actually, there are at least six forks of Python:
CPython (the canonical version)
Jython (compiles to Java bytecode)
Psyco (JIT compilation of a sort)
Pypy (Python implemented in Python)
ActivePython (ActiveState's fork)
IronPython (compiles to.NET bytecode)
In practice, it's not much of a problem, I don't see why people are so scared of forking.
gzip was created in response to the patent status of the algorithm in compress
I know. That's what I said. compress uses LZW.
the GP said that gzip uses the same algorithm as zip.
ZIP can use multiple algorithms, one of them being LZW - the very algorithm that gzip was created to avoid. ZIP and compress both use this algorithm, gzip does not.
Zip uses deflate, just like gzip does. Sure, newer versions of zip can use LZW
No, deflate is just one of the algorithms that ZIP can use. LZW is another one. gzip deliberately avoids LZW, which is probably why it does not compress as well as ZIP (which is how this thread started).
'How company can make money, if its products are available for free?'
Simple answer: it's extremely dificult to do so.
The question you should be asking is 'How can a company make money, if it gives away software for free?', and the answer should be more obvious - it can do so if its product is not the software it's giving away.
For instance, IBM's "product" is the tailor-made services and consultancy it provides. The software is merely a tool they use to provide it.
You might argue that keeping such tools to yourself is a commercial advantage over your competitors. That's true to an extent, but there are also downsides - e.g. if you provide your own proprietary operating system instead, you don't get benefits contributed by the community, and your competitors are more attractive because there is no lock-in.
It sounds correct to me, although you should consult a lawyer. Essentially, you would be locking yourself into a single vendor, because you wouldn't be able to operate your website without their proprietary libraries.
As somebody mentioned elsewhere, it might not be feasible to get copyright signed over to you for components like this, but you should get something in writing entitling you to use of the libraries should you want to take your business elsewhere. Remember, you need source, or you might have showstopper bugs that you can't fix (or pay somebody to fix).
You always have the option of taking the risk and locking yourself into that firm. It just seems to be an unnecessary risk as far as I'm concerned.
Where do you see that they could save bandwidth but aren't bothering?
Look at a results page, for example. They could eliminate over 1K per page load simply by moving the CSS and Javascript into external resources.
I'm sure you're thinking "but the client has to download them anyway". Not from Google. Google is that popular, and the resources change that infrequently, that virtually every shared cache in existence would keep a copy of the resource, meaning Google would effectively cease serving it from their servers almost entirely.
Even if that weren't the case, Google would still come out ahead in the bandwidth stakes for every visitor that loads more than a single page, as the presentation would be shared across multiple pages, yet only downloaded once.
Embedding the CSS in the (not publically cachable) HTML documents means that every visitor has to download the unchanging presentation for every page load individually.
Maybe they could probably also use stylesheets to save some, but that might get in the way of the goal of having Google render properly in EVERY browser.
They already use CSS. They could save even more bandwidth by dropping the <font> elements, which would mean that Internet Explorer 2 and Netscape Navigator 3 wouldn't be quite so colourful.
They probably save untold gigabytes just by not putting a doctype, type attributes, alt tags, etc.
Doubtful; last time I looked, there were plenty of other places they could save on bandwidth easily and they don't bother. Mistakes in HTML are usually due to ignorance or apathy, not bandwidth reduction. You don't have to look very far to find a prime example:).
I believe it's a little bit of both. Safari initially had problems, so Google fixed things up a little for them. Konqueror still had difficulties, and the Konqueror developers fixed a couple of bugs their end as well.
It's definitely an advantage to have Safari using KHTML; I doubt Google would have made these changes for Konqueror alone.
Unfortunately, the new browser detection code they are now using seems to have been put together in a rather sloppy manner
They shouldn't be detecting the browser at all. It's fragile, it breaks with unusual browsers, and you have to keep updating the detection routines whenever a new browser comes out. It's Javascript straight out of the 1990s.
The proper way of doing it is to detect objects not browsers. If you need XMLHttpRequest, first check to see if XMLHttpRequest is defined. If so, use it. If not, try instantiating it the Microsoft way. If you get the object, use it. Otherwise, give the user the fallback plain HTML version. You don't need to worry about which browser is being used, so long as it supports the APIs you use, and new browsers, or browsers that you haven't heard of, work automatically without you having to alter your code to accommodate them.
Sure they have, in bits and pieces here and there. Nice hacks. But the entire GMail interface depends on these hacks. That's the difference.
You're saying that it's innovative because it's depended upon instead of having a fallback? People have been writing Javascript that doesn't have a fallback since the days of Netscape 2.0. It's a pain in the neck and certainly not anything innovative.
I honestly don't see anything whatsoever that GMail does that hasn't been done elsewhere years ago. I see a lot of people impressed because it's the first time they've seen these techniques applied. That doesn't make it innovative, just popular.
Here experience is paramount.
I'm not going to say this again: go back and read what I am writing. Graceful degradation does not have any negative effect on the users' experiences whatsoever.
This might be an issue inside the NSA/CIA but in the rest of the real world this is never going to happen,
Ahh, yes, the "real world" argument. It can be summarised as "I haven't seen it, I don't want to deal with it, so it doesn't happen".
Yes, the clients with Javascript available far outnumber the clients with Javascript unavailable. But there are plenty of legitimate reasons for using a client with Javascript unavailable, some of which are very important to cater to. Blind users and search engines generally don't get on well with Javascript, for instance.
Are you familiar with the HCI definition of 'verbs'? There are certain UI verbs that a richer-UI platform will allow that less-rich platforms simply don't.
You're looking at the wrong level. The aim isn't to provide the same UI to lesser browsers, the aim is to provide the same functionality. In some cases, this is impossible - video streaming to Lynx, for example, but this isn't the norm.
GMail, for example. Which features of GMail are impossible for a non-Javascript client? I can't think of any off the top of my head. But Google have coded the interface so that it depends upon Javascript. There are well-established techniques that have been in use for years that mean locking out non-Javascript clients just isn't necessary. And these techniques do not require any changes to the interface for the clients that already handle what Google expects.
From everything you are writing, it seems you still don't understand the concept of graceful degradation, so I'll give the simplest example I can think of:
The first link is an example of fragile code. It works for clients that have Javascript available, and breaks for everyone else.
The second link is an example of highest common factor design. Since not all clients can understand Javascript, it doesn't use it. It works for all clients, but at the cost of sacrificing the extra functionality that clients with Javascript available have with the first example.
The third link is an example of graceful degradation. Clients with Javascript available get the extra functionality that is possible for them, and it still works for clients without Javascript available.
It sounds like you still think I'm talking about highest common factor design. I am not.
That doesn't really matter with respect to this story. The thing is, us humans have brains that are built to recognise patterns. A completely random sequence of songs will have something that appears to be a pattern before too long. If there was no possibility of this, then it wouldn't be truly random, would it?
Now, you take all the people who have iPod Shuffles, you realise that a lot of them will have been listening to them a lot, and you take the above fact into consideration, and you'll soon realise that there will be quite a few people who have noticed patterns in their random sequence of songs.
A minority of these will think there's a conspiracy, and tell others, perhaps even a journalist or two. It doesn't mean a thing though, because it's a natural consequence of truly random sequences.
It's like monkeys and Shakespeare. If enough people listen to their iPod Shuffles, if they are truly random, eventually there'll be some unfortunate person whose iPod won't stop playing the YMCA.
There is nothing Flash can do that html cannot, except make the page cutesy and ten times longer to load.
That's not true. Vector graphics, for a start (and that can speed up download times, not slow them down). Can't the latest versions use sockets and connect to databases from the client too?
Their fuckwittery isn't just limited to the Internet. I bought 28 Days Later (Region Two), and it has unskippable adverts at the beginning of the DVD. I hear that's not uncommon with Region One now, but it's the first time I've encountered it. Utterly ridiculous. If all DVDs were like that, I'd stop buying and start downloading.
Its the difference between saying "you shall not position elements" and "you shall not position elements on top of other elements (as opposed to inside them, for example)".
But this still leaves loads of sites that will break when you tamper with stuff like this. It's not as clear-cut as unrequested popups, it's things as simple as drop-down menus.
A useful limit to javascript would be to allow it to ONLY alter class/id data; not to add page source. (so you can show/hide elements, but not ADD them later; ergo everything shows up in view source)
That would be a counterproductive limit. You don't want to force web developers to include everything as content. Lots of techniques that enable web developers to transparently include features that enhance websites without breaking things for browsers that don't support it depend on being able to alter the page content. If such restrictions were commonplace, web developers would be faced with either not including the features or breaking things for people who use certain browsers.
Until a decent way of determining what is legitimate use of these techniques and what isn't automatically is found, you're simply throwing out the baby with the bathwater. Anybody who is willing to break such wide-ranging techniques as these would be better off simply disabling Javascript altogether.
remember specificity as well; more specific instructions can overwrite your general ones
No they can't. Did you miss the !important?
The browser should treat incoming pages as "suspect" and permit them to do only what the user allows; not the current state where they are assumed to be fine, and can do whatever they like.
You are missing the point. It's not the policy of disallowing by default that causes the problems. It's deciding what features can be usefully singled out to specifically allow/disallow that is difficult. What's an advert is obvious to a human, but the few dozen lines of code that produce it - every individual statement of which is used usefully in millions of websites - aren't obviously an advert to a computer.
The standards should force pages to act in a responsible and TRACEABLE fashion
I'm not sure what you mean by this, I can look at the address bar to see who's responsible for a page.
I can safely say the only time I click on an ad when online, is when my mouse slips?
I've clicked on an advert and bought something.
It was a small, text-only advert that simply gave the relevent product details: root on a FreeBSD virtual server for $65/mo, no set-up fee. I saw it, I thought it sounded like a good deal, clicked through, their website was simple and clear, so I signed up. They've given excellent service with the best technical support I've ever found in a hosting company, and I've been using them for years now.
I realise this sounds like an advert, but I'm not paid to say this or anything; I think it's a good example of effective advertising - a targeted ad that gives the relevent facts without being obtrusive, followed up with an excellent product. Compared with the "throw yourself at as many eyeballs as you can" approach, I know which I'm willing to tolerate and even give business to, and which I am going to block permanently.
Slashdot Mirror
You're probably thinking of JSSS, which was a stylesheet language based upon Javascript, introduced by Netscape 4, that competed with CSS. Internet Explorer has had a partial implementation of CSS since 3.0 (it was the first browser with CSS support).
That's a common misconception. CSS has made that easy for seven years (display: table-cell), it's part of the CSS 2 specification.
The reason why nobody knows about it is because even though Safari, Mozilla, Opera, Konqueror, Firefox, Omniweb, etc. implement it, Internet Explorer doesn't, which means it might as well not exist.
This is why everybody is so keen for Microsoft to implement CSS 2. Or CSS 2.1, which is CSS 2.0 with the more difficult parts taken out and a couple of proprietary Internet Explorer properties thrown in.
It's not "CSS making it hard", it's "CSS making it easy and Microsoft making it hard".
For most purposes, grouping selectors is more than enough. The example you gave is a bit odd, because CSS lets you do that easily:
Oops, there's also Stackless Python. I knew I forgot one.
Actually, there are at least six forks of Python:
In practice, it's not much of a problem, I don't see why people are so scared of forking.
I know. That's what I said. compress uses LZW.
ZIP can use multiple algorithms, one of them being LZW - the very algorithm that gzip was created to avoid. ZIP and compress both use this algorithm, gzip does not.
No, deflate is just one of the algorithms that ZIP can use. LZW is another one. gzip deliberately avoids LZW, which is probably why it does not compress as well as ZIP (which is how this thread started).
Are you kidding? Redhat contribute to a lot of high-profile open source projects. They also provide hosting to many projects.
Simple answer: it's extremely dificult to do so.
The question you should be asking is 'How can a company make money, if it gives away software for free?', and the answer should be more obvious - it can do so if its product is not the software it's giving away.
For instance, IBM's "product" is the tailor-made services and consultancy it provides. The software is merely a tool they use to provide it.
You might argue that keeping such tools to yourself is a commercial advantage over your competitors. That's true to an extent, but there are also downsides - e.g. if you provide your own proprietary operating system instead, you don't get benefits contributed by the community, and your competitors are more attractive because there is no lock-in.
According to the ZIP file format specification, ZIP can use a dynamic LZW algorithm.
The whole reason gzip exists is because the standard UNIX compress uses LZW - which, until recently, was protected by a patent (that was the problem with GIFs).
Instead of using LZW, gzip uses the unprotected LZ algorithm, which doesn't contain the improvements that Welch (the 'W' in LZW) made.
So not only do they not use the same algorithm, but that's the whole point of gzip in the first place!
It sounds correct to me, although you should consult a lawyer. Essentially, you would be locking yourself into a single vendor, because you wouldn't be able to operate your website without their proprietary libraries.
As somebody mentioned elsewhere, it might not be feasible to get copyright signed over to you for components like this, but you should get something in writing entitling you to use of the libraries should you want to take your business elsewhere. Remember, you need source, or you might have showstopper bugs that you can't fix (or pay somebody to fix).
You always have the option of taking the risk and locking yourself into that firm. It just seems to be an unnecessary risk as far as I'm concerned.
I said no such thing.
Opera can't "imitate any browser". It can provide arbitrary user-agent strings, but that's nothing like using the Internet Explorer rendering engine.
I can't see those pages easily because they redirect to .co.uk, but see this comment for an example of cutting code.
Look at a results page, for example. They could eliminate over 1K per page load simply by moving the CSS and Javascript into external resources.
I'm sure you're thinking "but the client has to download them anyway". Not from Google. Google is that popular, and the resources change that infrequently, that virtually every shared cache in existence would keep a copy of the resource, meaning Google would effectively cease serving it from their servers almost entirely.
Even if that weren't the case, Google would still come out ahead in the bandwidth stakes for every visitor that loads more than a single page, as the presentation would be shared across multiple pages, yet only downloaded once.
Embedding the CSS in the (not publically cachable) HTML documents means that every visitor has to download the unchanging presentation for every page load individually.
They already use CSS. They could save even more bandwidth by dropping the <font> elements, which would mean that Internet Explorer 2 and Netscape Navigator 3 wouldn't be quite so colourful.
Doubtful; last time I looked, there were plenty of other places they could save on bandwidth easily and they don't bother. Mistakes in HTML are usually due to ignorance or apathy, not bandwidth reduction. You don't have to look very far to find a prime example :).
I believe it's a little bit of both. Safari initially had problems, so Google fixed things up a little for them. Konqueror still had difficulties, and the Konqueror developers fixed a couple of bugs their end as well.
It's definitely an advantage to have Safari using KHTML; I doubt Google would have made these changes for Konqueror alone.
They shouldn't be detecting the browser at all. It's fragile, it breaks with unusual browsers, and you have to keep updating the detection routines whenever a new browser comes out. It's Javascript straight out of the 1990s.
The proper way of doing it is to detect objects not browsers. If you need XMLHttpRequest, first check to see if XMLHttpRequest is defined. If so, use it. If not, try instantiating it the Microsoft way. If you get the object, use it. Otherwise, give the user the fallback plain HTML version. You don't need to worry about which browser is being used, so long as it supports the APIs you use, and new browsers, or browsers that you haven't heard of, work automatically without you having to alter your code to accommodate them.
Internet Explorer 7 will be available for Windows XP.
You're saying that it's innovative because it's depended upon instead of having a fallback? People have been writing Javascript that doesn't have a fallback since the days of Netscape 2.0. It's a pain in the neck and certainly not anything innovative.
I honestly don't see anything whatsoever that GMail does that hasn't been done elsewhere years ago. I see a lot of people impressed because it's the first time they've seen these techniques applied. That doesn't make it innovative, just popular.
I'm not going to say this again: go back and read what I am writing. Graceful degradation does not have any negative effect on the users' experiences whatsoever.
Ahh, yes, the "real world" argument. It can be summarised as "I haven't seen it, I don't want to deal with it, so it doesn't happen".
Yes, the clients with Javascript available far outnumber the clients with Javascript unavailable. But there are plenty of legitimate reasons for using a client with Javascript unavailable, some of which are very important to cater to. Blind users and search engines generally don't get on well with Javascript, for instance.
You're looking at the wrong level. The aim isn't to provide the same UI to lesser browsers, the aim is to provide the same functionality. In some cases, this is impossible - video streaming to Lynx, for example, but this isn't the norm.
GMail, for example. Which features of GMail are impossible for a non-Javascript client? I can't think of any off the top of my head. But Google have coded the interface so that it depends upon Javascript. There are well-established techniques that have been in use for years that mean locking out non-Javascript clients just isn't necessary. And these techniques do not require any changes to the interface for the clients that already handle what Google expects.
From everything you are writing, it seems you still don't understand the concept of graceful degradation, so I'll give the simplest example I can think of:
The first link is an example of fragile code. It works for clients that have Javascript available, and breaks for everyone else.
The second link is an example of highest common factor design. Since not all clients can understand Javascript, it doesn't use it. It works for all clients, but at the cost of sacrificing the extra functionality that clients with Javascript available have with the first example.
The third link is an example of graceful degradation. Clients with Javascript available get the extra functionality that is possible for them, and it still works for clients without Javascript available.
It sounds like you still think I'm talking about highest common factor design. I am not.
That doesn't really matter with respect to this story. The thing is, us humans have brains that are built to recognise patterns. A completely random sequence of songs will have something that appears to be a pattern before too long. If there was no possibility of this, then it wouldn't be truly random, would it?
Now, you take all the people who have iPod Shuffles, you realise that a lot of them will have been listening to them a lot, and you take the above fact into consideration, and you'll soon realise that there will be quite a few people who have noticed patterns in their random sequence of songs.
A minority of these will think there's a conspiracy, and tell others, perhaps even a journalist or two. It doesn't mean a thing though, because it's a natural consequence of truly random sequences.
It's like monkeys and Shakespeare. If enough people listen to their iPod Shuffles, if they are truly random, eventually there'll be some unfortunate person whose iPod won't stop playing the YMCA.
Okay, I'll bite. I don't work for them, and I don't see anything in my history that could possibly suggest that I did. I hate spam as much as anybody.
So what, was this just a drive-by trolling, or do you actually have a reason for believing that?
That's not true. Vector graphics, for a start (and that can speed up download times, not slow them down). Can't the latest versions use sockets and connect to databases from the client too?
Their fuckwittery isn't just limited to the Internet. I bought 28 Days Later (Region Two), and it has unskippable adverts at the beginning of the DVD. I hear that's not uncommon with Region One now, but it's the first time I've encountered it. Utterly ridiculous. If all DVDs were like that, I'd stop buying and start downloading.
But this still leaves loads of sites that will break when you tamper with stuff like this. It's not as clear-cut as unrequested popups, it's things as simple as drop-down menus.
That would be a counterproductive limit. You don't want to force web developers to include everything as content. Lots of techniques that enable web developers to transparently include features that enhance websites without breaking things for browsers that don't support it depend on being able to alter the page content. If such restrictions were commonplace, web developers would be faced with either not including the features or breaking things for people who use certain browsers.
Until a decent way of determining what is legitimate use of these techniques and what isn't automatically is found, you're simply throwing out the baby with the bathwater. Anybody who is willing to break such wide-ranging techniques as these would be better off simply disabling Javascript altogether.
No they can't. Did you miss the !important?
You are missing the point. It's not the policy of disallowing by default that causes the problems. It's deciding what features can be usefully singled out to specifically allow/disallow that is difficult. What's an advert is obvious to a human, but the few dozen lines of code that produce it - every individual statement of which is used usefully in millions of websites - aren't obviously an advert to a computer.
I'm not sure what you mean by this, I can look at the address bar to see who's responsible for a page.
Very well then.
I've clicked on an advert and bought something.
It was a small, text-only advert that simply gave the relevent product details: root on a FreeBSD virtual server for $65/mo, no set-up fee. I saw it, I thought it sounded like a good deal, clicked through, their website was simple and clear, so I signed up. They've given excellent service with the best technical support I've ever found in a hosting company, and I've been using them for years now.
I realise this sounds like an advert, but I'm not paid to say this or anything; I think it's a good example of effective advertising - a targeted ad that gives the relevent facts without being obtrusive, followed up with an excellent product. Compared with the "throw yourself at as many eyeballs as you can" approach, I know which I'm willing to tolerate and even give business to, and which I am going to block permanently.