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."
I remember them saying HTML was going away 5 years ago.
"Anything tastes good if you deep fry it."
"Everything will be in Macromedia Flash soon." - 1999
The thing I think needs the most attention is javascript or the use of. I hate coding things twice and all the limitations. I would love to see a full featured object oriented standard language.
And suddenly pigs fly out of my arse.
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
HTML sucks for making web pages; can you imagine if HTML was popular?
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
Anyone who has dealt with security in web-based applications knows that server-side validation in some manner is a requirement for anything non-trivial submitted through a web form. So, why does it matter if Web Forms 2.0 is, as the article puts it, "in a mature state?" It is yet another validation technology useless for security. It isn't even that useful for client-side validation, seeing that most web users do not use a browser that supports Web Forms 2.0 natively. So, if a developer wants to use Web Forms, he or she also needs to code in javascript and do server-side validation?
What's the point?
HTML is fine. CSS is great. It's everything inside of that needs cleaning.
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.
Don't worry, it's not really dead, it just smells that way because of some 20 years worth of accumulated dirt.
It could use some washing, doesn't look like it would happen anytime soon though.
Anagram("United States of America") == "Dine out, taste a Mac, fries"
Let's face it... HTML, CSS, etc, etc isn't the problem with websites .. it's the people designing them.. Does anyone really think that WHATWG is going to change that ? I'm fairly certain that the same monkeys will still make hidious websites using the same reasoning behind them now.."But I think that color of green.." and my favorite "It looked ok in frontpage.."
I'm a first year Computer Science student. In high school, I took a year of HTML; it's amazing what you can do with it. If you include CSS (our book did) and Server Side Includes (it didn't), you can make extremely streamlined and beautiful pages. HTML along the lines of using h1 through h6 is foolish, but I've (literally) never seen anyone use any heading smaller than h2. Just because a feature exists doesn't mean you have to use it. PHP, Javascript and the like are easier to break, and harder to interpret; for a small business without a dedicated web programmer or a programmer without a lot of time, HTML is *the* way to go. The best web pages I've seen have been courtesy of a text editor and photoshop, using HTML and CSS only. HTML is simply not going away, any more than times new roman is.
I used to carry a bottle of whiskey for snake bite. And two snakes. -Nefarious Wheel
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"
yeah it will generate the JS validation based of your asp validation. pretty neat hey.
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.
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.
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
let's just deprecate all tag except div :p
The bits on the bus go on and off... on and off... on and off...
JavaScript, jScript and ActionScript are all variations on the ECMAScript standard. Everyone else - including Flash - is moving towards compliance with the ECMAScript standards - I don't know about MS intentions, but I'm not hopeful - they'll only do it if the market forces them - i.e. when people start producing web sites that only work properly on standards compliant browsers.
Which of course will never happen (if businesses are willing to 'waste' time duplicating code for the 10% NOT using IE, they will do the same to cater for even a 10% IE usage).
'Capitalists of the world, unite! Oh
HTML is good for making web pages, but bad for web apps. For that you have DHTML, CSS, JavaScript, AJAX, etc...
I was speaking to a webdesigner friend and he said HTML is a pain as its trys to combine formatting of a page and content. The split between content (XML) and then having formating (say CSS) makes things much easier to handel and use as you can changes things on the fly
Cheap UK and US VPS
HTML isn't a very good language for making Web pages.
Compared to what? Sure, I've coded enough HTML to have bumped into countless limitations and annoyances. But with all the file formats invented over the years that have been even less adopted, why are we so sure there's something so much better than HTML? Describing visual objects with words (what any web page language has to do) is hard. I've used Java and other languages to do app layout, and they're certainly not any better. Or perhaps we want to move to a drag-n-drop wysiwyg system with binary files underneath, like Flash?
Sure, there are improvements that can and should be made to HTML. But saying it's not good for making web pages is like saying food is not good for eating. Maybe there's something else better, but we've yet to see it. And it seems it's done a pretty astonishing job so far.
Cheers.
Already a jumble of variant support. WebForms 2, XHTML 2, canvas. Different browsers supporting different subsets of features: IE, Opera, Firefox, Safari, Konqueror.
I agree this looks like a great extension to HTML. But these standards groups need to get agreement and cooperation out of the browser development groups and releases. I guess I wouldn't mind Firefox and Opera leading the edge, since they seem to have better rate of development (well, MS could beat them with sheer resources, but the play-nice strategy tax still comes into play here).
Christ, at minimum, will they please have alterate form submission destinations without JS in the buttons? Even WML and HDML for phone microbrowsers had this in 2001.
I think a large set of feature extensions to HTML would be fine, as long as some sort of idea of a rollout schedule can be estimated from the major browsers. I'm a corporate developer, so I can generally rely on only one or two browsers being used. But consumer sites will be in deeper pits of version hell.
Hey, I'm just your average shit and piss factory.
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.
"HTML isn't a very good language for making Web pages."
Only the first sentence and the article is already wrong enough to stop reading more
According to prophecy
If browser wars weren't enough, now we're going to have web standards organisation wars.
Current, html+css+javascript+ajax are good enough.
Theyre not a lot of "diferent languages, they are just different specifications for the same thing.
About, interactivity, there is javascript for client side parsing, presentation using html + css isnt so hard to make, also, How may applications are "nicer" or "friendlier" than a web page?
Yeah, sure "Ok" and "Cancel" are self explanatory, pull down menus are SO easy to do, and adding timers or counters is SOOOooooo easy in any language... No, sir.
HTML has made the development of richer UI app easier, applications maintanance centraliced, so is cheaper.
How may "lines" do you need write or wizards to click to add a single image to a desktop application? What about an animation? those, common task are done with just a couple of lines at the web.
Trying to make web app look like desktop app, is WRONG... SAP interface, is one of the ugliest, difficult and cryptical interfaces I have ever seen. Pull down menus, inside pull down menus, inside lateral menus, as word/excel and so many other app, are less than intuitivie!!!
Stop trying to make web app look like desktop app, web experience, is much more richer than desktop app. We can help the user with flash, process data with php/perl/c/net/pick your language, client-side parse thing with javascript, create "real-time" feedback with ajax...
What is the issue? Desktop should be working to be AS easy as the web... not web trying to be as clumsy as desktop app...
Â_Â
I'm not a atl developer, but more of a unix guy. But I have dabbled with delphi. I did such a thing once by getting the hdc as a canvas and rendering to that. I don't know if delphi uses the MFC, but their VCL is a damn sight easier to mess with.
I assume you mean that hdc is a device context like, say, the desktop?
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
What I think needs to be done is to package HTML and all the components for a webpage into a small, highly compressed binary file utilizing an open standard, or perhaps creating XML-based binaries similar to how ODF files work.
.HTML file and all of the graphics, and sometimes if something is out of place a link or page is broken. A Binary file approach to HTML could fix this. Images and other web componnets would be embedded into a single, compressed download. Pointers could be used to point to specific pieces of another web document the same way you can create links in Word and OpenOffice documents to other portions of a separate document or how PDF files can link to other parts of another PDF file. Using a method like this would reduce the amount of space needed for most webpages and making updates to them would be easier also. I also don't see why browsers couldn't be made to support both existing HTML and a new binary file standard. Perhaps it would even require a new Protocol.
The reason for this is to decrease the load on web servers when a webpage is loaded. Separate connections are made to download the
Michael "TheZorch" Haney
thezorch@gmail.com
http://thezorch.googlepages.com/home
If people would write code good in the first place - and not use things like MS word, Publisher, Front Page and other programs where it works fine in IE but not other browsers - or only USE browsers like IE which overlook forgotten close tags and try to compensate and make bad code LOOK good.....
Then maybe more website would work in all browsers and look the same in all browsers - instead of just settling for "ok it works in ie, so it must be right" and forgetting the other people.
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
I'd say that the real problem is that HTML isn't very good for anything else! By which I mean that in order to *display* a web page you really don't need much more than a set of tags pointing at appropriate bits of a CSS, so HTML is pretty much overkill since it gives you more tags than you really need for that purpose (now).
If you want usefully to store the information that's going to be rendered into a web page, you probably want to store some semantic information about the content of the text which you can later use to influence the way it's displayed (for example, distinguish which names in a court report refer to the accused, which to the victim and which to witnesses) but also the way in which the information can be navigated. The HTML spec makes a half-hearted stab at this by enabling you indicate which bits of the text are headings, but there's not a lot of other semantic information conveyed by tags (and where there was the tags were typically misused for their formatting side-effects).
XML is much more flexible about allowing the markup of semantic content - a browser could (under certain circumstances) use XML+CSS without having necessarily to understand any XML schema or XHTML, but even XML has problems with overlapping and discontiguous semantic blocks.
There's a big difference between putting a document on screen for someone to read and marking it up for semantic content: there's more cruft in HTML than is required for the former and nothing to assist with the latter.
It ain't going away soon, though...
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.
There is already the MS .mht web archive which does html archiving/packing.
But if the archive is page based, you would have to transfer data such as big images multiple times for each page inside the archive.
Or you could place the entire site into the archive, but that is kind of pointless, inefficient and loads slowly, because you'd have to wait for the entire package.
What you are looking for is "HTTP keep-alive", because this saves the connect effort.
I'd be much more interesting a P2P-enhanced version of HTTP
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.
Too late now , but when Berners-Lee first came up with his way of doing hyperlinking (lets not forget , he didn't invent the idea!), he should have (IMO) , defined a simple page format programming language , perhaps like BASIC, perhaps like C/javascript , so that over the years it could be added too, improved upon , made more powerful. This would have probably negated the point of most plugins and add on scripting languages and tools - just one interpreted language which the browser understood which did everything. Eg:
/home/me/myimage.jpg
:o)
locate 20,1
printtext "heading", bold
locate 30,10
printimage
Or something to that affect. With looping constructs it could have become very useful and avoid the mess of different things a web page relies on now. But then , I guess hindsight is a wondering thing eh?
How bout this: The reason why html sucks is because its almost impossible to write an html parser that will write to a device context without having a windowed app.
Just because the available html-rendering libraries for your platform suck (or maybe you didn't search enough), that doesn't necessarily mean that the language you are trying to parse sucks.
The thing I have always wanted is client side image handling added to the img tag, this would make many things more efficient and simpler, you would only need an extra two attributes. Adding a frame= attribute and a subimage=x,y:x,y would reduce all the server requests needed for the cut up table images and gallery pages. Possibly a mask image attribute might help also?
embedded linux
The solution to this of course is "display: table-cell" and the like...if only it was supported well by all browsers...darn it, i guess you're right.
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.
Parent is either being cryptic, naive, or sarcastic, because he's basically saying "hey, let's modify postscript and use it to replace html."
:-)
Postscript allows you to do absolute and relative positioning. It lets you print text, raw images, and vector graphics. It has looping constructs and recursion (hint: the language is turing complete). Add a few primitives for URLs, and postscript would work just fine* as a replacement for HTML + javascript + plugins!
* - Fine is a relative term. Lispers would love it, but everybody else would pull out their hair trying to make a "Hello, World" postscriptwebpage.
No i'm not. Postscript is a Forth based language , is very hard to code
manually and useless for the beginner. I was thinking of a simple BASIC
style page layout language that could be expanded to do more complex
things as and when the need required. NOt that hard to understand I wouldn't have thought.
Using target="_blank" in your... /> tag limits the new window to be very plain in appearance and gives you no control over its size.
Fine if that's what you want.
If it ain't what you want, you have to use something else...
So in summary, the assertion that HTML isn't a very good language for making Web pages is false overall, although in some cases, it doesn't always do what you might want, and is subject to bad use by c0derz, and appalling browsers which still cause problems after all these years.
Carbon isn't a very good element for building intelligent life forms, either, but hey, it's a start.
...
Trillions of dollars of market value were created in the last 10-15 years based on HTML's not-very-good ability to build a webpage. Having trouble printing? That's a conversion problem. Having trouble interacting? Maybe you could spend some time with air-breathing carbon-based life forms instead of digital avatars
"He that breaks a thing to find out what it is has left the path of wisdom."
Time and again, we hear that the available "technology" is not good anymore and a change is in order. To who's benefit, I wonder? Which compaby has a "better technology" under wraps and has started its marketing campaign? What exactly is missing in the current web pages? HTML ensures basic functionality; extra functionality is provided through plug-ins. Installing a new browser supporting some kind of "super-HTML" language would be more cumbersome for te end user than installing a new plug-in.
"HTML isn't a very good language for making Web page"
We must remember that there are at least two different discussions going on here:
1) HTML, as a markup language, is fine and fairly simple. It is more important to look at how we are using HTML and for what we are using HTML. We have evolved to want so many things from WWW pages. In other words, when used for the task for which it was meant, HTML works great.
2) Implementors and programmers: We have a variety of rendering engines, proprietary extensions, and a mixture of skill levels of HTML "programmers" out there. What's new about something like this? As long as software has existed, so has The Good, The Bad, and The Ugly (tm).
The better question is, can you imagine the web without HTML?
A Passionate Independent Musician
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!
Speaking as an ordinary user and on behalf of other ordinary users, what you describe is something that I and the others absolutely do not want. Pushing programmers' wishlists onto reluctant and skeptical users is not the way forward. Give me good writing over fancy presentation tricks anyday. I am happy with a web that has neatly formatted plain text and occasional images, video and audio pieces without the distraction of unnecessary popups and tedious web gadgets etc.
Please feel free to ignore us while we continue to enjoy the essence of good authorship, which is no more or less than good writing -- a fact apparently lost on fans of technology for special effects whether in the movie industry or in web technology circles -- and we will happily ignore all this unnecessary "techno glitz".
Absolutely - I had a big problem with this, too.
Regardless of whether the author ever uses them, it does no harm and causes no confusion to include them. Also, if one is writing "proper" CSS, making use of intrisic HTML tags and applying styling directly where possible, I can think of many occasions where and smaller would be very useful.
This article is essentially a rather complex troll - a peice of writing by someone who's read an HTML book and chatted to some professionals, but almost certainly has never worked for a sustained period on a modern (X)HTML and CSS project. A genuinely workable content-presentation format has to cater for *everyone's* requirements adequately, not just some jerk who thinks he knows what's best for the Web.
As a developer using and its siblings frequently, the XHTML 2.0 system of calculated heriarchies sounds jolly useful as a replacement, though - if it ever happens.
sig:- (wit >= sarcasm)
All the things that have been invented for doing web applications, either static or dynamic, are completely wrong from a software engineering point of view. What is needed is:
1) a strong programming language that can be as declarative as HTML up to as dynamic as C++.
2) a toolkit for that language that offers the basic services a distributed application needs.
With all the standards available now and in the near future, the same things are being re-invented over and over. For example, any plain HTML page can easily be recreated in a language that can/made to be declarative (LISP, for example). Any dynamic content needs some form of imperative programming language, whereas any constants HTML has (for example, H1 to H6 headings) can be specified with static objects.
We need a language that can be transmitted as plain text, executed interactively at the client using just-in-time translation of source and appropriate caching of binary code.
The toolkit and environment would come pre-installed in most O/Ses, just like a browser is. After all, a browser is needed anyway for web access.
Java does not cut it because it is not as declarative as it is needed. Provided that there is a suitable API, there shouldn't be any need for imperative constructs in most applications. Java fails in this respect, because everything needs to be done in an imperative style, which makes it difficult to be simple.
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."
Microsoft has been saying this for years. They invented AJAX as an extention to speed up HTML since it is just not fast enough in their opinion.
Just admit it - you pulled this out of your ass, right? I can't figure out how you could think that making HTTP requests from JavaScript speeds up HTML in any way at all. What is your reasoning here?
Slashdot - where whining about luck is the new way to make the world you want.
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.
CSS is great for a very few certain things (like flowing text), but totally sucks at a lot of other very common layout tasks.
I've managed to get pixel perfect display and printing in a number of web apps using CSS. I fail to see how it totally sucks.
-Stu
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.
You're making the assumption web pages should provide a good widget set and rich controls.
It's like complaining your car can't fly unless you bolt a pair of wing to it. You car wasn't meant to fly and neither was HTML meant to provide an application interface. It was always about structuring information in a simple, easy to understand way and to include hypertext ideas into the structuring format.
*Script, Flash, JAVA, etc... these all run counter to the original design of the web. But who's going to complain? And why would a browser developer not include these extra features if it'll help boost the browser's overall market share?
Browsers are being turned into hardware-independant application platforms, which they were never meant to be.
Why would you want to do this though?
Why would a man want to be bound, gagged, and spanked while being called a "dirty boy".
er.
Nevermind.
Ok, so I've not read every single comment on here because I don't have the time to sort through all the "good" comments and opinions and the "flamebait" material. That being said, I think some people are missing an important point. The WHATWG group is working on a specification for how HTML, CSS, Web Forms, etc are implemented by authors, developers and designers. How is this any different from the specifications being developed by other computer related industries? The ATA specification is currently at version 7 and they are already working on version 8. The SCSI specification is still being "tweaked", even though most people feel that the entire interface is on the way out, soon to be replaced by SAS and possibly Fibre Channel. My point is that while people may find it frustrating that they're recommending another change to the HTML standard, I think it's a very good thing. It gives everyone a base point from which to work from. Simply based on the number of different tutorials and examples found on the web, there are obviously many, many ways of getting something working the way that you want, so even with a new specification you're not all that limited in how you implement those guidelines. I, for one, am glad that someone is stepping up to the plate and trying to keep web design in some sort of order. With the number of programming languages available to use and the number of ways each option can be configured, SOMEONE needs to try to bring order out of chaos.
if anyone actually listened to your recommendation, the Internet would still be an academic curiosity and we'd all be vegging out to shitty interactive TV.
.. any programming paradigm that passes a certain threshold of mathematical reasoning will remain a niche. HTML succeeded because it was dumb.
There's a saying
-Stu
Are you serious?
The second that http was used for more than just telling a webserver to retrieve a static file, web based applications were possible. That was what 15 years ago?
Good authorship is irrelevant when someone is just using a website to do data entry or check email.
Pure HTML can work for most applications if you don't mind doing full page refreshes and 100% server side form validation.
HTML + javascript helps somewhat by doing basic client side validation.
HTML + javascript + XMLHTTPRequest (AJAX) can be used to things much easier for the user
For example: You can keep server side validation for security, client side javascript for simple validation, and use AJAX for complex validation such as a part number validation against a database for an order form.
It can be used to browse data that is logically in a tree form by only expanding sections and marshalling data requested by the user.
Whether or not an application is complex to write is irrelevant to the user, but an application that doesn't appear so limited by bandwith could provide a better experience.
This may not matter much if all you want from your internet connection is to pull down static content. But if that was the case, why are you hanging out and posting comments to an interactive forum?
"If they have both, tell them we use Linux. And if they have that, tell them the computers are down." -Dave Chapelle
What HTML was great for, and what I feel is gradually being lost with CSS, frames, and Flash, is the accessibility. HTML was built to convey information. An EM tag meant emphasis. It might show up as italics, underscores around the item, or a stress in a voice-reading program. There was no guarentee that it would display the same for everyone, but the same meaning was to be conveyed. This meant that any browser, even the text-based ones, would convey the same information. That simplicity has been lost and along with it, accessibility. Many sites, you can't use TAB to navigate the page. Heck, on Flash-based sites, you can't even use the keyboard half the time. And goodness only knows how accessibile the average web page is for someone who can't see, or has limitted input capability...
This sig has absolutely no significance and serves only to take up screen space and waste the time of the reader.
What I haven't seen much discussion of in the comments here is much discussion of the longevity of the standard. I want to write documents that my grandchildren and their grandchildren will be able to read if they so desire. There seems to be a lot eagerness to design standards with lots of bells and whistles but I want something that will still be viewable in a hundred years without having to spend time every few years reformatting it to the next *TML. Do these new proposals include an "archival layer" (a "people should never, ever, ever change this again" base of codes to which people can safely format documents/data for posterity).
Formats are the new alphabets.
Even a child can do it.
There is no need for style sheets. A child can get simple HTML right.
You can publish extremely well on the web with the knowledge of only 5 or 10 html tags. HTML was written in the first place in such a way that it was easy to publish on the Internet. That is why the Web flourished in the first place. Now its becoming a wash in the quagmire of unneeded complexity.
Even MSIE can get the the few html 1.0 tags one needs to publish right. After that I am not interested. Unless you have written a good MMORPG in a web page we can all play. But we all don't need need to write pages like that every day.
The future of the web you ask?
Publish with a wiki. You don't need even HTML 1.0. Unless your maintaining the wiki. even then keeping it simple is best.
Why a wiki is as easy to publish with as what ... /.
kind of makes you say hummmmmm.
PS. I used only 2 tags for this.
You're making the assumption web pages should provide a good widget set and rich controls.
:)
No, I'm making an assumption that markup language for web must provide a way to provide a good widget set and rich controls on the page. There is a difference. Don't use it if you don't like it.
Browsers are being turned into hardware-independant application platforms, which they were never meant to be.
Now they are.
Seriously, many applications that were meant to be desktop applications are now becoming *web* applications: e-mail clients for example. AJAX won't help and it is only a temporary solution. Besides, it is ugly solution, IMHO. I think we should go even further than just extending markup. We have to rethink the way browser interacts with the server and bring asynchronousity to this interaction. Than we can make really good web apps and services.
Anyway, I'm glad it all seems to be working out my way
May Peace Prevail On Earth
Apparently even Microsoft agrees: .NET's "downscale" mode (i.e., a non-IE browser is used) generates html 3.2.
As long as HTML continues to deliver an immense amount of porn to my screen, I could care less.
I don't know why that was moderated as flamebait, it's quite true. One doesn't need the proprietary Flash player at all. One might not even need a Free Software Flash player to be installed either.
The proprietary Flash player will open browser windows, thus bringing you back to pop-up and/or pop-under ads. Combined with the loss of software freedom, this sounds like a detriment that doesn't outweigh the possible advantages.
Digital Citizen
"Which browser is going to be the first to stop supporting HTML?"
My question is, which browser will be the first to stop supporting GOPHER?
Firefox 1.5 supports the gopher protocol.
If brosers are still supporting the vast, huge quantities of gopher sites, I think it may be a little while before they stop supporting HTML.
----- If communism is a system where the government owns business, what do you call a system where business owns govern
Times New Roman I can stand. It's Courier and Courier New I never want to see again.
GCHQ Quantum Insert installed. If only our tongues were made of glass, how much more careful we would be when we speak
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.
AJAX and Javascript unavoidably result in enormous bloat in terms of the additional bandwidth consumed and the much greater size, startup time, CPU consumption, and memory consumption for AJAX-capable web browsers, compared to plain HTML and simple web browsers. It is not common to require full page HTML refreshes, and if bandwidth really is an issue, which is unlikely, the web page can be divided into a number of smaller sub-pages.
Client-side validation is always repeated redundantly at the server. The CPU and bandwidth usage of server-side validation is a non-issue.
Very few types of web application that are limited by bandwidth -- video and audio streaming are the main ones -- necessarily require the use of AJAX.
I should let you know that using slashdot interactively for reading and writing comments works just fine for users of plain HTML.
I'll take two of those!
Couldn't agree more. I like having full control over my PC. Maybe that's why I liked the simplicity of Windows for Workgroups 3.11. No unneccessary rogue processes running in the background. It was actually difficult to really screw things up (unless you ran too many things at once and bogged down the GDI and User resources, but that's a different issue altogether.)
It's really not as bad these days as you might think. Pretty much everything supports getElementbyId() - only IE4 and similarly stone-age browsers don't, with a combined market share of less than 1%. So, frankly, leaving them out in the cold wouldn't be exactly tragic - and if you do want to extend legacy support to them it's a simple matter to check for the non-existence of that function, and add a 'wrapper' with the same name which uses document.all or document.layers to have the same effect.
That way your entire code is free of if-this-browser/else-this-browser crap: it all just uses the standard DOM, except for one tiny wrapper function at the very start of your code.
For an example of this technique see: http://javascript.internet.com/snippets/getelement byid.html
(I found a better version of this technique a few weeks ago, but I can't seem to find it now. You get the idea though.)
Overall though, I don't really like javascript at all, I must admit.
For some things, sure. For others, no; otherwise there wouldn't have been the obvious examples that started this subthread.
IMHO, what the CSS guys should have done is introduce some proper relationships between different boxes, so that a fluid layout could be described in some reasonably natural way. Think about the toolkits you get for defining dialog boxes that scale nicely so controls are appropriately sized and positioned on different platforms. For that matter, think about the simple alignment tools you get in every decent vector graphics program ever, where positions can be set absolutely, but also elements can be aligned vertically and horizontally, made the same width and height, etc. We could even allow (shock!) simple equations to relate the relative proportions of text blocks, white space, font heights, etc. Hey, it worked for Knuth. :-)
It's not like these are new, or even particularly complicated, ideas. They just didn't go into the style sheets that are supposed to describe how to render HTML. Instead we have a load of special cases like "float: this" and "clear: that" and "position: the other", and a lot of underpowered "auto" entries that just don't cut it for serious design. How much nicer would it have been, if we'd had a technology with the same content vs. styling separation, that actually let designers specify a fluid (or, for that matter, fixed) layout in an simple, natural, intuitive way?
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
Yeah, splitting the content and formatting makes pages easier to maintain. It's also important for accessibility - browsers for users with disabilities need information about the content. The H1, H2, ... tags could be pretty worthless with a blind user.
CSS makes it seem like they're doing that, but why not think of different tags as having parent-child relationships? Derive p from div, blockquote from p, and so on, letting each child have the parent's attributes. The big problem is letting an old browser know that a new tag is derived from a known tag so it displays correctly. Maybe that sort of thing can be defined in something like a DTD or schema which can be read from the html header (html already requires a DTD on every page), and the browser can cache the definitions so the w3c doesn't DOS itself.
You say that with a smiley, but Adobe is doing just that with PDF which I've heard is Postscript with a few modifications. It can do hyperlinking, inline multimedia, connect to databases, and basically do a whole hell of a lot more in the file format than HTML can and in a more user-friendly way. Where I'm working is planning on replacing a small GIS web mapping system with a PDF file, and it'll probably be better (easier to use + more features) than the Mapserver system that's running now. The developers of the next HTML would do well to look at PDF and the MS, Oasis, and Docbook formats for inspiration or combining feature sets, and even the gui widget libraries for desirable CSS additions.
You must not get out much. See Edd Dumbill.
You may disagree with his p-o-v (a &Deity;-given right on /.), but to call the article a troll is a bit much.
Agreed.
And, BTW, since his "Part 1" (TFA) was mostly about the WHATWG's offerings, I'd venture that "Part 2" will likely deal more with XHTML 2 (and the W3C). That's just a guess of course, but since his XTech 2005 conference in Amsterdam featured a thoroughly entertaining and provocative HTML5/Webforms2 vs. XHTML2/Xforms "shootout", I'd hazard it's a decent one.
I have little trouble blaming M$ for such things, but there is a bigger pattern at work here in the software industry.
Mmmkay, that was kinda an invitation, wasn't it? My bad. I must not have been paying attention - I'm a professional developer and I've not heard of him...
Seriously, though, this guy (now that I've read around his background a bit) should really know better. Someone with his background should know not to make such enromously sweeping statements. I think it's quite telling, actually - it's this sort of semi-blind praise that's pushing "Web 2.0" as a buzzword, even though it doesn't really mean anything without context.
Sorta reminds me of a recent client who insisted (until I gave him an ultimatum) on my using XML files as a live database for a few tens of thousands of records. A cool idea, buzzword of the moment, but ultimately either inappropriate or pointless on its own. If you get my meaning. Just my $0.02.
sig:- (wit >= sarcasm)
Everyone wants to reinvent the wheel for no good reason. I'm sick of it. I'm tired of hearing, "[new thing] is better!". I ask, "Why is [new thing] better?". At least 80% of the time is answer is, "Because [new thing] is new!"
What is HTML? It's a markup language that allows us to create/parse documents on the web. Personally, when I surf the web I'm looking for [good] content. Most often, this [good] content is made up mostly of text (unless we're talking pr0n, which is presented with html well enough anyway).
From what I can tell, most sites don't need "dynamic content". E-commerce sites and some of the HUGE community driven sites? Yes, I can see a need for dynamic content there. Especially seeing as how inventory [content] changes frequently, etc. However, the vast majority of sites are not e-commerce nor are large community driven. 90% of these small-medium, non-e-commerce sites can do just fine with html+css. That's it, that's all they need. Most of them don't need AJAX, PHP, Javascript, etc.. Just give me some good content in a decent layout.
I don't need the site I'm viewing to dynamically pull content from another site and have it automatically included in the page - just give me a link to the other site's page. I don't need to be able to "map [my] location on Frapper". It's a total waste. These seem to be just proof of concept inventions that the vast majority of sites don't truly need.
IMO, most sites lack [good] content so they try to make up for it with bells and whistles. That's probably the only reason we're even having this discussion.
So when you say "it is Mozilla's fault for not implementing specs from 2003", what you really mean is "is it Mozilla's fault for not implementing unfinished specifications"?
Mozilla implements unfinished specifications all the time! Parts of CSS 3? Yup. The canvas tag? It's hardly safe to hide behind the done-ness of the specification, when Gecko already supports quite a few draft specs.
Anyhow, it was largely a rhetorical question. I was trying to point out that even so-called "standards-compliant" browsers can have plenty of holes in their support, and that these holes rarely overlap.
Until CSS 2.1 reaches final recommendation status, you are complaining that you can't use properietary Internet Explorer code in all browsers, which doesn't seem that reasonable to me.
Calling it "proprietary Internet Explorer code" is a strawman. If display: inline-block is "proprietary IE code", then the Canvas tag must be "proprietary Safari code", right? But I can use it in Firefox.
Don't become a regular here -- you will become retarded.
Clearly, the right answer is (c) use semantic markup, and let the sections (with their headers) nest arbirarily; but if you perceive your choices as a & b, doesn't it make sense to pick a?
Patrick Doyle
I mod down every jackass who puts his moderation policy in his sig. Oh, wait a sec....
I considered mentioning that PDF is essentially prerendered postscript, but I didn't think it contributed anything to the post. By calling it prerendered postscript, I mean PDF is basically just the drawing primitives (i.e. data). It doesn't have any ability to do looping, recursion, variable definition or function calls, so in that regard it is like HTML without scripting.
Amazon has a web services API to get at their data. I've used it to get product data for a school project (online shop). And if by "pure XML API" you mean SOAP, then they have that too — although I prefer the REST request style (much more simple).
A pudgy ex-Navy guy that says "sir" a lot while he talks down to you will arrive and inform me that I have unauthorized software on my machine which violates security policies. I will receive an email stating the same, and the next time I reboot, the startup scripts will automatically remove all "offending" software.
Doesn't anybody notice that all of this is going in an entirely wrong direction? A lot of different stuff such as JavaScript, SVG, XML, HTML and so on is thrown together... for what purpose? To create more interactive web pages. The only problem is that web pages never were meant to be interactive - they were meant to be _documents_ and not _applications_. More and more of the application logic is pulled from the server to the client (browser)... this way, the boundaries between the two get blurred. The browser paradigm goes over board, things like the 'back button', bookmarks etc. do not make any sense in the application context. Thinking this through leads to something for which a solution has been available for 10 years: a platform-independent way of executing applications on the client - spell 'JAVA'. With AJAX & Co, the wheel is being reinvented (poorly) by throwing together a bunch of heterogenous tools...
He should have developed a JavaScript-like solution half a decade before JavaScript was made available? Do you understand how fucking stupid that idea makes you sound?
Cyric Zndovzny at your service.
...Now I can use flexible datagrids for my layout!
But the English language is itself defined by the conventions and precedents established in the literature that is created with it and accepted by concensus as important. Some people will say that since the vocabulary and grammar is ultimately determined by the body of literature, the body of literature is the real language and the vocabulary and grammar are an abbreviated form used for reference rather than definition.
Liberal arts types typically appreciate this perspective, but it is not well received by a certain category of technical people. I think this is because liberal arts types typically side with the human brain which is very adaptable to changing grammar and vocabulary, whereas the certain category of technical people side with version X.YZ of compiler ABC which is not very adaptable.
Fortunately, technical people usually come around as they get older, :-). Unfortunately, I am not old and I have a graduate degree in a technical field, so I'm just praying for old age so I can understand what I just said. I think it was something like, "There's more than one right way to look at something."
Incidentally, has Netcraft confirmed the death of HTML?
This sig has absolutely no significance and serves only to take up screen space and waste the time of the reader.
In my opinion, they used the correct box model: width = content + padding + border. When I specify that I want something to fill the page width, with margins of, say, 10% on the left and 5% on the right, borders of 2px, padding of 2em, I don't want to end up with a page that is 100%+4em+4px of the browser width. Calculating correctly requires using relative values throughout, which can look pretty silly when it comes to things like borders.
I reckon width should mean visible width of the whole element, not content width.