I have a better idea. Decorate the doorway with grinning human skulls. To the best of my knowledge, there has never been any culture on Earth to which the message would have been the least bit unclear.
You mean like in the catacombs of old Europe? They're quite a tourist attraction nowadays.
This depends on what variation of this theory you subscribe to. If matter is allowed to escape the "big crunch" before the next "big bang", the universe would contain information about the previous cycle (or even earlier).
I don't know, 10 years sounds about the right length for a TV series, assuming it's a hit. You can't have things go too slowly or you'll have a series that's skipping months or years ahead between episodes or seasons.
(But then I guess we just saw that with BSG, didn't we?)
Maybe it's the gift of self-replication that we give to the Cylons that starts the whole chain reaction? Once they have the means and resources to do that, you can create an army in geometric time.
Hey don't knock it before you see it. I myself had very low expectations and very nearly didn't watch the first episode. I haven't missed an episode since.
I really hope this element gets some treatment in the prequel.
For example, what if it turns out that the early Cylons were unsafe machines, or made judgements that were too cold and treated walking-toasters and biological humans equally? Maybe the people tried to fix this by introducing a form of the Three Laws of Robotics by impressing the Cylons with a human religion: biological humans are "chosen", follow God's rules, etc.
So after the war, they sulk about how they're not biological, and then they have a eureka moment and figure out how to evolve themselves to be biological humans too. Maybe then they could claim to be God's children too and finally be at peace with their beliefs.
Of course, I'm just pulling this out of my ass, but there's a lot of possibilities here that would make for a very entertaining story.
Since the audience already knows what will happen to the characters in the future based on earlier movies, there is never that subconscious element of suprise.
I can only speak for myself, of course, but I get a lot of enjoyment out of solving puzzles and connecting things together. Prequels may not carry an "is he going to die?" element for the reasons you state, but they do frequently cause people to say "so THAT's why _____".
Stories frequently gloss over the history of something to tell you a story. If you can turn right around and connect "present day" events in a way you weren't expecting, that can be very interesting and entertaining. It might also let you see the "present day" story in a new light, bringing new depth.
I think this just amounts to a "best tool for the task" problem. HTML is not a replacement for PDF. If you need a brochure, designed by graphics folks, use a professional publishing tool, create your brochure, and save it as a PDF (or even a SVG). If you need easily searched, easily understood text online, use HTML.
There are plenty of absolutely stunning web sites out there that are standards-compliant, don't have layout tied to imagery, and scale wonderfully and appear reasonably on a variety of media. The technology and skills exist out there today to do this effectively. The problem has been solved repeatedly over several years by lots of very smart people. It's primarily the novices or those who misunderstand the capabilities of the web that have all of the trouble.
Now I'm not saying that incremental improvements such as some of those advocated by the article are a bad thing for HTML and CSS, but it's important that we realize that HTML/CSS were designed with completely different requirements than, say, PDF or SVG. We really need to resist the temptation to blur the line between them simply because we don't understand how they're supposed to work together and complement one another.
In print media, you don't deal with pixels. It's done in inches.
I was trying to say that people moving from print to web still think with the same concepts and methods. In the web world, their intents are expressed through pixel-based layout.
Thus, the web was intended to work with pixels.
The operative word here is "was". The web changed the moment non-PC web browsers were conceived. CSS and the push away from hard pixel-based layouts were created from that realization.
If you go back far enough, though, there really was no such thing as a layout by any modern definition. Text was black on white, Times New Roman, and only superficial changes could be made. It was never anticipated that people would start using tables to construct a page layout/design with images. This eventually did become common practice ("Thus, the web was intended [at that point] to work with pixels"), but lots of smart people saw right away that this was going to become problematic.
I specify the fixed element in pixels (because it's based on raster images)
But why? When you're preparing a Word processing document to print, do you specify your printed image size to match the printer's dots to the image's pixels? No, you indicate that the image should be 2-inches wide, or take up 25% of the page width, and flow text around it. A 100x100-pixel image or a layout based around it is going to look mighty tiny on a high-resolution printer without an author-based decision to take real-world canvas sizes into account.
I will concede that raster graphics don't always scale very well in Firefox and IE, but work is underway to improve the algorithm used so that raster graphics don't have to be rendered at exactly the same number of pixels the original image intended. (In fact, some raster graphics formats actually include DPI information within the image itself–they were already thinking ahead to when they would need to be rendered in situations where a 1-to-1 pixel mapping was less meaningful.)
I specify the fixed element in pixels (because it's based on raster images) or in ems (if it isn't) and now the remaining size of the window is a percentage
Why does the rest of the window have to be a percentage? Consider using 'float' here to make your fixed-size element float to one side of the canvas, and let the browser figure out how to wrap everything else around it. You might also consider more complex CSS positioning. Set a 100px margin to the left of your text, and stick the fixed-size element inside that 100px margin. There are all sorts of ways to approach this, as people have been solving this problem over and over again for years.
Give me inches or centimeters or some real measurement.
I'm not sure if you're asking this because you don't think it already exists. I apologize if you aren't, but if you are, CSS does have inches and centimeters (and points and picas). It's still not the best solution, because 2in on a cell phone is a lot different than 2in on a wall-sized projection (heck, 1in might be smaller than 1px in a scaled-px world).
even down to maintaining accurate relationships between items is to use pixels.
Only when your design and layout are heavily based on pixel-oriented display elements (raster images) to begin with. The position that I'm taking here is that precise relationships between image-oriented display elements for your layout is the wrong approach to start with. I'm not disagreeing with your conclusions here. I'm disagreeing with the assumption that our starting situation is actually the best practice.
Changing the content itself? The whole point of CSS is separating content from presentation.
You can select what does or does not appear, or where it appears, through CSS. If your navigational markup is basic, and you have terse text followed by verbose text, CSS can style that navigational markup in a cell-phone-friendly manner and hide the verbose text entirely.
It's not really different markup, but it is taking what you have and tailoring it to a specific output device.
em sizes redefine subsequent em sizes, and in different ways in different browsers.
The standards define how this behavior should work. If browsers are implementing this in unexpected ways, that's a legitimate bug that the browsers should fix. Here, you can point to a specification and say, "This is what you're doing wrong."
But what is true is that specifying everything in ems doesn't work worth a shit, and more people have gone the other direction, specifying everything (including font sizes) in pixels.
I think perhaps you're missing the point here: The problem isn't that pixel-perfect layouts with heavy use of positioned raster graphics fail to scale very well in web browsers. The problem is that pixel-perfect layouts with heavy use of positioned raster graphics shouldn't be part of the requirements to begin with.
HTML and CSS were designed with very specific goals: marking up and styling text. It is not a replacement for Microsoft Word, PDF or Flash.
There are lots of sites out there that look very nice. They use imagery in their presentation, yet everything scales nicely and degrades gracefully for less capable devices. Their pages validate and they don't abuse the technology. I don't mean any disrespect towards you or other web developers when I say that this stuff can be done, and this is how you do it. The difference between these web authors and other web authors that can't seem to make it work is skill and experience. There's nothing wrong with a field where the experts are able to do things novices cannot do. But the novices should be working to become experts. Instead, we have the novices claiming that they know better than the experts and the people that wrote the specifications, and that everyone else should simply adapt and make the novice approach the correct approach.
DDC does carry this information, but it requires (a) a capable monitor, (b) a capable operating system, and the OS isn't going to do it unless (c) applications don't fuck up when the OS's DPI settings are changed around.
Not everyone has (a), and fewer still have (b) (even manually changing the DPI in Windows breaks a lot of things), and very few applications fit (c). Lots of GUI frameworks let developers tie their layout to pixel-specific dimensions.
1. Author: Stop tying your layout to images 2. Author: Use relative units when laying out raster graphics 3. Author: Use vector graphics instead of raster graphics (perhaps with HTTP content negotiation) 4. Browser: Improve browser raster scaling algorithms 5. Browser: Wider SVG support 6. Browser: Consider rendering graphics per the DPI setting in the graphic file, or an implied ~72dpi for raster graphics generally
... it has nothing to do with the web site author. It's the interface displaying the web page that needs to compensate for the high DPI
I'm not sure I understand/agree here. It is the web site author that states, in CSS, "render this 10 pixels high". It's the web site author that creates a raster graphic 10 pixels high.
Today, the user agent does what the web author says, and renders that display element, font or image using 10 pixels of the monitor.
You're saying that even though the page's author specifically said 10 pixels, that this problem is, in fact, the fault of the user agent for doing what the author said?
The W3C would seem to agree with you in that they state that 1px in CSS isn't actually supposed to correspond to exactly 1 display pixel, but this doesn't extend to imagery or other display elements not styled with px units in CSS.
A "point" is an absolute unit of measurement, so a 12pt font will display at the same size on any properly configured monitor.
That's just it, though. It's your OS that needs to be "configured". It doesn't know how large your monitor physically is. It just knows how many pixels it can display. It needs to be told how many inches/centimeters those pixels take up. This can be done on most operating systems, but it's handled poorly by Windows XP in that the display elements within the OS and most applications still make bad pixel-based assumptions about how they're going to be rendered, and lots of things look pretty awful.
E.g., <img width="10cm" src="file.jpg"> <!-- is not allowed! -->
I agree but I think it's a necessary evil. The definition of what a pixel is varies, from a size perspective, so much between even monitors and printers. My monitor can do 100-200dpi. My printer can do 10 times that. So when I print out a web page, should those fonts that developers have said should be 8px tall be rendered at 1/250th of an inch? The W3C decided instead to make a 'px' represent something more useful than a simple pixel. For PC monitors, the difference is insignificant enough for browsers to change their behavior, but you can clearly see how the difference is applied when printing pages.
Of course, you avoid all of this problem when you stop using absolute units of measure and start using relative. An unimportant display element styled to be "2in" wide is far too large on a cell phone, about right on a PC monitor or a printer, but way too small when projected onto a large screen or viewed on a big-screen TV. Should we convert all of these display units into something that's based on the distance to the user and the angle it takes up in the user's field of view? Where do you draw the line?
I think you missed the main point of the parent post: Why is this so?
The typical answer is that web design is being done by marketing departments. These departments have specialized in one thing: print media. They know exactly how big the logo is supposed to be, where it has to be placed relative to the text, exactly how many pixels need to separate it from the edge of the canvas, etc.
This is not how the web is intended to work, and what the "stop coding to pixel sizes" crowd is trying to say. People coding to an 800x600 standard do this by making their banner graphics, say, 750 pixels wide, their left navigation menu exactly 150 pixels wide, etc. These are all completely artificial requirements that are a hold over from table-based layouts that are heavily dependent upon raster graphics (GIF, JPEG, etc.).
What is normally recommended for the web is different: sizes based on percentages, or relative units of measure like em/ex that work based on the preferences of the rendering engine and the user, not on the needs of the graphics guy.
Requiring that text be exactly 8 pixels high is fine for low-resolution devices, but is ridiculous when you start working with 20" displays that operate at 200dpi. The proper solution is to stop tying your display elements to the pixels of the display, and start tying them to more meaningful and useful units of measure. It's really sad that we have to consider redefining what a "pixel" is to the perspective of a web author, because it's been abused so much. Stop abusing it and we won't have this problem!
Adapting to different media requires much more than playing around with fonts, sizes, and CSS. Usually, the navigation structure and content itself need to change.
This can be accomplished with CSS.
People like you should be kept as far away as possible from creating either software or content for the web; you simply don't have a clue.
Don't be an ass. The original poster has a perfectly valid point. While your point is also a good one, it's really an extension to what the other poster was saying. Just because some sites may need a lot of work to become truly universal doesn't mean that non-raster authoring techniques aren't a significant part of that, or that some sites may be able to use CSS and SVG to achieve the goal without changes to navigation and content.
I'm not sure I agree with that statement generally. For many, no, the theory will never be used. But I find that there is a direct correlation between people that can properly troubleshoot a complex problem and an understanding of protocol layering, for example.
The guy gathering chuckles at using "Big O" notation in the real world isn't getting any chuckles from me.
I do completely agree, though, that a knowledge of how something works is often a hard prerequisite to being able to troubleshoot or program the thing. I think the parent poster was discussing the value of a non-science, non-engineering degree for the purposes of doing more business management. An IS guy is going to make an "okay" programmer, but probably a decent business manager or even a supervisor of proper developers. An engineering guy is probably going to make an excellent programmer or developer, but I'm not sure I would prefer one in more of a business management role.
Re:The problem of nerve impulse conduction
on
An Alternate Human
·
· Score: 1
But quick reactions like this can be handled somewhere other than the brain. Just like our spinal cord handles fast reactions for our hands and feet, some nerve center could handle involuntary eye blinks or flinches.
This nerve center would have to do some rudimentary image processing, or else you'd be ducking and flinching every time a bee flew by or a shadow passed over you. This image processing would take a lot of work. The reflex arcs within your spinal cord are very simplistic.
I'm not saying it couldn't be done, but it would greatly complicate image processing and thus your ability to see.
Re:The problem of nerve impulse conduction
on
An Alternate Human
·
· Score: 1
If you step on a nail, the amount of information that needs to travel to your head is minimum before your 'reflex' pulls your foot up
In fact, your brain hasn't received anything yet before your reflex is activated. The pain signal makes its way to your spinal cord, where it hits a reflex arc, which sends a message right back to your muscles telling them to withdraw.
Re:So what exactly *is* the bandwidht of my eyes?
on
An Alternate Human
·
· Score: 1
The bandwidth of the optic nerve is believed to be equivalent to about 100 kbps. You have to remember a few things:
Signals travelling through your nerves are electrochemical in nature, not electrical. Since you have the chemical aspect to deal with, you can't send signals along your nerves at anywhere near the speed of light. Think speed of sound.
The nerve fibers themselves are massively parallel, with about a million strands
All of this is analog, not digital, so a "bit" isn't really isn't even a very good way of measuring this to begin with.
All of this was highly evolved over thousands if not millions of generations
You only have the ability to pick up details at the very center of your field of vision. Take some text and look a few inches to either side of it and see how easy it is to read. Consider the types of pseudo-compression that your eyes can take advantage of here to encode information about things within your field of vision that you aren't directly looking at.
Re:So what exactly *is* the bandwidht of my eyes?
on
An Alternate Human
·
· Score: 1
Depth perception occurs where the two images are merged and processed. This would be within the brain and not the eyes, so no depth information would accompany the optical signal.
A hologram does not trick the eyes into seeing a three dimensional image, a hologram IS a true 3D image, and while it may have a reflective backing, the hologram itself is transmissive, not reflective.
I suspect the disagreement here is on the colloquial use of "image", "hologram" and "reflective". A hologram (the physical thing) is effectively a two-dimensional thing. On the two-dimensional hologram is encoded a three-dimensional holographic image (which I suspect is what you were trying to say when you said "hologram"). When light is reflected off of the two-dimensional hologram (thing), it produces a three-dimensional holographic image which is what your eyes see.
The physical hologram is reflective. When you turn off the lights, you can't see it anymore. You could stretch things and say the image is "transmissive" in that the information is being emitted with (encoded using) the reflected light. It might also be accurate to say the light itself is emissive or transmissive in the quantum electrodynamic sense that any photon interacting with matter is a brand new photon. But in the real world we consider the light to be reflective.
Slashdot Mirror
I have a better idea. Decorate the doorway with grinning human skulls. To the best of my knowledge, there has never been any culture on Earth to which the message would have been the least bit unclear.
You mean like in the catacombs of old Europe? They're quite a tourist attraction nowadays.
This depends on what variation of this theory you subscribe to. If matter is allowed to escape the "big crunch" before the next "big bang", the universe would contain information about the previous cycle (or even earlier).
I don't know, 10 years sounds about the right length for a TV series, assuming it's a hit. You can't have things go too slowly or you'll have a series that's skipping months or years ahead between episodes or seasons.
(But then I guess we just saw that with BSG, didn't we?)
Maybe it's the gift of self-replication that we give to the Cylons that starts the whole chain reaction? Once they have the means and resources to do that, you can create an army in geometric time.
Hey don't knock it before you see it. I myself had very low expectations and very nearly didn't watch the first episode. I haven't missed an episode since.
Maybe the human-like Cylons were based on actual living humans that the Cylons knew (perhaps revered) from their past?
I really hope this element gets some treatment in the prequel.
For example, what if it turns out that the early Cylons were unsafe machines, or made judgements that were too cold and treated walking-toasters and biological humans equally? Maybe the people tried to fix this by introducing a form of the Three Laws of Robotics by impressing the Cylons with a human religion: biological humans are "chosen", follow God's rules, etc.
So after the war, they sulk about how they're not biological, and then they have a eureka moment and figure out how to evolve themselves to be biological humans too. Maybe then they could claim to be God's children too and finally be at peace with their beliefs.
Of course, I'm just pulling this out of my ass, but there's a lot of possibilities here that would make for a very entertaining story.
Since the audience already knows what will happen to the characters in the future based on earlier movies, there is never that subconscious element of suprise.
I can only speak for myself, of course, but I get a lot of enjoyment out of solving puzzles and connecting things together. Prequels may not carry an "is he going to die?" element for the reasons you state, but they do frequently cause people to say "so THAT's why _____".
Stories frequently gloss over the history of something to tell you a story. If you can turn right around and connect "present day" events in a way you weren't expecting, that can be very interesting and entertaining. It might also let you see the "present day" story in a new light, bringing new depth.
Did anyone else notice that slashdot.org is in the list of vulnerable sites?
I think this just amounts to a "best tool for the task" problem. HTML is not a replacement for PDF. If you need a brochure, designed by graphics folks, use a professional publishing tool, create your brochure, and save it as a PDF (or even a SVG). If you need easily searched, easily understood text online, use HTML.
There are plenty of absolutely stunning web sites out there that are standards-compliant, don't have layout tied to imagery, and scale wonderfully and appear reasonably on a variety of media. The technology and skills exist out there today to do this effectively. The problem has been solved repeatedly over several years by lots of very smart people. It's primarily the novices or those who misunderstand the capabilities of the web that have all of the trouble.
Now I'm not saying that incremental improvements such as some of those advocated by the article are a bad thing for HTML and CSS, but it's important that we realize that HTML/CSS were designed with completely different requirements than, say, PDF or SVG. We really need to resist the temptation to blur the line between them simply because we don't understand how they're supposed to work together and complement one another.
In print media, you don't deal with pixels. It's done in inches.
I was trying to say that people moving from print to web still think with the same concepts and methods. In the web world, their intents are expressed through pixel-based layout.
Thus, the web was intended to work with pixels.
The operative word here is "was". The web changed the moment non-PC web browsers were conceived. CSS and the push away from hard pixel-based layouts were created from that realization.
If you go back far enough, though, there really was no such thing as a layout by any modern definition. Text was black on white, Times New Roman, and only superficial changes could be made. It was never anticipated that people would start using tables to construct a page layout/design with images. This eventually did become common practice ("Thus, the web was intended [at that point] to work with pixels"), but lots of smart people saw right away that this was going to become problematic.
I specify the fixed element in pixels (because it's based on raster images)
But why? When you're preparing a Word processing document to print, do you specify your printed image size to match the printer's dots to the image's pixels? No, you indicate that the image should be 2-inches wide, or take up 25% of the page width, and flow text around it. A 100x100-pixel image or a layout based around it is going to look mighty tiny on a high-resolution printer without an author-based decision to take real-world canvas sizes into account.
I will concede that raster graphics don't always scale very well in Firefox and IE, but work is underway to improve the algorithm used so that raster graphics don't have to be rendered at exactly the same number of pixels the original image intended. (In fact, some raster graphics formats actually include DPI information within the image itself–they were already thinking ahead to when they would need to be rendered in situations where a 1-to-1 pixel mapping was less meaningful.)
I specify the fixed element in pixels (because it's based on raster images) or in ems (if it isn't) and now the remaining size of the window is a percentage
Why does the rest of the window have to be a percentage? Consider using 'float' here to make your fixed-size element float to one side of the canvas, and let the browser figure out how to wrap everything else around it. You might also consider more complex CSS positioning. Set a 100px margin to the left of your text, and stick the fixed-size element inside that 100px margin. There are all sorts of ways to approach this, as people have been solving this problem over and over again for years.
Give me inches or centimeters or some real measurement.
I'm not sure if you're asking this because you don't think it already exists. I apologize if you aren't, but if you are, CSS does have inches and centimeters (and points and picas). It's still not the best solution, because 2in on a cell phone is a lot different than 2in on a wall-sized projection (heck, 1in might be smaller than 1px in a scaled-px world).
even down to maintaining accurate relationships between items is to use pixels.
Only when your design and layout are heavily based on pixel-oriented display elements (raster images) to begin with. The position that I'm taking here is that precise relationships between image-oriented display elements for your layout is the wrong approach to start with. I'm not disagreeing with your conclusions here. I'm disagreeing with the assumption that our starting situation is actually the best practice.
Changing the content itself? The whole point of CSS is separating content from presentation.
You can select what does or does not appear, or where it appears, through CSS. If your navigational markup is basic, and you have terse text followed by verbose text, CSS can style that navigational markup in a cell-phone-friendly manner and hide the verbose text entirely.
It's not really different markup, but it is taking what you have and tailoring it to a specific output device.
em sizes redefine subsequent em sizes, and in different ways in different browsers.
The standards define how this behavior should work. If browsers are implementing this in unexpected ways, that's a legitimate bug that the browsers should fix. Here, you can point to a specification and say, "This is what you're doing wrong."
But what is true is that specifying everything in ems doesn't work worth a shit, and more people have gone the other direction, specifying everything (including font sizes) in pixels.
I think perhaps you're missing the point here: The problem isn't that pixel-perfect layouts with heavy use of positioned raster graphics fail to scale very well in web browsers. The problem is that pixel-perfect layouts with heavy use of positioned raster graphics shouldn't be part of the requirements to begin with.
HTML and CSS were designed with very specific goals: marking up and styling text. It is not a replacement for Microsoft Word, PDF or Flash.
There are lots of sites out there that look very nice. They use imagery in their presentation, yet everything scales nicely and degrades gracefully for less capable devices. Their pages validate and they don't abuse the technology. I don't mean any disrespect towards you or other web developers when I say that this stuff can be done, and this is how you do it. The difference between these web authors and other web authors that can't seem to make it work is skill and experience. There's nothing wrong with a field where the experts are able to do things novices cannot do. But the novices should be working to become experts. Instead, we have the novices claiming that they know better than the experts and the people that wrote the specifications, and that everyone else should simply adapt and make the novice approach the correct approach.
DDC does carry this information, but it requires (a) a capable monitor, (b) a capable operating system, and the OS isn't going to do it unless (c) applications don't fuck up when the OS's DPI settings are changed around.
Not everyone has (a), and fewer still have (b) (even manually changing the DPI in Windows breaks a lot of things), and very few applications fit (c). Lots of GUI frameworks let developers tie their layout to pixel-specific dimensions.
I think this is a great idea, for future versions of Windows. How does this help us today?
This is solvable, though:
1. Author: Stop tying your layout to images
2. Author: Use relative units when laying out raster graphics
3. Author: Use vector graphics instead of raster graphics (perhaps with HTTP content negotiation)
4. Browser: Improve browser raster scaling algorithms
5. Browser: Wider SVG support
6. Browser: Consider rendering graphics per the DPI setting in the graphic file, or an implied ~72dpi for raster graphics generally
... it has nothing to do with the web site author. It's the interface displaying the web page that needs to compensate for the high DPI
I'm not sure I understand/agree here. It is the web site author that states, in CSS, "render this 10 pixels high". It's the web site author that creates a raster graphic 10 pixels high.
Today, the user agent does what the web author says, and renders that display element, font or image using 10 pixels of the monitor.
You're saying that even though the page's author specifically said 10 pixels, that this problem is, in fact, the fault of the user agent for doing what the author said?
The W3C would seem to agree with you in that they state that 1px in CSS isn't actually supposed to correspond to exactly 1 display pixel, but this doesn't extend to imagery or other display elements not styled with px units in CSS.
A "point" is an absolute unit of measurement, so a 12pt font will display at the same size on any properly configured monitor.
That's just it, though. It's your OS that needs to be "configured". It doesn't know how large your monitor physically is. It just knows how many pixels it can display. It needs to be told how many inches/centimeters those pixels take up. This can be done on most operating systems, but it's handled poorly by Windows XP in that the display elements within the OS and most applications still make bad pixel-based assumptions about how they're going to be rendered, and lots of things look pretty awful.
E.g., <img width="10cm" src="file.jpg"> <!-- is not allowed! -->
<img src="file.jpg" style="width: 10cm">
I agree but I think it's a necessary evil. The definition of what a pixel is varies, from a size perspective, so much between even monitors and printers. My monitor can do 100-200dpi. My printer can do 10 times that. So when I print out a web page, should those fonts that developers have said should be 8px tall be rendered at 1/250th of an inch? The W3C decided instead to make a 'px' represent something more useful than a simple pixel. For PC monitors, the difference is insignificant enough for browsers to change their behavior, but you can clearly see how the difference is applied when printing pages.
Of course, you avoid all of this problem when you stop using absolute units of measure and start using relative. An unimportant display element styled to be "2in" wide is far too large on a cell phone, about right on a PC monitor or a printer, but way too small when projected onto a large screen or viewed on a big-screen TV. Should we convert all of these display units into something that's based on the distance to the user and the angle it takes up in the user's field of view? Where do you draw the line?
You have to shoot for _some_ resolution
I think you missed the main point of the parent post: Why is this so?
The typical answer is that web design is being done by marketing departments. These departments have specialized in one thing: print media. They know exactly how big the logo is supposed to be, where it has to be placed relative to the text, exactly how many pixels need to separate it from the edge of the canvas, etc.
This is not how the web is intended to work, and what the "stop coding to pixel sizes" crowd is trying to say. People coding to an 800x600 standard do this by making their banner graphics, say, 750 pixels wide, their left navigation menu exactly 150 pixels wide, etc. These are all completely artificial requirements that are a hold over from table-based layouts that are heavily dependent upon raster graphics (GIF, JPEG, etc.).
What is normally recommended for the web is different: sizes based on percentages, or relative units of measure like em/ex that work based on the preferences of the rendering engine and the user, not on the needs of the graphics guy.
Requiring that text be exactly 8 pixels high is fine for low-resolution devices, but is ridiculous when you start working with 20" displays that operate at 200dpi. The proper solution is to stop tying your display elements to the pixels of the display, and start tying them to more meaningful and useful units of measure. It's really sad that we have to consider redefining what a "pixel" is to the perspective of a web author, because it's been abused so much. Stop abusing it and we won't have this problem!
Adapting to different media requires much more than playing around with fonts, sizes, and CSS. Usually, the navigation structure and content itself need to change.
This can be accomplished with CSS.
People like you should be kept as far away as possible from creating either software or content for the web; you simply don't have a clue.
Don't be an ass. The original poster has a perfectly valid point. While your point is also a good one, it's really an extension to what the other poster was saying. Just because some sites may need a lot of work to become truly universal doesn't mean that non-raster authoring techniques aren't a significant part of that, or that some sites may be able to use CSS and SVG to achieve the goal without changes to navigation and content.
No you will never directly use the theory
I'm not sure I agree with that statement generally. For many, no, the theory will never be used. But I find that there is a direct correlation between people that can properly troubleshoot a complex problem and an understanding of protocol layering, for example.
The guy gathering chuckles at using "Big O" notation in the real world isn't getting any chuckles from me.
I do completely agree, though, that a knowledge of how something works is often a hard prerequisite to being able to troubleshoot or program the thing. I think the parent poster was discussing the value of a non-science, non-engineering degree for the purposes of doing more business management. An IS guy is going to make an "okay" programmer, but probably a decent business manager or even a supervisor of proper developers. An engineering guy is probably going to make an excellent programmer or developer, but I'm not sure I would prefer one in more of a business management role.
But quick reactions like this can be handled somewhere other than the brain. Just like our spinal cord handles fast reactions for our hands and feet, some nerve center could handle involuntary eye blinks or flinches.
This nerve center would have to do some rudimentary image processing, or else you'd be ducking and flinching every time a bee flew by or a shadow passed over you. This image processing would take a lot of work. The reflex arcs within your spinal cord are very simplistic.
I'm not saying it couldn't be done, but it would greatly complicate image processing and thus your ability to see.
If you step on a nail, the amount of information that needs to travel to your head is minimum before your 'reflex' pulls your foot up
In fact, your brain hasn't received anything yet before your reflex is activated. The pain signal makes its way to your spinal cord, where it hits a reflex arc, which sends a message right back to your muscles telling them to withdraw.
Depth perception occurs where the two images are merged and processed. This would be within the brain and not the eyes, so no depth information would accompany the optical signal.
A hologram does not trick the eyes into seeing a three dimensional image, a hologram IS a true 3D image, and while it may have a reflective backing, the hologram itself is transmissive, not reflective.
I suspect the disagreement here is on the colloquial use of "image", "hologram" and "reflective". A hologram (the physical thing) is effectively a two-dimensional thing. On the two-dimensional hologram is encoded a three-dimensional holographic image (which I suspect is what you were trying to say when you said "hologram"). When light is reflected off of the two-dimensional hologram (thing), it produces a three-dimensional holographic image which is what your eyes see.
The physical hologram is reflective. When you turn off the lights, you can't see it anymore. You could stretch things and say the image is "transmissive" in that the information is being emitted with (encoded using) the reflected light. It might also be accurate to say the light itself is emissive or transmissive in the quantum electrodynamic sense that any photon interacting with matter is a brand new photon. But in the real world we consider the light to be reflective.