See those three symbols on their own? An S, followed by a triangle, followed by a three-pronged character? Well if you look in the table directly above those three characters, you'll see that the triangle translates to F and the three-pronged character translates to C, giving S.F.C. altogether.
Clearly the Roswell Greys were on their way home from picking up a Spacetucky-Fried Chicken takeaway when they crashed here.
this automatic bundling business is one of the huge anti-competitive issues with Microsoft.
Because Microsoft are a monopoly. Bundling Free Software is hardly anticompetitive — other manufacturers are free to bundle the exact same software, or even bundle modified versions. It's pro competition.
Yes, you're right, you CAN choose not to buy an ASUS board (just like you can choose not to buy a HP or Dell preloaded with Windows).
Sure, you can choose not to buy something bundled with Windows. And you pay the price by being cut off from a vast supply of software that the rest of the world uses. Choosing to forgo this motherboard with its bundled Linux doesn't disadvantage you in the same way because there isn't an entire industry locked into it.
Just because you don't have the majority of the consumer market, doesn't make the practice any more justifiable.
Of course it does. Anticompetitive practices aren't intrinsically bad, they only become bad when they harm the market. If you don't have a monopoly market share, then anticompetitive actions don't harm the market, they harm your business as people switch away from you.
It's really difficult to give advice without knowing the specifics. For instance, you might have luck adding a plugin system, so that the barrier to entry is low enough for more people to join in without feeling like they have to become a proper developer. But that only works for some types of application.
No. You're going to see the billboards whether or not you have this phone, the difference is that the advert you end up seeing is tailored to the people in the vicinity that have this phone. The spam blocker is presumably for email/SMS/etc and obviously isn't going to block you from seeing billboards.
This is incorrect. A typeface cannot be copyrighted (in the USA), but the implementation of that typeface in a scalable font can be, as the Copyright Office considers them to be computer programs. This means that you can take a TTF font, draw your own that looks exactly like it and distribute the result, but you cannot distribute the original font file.
There's no part of copyright law that allows a tool creator to dictate how the output of the tool can be licensed
Who needs copyright? If you don't agree to the terms, they simply won't generate the font file for you. Just because they don't have copyright over the final result, it doesn't mean they are compelled to provide you with service.
You don't really need the quotation marks around the URL
While this is true in this specific case, it's only because Slashdot automatically corrects your broken markup. You cannot use slashes in an attribute value without quoting it, and slashes appear in most URLs.
Given that the copy only lasts as long as the software is in use, and cannot be readily separated from the copy on disk, and also that it is absolutely necessary to create to actually use the software, this should be considered purely part of the technological process of viewing the software.
You've basically paraphrased what USA law has to say on the matter:
it is not an infringement for the owner of a copy of a computer program to make or authorize the making of another copy or adaptation of that computer program provided [...] that such a new copy or adaptation is created as an essential step in the utilization of the computer program
How judges can rule that EULAs have a leg to stand on is beyond me. Copies made in the process of using software are not covered by copyright. The law seems quite clear on the matter.
Hmm, I'm not so sure about some of that. For instance:
Yahoo recommends turning ETags off because they cause problems on server farms due to the way they are generated with machine-specific markers. So unless you run a server farm, you should ignore this guidance. It'll only make your site perform worse because the client will have a more difficult time determining if its cache is stale or fresh. It is possible for the client to use the existing last-modified date fields to determine whether the cache is stale, but last-modified is a weak validator, whereas Entity Tag (ETag) is a strong validator. Why trade strength for weakness?
Because "strength" isn't anything particularly important here. The difference between strong and weak validators is that a strong validator is supposed to change even if only minor alterations take place (e.g. spelling mistakes), while a weak validator can remain the same if minor changes take place.
In practice, I've never seen anybody make a distinction like this for websites/web applications. If anybody did bother, then weak validators would be more efficient, as they would have a better cache hit ratio. For all intents and purposes, there is no difference between a strong and a weak validator. But what you are doing is computing and transmitting useless ETag headers with every single request you serve, so it is beneficial to turn them off, even if you don't have a server farm. Last-Modified is good enough for practically everybody. If Last-Modified isn't good enough for your purposes, then you don't need to be told to switch ETags back on, you know what you are doing.
All you're really saving here is the cost of the client pinging the server for a new version and getting a 304 not modified header back in the common case that the resource hasn't changed. That's not much overhead.. unless you're Yahoo.
Well how much overhead it is really depends on what it is you are doing. If it's expensive to figure out if the resource has changed, you don't want to incur that expense a lot, for example naïve dynamic stylesheet implementations can noticeably slow down a site. And remember, even if you have a fast server, it doesn't mean your users have a fast connection, and going back and asking the server if things have changed for a dozen resources on the page when you know for a fact you don't change them for months at a time is ridiculous.
His basic point, that you shouldn't take Yahoo's advice as gospel is good, but you shouldn't automatically assume that efficiency is only something that benefits giants.
Yeah, because message queues and SMS gateways and email-parsing daemons just write themselves
Twitter don't use Rails to handle most of that though, do they? I don't think drix is suggesting that they rewrite every piece of code they have, just the Rails portion.
Then, you run a tool that does a two-pass process over the content and creates the links, but the original attributes are preserved. Whenever a document moves, the links can be corrected programmatically because the content is referenced semantically rather than positionally. Trying to wedge that into a class tag would be really, really ugly
Yes, it would. But I think discarding the source and trying to preserve the information in the processed output is ugly too. If you're moving stuff around, then you presumably need to re-run the processor to fix the links, and if you're doing that, why don't you use the original source?
As for your other examples, the information doesn't need to touch the markup at all, does it? If you change something and you want JavaScript to be able to change it back, then why don't you save the information with JavaScript objects rather than in the markup?
As I say, I'm not totally against the idea of generic data handling, I just don't find it useful personally.
I'm sorry, that's not clear at all. Here's an example I used earlier: "­ ". How does separating the framework from the content tell you whether that is supposed to be a soft hyphen or an ampersand followed by the word "shy"?
I found great amusement in your haughty, pedantic response
Haughty — perhaps. Pedantic — no. What's pedantic about disagreeing when somebody mistakenly attempts to correct you when there is nothing wrong?
I posit that it's impossible to maintain "ownership" over a language when it's spoken by over 285 million people in a little country called the US.
I agree completely. There's nothing in my comment that attempted to claim ownership over any language.
In the grand scheme of things, what makes you think that "misspelt" won't be a colloquialism relatively soon?
It's not a colloquialism today, so what's your point?
To call your English more "proper" is a shallow-minded view of the world.
I didn't do that. Read my comment again. You'll see that you mistakenly saw the word "more" where there was none. That changes the meaning of the sentence significantly.
The US hasn't been a British colony for well over 200 years. Your imperialistic attitude about language has apparently not had enough time to catch up.
The only imperialism here is the attempt to define American English as the only correct dialect. There's nothing about my attitude that is imperialistic, all I want is to be able to speak English without being criticised for not speaking American English.
P.S. How's your Received Pronunciation doing these days?
SGML allows them to skip the final semi-colon in certain circumstances (before whitespace or a tag). HTML may. XHTML does not.
Who said anything about XHTML? We've been talking about HTML up to this point. The NYTimes use HTML. So do most people. Your objection that skipping the semicolon isn't valid in XHTML because your code can't handle HTML syntax seems to be nothing more than a dodge to me.
An implementation of the algorithm IS the heart of the matter.
No, it isn't. An algorithm is designed to do something. If you don't know what it is you are supposed to be doing, then you can't write a correct algorithm to do it. If you can't figure out what to do with "­ ", then how do you expect to write an algorithm to handle it correctly?
Thanks for the info. I find it intriguing that Google really are concerned with bandwidth; there must be reasons why they miss so many optimisations, but they certainly aren't obvious to me.
I used to prefer CSS hacks (just the valid ones) for the same reason of it being fewer requests, however when they brought Internet Explorer out of retirement and broke a bunch of the hacks, I realised that approach wasn't sustainable in the long run. It's a shame there's nothing similar to conditional comments / conditional compilation for CSS that would allow switching within a single stylesheet.
Only insofar as the className in JS is nothing more than a string.
It really shouldn't be. The HTML content model is a space-separated series of values, so it's the DOM at fault for not providing it in array form, and I'm pretty sure all the major JavaScript libraries offer a better interface.
Turning that string into something remotely useful (e.g. an key-value array) requires you to roll your own parser, which opens up room for truckloads of bugs
I've personally done just this, it was quite a while ago, but I don't remember any difficulties at all. You urlencode the values and split on whitespace. It's almost a one-liner, it even automatically handles quotes, spaces in values, unicode characters, etc if I remember correctly. I agree that having to parse it yourself is sub-optimal, but it's not as difficult or fragile as it first seems.
In any case, this objection is going away as HTML 5 will probably include this facility. On its face, it seems useful, but I have to say, when I want to embed data in an HTML document, there's usually a perfectly appropriate element type or attribute ready and waiting, and I can't think of a time when I'd have actually used this.
the slash at the end of the tag would be safely ignored by any properly written HTML parser.
Untrue, as I've posted elsewhere in the thread, the slash signifies the end of the opening tag, and the following greater-than sign is character data. It can't be treated as an unrecognised attribute by "any properly written HTML parser" because the slash has a special purpose in that position.
Ah yes, I automatically corrected for one of your bugs without even noticing. Character entity references don't always end with a semicolon. Your code still doesn't work, but for a different reason than the one I originally thought. You are now double-escaping character entity references and causing ugly code to be presented to the end-user.
Rather than play with pseudocode, why don't we skip straight to the heart of the matter. Given the text fragment "­ " can you tell me whether that is supposed to be a soft-hyphen or an ampersand followed by the word "shy"? Remember, this is an environment where people may be using character entity references and are also placing ampersands directly into the text without encoding them properly.
There are still some attributes that cannot be set with CSS
CSS doesn't set any attributes. What do you mean?
not every browser displays CSS the same way.
Not every browser displays HTML the same way either. They aren't supposed to. Displaying things the same way is impossible on the web. It's a good thing.
Tables may be predicated
The only thing I can guess you mean by this is "deprecated", but tables aren't deprecated at all.
do you honestly think anything is going to refuse displaying them? Ever?
Refuse to display them the way you want? It's already happened.
When Netscape 6 came out, people using table layouts complained that it left gaps everywhere. I believe some other browsers act this way as well now. It was due to people assuming that images would be treated specially in table cells rather than being vertically aligned to the baseline like the specification describes.
When Internet Explorer 6 came out, its standards mode didn't treat centring specially like previous versions did, so alignment broke for lots of people using table layouts.
I know table layout advocates like to tell people that table layouts are robust, that they work the same everywhere, and that support for them is everlasting, but it simply isn't true. They are quirky, they work differently in different browsers and browsers have dropped special handling for them on several occasions. Sure, you've picked up workarounds for them over the years, but if you'd have been using CSS, you'd have picked up the workarounds for those problems over the years instead.
The class attribute is a heavily overloaded attribute
Not really, it's a generic classifier, a way to "arbitrarily tag elements" as you put it. The fact that arbitrarily tagging elements is a technique that can be applied for a wide range of purposes is, well, the entire point, and hardly something to complain about.
that also controls presentation
It doesn't really control presentation at all. Stylesheets can reference the arbitrary tags. The "arbitrary tagging of elements" that you desire can be used for presentational purposes, among others.
With all due respect, I wasn't looking for guesswork, I was looking for a quote from some Google engineer. As I posted in the other comment, I find the fact that they don't take some other very obvious steps to cut down on code size to be evidence that they really aren't that bothered. Sure, it may seem obvious that skipping quotes for bgcolor=#ffffff is trading validity for bandwidth, but they could save even more bandwidth, remain valid, and have more readable code if they used bgcolor=white instead. I don't think it's at all the obvious truth people claim it to be, and I've never heard anybody from Google weigh in on it, which is why I think claims like "Google, in particular, has stripped down their web code to the bare minimum" are just hot air. If I recall correctly, there were a few valid redesigns for Google a couple of years ago, and most of them would have saved bandwidth.
Did you miss my example? One of the problems of ignoring the escaping of ampersands is that you are never sure if something is meant to be an entity reference or not. You'd put a soft hyphen into the example where there shouldn't be one.
I use a lot of deprecated tags and structures myself -- because they work the same for EVERY visitor using ANY browser.
No they don't, nor should they. The web doesn't work that way.
If that makes my code 100% "invalid" -- oh well!
No, using deprecated element types (not "tags") does not make your code invalid, so long as you pick a document type that uses them. <font> and friends are all perfectly valid.
Slashdot Mirror
See those three symbols on their own? An S, followed by a triangle, followed by a three-pronged character? Well if you look in the table directly above those three characters, you'll see that the triangle translates to F and the three-pronged character translates to C, giving S.F.C. altogether.
Clearly the Roswell Greys were on their way home from picking up a Spacetucky-Fried Chicken takeaway when they crashed here.
Because Microsoft are a monopoly. Bundling Free Software is hardly anticompetitive — other manufacturers are free to bundle the exact same software, or even bundle modified versions. It's pro competition.
Sure, you can choose not to buy something bundled with Windows. And you pay the price by being cut off from a vast supply of software that the rest of the world uses. Choosing to forgo this motherboard with its bundled Linux doesn't disadvantage you in the same way because there isn't an entire industry locked into it.
Of course it does. Anticompetitive practices aren't intrinsically bad, they only become bad when they harm the market. If you don't have a monopoly market share, then anticompetitive actions don't harm the market, they harm your business as people switch away from you.
It's really difficult to give advice without knowing the specifics. For instance, you might have luck adding a plugin system, so that the barrier to entry is low enough for more people to join in without feeling like they have to become a proper developer. But that only works for some types of application.
No. You're going to see the billboards whether or not you have this phone, the difference is that the advert you end up seeing is tailored to the people in the vicinity that have this phone. The spam blocker is presumably for email/SMS/etc and obviously isn't going to block you from seeing billboards.
Clippy: It looks like you are having a heart-attack! Would you like help?
Me: Ow! Stop zapping me! I'm not having a heart-attack, I just dropped my phone!
This is incorrect. A typeface cannot be copyrighted (in the USA), but the implementation of that typeface in a scalable font can be, as the Copyright Office considers them to be computer programs. This means that you can take a TTF font, draw your own that looks exactly like it and distribute the result, but you cannot distribute the original font file.
Who needs copyright? If you don't agree to the terms, they simply won't generate the font file for you. Just because they don't have copyright over the final result, it doesn't mean they are compelled to provide you with service.
While this is true in this specific case, it's only because Slashdot automatically corrects your broken markup. You cannot use slashes in an attribute value without quoting it, and slashes appear in most URLs.
You've basically paraphrased what USA law has to say on the matter:
How judges can rule that EULAs have a leg to stand on is beyond me. Copies made in the process of using software are not covered by copyright. The law seems quite clear on the matter.
Hmm, I'm not so sure about some of that. For instance:
Because "strength" isn't anything particularly important here. The difference between strong and weak validators is that a strong validator is supposed to change even if only minor alterations take place (e.g. spelling mistakes), while a weak validator can remain the same if minor changes take place.
In practice, I've never seen anybody make a distinction like this for websites/web applications. If anybody did bother, then weak validators would be more efficient, as they would have a better cache hit ratio. For all intents and purposes, there is no difference between a strong and a weak validator. But what you are doing is computing and transmitting useless ETag headers with every single request you serve, so it is beneficial to turn them off, even if you don't have a server farm. Last-Modified is good enough for practically everybody. If Last-Modified isn't good enough for your purposes, then you don't need to be told to switch ETags back on, you know what you are doing.
Well how much overhead it is really depends on what it is you are doing. If it's expensive to figure out if the resource has changed, you don't want to incur that expense a lot, for example naïve dynamic stylesheet implementations can noticeably slow down a site. And remember, even if you have a fast server, it doesn't mean your users have a fast connection, and going back and asking the server if things have changed for a dozen resources on the page when you know for a fact you don't change them for months at a time is ridiculous.
His basic point, that you shouldn't take Yahoo's advice as gospel is good, but you shouldn't automatically assume that efficiency is only something that benefits giants.
Twitter don't use Rails to handle most of that though, do they? I don't think drix is suggesting that they rewrite every piece of code they have, just the Rails portion.
Yes, it would. But I think discarding the source and trying to preserve the information in the processed output is ugly too. If you're moving stuff around, then you presumably need to re-run the processor to fix the links, and if you're doing that, why don't you use the original source?
As for your other examples, the information doesn't need to touch the markup at all, does it? If you change something and you want JavaScript to be able to change it back, then why don't you save the information with JavaScript objects rather than in the markup?
As I say, I'm not totally against the idea of generic data handling, I just don't find it useful personally.
I'm sorry, that's not clear at all. Here's an example I used earlier: "­ ". How does separating the framework from the content tell you whether that is supposed to be a soft hyphen or an ampersand followed by the word "shy"?
Haughty — perhaps. Pedantic — no. What's pedantic about disagreeing when somebody mistakenly attempts to correct you when there is nothing wrong?
I agree completely. There's nothing in my comment that attempted to claim ownership over any language.
It's not a colloquialism today, so what's your point?
I didn't do that. Read my comment again. You'll see that you mistakenly saw the word "more" where there was none. That changes the meaning of the sentence significantly.
The only imperialism here is the attempt to define American English as the only correct dialect. There's nothing about my attitude that is imperialistic, all I want is to be able to speak English without being criticised for not speaking American English.
I don't see the relevance.
In what way?
Who said anything about XHTML? We've been talking about HTML up to this point. The NYTimes use HTML. So do most people. Your objection that skipping the semicolon isn't valid in XHTML because your code can't handle HTML syntax seems to be nothing more than a dodge to me.
No, it isn't. An algorithm is designed to do something. If you don't know what it is you are supposed to be doing, then you can't write a correct algorithm to do it. If you can't figure out what to do with "­ ", then how do you expect to write an algorithm to handle it correctly?
Thanks for the info. I find it intriguing that Google really are concerned with bandwidth; there must be reasons why they miss so many optimisations, but they certainly aren't obvious to me.
I used to prefer CSS hacks (just the valid ones) for the same reason of it being fewer requests, however when they brought Internet Explorer out of retirement and broke a bunch of the hacks, I realised that approach wasn't sustainable in the long run. It's a shame there's nothing similar to conditional comments / conditional compilation for CSS that would allow switching within a single stylesheet.
It really shouldn't be. The HTML content model is a space-separated series of values, so it's the DOM at fault for not providing it in array form, and I'm pretty sure all the major JavaScript libraries offer a better interface.
I've personally done just this, it was quite a while ago, but I don't remember any difficulties at all. You urlencode the values and split on whitespace. It's almost a one-liner, it even automatically handles quotes, spaces in values, unicode characters, etc if I remember correctly. I agree that having to parse it yourself is sub-optimal, but it's not as difficult or fragile as it first seems.
In any case, this objection is going away as HTML 5 will probably include this facility. On its face, it seems useful, but I have to say, when I want to embed data in an HTML document, there's usually a perfectly appropriate element type or attribute ready and waiting, and I can't think of a time when I'd have actually used this.
Untrue, as I've posted elsewhere in the thread, the slash signifies the end of the opening tag, and the following greater-than sign is character data. It can't be treated as an unrecognised attribute by "any properly written HTML parser" because the slash has a special purpose in that position.
Ah yes, I automatically corrected for one of your bugs without even noticing. Character entity references don't always end with a semicolon. Your code still doesn't work, but for a different reason than the one I originally thought. You are now double-escaping character entity references and causing ugly code to be presented to the end-user.
Rather than play with pseudocode, why don't we skip straight to the heart of the matter. Given the text fragment "­ " can you tell me whether that is supposed to be a soft-hyphen or an ampersand followed by the word "shy"? Remember, this is an environment where people may be using character entity references and are also placing ampersands directly into the text without encoding them properly.
CSS doesn't set any attributes. What do you mean?
Not every browser displays HTML the same way either. They aren't supposed to. Displaying things the same way is impossible on the web. It's a good thing.
The only thing I can guess you mean by this is "deprecated", but tables aren't deprecated at all.
Refuse to display them the way you want? It's already happened.
When Netscape 6 came out, people using table layouts complained that it left gaps everywhere. I believe some other browsers act this way as well now. It was due to people assuming that images would be treated specially in table cells rather than being vertically aligned to the baseline like the specification describes.
When Internet Explorer 6 came out, its standards mode didn't treat centring specially like previous versions did, so alignment broke for lots of people using table layouts.
I know table layout advocates like to tell people that table layouts are robust, that they work the same everywhere, and that support for them is everlasting, but it simply isn't true. They are quirky, they work differently in different browsers and browsers have dropped special handling for them on several occasions. Sure, you've picked up workarounds for them over the years, but if you'd have been using CSS, you'd have picked up the workarounds for those problems over the years instead.
Not really, it's a generic classifier, a way to "arbitrarily tag elements" as you put it. The fact that arbitrarily tagging elements is a technique that can be applied for a wide range of purposes is, well, the entire point, and hardly something to complain about.
It doesn't really control presentation at all. Stylesheets can reference the arbitrary tags. The "arbitrary tagging of elements" that you desire can be used for presentational purposes, among others.
Sure it does. class="foo=bar baz=qux".
With all due respect, I wasn't looking for guesswork, I was looking for a quote from some Google engineer. As I posted in the other comment, I find the fact that they don't take some other very obvious steps to cut down on code size to be evidence that they really aren't that bothered. Sure, it may seem obvious that skipping quotes for bgcolor=#ffffff is trading validity for bandwidth, but they could save even more bandwidth, remain valid, and have more readable code if they used bgcolor=white instead. I don't think it's at all the obvious truth people claim it to be, and I've never heard anybody from Google weigh in on it, which is why I think claims like "Google, in particular, has stripped down their web code to the bare minimum" are just hot air. If I recall correctly, there were a few valid redesigns for Google a couple of years ago, and most of them would have saved bandwidth.
Did you miss my example? One of the problems of ignoring the escaping of ampersands is that you are never sure if something is meant to be an entity reference or not. You'd put a soft hyphen into the example where there shouldn't be one.
They don't use XHTML, they use HTML 4.01 Transitional.
No they don't, nor should they. The web doesn't work that way.
No, using deprecated element types (not "tags") does not make your code invalid, so long as you pick a document type that uses them. <font> and friends are all perfectly valid.