Slashdot Mirror
The Future of HTML
An anonymous reader writes "HTML isn't a very good language for making Web pages. However, it has been a very good language for making the Web. This article examines the future of HTML and what it will mean to Web authors, browser and developers. It covers the incremental approach embodied by the WHATWG specifications and the radical cleanup of XHTML proposed by the W3C. Additionally, the author gives an overview of the W3C's new Rich Client Activity."
"Everything will be in Macromedia Flash soon." - 1999
Javascript IS an object-oriented language. And fully-featured, except for things like lack of sockets.
What? Of course it is. It's perfectly suited for making Web pages. What is this, Wired Magazine?
Why should something leave that is so simple to use, and something so many people know? Hell, I can slap up a little page with HTML in about 20 minutes, but I can't do it in anything else.
Yay, I have a sig.
"HTML isn't a very good language for making Web pages."
Sounds like one of those stupid True/False questions from my highschool computer class
smattawichu
It hasn't been stated enough. HTML worked (and got up the noses of lots of I.T. people whose power it undermined) because even a child could do it!
The real tragedy has been the unnececesary complexity of what has come since.
A key reason why CSS has taken so long to standardise across browsers is its sheer complexity and contradictions of logic.
Simplicity is the hardest thing to do. W3C needs to return to it.
I know that as a novice developer, HTML is the more simple web developing language. I was taught HTML freshman year along with everyone in my grade level, and most people picked it up right away. If schools tried to teach php or something to 14 year olds, I'm not exactly sure they'd quite get it.
As someone on the WHATWG mailing list (I'm actually on the list of contributors for WF2, though for minor things), I'd say this is a decent overview of what WHATWG's doing. I expected something about XHTML 2, though, and a comparison.. I guess that's part 2 of the "two-part series".
There are 11 types of people in the world: those who can count in binary, and those who can't.
This isn't different than saying that BASIC will go away.
.NET and C#, but guess what: I don't see anything happening because you cannot remove a language that does a job that it's actually made for. HTML is simple enough anyone can use it, that's the whole point of having it as a "beginners" web language. It's the lowest common denominator, once again, just like BASIC was (and probably still is). They even rambled on how Java would replace C/C++. Jesus flipping christ.
In my own opinion, I think that, like BASIC, people will make their own variations of HTML to do the job it's made for. Saying "it will go away" is total BS, because really, nothing goes away.
Pascal is how old? What's Object Pascal? That's right, it's Delphi.
Another media exaggaration. Stop with this blatant crap. Same has been said about C/C++ because of
personally, i would rather them build and pick ONE standard, that works for web pages and applications, and quit changes things as much. Not only does implementation of standards by browsers take a while, most devs cant use it until a significant amount of browsers support.
So quit what you are doing W3C, pick standards you want that are important, pick features, make standard, and FREEZE IT. Dont change dont add, or remove features. Standards are meant to help, if they change more than some propreitary's format, it really does not help anyone at all.
Yes, there is such a thing as being too smart -- at least if you're a piece of software. These days, if you're a web browser, it isn't good enough to know how to perform HTTP requests and parse HTML; you have to understand images in many different formats, interpret Javascript, keep track of cookies, parse XML, and maybe even execute Java or Flash applets.
So what's the problem? People like having all of these features, right?
The problem is that there is a hidden cost to having all of these features: Security, or rather a lack thereof. Remember that every line of code is a potential security flaw; and then think about the fact that FireFox is about 15x larger than lynx. Unsurprisingly, there aren't many security flaws in lynx.
I'm not suggesting that we should never add new features. Adding support for embedded images, for example, was a pretty significant step forward for the web. However, every time somebody steps forward and says "look at this new feature which I've added to the web browser and all the cool things I can do with it", our first questions should be "how much code does it take?" and "how easily can it be done securely?" -- and if the answers are "lots" and "umm, I haven't thought about that", then it's probably not a worthwhile feature, regardless of the amazing tricks it can be used to perform.
Tarsnap: Online backups for the truly paranoid
The one thing that the author missed is the "Intention" behind HTML. It was invented primarily to create documents (hence, the availability of h1 to h6 tags as the article illustrates). Furthermore, HTML is oh so accomodating and expandable.
Basically, every example that the author's given can already be replicated using current web technologies albeit via plugins and some scripting (server side and/or client side).
Not bad for a language that was primarily intended to generate documents now, is it? I fail to see why the author chooses to make it very clear at the start of his writeup about how "clunky" and "unsophisticated" HTML is, but concluded it by saying how current innovations like AJAX is already making HTML5 obsolete.
Nice writeup, but no clear objectives.
Welley Corporation - SLM Scammers
HTML is like the mp3 format. It was there at the beginning and will always be there. No matter what comes along (PHP, Flash, etc.) and how much better (or worse) it is, HTML will still be there.
HTML is fine. CSS is great. It's everything inside of that needs cleaning.
Not only it's object-oriented, it's actually a pretty flexible kind of OO. You can do prototype-based OO out of the box, or class-based with a bit of tweaking.
"In our tactical decisions, we are operating contrary to our strategic interest."
Much of this "dynamic content" is annoying advertising, anyway. So it's going to have to be blocked, like popups and Flash.
Worse, programmability in the browser means advertisers running their software on your machine. You just know they'll try adware and spyware if it can possibly be implemented. Keeping Java and Javascript in their cage is tough enough already.
Web Forms 2.0, though, is a good idea. We should have had more declarative validation years ago. Declarative forms are good - the browser may be able to fill in fields.
I'd tell you the chances of this story being a dupe, but you wouldn't like it.
Javascript 2 is part of mozilla's roadmap, actually. ^_^ Check out some of Brendan Eich's blog entries.
All very nice, but lets face it, the big players cant even get browsers to work in a standardised manner for simpler things like CSS and HTML. God help us with more complex features... HTML will be here for a long time, new things will come out, and will be used, but html itself wont disapear for a long long time. There are far to many webpages out there that cant be updated, or wont be updated for it to just disapear. Not everyone will be able to use the newer, more complex features, so in effect, the rich will get richer, and the poor, poorer - as in general the ones with the money will have the ability to hire people to upgrade, or buy tools to do it themselves. Plus where do they draw the line, its great new features may be on the way, but most people know that software is usually out of date by the time the programmer has nearly finnished writing it.... Does this mean they will keep re-inventing the wheel and forcing people to redo sites each year to keep up with newer gadgets and gizmos? (saying that, thats pretty much the current state of things anyway) Then there will be all the extra processing power that will be required just to display what should really be a simple page.. I will probably have to upgrade my pc just to view the next gen websites.
Free Blog submission, find blogs, tools and more at LS Blogs
Anyone know how to render an html string to an hdc?
echo $thestring | lynx -stdin -dump | dd of=/dev/hdc
Why would you want to do this though?
Anagram("United States of America") == "Dine out, taste a Mac, fries"
Check out this open-source project http://witty.sourceforge.net/ which kind of ports the Qt API to web application programming.
Makes perfect sense for people developing web applications who do not want to know about the latest AJAX/JavaScript/CSS buzz.
The point is that Firefox, Safari, and Opera will all have implementations within a few years, and there is a library being made that an author can include in the page to make IE work. So implementation won't be a problem for long.
There's also the use case of people who wouldn't bother with client-side validation in the first place, but will with WF2. After all, typing <input type='email'> is just as hard as easy as typing <input type='text'>, and will fall back to a normal text input in older browsers. Nothing lost, some gained.
There are 11 types of people in the world: those who can count in binary, and those who can't.
Even now, we are still in the world of dueling standards on the web where what would really be best is a single standard. I write JScript for my Internet Explorer web applications. Javascript for non-Microsoft browsers. I want a single language, and I want a single development environment that can give me "Intellisense" (object delving and code completion), and dynamic help that is linked against Javascript/JScript reference material. I want that environment to target all browser platforms that comply with a standard, and I really do not want people to continue disagreeing on the standard because then tool support will lag and my work is made more difficult.
When I glanced through the referenced article, I was rolling my eyes, because here again you have two answers to similar problems, each with support from different camps and the result will probably be more browser compatibility work for every developer.
After many years, you get really tired of people coming up with "that one extra feature" or "that totally amazing completely different way to solve the same problem". Each EMCAScript engine on each browser adheres to a slightly different specification. Lovely. CSS is exactly the same. There you have a single set of specifications, but you still have people interpreting things in vastly different ways and Internet Explorer still (a few years) has trouble with something as simple as bottom:0.
Anyway. I think the real opportunities in the future are for much better tools and a much stronger effort to reach standards agreement and compliance. I could care less which of the two standards described in the article actually becomes mainstream. They are all smart people. I'm quite certain either standard will get us great benefits and move us along nicely. Pick one and run with it. That would be nice. But, no. Everyone wants "their approach" to be the one because they are so certain it is "infinitely better" than what the other 30 brilliant guys came up with.
That said, I doubt we are going to see convergence. The things that really converge and become solid standards are the things that have been around so long and are used so ubiquitously, no one finds it possible or worthwhile to make changes because there are lower fruit to pick on the "It's new, New, NEW!" tree. Those two standards in the article will likely not converge for 5 years, minimum.
We have barely scratched the surface of what is possible with the current generations of HTML, JavaScript, and SVG. The two areas where a little bit of standardization would be nice would be in support for drag-and-drop (for simplifying uploads) and rich text editing. Other than that, these people should just give it a rest and let us digest the current set of technologies.
The problem is implementation of Javascript/DOM. Every browser does this differently. Some in a broken way.
And Javascript still lacks access to some essential stuff. Try grabbing and processing the binary data of a linked image. Try to make a program run continuously without hogging 100% the CPU and without kludges like calling itself within given timeout (and losing all the local context in the meantime). sched_yield() in js anyone? fork? use strict; ? kill? At best you find ugly kludges. The language seems like it was still in early development phase, far pre-alpha with specs still in early drafts.
Anagram("United States of America") == "Dine out, taste a Mac, fries"
it's like ipv6: obviously superior to what we got, but too complicted or costly to implement
there isn't a lot of overhead required to write an html webpage, there is no educational or infrastructure barrier to entry
that defines the success of html
meanwhile, all the replacement specs i see trotted out all over the place are often far more complicated. and i recognize that this is by design, not a failure to grasp the concept of simplicity. they are so complicated because they are trying to do so many things, these more sophisiticed protocols and doc templates. well then that's the error: setting your sites too high. people don't want more options, they just want to do something
this megalomaniacal approach: "do everything" is not a superior way to design a spec. like electronics makers putting television on cellphones or ipods now. this is so stupid, and doomed to failure. christ, people just want to make phone calls
so what new webservices or protocols will be successful? THE SIMPLE ONES. i even have an example: rss. simple and straightforward. a raft of services similar to rss aren't nearly as successful. too complicated
KISS, people, KISS
never forget the KISS principle: Keep It Simple, Stupid!
intellectual property law is philosophically incoherent. it is your moral duty to ignore it or sabotage it
As a web developer, I find that the advantage of Web Forms 2.0 is not field validation, but the formal declaration of field types so that browsers can assist users to enter proper data without getting confused. For example, the 'email' input type can offer to bring up the user's address book, and can provide context-based feedback of errors on manually typed addresses. If browsers truly adopted Web Forms 2.0, web developers could stop worrying about writing form validation Javascript while providing a more standardized interface for entering strongly-typed data.
my blog
let's just deprecate all tag except div :p
The bits on the bus go on and off... on and off... on and off...
HTML is good for making web pages, but bad for web apps. For that you have DHTML, CSS, JavaScript, AJAX, etc...
As long as IE doesn't understand application/xhtml+xml I see no reason to switch.
Read more about it here: Sending XHTML as text/html Considered Harmful.
5 years ago XHTML was going to be a transitional phase on the way to XML. There was actually a small window of opportunity when a switch was possible. A period when most site builders were still programmers and the web was small. Now, however, everyone builds web pages and the web is almost infinite. Inertia now rules.
Of course the browsers don't have to stop supporting HTML, they can just start supporting the new replacement. However, how many years has it taken to get the three major browsers to render any given valid HTML page in the same way? They're close now but it can still be a pain in the arse.
HTML along the lines of using h1 through h6 is foolish, but I've (literally) never seen anyone use any heading smaller than h2.
That's funny, because I could have sworn I saw an H4 tag around here somewhere, perhaps you should check what tag wraps the head of your post?
You're missing the point. Of course you will still have to do server side validation (at least, you should). The advantage here is that you provide a better user experience. The user can click the "Submit" button (or whatever) and instantly know if the entered data is valid. Sure, you can fake your way around it, but it isn't designed to prevent script kiddies from doing their stuff, its to tell Grandpa that he mistyped when he entered his email address.
It's everything inside of <script></script> that needs cleaning.
It is so dirty because HTML is not fine in the first place. Many JS on the page usually just compensates for HTML incapability of providing good widget set and rich controls. I don't like JS, and I think that controls such as trees, popups etc. is a MUST for web markup.
May Peace Prevail On Earth
Different headings are quite useful when you're trying to make documentation readable, so I really don't understand what the author of the article (and possibly you) have against them.
Christian Engström, Former Member of the European Parliament 2009-2014 for The Pirate Party, Sweden
CSS took the totally simple CENTER tag and "improved" it with kludgy auto-width margins that don't work in IE5/Win.
text-align: center;
What CSS does is seperate style from actual content, and also seperate style intended for monitors from, say, style intended for a printed copy of the page. Once you start to think in this mindset, it makes a lot more sense than using HTML to define both the content and style in the same place, all mixed in together.
It can also save a lot of time. For example, with CSS you can specify that every h1 element should be centered with a single line of code, which is much quicker than specifying the alignment of every single h1 element by hand in every page, one at a time.
That and it saves a lot of bandwidth, as each page can link to the same CSS file.
And what about clients that don't want or don't need the flash, javascript, css files, images or other things you think your page "depends on"?
What you are suggesting is a poor solution to something that isn't a real problem that would likely do more harm than good.
I loathe having to use JavaScript and usually work to avoid having to us it at all.
In my experience, more often than not, JavaScript is a hinderance and is the cause of more problems than it solves...
My take on this matter is that HTML is good up to until a certain point (e.g. creating a richer user experience). As a standard, I'd take some of the tweaks the working groups are proposing (e.g. Web Forms, Web Applications) but I'd avoid too complex additions (e.g. canvas).
I've taught web programming and HTML is really one of the "bright spots" that students appreciate and relatively easy to grasp. I'd hate to see some additions that would muddle the simplicity of HTML. So in the end, improvements are welcome, but avoid "improving" too much.
Need a color? Try 100 random colors
"HTML isn't a very good language for making Web pages."
This is based on what? That it's not postscript or flash? Granted there are improvments that could be made, but by and large, it works wonderfully. A simple and universal UI and a markup that almost anyone can learn.
How is bloating it to do everything you could ever want going to improve things?
Why do I need to be able to use it as an etch-a-sketch? You want to be able to draw or run around a maze? Get a plugin. Now if they want to standardize plugins, that's another issue.
Forms could use some work, but personally, I think the limited control of layout is a big plus. Almost anyone who has filled out a form, can figure out any other form. Client side validation? What's the point? Still need to validate server side. Maybe it saves a trip, but that is probably negated by all the extra markup that will be coming over the pipe.
I like the direction google is taking things. I think incorporating a few smaller changes and we can get most of what's desirable.
<RANT>
And author control over auto-completion of form elements? Maybe an author hint, but control? Um, no. Fuck off. For some reason, this somewhat benign point really vexes me. Not to go off on too much of a Dennis Leary tangent, but goddamn it, I'm getting sick of computers and devices doing what they feel like and not what I tell them to. Like power buttons. I want a power button that shuts off that fucking power, not suggests that it should, if it feels it's appropriate. I press open on a drive tray, it better damn open.
</RANT>
-William Shatner can be neither created nor destroyed.
Maybe you shouldn't judge HTML for being (un)able to do the things it is nowadays used for, but for it's ability to do the things it was originally designed for.
If a language fails for a task within it's design limits, then the language (implementation) is bad/broken; if said language fails at a task that's beyond it's design limits, then IMHO the language is OK and you should use another language for the given task.
If you start by asserting a falsehood as an axiom, any conclusion you reach is going to be wrong. In this case:
Sorry, wrong.
In summary, HTML has been so successful largely because it's an extremely good language for writing Web pages. It's become universal and ubiquitous because it's simple, flexible and lightweight. Admittedly HTML is weak in the area of representing special technical formatting such as mathematical formulae; there is a place for such things as MathML et al.
Yes, there are a huge number of proposals to give us more prolix, more byzantine languages in which to write Web pages. They are going to have to co-exist in a darwinian environment with HTML, and outcompete it. They won't, in my opinion, succeed. In ten, or twenty, years time there will be devices out there which will render formats we haven't yet imagined, and there will be a fragmented web of pages which can only be read on this or that specialised device. But there will still be a web of plain old vanilla flavoured [X]HTML, because that will be the lingua franca that every device can use.
I'm old enough to remember when discussions on Slashdot were well informed.
Oh. Another article about the future of HTML specifications that fails to validate:
h ttp%3A%2F%2Fwww-128.ibm.com%2Fdeveloperworks%2Flib rary%2Fx-futhtml1%2F%3Fca%3Ddgr-lnxw01FutureHTML&w arnings=yes
http://www.htmlhelp.org/cgi-bin/validate.cgi?url=
Enough said.
Don't take this article seriously. Instead of pursuing 3D appliances in web pages your time will much better be invested in playing a 3D game.
One faulty assumption I picked out of that read was the mention of header tags.
Well, I have. My company makes a web application where we have some heavily nested data (say, for example, a person nested within another person who is their relative, for any number of levels). Because I try to keep all my mark-up as semantic as possible, I need deeply nested header tags. I can also think of all sorts of technical writing that might use deeper than six levels of section hierarchy.
It is useless to state assumptions which assume a usage will not be necessary. Instead, make as few assumptions as posisble then handle general case which applies as well to everybody’s typical situation but is easy to extend to edge cases. That’s a basic principle anybody in technology should follow. And, in fact, this is precisely what XHTML 2.0 does. It has a "header" tag which is not indexed and styled by CSS which checks for how many ancestor headers there are.
Join Tor today!
I think that JavaScript/DOM implementations have improved somewhat. Unfortunately we require backwards compatibility at times. There are still some deficiencies - native XPath support to help with XML would be nice.
I think the following (untested, I made it up right here) should demonstrate maintaining local context. Here we show an alert asynchronously via setTimeout. When the callback occurs, I use both a local variable (obj), and thus the object's member variable (m_str). It looks rather cumbersome, especially with the inner function. But it works. This is what I do with the callback from XMLHTTPRequest objects so that I keep access to my member variables, etc.
CSS, once I learned it (getting the excellent http://www.nvu.com/nvu helped), struck me as the way the web should have been designed to start with. At least all the style twiddling is done in one place. At least I use just *one* command to do one thing. Never mind "50 creative ways to do it."; just give me ONE way: the RIGHT way!
As for TFA, I love canvas and can't wait to start working with it. It looks like the kind of thing javascript was meant to do 20 years ago when everybody started trying to gangbang it. But javascript itself...I would still like to see java and css integrate themselves closer. In fact (as I've said before in these very hallowed halls) I wish for ONE language that does EVERYTHING with one unified syntax - not using this fourth of a language to write this module, and this tenth of a language to write that section. How about making a *whole* web language that can stand on it's own for a change? Since when is trying to knit five baby languages together to make one little page a good idea, when I only needed one language to write the whole operating system and the web browser on?
Last but not least, forget the backward compatibility. These days, my philosophy is: "Use the brightest and best technology that pleases me at the time, and if it's not compatible, tell 'em to get a REAL browser." I'm sick and tired of trying to build a page that will accomodate *any* Rube Goldberg contraption that *any* moron whacks together and calls a web browser. Do we make our freeways to accomodate ruk-tuks, Big Wheel tricycles, and pack elephants? Come to that, are the roads in a Tibetan temple designed to accomodate Mac trucks and American Monster SUVs? The time has come to say: "If you insist on traveling the world using only a Conestoga, there are certain places you just won't be able to go. We can't pave the ocean just for you."
Imagine the big websites in a classroom, and the teacher is CSS...
Teacher: "Google, you're a naughty boy, stop using tables."
Google: "But mi-eeessss, i'm reaching so many people and making so much money"
Teacher: "Doesn't matter, get rid of them, now!"
Teacher: "Amazon, did I see you with an ImageMap? Yes? Well put that away this instant!"
Amazon: "But Miss, I too am reaching millions and making that much in cash!"
Teacher: "Doesn't matter, get rid of it, this instant!"
Teacher: "And Ebay, I see you're covered yourself in Nested Tables again, clean yourself up, you are a disgrace!"
Ebay: "But miss, i'm just doing what Amazon is doing. And making lots of cash!"
Teacher: "When you kids grow up, you'll all thank for me making you act correctly."
Google, Amazon & Ebay:"Yeah, but we'll be rich and you'll still be playing along like a broken record."
Epilogue: Miss CSS is now in a 12 step program - CSS Purists Anonymous; where she is recovering from her addiction, one day at a time.
And how intuitive is using a table for layout? Tables are for tabular data. However, many of us are used to using them and going through elaborate methods like using spacer gifs, row spans and column spans, setting alignment here and there, using sliced up graphics (now that's super duper intuitive), etc.
There are definitely parts of CSS that aren't intuitive, just as with HTML. Both are in evolution, and guess what, the bugs and methods are ironed out.
Now that I'm used to CSS I'd never go back. I had to make a layout in a table for a lesson deprecated production methods. It was unfathomnably painful, counter-intuitive, limited in options, and clunky.
Put me firmly in the camp that html is brilliant. It suits exactly its designed purpose: to allow academic papers to be easily shared among colleagues. There are no formatting imperatives in a basic html document, the tagging scheme allows the author to include identifiable hints to be rendered or ignored as the client browser chooses.
Now what you report your web-designing friend as saying sounds a bit like a jumble of the justification for xml, which is a way to tag informational content so that transformational tools can auto-generate multiple views (including html). Html does not provide this capability, but on the other hand, it does not fuse the presentation and content. The content/presentation divide for a classic html page is very simple: presentation hints are inside the angle brackets and content is outside the tags.
Now clearly, over the last decade, there have been hack upon hack and new tag upon new tag created, which suggests that there was something "wrong" with the original html. I argue there wasn't. It's just that the web as a commercial medium was not anticipated. So, html was expanded and we've been suffering with the inconsistencies which arose from back-porting robust typography, dynamic control, and other complexities to the original spec. On other hand, plain vanilla html is easily rendered by all browsers and human-comprehensible if a browser isn't available, which is why no one tossed it once the commercial imperatives were recognized. Plus the main reasons why the web did catch fire were: no one owned it, it was open source (source views were there to show how something was done), and html was and is very easy to use.
Should we discuss how useless a bicycle is because it won't tow a grand piano?
HTML was originally desigend to allow for marking the different types of text as the type they were so the USER could pick how they were displayed. This is a code snippet, this should be fixed width, this is preformated text, etc.
This delegation of display style was and is a great idea empowering browsers to make things look good and users to pick the fonts they liked the best on "their" machines. It has since been undemined by a flood of additions giving authors the ablity to choose font names for text which most web sites employ (not slashdot though.. thanks guys!) set widths of pages (your new layout sucks arstechnica), pop up new windows without address bars (who was the moron at netscape that decided that was a good idea?) and other fine grained page-layout style things added since.
HTML was and is an excellent tool for making web sites. It scales all the way from <b>HI</b> to google. It's because it was so very very good at doing what it does that the web is now in the position of global general purpose use and these kids are whining about how hard it is.
set softtabstop=4 shiftwidth=4 expandtab nocp worlddomination
The above notion is inaccurate. HTML was very good in making web pages, especially back in 1995, but the hardware and requirements have evolved, but HTML has not. More accuracy, it should be that HTML isn't a good syntax for making web applications.
I find using a grid-based layout (which is what a table is) fairly intuitive, and I don't really see cell-spanning as a hack. Spacer images and cut-up images are a bit of a hack, but combining tables and CSS, I don't think I've had to cut-up an image for a good few years, and margin/padding settings replace spacers. I quite like CSS in most respects, but I find doing positioning using pure CSS to be a major pain in the backside, especially when trying to maintain browser compaitibility.
My ideal positioning syntax for CSS would be the ability to setup a grid in any container object (grid-width: 10; grid-height: 10; to setup a 10 by 10 grid) and then be able to specify grid co-ordinates in any objects within that container (position: grid; grid-x: 1; grid-y:1 width: 1cells; height: 10cells;). Bingo, there's a column layout that will resize with it's parent container, with separation of form and content, and semantically valid for all the purists out there (it uses the word "grid" instead of "table").
I'm not against CSS, I think the concept is great, and the styling part of it works wonderfully. I think the positioning method sucks and should be scrapped, and the alignment method should be fixed - vertical-align working on more objects than just table cells, and being able to center table/fixed-width block elements without resorting to margin hacks.
Just because you're paranoid doesn't mean there isn't an invisible demon about to eat your face