The web was designed to not let you specify format for a reason.
Quite so, but was that reason "allow the user to customize", or "make it really easy to implement an HTML renderer on many different systems with different constraints"? I submit that the latter was a far more important point. (Tim B-L, if you're listening, please feel free to correct me if I am mistaken.)
sIFR and similar stupid hacks are, without any room for argument, the wrong way to do it.
Oh! Well, since you have declared there's no room for argument, I guess there's no point in anyone even suggesting an alternative..... </sarcasm>
The whole point of HTML is allowing the user flexibility in display
Well, that's really a matter of some debate, isn't it?
I always thought of the point of HTML as being a simple text-based hypertext markup language that requires no funky special proprietary editor to create, nor any proprietary renderer to display.
Flexibility in display is rather important to the second goal, but *user* flexibility (as opposed to html-renderer-implementation flexibility) seemed secondary to me.
Let's get to work on defining the standard, then convincing all the browser makers to accept it, and everyone to upgrade to those new browser versions. I'm sure all that will be in place by, oh, 2010 or so. (For at least 60% of users, anyway.)
In the meantime, this is a scheme that actually works for the 98% of non-Slashdot readers who have Flash installed.
...if only there was a "Didn't Bother To RTFA" mod.
Unhighlightable:In addition to the obvious accessibility features, sIFR text can also be selected, copied, and pasted by users. It also zooms with the user's text-zoom settings, although this only occurs on page load and not on-the-fly. And finally, of course sIFR works with linked text (anchors).
Unsearchable, undisplayable without Flash:If Flash isn't installed (or obviously if javascript is turned off), the (X)HTML page displays as normal and nothing further occurs. If Flash is installed, javascript traverses through the source of your page measuring each element you've designated as something you'd like "sIFRed".
And just for an added bonus, before someone complains about accessibility:
sIFR is fully accessible to screenreaders and other assistive technology. Don't take our word for it. Ask Matt May of the W3C who endorses it as an accessible method to create rich typography on the web. Or ask Joe Clark, one of the world's leading accessibility experts, whose interest in typography is only trumped by his interest in accessibility.
The knee-jerk reaction of some people whenever they see Flash is that it must be inaccessible because it's Flash. What we've done with sIFR, however, is turn that model completely on its head. Your (X)HTML document is still the exact same document it was before sIFR kicked in. Your code is untouched and sIFR is completely abstracted to the javascript layer; therefore, your accessibility, your search engine friendliness, and your semantics are the same as they were before the day you decided you like nice fonts.
If by "many" you mean "tiny percentage of people who even know what FireFox Extensions are", then yeah.
Look, no offense, but people using FlashBlock (or other such doodads) really are in the teensy minority. (Of course, I say this without any supporting data whatsoever, aside from the fact that absolutely none of my friends or family use 'em.)
Good thing Google is buying up all that dark fiber, eh?
It may be fashionable to consider them The Next Evil Empire (on/., anyway), but at least they haven't shown any particular propensity to the extreme insularity of the old-guard telcos...
All this talk of boycotting Sony is well and good -- I've already had geek friends comment that Sony is now off their shortlist for HDTV's, games, etc. -- but unless this behavior spreads beyond the typical/. crowd, I don't think it's gonna make a speck of difference.
So, let me make a modest proposal: all you geeks in the USA who are about to visit friends and family for Thanksgiving, TELL THEM THIS STORY.
"Sony has been making music CDs that have a computer virus on them. The idea is that if you play the CD in your computer, the computer gets modified to prevent you from making illegal copies of the CD. The problem is that not only is this illegal to do, it makes it easy for more viruses to get on your system. Even the Department of Homeland Security has condemned Sony for this, but they have yet to apologize. So I'm going to avoid buying any Sony product -- music, movies, games, electronics, computers, etc. -- until they do. I wasn't planning on stealing their CD, and I don't appreciate them treating me with the presumption that I was going to."
(I realize that calling it a "virus" isn't technically accurate, but I'm assuming that's much more likely to be a meaningful term to grandma than trying to explain what a "rootkit" is...)
Okay, so first of all, my head would have to be a little bean. With real, real big eyes. Get rid of my thumbs, make me all shiny {clean noise that sounds like a harp, or bells, or both}...my boots would be a whole lot cooler. Like robot boots. {robotic 'shooo' noise} And for some reason, I got blue hair. You gotta have blue hair. Then there's my mouth. Real tiny when it's closed; ridiculously huge when it's open. And then you basically just put me in space and let me fly around in cool poses!
Well, by "fired" I mean "refuse to accept their code", but yeah, you have a point...
Thats the problem. ABI's change in a matter of months which it impossible for ISV's to support.
Yep. And this is one of the major reasons for the lack of 'shrink-wrap' software on Linux. Most vendors of such software (e.g., Adobe) cannot, and will not, release their product in source form -- ever.
So it all boils down, once again, to an ideological issue, not a technical one.
Windows does not have this problem because of smart dynamic versioning of its dlls. Why can't linux have it.
My assumption has been that it's the FOSS attitude of source being the proper distribution method: you don't need versioning of binary code when you have the source code available to recompile as necessary. Which is true enough, I guess, *if* you have the source code available.
I did RTFA, and the author seems to have a different definition of "stable" than I do:
Assuming that we had a stable kernel source interface for the kernel, a
binary interface would naturally happen too, right? Wrong. Please
consider the following facts about the Linux kernel:
Depending on the version of the C compiler you use, different kernel
data structures will contain different alignment of structures, and
possibly include different functions in different ways (putting
functions inline or not.) The individual function organization
isn't that important, but the different data structure padding is
very important.
Depending on what kernel build options you select, a wide range of
different things can be assumed by the kernel:
different structures can contain different fields
Some functions may not be implemented at all, (i.e. some locks
compile away to nothing for non-SMP builds.)
Parameter passing of variables from function to function can be
done in different ways (the CONFIG_REGPARM option controls
this.)
Memory within the kernel can be aligned in different ways,
depending on the build options.
But see, the thing is... a "stable" binary interface requires that structures used specify padding, alignment, and fields to be fixed! If these can vary, then by definition, it's not stable. Ditto the variations that depend on kernel build options.
Now, if you want to make the case that it's not possible / practical to make an interface that can cover all of these conditions adequately, well, by all means, do so (though I'd say that the hundreds of existing operating systems with binary interfaces show that this isn't the case in the general sense).
But what I see here is a relatively weak technical argument that is being used to justify an ideological decision.
Um... did you notice the word "alpha"? As in, "not even beta yet"?
No, there's no OS X or Linux version yet. The alpha is Windows-only. OS X version is definitely planned, just not ready yet. I don't know what we've announced regarding Linux plans, so I can't comment on that.
In fact, you can try it out yourself: a public alpha of the player with the new VM, along with an alpha of the new Eclipse-based authoring tool ("Flex 2.0"), is available *free* (as in beer, not in speech) at http://labs.macromedia.com/...
There's more than just a new VM; it also provides an ECMAScript-4 compliant language ("ActionScript 3" in Macromedia-speak), which seems *much* more suitable for real coding work.
(Disclaimer: I work for Macromedia, so I'm not unbiased, but even so, it's pretty cool:-)
Slashdot Mirror
The web was designed to not let you specify format for a reason.
Quite so, but was that reason "allow the user to customize", or "make it really easy to implement an HTML renderer on many different systems with different constraints"? I submit that the latter was a far more important point. (Tim B-L, if you're listening, please feel free to correct me if I am mistaken.)
sIFR and similar stupid hacks are, without any room for argument, the wrong way to do it.
Oh! Well, since you have declared there's no room for argument, I guess there's no point in anyone even suggesting an alternative..... </sarcasm>
The whole point of HTML is allowing the user flexibility in display
Well, that's really a matter of some debate, isn't it?
I always thought of the point of HTML as being a simple text-based hypertext markup language that requires no funky special proprietary editor to create, nor any proprietary renderer to display.
Flexibility in display is rather important to the second goal, but *user* flexibility (as opposed to html-renderer-implementation flexibility) seemed secondary to me.
To be fair, there are still a nontrivial number of browsers out there that don't support PNG. You'd have to use GIF or JPEG.
An OpenType font reference would, indeed, make more sense, if there was any cross-browser standard whatsoever. But there isn't.
Wow. Now there's a nice, even-handed, fair-minded response to the situation.
The fonts should be fixed thru a W3C standard.
Yep. Totally agree.
Let's get to work on defining the standard, then convincing all the browser makers to accept it, and everyone to upgrade to those new browser versions. I'm sure all that will be in place by, oh, 2010 or so. (For at least 60% of users, anyway.)
In the meantime, this is a scheme that actually works for the 98% of non-Slashdot readers who have Flash installed.
...if only there was a "Didn't Bother To RTFA" mod.
Unhighlightable: In addition to the obvious accessibility features, sIFR text can also be selected, copied, and pasted by users. It also zooms with the user's text-zoom settings, although this only occurs on page load and not on-the-fly. And finally, of course sIFR works with linked text (anchors).
Unsearchable, undisplayable without Flash: If Flash isn't installed (or obviously if javascript is turned off), the (X)HTML page displays as normal and nothing further occurs. If Flash is installed, javascript traverses through the source of your page measuring each element you've designated as something you'd like "sIFRed".
And just for an added bonus, before someone complains about accessibility:
sIFR is fully accessible to screenreaders and other assistive technology. Don't take our word for it. Ask Matt May of the W3C who endorses it as an accessible method to create rich typography on the web. Or ask Joe Clark, one of the world's leading accessibility experts, whose interest in typography is only trumped by his interest in accessibility.
The knee-jerk reaction of some people whenever they see Flash is that it must be inaccessible because it's Flash. What we've done with sIFR, however, is turn that model completely on its head. Your (X)HTML document is still the exact same document it was before sIFR kicked in. Your code is untouched and sIFR is completely abstracted to the javascript layer; therefore, your accessibility, your search engine friendliness, and your semantics are the same as they were before the day you decided you like nice fonts.
If by "many" you mean "tiny percentage of people who even know what FireFox Extensions are", then yeah.
Look, no offense, but people using FlashBlock (or other such doodads) really are in the teensy minority. (Of course, I say this without any supporting data whatsoever, aside from the fact that absolutely none of my friends or family use 'em.)
Holy Christ!
I hate to see myself reduced to grammar nazi, but can't people get THIS ONE FREAKING THING RIGHT?
Learn the damn difference!
Good thing Google is buying up all that dark fiber, eh?
/., anyway), but at least they haven't shown any particular propensity to the extreme insularity of the old-guard telcos...
It may be fashionable to consider them The Next Evil Empire (on
All this talk of boycotting Sony is well and good -- I've already had geek friends comment that Sony is now off their shortlist for HDTV's, games, etc. -- but unless this behavior spreads beyond the typical /. crowd, I don't think it's gonna make a speck of difference.
So, let me make a modest proposal: all you geeks in the USA who are about to visit friends and family for Thanksgiving, TELL THEM THIS STORY.
"Sony has been making music CDs that have a computer virus on them. The idea is that if you play the CD in your computer, the computer gets modified to prevent you from making illegal copies of the CD. The problem is that not only is this illegal to do, it makes it easy for more viruses to get on your system. Even the Department of Homeland Security has condemned Sony for this, but they have yet to apologize. So I'm going to avoid buying any Sony product -- music, movies, games, electronics, computers, etc. -- until they do. I wasn't planning on stealing their CD, and I don't appreciate them treating me with the presumption that I was going to."
(I realize that calling it a "virus" isn't technically accurate, but I'm assuming that's much more likely to be a meaningful term to grandma than trying to explain what a "rootkit" is...)
So what?
I've kinda wondered why Apple didn't decide to skip 32-bit x86 entirely and go with the AMD64 architecture exclusively (regardless of chip supplier).
Seems like it would make a whole lot simpler, especially given the superior instruction set of AMD64.
And here I had thought it was a crusty loaf of bread...
I guess it's not champagne unless it's made in france, either?
0 2582914_winecol26.html
Correct... and not just anywhere in France; it has to actually be made in the Champagne area (duh!)
http://seattletimes.nwsource.com/html/foodwine/20
Okay, so first of all, my head would have to be a little bean. With real, real big eyes. Get rid of my thumbs, make me all shiny {clean noise that sounds like a harp, or bells, or both} ...my boots would be a whole lot cooler. Like robot boots. {robotic 'shooo' noise} And for some reason, I got blue hair. You gotta have blue hair. Then there's my mouth. Real tiny when it's closed; ridiculously huge when it's open. And then you basically just put me in space and let me fly around in cool poses!
This is linux. No one gets fired.
Well, by "fired" I mean "refuse to accept their code", but yeah, you have a point...
Thats the problem. ABI's change in a matter of months which it impossible for ISV's to support.
Yep. And this is one of the major reasons for the lack of 'shrink-wrap' software on Linux. Most vendors of such software (e.g., Adobe) cannot, and will not, release their product in source form -- ever.
So it all boils down, once again, to an ideological issue, not a technical one.
Windows does not have this problem because of smart dynamic versioning of its dlls. Why can't linux have it.
My assumption has been that it's the FOSS attitude of source being the proper distribution method: you don't need versioning of binary code when you have the source code available to recompile as necessary. Which is true enough, I guess, *if* you have the source code available.
We should all buy new hardware and spend hours on top of hours getting things to work, rather than just "having" things work
:-)
No thanks.
An hour I have to spend (re)configuring my OS is one less hour that I can spend reading Slashdot
But people need to remember "Linux", at its most basic is about being free and open. If you want easy, get a Mac ;)
So, in other words... "free and open" is incompatible with "easy"?
It's a bad idea because what happens when the driver ABI changes?
Then you go and fire the developer(s) who called it a "stable" ABI.
By definition, a "stable" ABI should change very rarely, and provide backwards compatibility.
Without this, it ain't stable.
It also means that a driver will only work with one kernel
If this is the case, then I'd say that the "stable" binary interface isn't stable at all.
By definition, a stable interface should work across all conforming variations of the kernel.
If it doesn't, it's a very poorly-defined interface (or a very poor use of the term "stable").
Assuming that we had a stable kernel source interface for the kernel, a binary interface would naturally happen too, right? Wrong. Please consider the following facts about the Linux kernel:
But see, the thing is... a "stable" binary interface requires that structures used specify padding, alignment, and fields to be fixed! If these can vary, then by definition , it's not stable. Ditto the variations that depend on kernel build options.
Now, if you want to make the case that it's not possible / practical to make an interface that can cover all of these conditions adequately, well, by all means, do so (though I'd say that the hundreds of existing operating systems with binary interfaces show that this isn't the case in the general sense).
But what I see here is a relatively weak technical argument that is being used to justify an ideological decision.
http://www.jhuger.com/kisshank.php
This morning there was a knock at my door.
When I answered the door I found a wellgroomed,
nicely dressed couple. The man spoke first:
John: "Hi! I'm John, and this is Mary."
Mary: Hi! We're here to invite you to come kiss Hank's ass with us."
Me: "Pardon me?! What are you talking about? Who's Hank, and why would I want to kiss His ass?"
John: "If you kiss Hank's ass, He'll give you a million dollars; and if you don't, He'll kick the shit out of you."
Oh, please, there's not even an OS X download which doesn't need Windows to extract it
f lex-2-on-mac-os-x/
FYI, this isn't supported by MACR, but there are instructions on how to use the framework (if not the IDE) on OS X here:
http://robbevan.com/blog/2005/10/23/working-with-
No, there's no OS X or Linux version yet. The alpha is Windows-only. OS X version is definitely planned, just not ready yet. I don't know what we've announced regarding Linux plans, so I can't comment on that.
Also true that there's no Linux version of Player 8 yet. But as one of the engineers on that team said, they're looking for experienced Linux engineers to help finish the port.
In fact, you can try it out yourself: a public alpha of the player with the new VM, along with an alpha of the new Eclipse-based authoring tool ("Flex 2.0"), is available *free* (as in beer, not in speech) at http://labs.macromedia.com/ ...
:-)
There's more than just a new VM; it also provides an ECMAScript-4 compliant language ("ActionScript 3" in Macromedia-speak), which seems *much* more suitable for real coding work.
(Disclaimer: I work for Macromedia, so I'm not unbiased, but even so, it's pretty cool