"cheap foreign knockoff souvenirs" Ironic thing is the souvenirs probably cost more than the original to build. Sweatshops may be cheap, but good ole fashioned slave labor wins hands down.
"I'd like to see it hit with a 175lb crossbow!" Haha, you'd have monitor crumbs.
But good lord! Take your monitor at home, a spoon, and a marble. I'd bet you could use the spoon to catapult your marble towards your monitor and bust it real good. That's one durable monitor!
You are absolutely right. I am just waiting to see how many people reply to you with nonsense like "Nuh unh! You should have presented it. You just *gave* it to your boss!"
IP can be a tool to protect one's own ideas, or it can be a cudgel to stifle innovation. It was intended to be used for the former, and today it's being used for the latter.
This whole debate will never go away and will never be solved because nobody can enforce the law properly by addressing these issues: 1) who owns IP? Corporations or the people who do the inventing who are also working for these corporations? 2) should IP be used to prevent others from building on your ideas? 3) just what exactly should be considered IP? 4) is your "IP" really IP, or was it common knowledge or a historcal inevitability that someone come up with the idea? In other words, if your IP truly unique or were you just the first to get to the USPO?
Should music be considered IP? Should technology, which is clearly IP, prevent others from using your ideas to build on? Should corporations be allowed to "obtain" IP and thus own it? Also, while there is overlap, what is IP and what is merely copyrighted?
If anyone can actually answer these questions definitively, then that person could fix the whole problem. Trouble is, nobody can and nobody will.
Gimme a break. I suspect many geeks here like electronics. I don't see how you *can't* like electronics if you're a geek.
I mod guitar amps, and am working on building my first one, which will be all tube (5y3 rectifier tube, 12at7 and 12ax7 preamp tubes, and 6v6 output tubes.)
Absolutely, it's just natural that the people who would have to enforce this piece of crap don't like it. Unenforceable, arbitrary, hard to prove...need I go on?
There ought to be a law against unenforceable legislation! Oh, wait...
Absolutely right, what I mean is this: the large corporation needs your skills. Your skill set / experience may be very costly or difficult to replace. But your loved ones care about *you*. They couldn't find someone else with your same skill sets to replace you, because to them you are irreplaceable. I was just trying to show the absurdity of people misplacing their priorities. Killing yourself for a corporation is crazy. That's all I meant.
If you were to die tomorrow, this would affect your family for the rest of their lives. You are irreplaceable. Your company would fill your position within days and except for your immediate co-workers, nobody would even care.
From TFS: "senior executives claiming a BlackBerry can contribute to work/life balance by facilitating telecommuting and more flexible schedules. "
More flexible for whom? Where I work, that seems to be a one way flexibility. Senior executives are making (SWAG alert) 3x - 10x what I am making. They have made the choice to have a large stake in how the company performs. While I have a stake, of course, it's just not as large or worth my personal/family life. It seems like despite being more accessible, people's work hours never get shorter. And that's what it's about in the end, isn't it? Getting more done in less time? But in rality, it just seems that it's about getting more done in more time. No good. I am glad I have no blackberry.
I stopped worrying about that kind of stuff when I started using the prototype javascript library. It is easy to use and it Just Works. I've used it in a production environment for...I think ~2 years now. I normally detest using other peoples' third party javascript libraries. Prototype is a notable exception to my roll-your-own approach. I cannot say enough good things about it.
I think you are making a bit of a blanket statement here, and you have to be careful with those. I have a site that I am working on right now, unfortunately on an intranet so I cannot show it to you. The site has a header bar (a horizontal bar 100% wide) a menu bar (same as header) the content area, which I'll come back to, and a footer (a simple horizontal bar 100% wide).
The content area must have a 200px wide sidebar that is expandable and collapsible. The header, menu, content, and footer need to be 100% wide or 1000px whichever is wider (sorry, 600x800 folks, get with the times). The sidebar and content need a divider line between the two.
I was able to do ALL of that using divs and CSS. I used a container for the content with a 200px negative margin, and the content div floated left with a 200px margin. The sidebar floated right. To close the sidebar, I'd just set display to none, and remove the negative margin on the wrapper and the margin on the actual content. Beautiful.
So what's the problem? Well to make a long story short, lack of min-width support in IE. Without min-width, there is no good way to make sure that my menu and content don't get *mangled* when users resize the browser smaller than about 800px wide. But when a div has floating elements inside it, there is nothing to prevent those floating elements from getting scrunched up. That is just the natural flow of floating (or inline) elements, and I accept that. I wanted to put a spacer div inside the container and menu to keep them open to a certain width, but no dice.
I adhere to web standards for all of my sites and they work well in all browsers. However, the reality is that IE is 95% of the traffic, so the design MUST work in IE. Oh, how I hate IE. Anyhow, IE doesn't understand min-width or min-height and that kills my design. I know there are hacks; all that I have seen mean you have to put javascript in your CSS and an onresize event handler in the body (yuck and yuck). Two problems with that: 1) putting javascript in CSS? Um, no. Why not just use activeX while we are at it? 2) I abandoned my moral objections to this and tried it in a prod setting. It crashed IE for not just a few people, and that's unacceptable. Turns out, executing a simple javascript expression every time the browser resizes is just too much computation for lamebrained IE. Of course, there may have been some other facet of my design exacerbating the problems, I don't think people would knowingly publicize IE hacks that kill IE. However, not having unlimited time at my disposal, I did not figure out *why* this happened. I just axed the layout.
I have been programming for a very long time in a professional environment, and there is something that the many years have taught me: if you are beating your head against a wall to accomplish some programming task, you are approaching it wrong. Well, this is no different. If you have to pile hack upon hack just to make a layout work, then your approach probably all wrong. Not only that, but you are defeating one of the main benefits of separating content from presentation, namely, making a lightweight and easily maintainable layout. The more hacks you pile on, the more problems you create for yourself. The harder the site will be to maintain. And you'd better hope that the hacks that fix one version of a browser *cough*IE*cough* don't break under the next version.
After trying for a week to do things the academically correct way, I gave up and made a tabular layout that validates, is lightweight, and works perfectly. In doing so, I had to overcome my prejudice against tabular layouts. Then I found this article on a respected design site and it kind of validated the conclusion I had already come to: that using tables for some layouts is not only necessary, but also appropriate. Not saying that you need seven layers of nested tables. But I could see someone having to do what I did: use a 1x5 table or
Some things are easy to learn. Other things are easy to do once you've learned them. Checkers is easy to learn. Five minutes and you've got the gist of it. Reading is difficult to learn. It takes years to become an effective reader. Yet, once you've learned to read, reading is relatively easy. A programming language, or in this case, a programming methodology, can be difficult to learn. But once learned, it becomes easy to use.
Writing AJAX apps is easy, don't let your ignorance fool you. It's not easy to learn how to do it properly, but once you've learned it is easy. If you do not know how to use it, then you are really in a poor position to judge its ease of use.
I used to be on the side of using semantically neutral elements like divs and css to specify layout.
Most layouts work fine with semantically neutral elements (divs). Some don't. I have used tables for layout in one or two cases, but not before trying VERY hard to make a purely CSS driven solution. To approximate it using no tables, I'd have to put javascript in my CSS expressions to make IE simulate min-width and min-height, among other things. Since that's a clever but ultimately sucky solution, tables won out. We're talking very specific layouts here. Usually you shouldn't need tables.
I said it in another nearby post, but I'll say it again here: being a professional is knowing the rules. Another part of being a professional is knowing when to break them. Yes, using tables for layout is a semantic faux-pas. But sometimes it makes the most sense.
If you find yourself having to cobble together a collections of hacks to make a certain layout work without tables, then you either need to abandon the layout, or if you cannot, use tables. Semantically incorrect, but it's better than some of the hacks that you have to use to work around browser (IE) flakiness. I am not talking about wrapping floating divs in a container with negative margins. That's a pretty elegant solution. I am talking about several layers of nested divs with wacky CSS tricks and IE hacks on top of Javascript magic. That stuff is ridiculous. In short, use the best tool for the job and get over your prejudices about a certain design methodology being "bad".
Please do not take offense, but the fact that you tried using the position property shows that you don't really understand CSS that well. That's not meant as an insult, just a statement of (apparent) fact. I just wrote a very simple page (just a div and image tag, no doctype or anything) that had this content: <div style="width:40pt;height:40px;border:solid;">
<img src="foo.png" style="width:50%;height:50%;"/> </div>
That displayed the image correctly in Firefox and IE6, the image's dimensions being 50% of the div's width and 50% of the div's height. Not that you *should* use points for dimensions, but that's just in keeping with what you said you did.
That said, browser behavior is very flaky. Your frustration is not unjustified. Especially with IE. IE sucks. There's not much more to say about it.
"It would be even better not to use the defective product at all, but that is hard when the vendor has a monopoly status." Preaching to the choir, dude.
Eh, I don't know if that's entirely true. Maybe true in a VERY pragmatic sense only.
A screwdriver can also pry nails out of a 2x4. That doesn't mean you should do it. You will probably impale your hand. A flamethrower can light the candles on your kid brother's birthday cake. But you might light grandma on fire.
Using HTML elements for things that are not quite correct might work on the browser you are using. Why, I could use <label> tags to lay out an entire site and use CSS to make it look ok in mainstream web browsers. That doesn't mean another user agent or screen reader won't totally freak out upon seeing it.
Table are necessary for some layouts. I have a site where it is just impossible to avoid using a simple table for layout. But you should know that it is semantically a faux-pas to do so. Part of being a professional is to know the rules and also to know when to break them.
I don't think you'll find any web developers who like IE. That said, what did you expect <img src="foo.gif" style="width: 50%;height:50%;"> to do? In other words, you wanted the width and height to be 50% of what? The image or the thing that contains it? I think maybe the browsers didn't do what you wanted it to and instead of finding out why you just gave up. The web is a great platform, but since browsers can be really sketchy, you need to understand why some things go wrong. This is essential. In programming languages like Java, an error results in a nice tidy error message. But since browsers *try* to render bad markup, instead of concise errors, you get weird behaviour that you have to figure out. Over time, it gets much easier. But that is why when you get unpredictable results, you need to figure out why. You can't just hack your way around it and move on, not if you want to learn.
I don't know much about GWT (the fact that Google developed it is at least encouraging). But if it's like some of the other java based solutions that are designed to write HTML, I'd run away fast. If you want to be a web developer, then you need to learn the languages of the web (HTML, CSS, Javascript at the very least). I'd be shocked to find that GWT doesn't generate steaming piles of dung in place of good, clean, standards compliant markup, and that means you have all kinds of compatibility issues, accessibility issues, and code that is harder to maintain.
The thing is, the AJAX bit is a very small part of the total AJAX package. Then you'll need to learn JSON (a good data interexchange format) and how to use Javascript to create elements.
There, now that I have provided what you asked for and not just some smart alek remark about how you need to google it, this has to be said...If you seriously expect to master a useful skill in an afternoon, then you have some expectation issues. If there's one thing life has taught me, it's that something worth having doesn't come in a day, and if it does come in a day, it's probably not worth much. Did you learn to program in one day? No? Then why would you expect to learn a complex object and a totally new technique for making web applications on one day? But if you really want to learn then you'll thank me for those links later when your web development reaches the next level. If you are just bashing AJAX with a cudgel of ignorance, then you'll ignore those links and keep griping about AJAX being too hard. I guess time will tell.
Developing for the web is about knowing your audience. If I were designing a site like ebay or amazon, in other words, trying to have the widest possible user base, or if I were working for some entity that had to abide by ADA requirements, then maybe avoiding AJAX would be advisable. For a site that is not a necessity, like, for example, youtube, slashdot, digg, flickr, etc AJAX is great. When done properly, AJAX makes more efficient applications that enhance the user experience.
Also, if you really want to, you can develop sites that use AJAX but also degrade nicely. Everyone here (at least, anyone who calls himself a serious web developer) is using web standards and writing good semantic markup, right? Well, that will make your site at least accessible. If you just use the noscript tag to handle non javascript user agents (where necessary, obviously not where there isn't ROI anyway) then your site should work pretty well.
As someone else who replied to you mentioned, we cannot develop web sites around people who for some crazy reason refuse to use new technologies (if you call javascript new, as if!). That, along with MSIE, are holding the web back.
I think people who hate AJAX just hate it because of all the bad AJAX sites. But that's like hating the web because there are bad non-ajax sites. AJAX, like other technologies, makes things better when used properly.
Whatever kind of software we are talking about, you'll most likely get a horrid UI and the resulting usability headaches.
On one hand, you get design by committee. A UI that is not great, but just didn't offend anyone, the software equivalent of a meal at Olive Garden. Many MSFT apps have a designed by committee feel.
On the other hand you get no real UI conventions so various parts of the application look like what they are: a patchwork. Some F/OSS software has this type of design shortfall.
Sounds like a less focused version of an open source project. F/OSS embraces a certain ideal. I don't know if providing a free service for a for-profit corporation falls under that idea.
Are people really using YouTube as an authoritative source of information for ANYTHING???
Ok, thanks. I was just checking in on this story's comments to make sure that somebody said this. This is the only comment that is really needed in this whole discussion, and of course, this one pointing out that your comment is the only one that is really needed on the subject.
You are absolutely correct. I knew someone would say that, because it's what I would have said.
However...
If someone wants to track you, regardless of what means you used to file a report, some work is going to need to be done. That eliminates the petty criminals right off. The guy breaking into a car at night isn't smart enough and doesn't have the resources to find you. If he is, then he finds out who submitted the police report (which means he has to make an assumption that someone reported him and that the police didn't just catch him in the act.) Now, many municipalities have sunshine laws, which means that he can see who reported what. IIRC, if you report a crime anonymously, then the sunshine laws cannot bypass that and your phone number and name cannot be revealed. So, unless some ill-advised law actually allows him to find out the number that an anonymous report was filed from (and I would be shocked if such a law existed, since this would be a pretty effective deterrent to anyone reporting anything), then you've gotta assume that some sort of conspiracy existed between the criminal and the law enforcement agency. For petty criminals, that's a tall order and a big stretch.
Therefore, for most complaints, making a report anonymously is safe regardless of the means used. For reporting crimes committed by more well connected individuals (organized crime), well, you're a fool to use *anything* traceable. So unless you see the mob knock off a star witness in a murder case (too much TV, I know:) ) or something equally grandiose, then report the crime. Make it anonymous. You'll be fine.
Not that these things would be used against a person just for reporting a crime, but the potential is there.
Me, I use a cell phone to file complaints with the police department. Yes, I have become *that* guy who doesn't hesitate to call the cops. Being a homeowner with an apartment building with redneck tenants across the street turns you into a dime-dropper real quick, and I am getting too old to be a hero. Get drunk and start fighting at 3AM and wake me up, then I am calling the cops. I know my cell phone can be traced, and there are sunshine laws that enable someone who is really determined to find out who filed the report. But the rednecks across the street aren't nearly smart enough and don't have the resources to track me down anyhow.
Using a cell phone and remaining anonymous is safe. If you are scared of that, you have to follow a certain path of logic that involves collusion between the police dept and the person committing the crime. You'd have to be pretty paranoid to follow that path, unless you have some organized crime stuff going on.
But if you want to be realistic, then you have to realize that *any* form of electronic communication can be tracked and traced. Pay phone, cell phone, anything. Don't like that? Then stay off the grid
Slashdot Mirror
"cheap foreign knockoff souvenirs"
Ironic thing is the souvenirs probably cost more than the original to build. Sweatshops may be cheap, but good ole fashioned slave labor wins hands down.
Hey, it's all a big joke!
"I'd like to see it hit with a 175lb crossbow!"
Haha, you'd have monitor crumbs.
But good lord! Take your monitor at home, a spoon, and a marble. I'd bet you could use the spoon to catapult your marble towards your monitor and bust it real good. That's one durable monitor!
You are absolutely right. I am just waiting to see how many people reply to you with nonsense like "Nuh unh! You should have presented it. You just *gave* it to your boss!"
IP can be a tool to protect one's own ideas, or it can be a cudgel to stifle innovation. It was intended to be used for the former, and today it's being used for the latter.
This whole debate will never go away and will never be solved because nobody can enforce the law properly by addressing these issues:
1) who owns IP? Corporations or the people who do the inventing who are also working for these corporations?
2) should IP be used to prevent others from building on your ideas?
3) just what exactly should be considered IP?
4) is your "IP" really IP, or was it common knowledge or a historcal inevitability that someone come up with the idea? In other words, if your IP truly unique or were you just the first to get to the USPO?
Should music be considered IP? Should technology, which is clearly IP, prevent others from using your ideas to build on? Should corporations be allowed to "obtain" IP and thus own it? Also, while there is overlap, what is IP and what is merely copyrighted?
If anyone can actually answer these questions definitively, then that person could fix the whole problem. Trouble is, nobody can and nobody will.
Well, that's just terribly exciting, now isn't it?
Hey, I went to work today, and everything went pretty well. Oh, don't worry. I'll tell you all about it. First, when I got to work...
Hey, where did everybody go?
Hello?
To restate you: never underestimate how hard lazy programmers will work to not work very hard.
Gimme a break. I suspect many geeks here like electronics. I don't see how you *can't* like electronics if you're a geek.
I mod guitar amps, and am working on building my first one, which will be all tube (5y3 rectifier tube, 12at7 and 12ax7 preamp tubes, and 6v6 output tubes.)
Absolutely, it's just natural that the people who would have to enforce this piece of crap don't like it. Unenforceable, arbitrary, hard to prove...need I go on?
There ought to be a law against unenforceable legislation! Oh, wait...
Absolutely right, what I mean is this: the large corporation needs your skills. Your skill set / experience may be very costly or difficult to replace. But your loved ones care about *you*. They couldn't find someone else with your same skill sets to replace you, because to them you are irreplaceable. I was just trying to show the absurdity of people misplacing their priorities. Killing yourself for a corporation is crazy. That's all I meant.
It may be trite to say it, but...
If you were to die tomorrow, this would affect your family for the rest of their lives. You are irreplaceable. Your company would fill your position within days and except for your immediate co-workers, nobody would even care.
From TFS: "senior executives claiming a BlackBerry can contribute to work/life balance by facilitating telecommuting and more flexible schedules. "
More flexible for whom? Where I work, that seems to be a one way flexibility. Senior executives are making (SWAG alert) 3x - 10x what I am making. They have made the choice to have a large stake in how the company performs. While I have a stake, of course, it's just not as large or worth my personal/family life. It seems like despite being more accessible, people's work hours never get shorter. And that's what it's about in the end, isn't it? Getting more done in less time? But in rality, it just seems that it's about getting more done in more time. No good. I am glad I have no blackberry.
I stopped worrying about that kind of stuff when I started using the prototype javascript library. It is easy to use and it Just Works. I've used it in a production environment for...I think ~2 years now. I normally detest using other peoples' third party javascript libraries. Prototype is a notable exception to my roll-your-own approach. I cannot say enough good things about it.
I think you are making a bit of a blanket statement here, and you have to be careful with those. I have a site that I am working on right now, unfortunately on an intranet so I cannot show it to you. The site has a header bar (a horizontal bar 100% wide) a menu bar (same as header) the content area, which I'll come back to, and a footer (a simple horizontal bar 100% wide).
The content area must have a 200px wide sidebar that is expandable and collapsible. The header, menu, content, and footer need to be 100% wide or 1000px whichever is wider (sorry, 600x800 folks, get with the times). The sidebar and content need a divider line between the two.
I was able to do ALL of that using divs and CSS. I used a container for the content with a 200px negative margin, and the content div floated left with a 200px margin. The sidebar floated right. To close the sidebar, I'd just set display to none, and remove the negative margin on the wrapper and the margin on the actual content. Beautiful.
So what's the problem? Well to make a long story short, lack of min-width support in IE. Without min-width, there is no good way to make sure that my menu and content don't get *mangled* when users resize the browser smaller than about 800px wide. But when a div has floating elements inside it, there is nothing to prevent those floating elements from getting scrunched up. That is just the natural flow of floating (or inline) elements, and I accept that. I wanted to put a spacer div inside the container and menu to keep them open to a certain width, but no dice.
I adhere to web standards for all of my sites and they work well in all browsers. However, the reality is that IE is 95% of the traffic, so the design MUST work in IE. Oh, how I hate IE. Anyhow, IE doesn't understand min-width or min-height and that kills my design. I know there are hacks; all that I have seen mean you have to put javascript in your CSS and an onresize event handler in the body (yuck and yuck). Two problems with that: 1) putting javascript in CSS? Um, no. Why not just use activeX while we are at it? 2) I abandoned my moral objections to this and tried it in a prod setting. It crashed IE for not just a few people, and that's unacceptable. Turns out, executing a simple javascript expression every time the browser resizes is just too much computation for lamebrained IE. Of course, there may have been some other facet of my design exacerbating the problems, I don't think people would knowingly publicize IE hacks that kill IE. However, not having unlimited time at my disposal, I did not figure out *why* this happened. I just axed the layout.
I have been programming for a very long time in a professional environment, and there is something that the many years have taught me: if you are beating your head against a wall to accomplish some programming task, you are approaching it wrong. Well, this is no different. If you have to pile hack upon hack just to make a layout work, then your approach probably all wrong. Not only that, but you are defeating one of the main benefits of separating content from presentation, namely, making a lightweight and easily maintainable layout. The more hacks you pile on, the more problems you create for yourself. The harder the site will be to maintain. And you'd better hope that the hacks that fix one version of a browser *cough*IE*cough* don't break under the next version.
After trying for a week to do things the academically correct way, I gave up and made a tabular layout that validates, is lightweight, and works perfectly. In doing so, I had to overcome my prejudice against tabular layouts. Then I found this article on a respected design site and it kind of validated the conclusion I had already come to: that using tables for some layouts is not only necessary, but also appropriate. Not saying that you need seven layers of nested tables. But I could see someone having to do what I did: use a 1x5 table or
You are confusing easy to use with easy to learn.
Some things are easy to learn. Other things are easy to do once you've learned them. Checkers is easy to learn. Five minutes and you've got the gist of it. Reading is difficult to learn. It takes years to become an effective reader. Yet, once you've learned to read, reading is relatively easy. A programming language, or in this case, a programming methodology, can be difficult to learn. But once learned, it becomes easy to use.
Writing AJAX apps is easy, don't let your ignorance fool you. It's not easy to learn how to do it properly, but once you've learned it is easy. If you do not know how to use it, then you are really in a poor position to judge its ease of use.
Ah, the old divs vs tables flamewar.
I used to be on the side of using semantically neutral elements like divs and css to specify layout.
Most layouts work fine with semantically neutral elements (divs). Some don't. I have used tables for layout in one or two cases, but not before trying VERY hard to make a purely CSS driven solution. To approximate it using no tables, I'd have to put javascript in my CSS expressions to make IE simulate min-width and min-height, among other things. Since that's a clever but ultimately sucky solution, tables won out. We're talking very specific layouts here. Usually you shouldn't need tables.
I said it in another nearby post, but I'll say it again here: being a professional is knowing the rules. Another part of being a professional is knowing when to break them. Yes, using tables for layout is a semantic faux-pas. But sometimes it makes the most sense.
If you find yourself having to cobble together a collections of hacks to make a certain layout work without tables, then you either need to abandon the layout, or if you cannot, use tables. Semantically incorrect, but it's better than some of the hacks that you have to use to work around browser (IE) flakiness. I am not talking about wrapping floating divs in a container with negative margins. That's a pretty elegant solution. I am talking about several layers of nested divs with wacky CSS tricks and IE hacks on top of Javascript magic. That stuff is ridiculous. In short, use the best tool for the job and get over your prejudices about a certain design methodology being "bad".
Please do not take offense, but the fact that you tried using the position property shows that you don't really understand CSS that well. That's not meant as an insult, just a statement of (apparent) fact. I just wrote a very simple page (just a div and image tag, no doctype or anything) that had this content:
/>
<div style="width:40pt;height:40px;border:solid;">
<img src="foo.png" style="width:50%;height:50%;"
</div>
That displayed the image correctly in Firefox and IE6, the image's dimensions being 50% of the div's width and 50% of the div's height. Not that you *should* use points for dimensions, but that's just in keeping with what you said you did.
That said, browser behavior is very flaky. Your frustration is not unjustified. Especially with IE. IE sucks. There's not much more to say about it.
"It would be even better not to use the defective product at all, but that is hard when the vendor has a monopoly status."
Preaching to the choir, dude.
Eh, I don't know if that's entirely true. Maybe true in a VERY pragmatic sense only.
A screwdriver can also pry nails out of a 2x4. That doesn't mean you should do it. You will probably impale your hand.
A flamethrower can light the candles on your kid brother's birthday cake. But you might light grandma on fire.
Using HTML elements for things that are not quite correct might work on the browser you are using. Why, I could use <label> tags to lay out an entire site and use CSS to make it look ok in mainstream web browsers. That doesn't mean another user agent or screen reader won't totally freak out upon seeing it.
Table are necessary for some layouts. I have a site where it is just impossible to avoid using a simple table for layout. But you should know that it is semantically a faux-pas to do so. Part of being a professional is to know the rules and also to know when to break them.
I don't think you'll find any web developers who like IE. That said, what did you expect <img src="foo.gif" style="width: 50%;height:50%;"> to do? In other words, you wanted the width and height to be 50% of what? The image or the thing that contains it? I think maybe the browsers didn't do what you wanted it to and instead of finding out why you just gave up. The web is a great platform, but since browsers can be really sketchy, you need to understand why some things go wrong. This is essential. In programming languages like Java, an error results in a nice tidy error message. But since browsers *try* to render bad markup, instead of concise errors, you get weird behaviour that you have to figure out. Over time, it gets much easier. But that is why when you get unpredictable results, you need to figure out why. You can't just hack your way around it and move on, not if you want to learn.
I don't know much about GWT (the fact that Google developed it is at least encouraging). But if it's like some of the other java based solutions that are designed to write HTML, I'd run away fast. If you want to be a web developer, then you need to learn the languages of the web (HTML, CSS, Javascript at the very least). I'd be shocked to find that GWT doesn't generate steaming piles of dung in place of good, clean, standards compliant markup, and that means you have all kinds of compatibility issues, accessibility issues, and code that is harder to maintain.
How well do you know javascript?
As someone else pointed out, XMLHTTPRequest is what makes AJAX tick. But without knowing Javascript, what are you gonna do with it?
Assuming you are very good with javascript, here are two resources for you. 1 will help you see what the XMLHTTPRequest object does. 2 will help you tame it a bit and abstract things.
[1]: http://w3schools.com/ajax/default.asp
[2]: http://www.prototypejs.org/learn
The thing is, the AJAX bit is a very small part of the total AJAX package. Then you'll need to learn JSON (a good data interexchange format) and how to use Javascript to create elements.
There, now that I have provided what you asked for and not just some smart alek remark about how you need to google it, this has to be said...If you seriously expect to master a useful skill in an afternoon, then you have some expectation issues. If there's one thing life has taught me, it's that something worth having doesn't come in a day, and if it does come in a day, it's probably not worth much. Did you learn to program in one day? No? Then why would you expect to learn a complex object and a totally new technique for making web applications on one day? But if you really want to learn then you'll thank me for those links later when your web development reaches the next level. If you are just bashing AJAX with a cudgel of ignorance, then you'll ignore those links and keep griping about AJAX being too hard. I guess time will tell.
Well too bad for you.
Developing for the web is about knowing your audience. If I were designing a site like ebay or amazon, in other words, trying to have the widest possible user base, or if I were working for some entity that had to abide by ADA requirements, then maybe avoiding AJAX would be advisable. For a site that is not a necessity, like, for example, youtube, slashdot, digg, flickr, etc AJAX is great. When done properly, AJAX makes more efficient applications that enhance the user experience.
Also, if you really want to, you can develop sites that use AJAX but also degrade nicely. Everyone here (at least, anyone who calls himself a serious web developer) is using web standards and writing good semantic markup, right? Well, that will make your site at least accessible. If you just use the noscript tag to handle non javascript user agents (where necessary, obviously not where there isn't ROI anyway) then your site should work pretty well.
As someone else who replied to you mentioned, we cannot develop web sites around people who for some crazy reason refuse to use new technologies (if you call javascript new, as if!). That, along with MSIE, are holding the web back.
I think people who hate AJAX just hate it because of all the bad AJAX sites. But that's like hating the web because there are bad non-ajax sites. AJAX, like other technologies, makes things better when used properly.
Actually, studies have shown that Embedded Junior Mints (EJMs, as they're known in the industry) actually speed recovery.
Who's gonna turn down a Junior Mint? It's chocolate, it's peppermint-- it's *delicious*!
Gosh, I sure hope not!
Whatever kind of software we are talking about, you'll most likely get a horrid UI and the resulting usability headaches.
On one hand, you get design by committee. A UI that is not great, but just didn't offend anyone, the software equivalent of a meal at Olive Garden. Many MSFT apps have a designed by committee feel.
On the other hand you get no real UI conventions so various parts of the application look like what they are: a patchwork. Some F/OSS software has this type of design shortfall.
Sounds like a less focused version of an open source project. F/OSS embraces a certain ideal. I don't know if providing a free service for a for-profit corporation falls under that idea.
Thanks for being there.
You are absolutely correct. I knew someone would say that, because it's what I would have said.
:) ) or something equally grandiose, then report the crime. Make it anonymous. You'll be fine.
However...
If someone wants to track you, regardless of what means you used to file a report, some work is going to need to be done. That eliminates the petty criminals right off. The guy breaking into a car at night isn't smart enough and doesn't have the resources to find you. If he is, then he finds out who submitted the police report (which means he has to make an assumption that someone reported him and that the police didn't just catch him in the act.) Now, many municipalities have sunshine laws, which means that he can see who reported what. IIRC, if you report a crime anonymously, then the sunshine laws cannot bypass that and your phone number and name cannot be revealed. So, unless some ill-advised law actually allows him to find out the number that an anonymous report was filed from (and I would be shocked if such a law existed, since this would be a pretty effective deterrent to anyone reporting anything), then you've gotta assume that some sort of conspiracy existed between the criminal and the law enforcement agency. For petty criminals, that's a tall order and a big stretch.
Therefore, for most complaints, making a report anonymously is safe regardless of the means used. For reporting crimes committed by more well connected individuals (organized crime), well, you're a fool to use *anything* traceable. So unless you see the mob knock off a star witness in a murder case (too much TV, I know
Voice Print.
Not that these things would be used against a person just for reporting a crime, but the potential is there.
Me, I use a cell phone to file complaints with the police department. Yes, I have become *that* guy who doesn't hesitate to call the cops. Being a homeowner with an apartment building with redneck tenants across the street turns you into a dime-dropper real quick, and I am getting too old to be a hero. Get drunk and start fighting at 3AM and wake me up, then I am calling the cops. I know my cell phone can be traced, and there are sunshine laws that enable someone who is really determined to find out who filed the report. But the rednecks across the street aren't nearly smart enough and don't have the resources to track me down anyhow.
Using a cell phone and remaining anonymous is safe. If you are scared of that, you have to follow a certain path of logic that involves collusion between the police dept and the person committing the crime. You'd have to be pretty paranoid to follow that path, unless you have some organized crime stuff going on.
But if you want to be realistic, then you have to realize that *any* form of electronic communication can be tracked and traced. Pay phone, cell phone, anything. Don't like that? Then stay off the grid