"They just went and put an indenter on the English Language!"
That's what I'm thinking too. Here's the summary reformatted with a couple of simple rules (sorry but I have to use monospace font to preserve formatting in slashdot:
"Scientists at a small startup called Walker Reading Technologies in Minnesota have determined that the human brain is not wired properly to read block text. They have found that our eyes view text as if they're peering through a straw. Not only does your brain see the text on the line you're reading, but it's also uploading superfluous information from the two lines above and the two lines below. This causes your brain to engage in a tug of war as it fights to filter and ignore the noise. The result is slower reading speeds and decreased comprehension. The company has developed a product that automatically re-formats text in a way that your brain can more easily comprehend."
The only rules I used to format the text were: * reset indent and start a new line after a full stop * next line with indent after comma (,) or before one of the stop words
And stop words are: at, in, that, to, as, on, from, and.
Also, one should compare specially formatted text to normal block text with bigger font and more line space so that both variants took equal amount of vertical space in the end.
Your solutions both require the HARDWARE perform a certain way.
Restrictions on the hardware or host OS are outside the scope of the GPL affecting software.
[...] The GPL can not force hardware or other software to a certain behaviour. This is the loophole TIVO exploits
Yes, GPL cannot specify the hardware or it cannot require the underlying platform to perform a certain way. The GPLv3 can, however, specify that you cannot sell such hardware with GPLv3'd software as a bundle. Selling such bundle requires you to distribute GPLv3'd software and that requires a license which would be the GPLv3. If you don't accept the requirements the GPLv3 specifies (which require you to provide the end user a way to run his own modifications) you are not allowed to distribute the software at all. Which was the point of GPL in the first place.
I have to agree that GPLv3 could still be circumvented by selling the HARDWARE and SOFTWARE (under GPLv3) separately. The customer would then be clearly informed that the HARDWARE he buys cannot be used to run software expect if it has been signed by company X. If the customer is happy to accept such restriction when he buys the HARDWARE, then there shouldn't be any issue with the GPLv3, right? If that customer later decides to buy some signed software for his newly purchased HARDWARE there shouldn't be any problems with such software being GPLv3 AND signed by company X.
I'm not entirely sure if GPLv3 legally forces you to provide a way to sign software for the hardware you sell if you ALSO distribute any software covered by GPLv3 for such hardware. Perhaps even this could be circumvented by distributing (/selling?) the signatures separately from GPLv3'd software.
The noise that the Macrovision system adds to normal analog is just noise that shouldn't be in the signal by the spec. The vertical and horizontal blanking space should be zeroed (practically grounded for analog signal). A signal with the noise by Macrovision has additional crap on those parts of the signal. The resulting signal isn't up to the original spec and that's is the reason it cannot be successfully recoded by some devices. If you use a device that is known to fix this kind of problems from the signal (i.e. a device that can fix a corrupted, against the spec signal, etc.) you now break the law?
Perhaps they should ban all the other systems that fix or improve analog signals, too? Pretty much all CLD and plasma displays do this already because they, too, are digital and wouldn't be able to display the "correct" signal without removing the noice by Macrovision from the signal. The only real difference is that the device made by Sima is external to the display device.
Re:I wish security were more accessible to the mas
on
PGP & GPG
·
· Score: 1
[http://www.rncca.com/] Haha, and if you click cancel, you still get directed to the page.
Funny indeed. The password check is a piece of JavaScript on the page. It seems that they used to accept three different passwords and the code that they use to check the password has been rotten. Whitness the following:
var password; var pass1="rncca"; password=prompt('Please enter the password rncca below!',' '); if (password==pass1 || password==pass2 || password==pass3) alert('Password Correct! Click OK to enter!'); else window.location="http://www.wocommsdinner.com";
Notice how pass2 and pass3 are undefined? An exception will not be raised if password is not correct and the script will be terminated before it can execute the window.location line. Bonus WTF points for the fact that the password is displayed in the dialog that prompts for it!
Some people are willing to pay more to get a book first, and they are willing to pay more than the difference between a hardcover and paperback copy - for example, a hardcover costs 10% more, but some people are willing to pay 40% more to get it early. If the publisher only released paperback, they would lose out on all the profits from the 'early adopters' while if they only released hardcover they would lose out on those who would be willing to pay a little less. So, release the hardover, which costs 10% more to produce, but has a 40% higher price tag compared to the paperback == more profit.
Then why not just release a paperback version first with 40% higher price tag and once early adopters have wasted their money, decrease the price to "normal". Is there any reason the publisher should use 10% valuable item for the first release? If the audience is ready to buy an overpriced product, they will do it anyway regardless of were it a paperback or a hardcover.
The 'Unipage Unifier' program instantly turns any online or local page into a 'Unipage' that can be viewed directly in a browser.
In case you're happy that "a browser" doesn't include Microsoft Internet Explorer, which doesn't support the data: URL spec (RFC 2397), be my guest. There isn't anything magically going on. According to RFC 2397 you can encode an external document, including all its data data, to an URL. Basically, you just need to prefix data:image/png;base64, to base64 encoded PNG image and paste the resulting string to SRC attribute of IMG element and you're done embedding the PNG image inside a HTML document.
Did I mention that MSIE does NOT support RFC 2397? So, you can use this method for every other browser but for MSIE and you have to use Microsoft's proprietary.MHT format for MSIE. IMO, it's not worth the trouble, just use PDF instead.
Wake me up again once somebody comes up with a way to put a HTML page with at least (originally) external PNG and CSS files inside a single file that can be viewed correctly without plugins with MSIE, Mozilla, Safari and Konqueror.
translate C++ source code into ELF/x86 object files [...} GNU's C++ compiler and Intel's C++ compiler, which perform the same task but have practically nothing in common internally, which is right and which is wrong? [...] Come on - if source code is "either write or wrong", then since they produce different (though equivalent) results, presumably one of them must be "wrong" - so which is it?
Why do you think either one of them is "correct"? Both of the compilers mentioned have been proven to generate invalid output for some inputs. You can consider both of them as "partial prove" for a great mathematical problem. Unfortunately, both of the solutions are just almost correct.
However, I think that (computer) source code and (complex) mathematical formulas should be granted copyright but no patents. The copyright should be granted for "creation time + 20 years" instead of current expiration day of "end of time minus one day" as it currently stands, though.
I can't affort to dedicate a whole machine to Internet Exploder testing.
I think you mean you cannot afford to dedicate one whole machine per one version of Internet Explorer. One test machine can only include one version of MSIE. So you need 4 machines to test for MSIE 5.0, MSIE 5.5, MSIE 6.0 and now MSIE 7. That is, unless you try all those browsers side by side. Instructions to run multiple different versions of MSIE side by side in MS Windows.
Don't yet know if it's possible to run MSIE 7 as stand-alone version but at least you should be able to install that as the "official" browser and the rest as "local" versions.
Also, note that I never claimed MS was innovating, simply that IE7 tabs would be superior to those in FF.
Perhaps out of the box but FF has extensions to make it much better. If you digg tabbed browsing, you should check out following extensions (these have overlapping features so you might want to select only a few):
Nobody [...] gives a rat's ass about source code as long as the software works properly.
I prefer open source (or free) software because I can be sure that it will work in the future, too. I understand that computer illiterates don't yet get this. Whitness the Flash player incompatibility with x86-64 platform of today, for example. Forget running Flash on Linux/PPC either. This is because Adobe/Macromedia is the only player on the field with the implementation and that's because Flash player isn't free (or open source).
The fact is that computer hardware is now interchangeable but software isn't. Make sure that the software solution you're using isn't locked down to a single vendor. Just because the plugin is "free" download doesn't mean it's a free lunch in the long run.
I wouldn't author any content for any proprietary format. I may, however, view some content inside some proprietary formats if somebody else has already done the mistake. That is, if I'm able to still view that content! If I'm not able to view that content, then that author cannot communicate with me. Why so many commercial web sites use Flash (or any other closed format) is beyound me -- if you try to sell me something, being able to communicate with me would be important, right? Flash may work today, will it be the same tomorrow?
Remember under GPL 2 i can take BSD (v2) licensed code and use it. I can't go the other way. [...] Most often the BSD camp is forced to use GPL code and comply to it. We can't just use code like the other way. BSDs must use a [GNU] compiler, tools, and any X11 window manager worth anything is GPL. Its a bitch.
Did I misunderstood something when you said that the point of using BSD is the desire to give out total freedom? You now say that "its a bitch" when they change the license from BSD to GPL after adding a new feature which makes a piece of software more desirable. Are you sure that you really prefer BSD to GPL?
As I see it, the whole point of using GPL license is that it says that derived works must be licensed under the very same license. That, plus the fact that you must distribute sources with the binaries. Of course, it follows that GPL cannot be compatible with any other license.
The only fear I have is that in the future we have some piece of software that is licensed under GPL version 2 (without "or later" clause) and an another piece of software that is licensed under "GPL version 3 or later" and we cannot ever combine those. I think that it would make an example case what's wrong with GPL in general.
Actually, we use Active X for quite a few of our internal apps [...] I can slap a DBGrid into a web page in seconds with an Active X control, or I can try some buggy Javascipt kludge that works in just a few browsers [...]
Oh, as opposed to ActiveX control that works in just one browser? If you're happy with just one supported browser, why not use XUL instead. It doesn't work in MSIE but it does support way more platforms than just Windows/x86. It might not seem that important now, but think about the future. Is your ActiveX componen going to work in 64 bit version of MSIE? The XUL application does work on a 64 bit platform.
Still, Firefox doesn't support [soft hyphen], even though people have been requesting it for literally years. Why not?
Their view is that an HTML compliant rendering of soft hyphen is to not render it in any situation. HTML doesn't require the UA to use soft hyphen as a line break opportunity. It just says that UA may break the the line at soft hyphen and if it does then it must display a visible hyphen at the end of the line. Mozilla/Firefox doesn't do the "may" part so it isn't required to implement the "if" part. Just ignoring the character is compliant behavior.
Yes, it sucks. Yes, my mother tongue is Finnish so I know how much it could help the rendering. But the fact is that Mozilla/Firefox is indeed following HTML to the letter on this issue. The spec should have required support for soft hyphen but it didn't.
Oh really? The way I understand it, CSS is only used to give hints about the author intended rendering. The C in CSS means "cascading", which in turn means that the user can override rules defined by the content author. In addition, there's no way to even specify anything in real pixels. The "px" unit is defined as a part of field of vision. Some displays just "happen" to have actual pixel size near the CSS "px" unit. As a result, some browser manufacturers have implemented the "px" unit as a pixel. The spec does not require that!
Comment #43 From Robert O'Callahan (Novell) 2005-11-23 19:17 PST I think the basic problem here is that we don't know how box-wrapped blocks are supposed to behave.
So the problem really is that they are trying a bit too hard to fix it correctly, but they don't yet know which the correct way is.
Could the same paradigm be extended to the browser and browser standards? [...] This would be very beneficial since every web page would look the *same* and act the same regardless of the browser use to view it.
The whole point of HTML is that it does not define a single way to view the content. The whole point of CSS is to provide hints about how the page author thinks that the content should be displayed.
As long as we're using different devices and different people have different needs, there's no reason to force same look and behavior for everybody. Some people do require 72pt font just to be able to read because they have such a bad vision. Some people are blind. Some are deaf. You cannot present the same content identically to everybody. What does matter, is that the user agent (commonly referred as the "browser") behaves the same when it comes to what the server sees. This is not the case today.
You're supposed to be able to always change the font size. The fact that MSIE isn't able to adjust font size if it's set to "12px" or "10pt" is a bug, not a feature. The fact that MSIE only has total of 5 different settings for font size in the UI might be a feature, but I consider that a bug, too.
The response time on an LCD is the amount of time it takes a pixel to change color once it's been instructed to do so.
Correct me if I'm wrong, but AFAIK the reported LCD pixel response time is (always?) the optimal case. The time it takes to go from white to black. All the other state changes are always slower.
I like CRT displays because they have predictable delays. A CRT display @100Hz has maximum delay of 10ms, always - and that includes the delay going from graphics adapter to visible dot on the screen.
Although Slashdot's HTML is old and bloated by modern standards this was actually a bug in the Firefox renderer.
Yes. It's in fact the bug #217527. The actual bug is a combination of table layout and javascript layout trickery. Slashdot was almost the only place to hit it.
The issue is hit with the following code:
<TABLE CELLPADDING="0" CELLSPACING="0" BORDER="0">
<TR>
<TD width="1" bgcolor="yellow">
<TABLE BORDER="0" CELLPADDING="0" CELLSPACING="0" ALIGN="LEFT">
<TR>
<TD>
xxx
<script type="text/javascript">var foo = document.body.offsetHeight;</script>
zzzzzzzz
</TD>
<TD></TD>
</TR>
</TABLE>
</TD>
</TR>
</TABLE>
The reason is that querying document.body.offsetHeight while the page is still loading caused element dimensions to be computed from partial page source. The results were then incorrectly cached and used later instead of recalculating the values once the page was completely loaded. In the example above, this causes the "zzzzzzz" part to fall out of table cell that is sized to fit only the width of "xxx". If the document.body.offsetHeight is not embedded inside the table or it's used only after the document has been fully loaded the bug can be avoided.
I don't expect that from any browser today. I'd settle with
correct implementation of supported CSS2 features
That's right. The problem isn't that MSIE doesn't support some CSS features but that it supports many of the features incorrectly. For example, read about quirky implemenatation of percentage unit in MSIE. MSIE implements not one but two different implementations for that feature and neither is the correct one! Just try that page with MSIE and hover the examples with mouse cursor.
For amusement, next time MSIE messes up the page layout, try inserting CSS rule * {zoom:1}. That CSS property should do nothing (it's a proprietatry property defined by microsoft and it's supposed to select "zoom level" for the element, 1 being "100%").
...but I agree that there's a need for more. For example, hCalendar has some merit being XHTML compatible and can be nicely embedded in any XHTML (or even HTML) page. Distribution of calendar files (.ics) isn't the problem. The real problem is that it's hard to discuss events outside.ics format so that applications are still able to automatically extract the information. hCalendar is nicely submerged inside the real content as demonstrated by the example. Throw in hCard and we can finally talk about usable metadata embedded in a web page.
There's default browser styling, sure, but <b> and <i> are just shorthands for <span class="b"> and <span class="i">.
Not true. <b> and <i> are still elements just like before. You'll still use CSS selectors b and i (as opposed to.b and.i) to select those. Yes, they have the same semantics as <span> but they are definately not shorthands but real elements instead.
This is like saying: there's no OS with using the Mozilla license! I'm gonna implement a new OSS, that walks and quacks like Linux, but is completely licensed under MPL rather than GPL!
There's one critical difference. Linux is licensed under GPL plus a clause that allows running non-GPL software on the system. That allows users to run software with GPL incompatible licenses already so there's no need to rewrite MPL (or any other license) compatible variant. Linux can be also freely distributed and its modified versions can also be re-distributed as long as the modifications are released under GPL license. On the contrary, Java license doesn't even allow distribution of verbatim copy of VM, much less re-distribution of derivative works. There's no contest here.
The point where ray of light hits a surface can move faster than light. Information (light) goes from light source to surface or the other way around but it doesn't go from one surface location to another so you're not limited by the speed of light
You have to remember the little thing called wavelenght. You cannot read details smaller than the wavelength. The smaller the angle the ray of light hits the surface, the fussier the surface seems to be. We're going towards blueray laser systems because normal laser has too long wavelength even for next generation spinning disk technology.
If it wasn't the cost, one could make a pretty high speed optical reader by creating 12cm x 12cm CCD chip capable of reading every single pit in the surface of DVD disk at once. It would be just like a flat bed scanner, just faster. Scanning the whole disk would take 1/100th a second at most. Then it would be just matter of moving bits from the CCD chip to system memory fast enough. I won't even try to guess how much a 12cm x 12cm CCD chip with enough resolution to contact read a DVD disc would cost.
Someone I work for uses GET for everything. [...] This is why he uses so many if statements to accomodate people altering the links.
You know that <form>s can be modified too, right? If you're writing application that works through HTTP/Web browser then you just have to do a lot of checking (that's where the "if" comes in) to make sure that the client (browser/user agent/the real user) isn't trying to hack your system. If you don't do input validation for everything you might as well use GET for everything.
I do sometimes use GET for state changing actions in web applications I write. In some cases some toggle actions that reflect only data display result in much better user interface if I use normal links instead of <button>s. Sometimes you have to accept some compromises when you're writing webapps that have to work without CSS, images and javascript and still be usable.
Slashdot Mirror
"They just went and put an indenter on the English Language!"
That's what I'm thinking too. Here's the summary reformatted with a couple of simple rules (sorry but I have to use monospace font to preserve formatting in slashdot:
"Scientists
at a small startup called Walker Reading Technologies
in Minnesota have determined
that the human brain is not wired properly
to read block text.
They have found
that our eyes view text
as if they're peering through a straw.
Not only does your brain see the text
on the line you're reading,
but it's also uploading superfluous information
from the two lines above
and the two lines below.
This causes your brain to engage
in a tug of war
as it fights
to filter
and ignore the noise.
The result is slower reading speeds
and decreased comprehension.
The company has developed a product
that automatically re-formats text
in a way
that your brain can more easily comprehend."
The only rules I used to format the text were:
* reset indent and start a new line after a full stop
* next line with indent after comma (,) or before one of the stop words
And stop words are: at, in, that, to, as, on, from, and.
Also, one should compare specially formatted text to normal block text with bigger font and more line space so that both variants took equal amount of vertical space in the end.
Yes, GPL cannot specify the hardware or it cannot require the underlying platform to perform a certain way. The GPLv3 can, however, specify that you cannot sell such hardware with GPLv3'd software as a bundle. Selling such bundle requires you to distribute GPLv3'd software and that requires a license which would be the GPLv3. If you don't accept the requirements the GPLv3 specifies (which require you to provide the end user a way to run his own modifications) you are not allowed to distribute the software at all. Which was the point of GPL in the first place.
I have to agree that GPLv3 could still be circumvented by selling the HARDWARE and SOFTWARE (under GPLv3) separately. The customer would then be clearly informed that the HARDWARE he buys cannot be used to run software expect if it has been signed by company X. If the customer is happy to accept such restriction when he buys the HARDWARE, then there shouldn't be any issue with the GPLv3, right? If that customer later decides to buy some signed software for his newly purchased HARDWARE there shouldn't be any problems with such software being GPLv3 AND signed by company X.
I'm not entirely sure if GPLv3 legally forces you to provide a way to sign software for the hardware you sell if you ALSO distribute any software covered by GPLv3 for such hardware. Perhaps even this could be circumvented by distributing (/selling?) the signatures separately from GPLv3'd software.
The noise that the Macrovision system adds to normal analog is just noise that shouldn't be in the signal by the spec. The vertical and horizontal blanking space should be zeroed (practically grounded for analog signal). A signal with the noise by Macrovision has additional crap on those parts of the signal. The resulting signal isn't up to the original spec and that's is the reason it cannot be successfully recoded by some devices. If you use a device that is known to fix this kind of problems from the signal (i.e. a device that can fix a corrupted, against the spec signal, etc.) you now break the law?
Perhaps they should ban all the other systems that fix or improve analog signals, too? Pretty much all CLD and plasma displays do this already because they, too, are digital and wouldn't be able to display the "correct" signal without removing the noice by Macrovision from the signal. The only real difference is that the device made by Sima is external to the display device.
Funny indeed. The password check is a piece of JavaScript on the page. It seems that they used to accept three different passwords and the code that they use to check the password has been rotten. Whitness the following:
Notice how pass2 and pass3 are undefined? An exception will not be raised if password is not correct and the script will be terminated before it can execute the window.location line. Bonus WTF points for the fact that the password is displayed in the dialog that prompts for it!
Then why not just release a paperback version first with 40% higher price tag and once early adopters have wasted their money, decrease the price to "normal". Is there any reason the publisher should use 10% valuable item for the first release? If the audience is ready to buy an overpriced product, they will do it anyway regardless of were it a paperback or a hardcover.
In case you're happy that "a browser" doesn't include Microsoft Internet Explorer, which doesn't support the data: URL spec (RFC 2397), be my guest. There isn't anything magically going on. According to RFC 2397 you can encode an external document, including all its data data, to an URL. Basically, you just need to prefix data:image/png;base64, to base64 encoded PNG image and paste the resulting string to SRC attribute of IMG element and you're done embedding the PNG image inside a HTML document.
Did I mention that MSIE does NOT support RFC 2397? So, you can use this method for every other browser but for MSIE and you have to use Microsoft's proprietary .MHT format for MSIE. IMO, it's not worth the trouble, just use PDF instead.
Wake me up again once somebody comes up with a way to put a HTML page with at least (originally) external PNG and CSS files inside a single file that can be viewed correctly without plugins with MSIE, Mozilla, Safari and Konqueror.
Why do you think either one of them is "correct"? Both of the compilers mentioned have been proven to generate invalid output for some inputs. You can consider both of them as "partial prove" for a great mathematical problem. Unfortunately, both of the solutions are just almost correct.
However, I think that (computer) source code and (complex) mathematical formulas should be granted copyright but no patents. The copyright should be granted for "creation time + 20 years" instead of current expiration day of "end of time minus one day" as it currently stands, though.
I think you mean you cannot afford to dedicate one whole machine per one version of Internet Explorer. One test machine can only include one version of MSIE. So you need 4 machines to test for MSIE 5.0, MSIE 5.5, MSIE 6.0 and now MSIE 7. That is, unless you try all those browsers side by side. Instructions to run multiple different versions of MSIE side by side in MS Windows.
Don't yet know if it's possible to run MSIE 7 as stand-alone version but at least you should be able to install that as the "official" browser and the rest as "local" versions.
Perhaps out of the box but FF has extensions to make it much better. If you digg tabbed browsing, you should check out following extensions (these have overlapping features so you might want to select only a few):
On the other hand, if you don't like tabbed browsing, that's okay too. There's an extension to totally disable tabbed browsing in Firefox.
I prefer open source (or free) software because I can be sure that it will work in the future, too. I understand that computer illiterates don't yet get this. Whitness the Flash player incompatibility with x86-64 platform of today, for example. Forget running Flash on Linux/PPC either. This is because Adobe/Macromedia is the only player on the field with the implementation and that's because Flash player isn't free (or open source).
The fact is that computer hardware is now interchangeable but software isn't. Make sure that the software solution you're using isn't locked down to a single vendor. Just because the plugin is "free" download doesn't mean it's a free lunch in the long run.
I wouldn't author any content for any proprietary format. I may, however, view some content inside some proprietary formats if somebody else has already done the mistake. That is, if I'm able to still view that content! If I'm not able to view that content, then that author cannot communicate with me. Why so many commercial web sites use Flash (or any other closed format) is beyound me -- if you try to sell me something, being able to communicate with me would be important, right? Flash may work today, will it be the same tomorrow?
And if you aren't that fluent with French, you could use Google's machine translation of the original study.
Did I misunderstood something when you said that the point of using BSD is the desire to give out total freedom? You now say that "its a bitch" when they change the license from BSD to GPL after adding a new feature which makes a piece of software more desirable. Are you sure that you really prefer BSD to GPL?
As I see it, the whole point of using GPL license is that it says that derived works must be licensed under the very same license. That, plus the fact that you must distribute sources with the binaries. Of course, it follows that GPL cannot be compatible with any other license.
The only fear I have is that in the future we have some piece of software that is licensed under GPL version 2 (without "or later" clause) and an another piece of software that is licensed under "GPL version 3 or later" and we cannot ever combine those. I think that it would make an example case what's wrong with GPL in general.
Oh, as opposed to ActiveX control that works in just one browser? If you're happy with just one supported browser, why not use XUL instead. It doesn't work in MSIE but it does support way more platforms than just Windows/x86. It might not seem that important now, but think about the future. Is your ActiveX componen going to work in 64 bit version of MSIE? The XUL application does work on a 64 bit platform.
Their view is that an HTML compliant rendering of soft hyphen is to not render it in any situation. HTML doesn't require the UA to use soft hyphen as a line break opportunity. It just says that UA may break the the line at soft hyphen and if it does then it must display a visible hyphen at the end of the line. Mozilla/Firefox doesn't do the "may" part so it isn't required to implement the "if" part. Just ignoring the character is compliant behavior.
Yes, it sucks. Yes, my mother tongue is Finnish so I know how much it could help the rendering. But the fact is that Mozilla/Firefox is indeed following HTML to the letter on this issue. The spec should have required support for soft hyphen but it didn't.
Oh really? The way I understand it, CSS is only used to give hints about the author intended rendering. The C in CSS means "cascading", which in turn means that the user can override rules defined by the content author. In addition, there's no way to even specify anything in real pixels. The "px" unit is defined as a part of field of vision. Some displays just "happen" to have actual pixel size near the CSS "px" unit. As a result, some browser manufacturers have implemented the "px" unit as a pixel. The spec does not require that!
So the problem really is that they are trying a bit too hard to fix it correctly, but they don't yet know which the correct way is.
The whole point of HTML is that it does not define a single way to view the content. The whole point of CSS is to provide hints about how the page author thinks that the content should be displayed.
As long as we're using different devices and different people have different needs, there's no reason to force same look and behavior for everybody. Some people do require 72pt font just to be able to read because they have such a bad vision. Some people are blind. Some are deaf. You cannot present the same content identically to everybody. What does matter, is that the user agent (commonly referred as the "browser") behaves the same when it comes to what the server sees. This is not the case today.
You're supposed to be able to always change the font size. The fact that MSIE isn't able to adjust font size if it's set to "12px" or "10pt" is a bug, not a feature. The fact that MSIE only has total of 5 different settings for font size in the UI might be a feature, but I consider that a bug, too.
Correct me if I'm wrong, but AFAIK the reported LCD pixel response time is (always?) the optimal case. The time it takes to go from white to black. All the other state changes are always slower.
I like CRT displays because they have predictable delays. A CRT display @100Hz has maximum delay of 10ms, always - and that includes the delay going from graphics adapter to visible dot on the screen.
Yes. It's in fact the bug #217527. The actual bug is a combination of table layout and javascript layout trickery. Slashdot was almost the only place to hit it.
The issue is hit with the following code:
<TABLE CELLPADDING="0" CELLSPACING="0" BORDER="0">
<TR>
<TD width="1" bgcolor="yellow">
<TABLE BORDER="0" CELLPADDING="0" CELLSPACING="0" ALIGN="LEFT">
<TR>
<TD>
xxx
<script type="text/javascript">var foo = document.body.offsetHeight;</script>
zzzzzzzz
</TD>
<TD></TD>
</TR>
</TABLE>
</TD>
</TR>
</TABLE>
The reason is that querying document.body.offsetHeight while the page is still loading caused element dimensions to be computed from partial page source. The results were then incorrectly cached and used later instead of recalculating the values once the page was completely loaded. In the example above, this causes the "zzzzzzz" part to fall out of table cell that is sized to fit only the width of "xxx". If the document.body.offsetHeight is not embedded inside the table or it's used only after the document has been fully loaded the bug can be avoided.
I don't expect that from any browser today. I'd settle with
That's right. The problem isn't that MSIE doesn't support some CSS features but that it supports many of the features incorrectly. For example, read about quirky implemenatation of percentage unit in MSIE. MSIE implements not one but two different implementations for that feature and neither is the correct one! Just try that page with MSIE and hover the examples with mouse cursor.
For amusement, next time MSIE messes up the page layout, try inserting CSS rule * {zoom:1}. That CSS property should do nothing (it's a proprietatry property defined by microsoft and it's supposed to select "zoom level" for the element, 1 being "100%").
...but I agree that there's a need for more. For example, hCalendar has some merit being XHTML compatible and can be nicely embedded in any XHTML (or even HTML) page. Distribution of calendar files (.ics) isn't the problem. The real problem is that it's hard to discuss events outside .ics format so that applications are still able to automatically extract the information. hCalendar is nicely submerged inside the real content as demonstrated by the example. Throw in hCard and we can finally talk about usable metadata embedded in a web page.
Not true. <b> and <i> are still elements just like before. You'll still use CSS selectors b and i (as opposed to .b and .i) to select those. Yes, they have the same semantics as <span> but they are definately not shorthands but real elements instead.
There's one critical difference. Linux is licensed under GPL plus a clause that allows running non-GPL software on the system. That allows users to run software with GPL incompatible licenses already so there's no need to rewrite MPL (or any other license) compatible variant. Linux can be also freely distributed and its modified versions can also be re-distributed as long as the modifications are released under GPL license. On the contrary, Java license doesn't even allow distribution of verbatim copy of VM, much less re-distribution of derivative works. There's no contest here.
If it wasn't the cost, one could make a pretty high speed optical reader by creating 12cm x 12cm CCD chip capable of reading every single pit in the surface of DVD disk at once. It would be just like a flat bed scanner, just faster. Scanning the whole disk would take 1/100th a second at most. Then it would be just matter of moving bits from the CCD chip to system memory fast enough. I won't even try to guess how much a 12cm x 12cm CCD chip with enough resolution to contact read a DVD disc would cost.
You know that <form>s can be modified too, right? If you're writing application that works through HTTP/Web browser then you just have to do a lot of checking (that's where the "if" comes in) to make sure that the client (browser/user agent/the real user) isn't trying to hack your system. If you don't do input validation for everything you might as well use GET for everything.
I do sometimes use GET for state changing actions in web applications I write. In some cases some toggle actions that reflect only data display result in much better user interface if I use normal links instead of <button>s. Sometimes you have to accept some compromises when you're writing webapps that have to work without CSS, images and javascript and still be usable.