Slashdot Mirror
W3C Publishes First Public Working Draft of HTML 5
Lachlan Hunt writes "Today W3C announced that the HTML Working Group has published the first public working draft of HTML 5 — A vocabulary and associated APIs for HTML and XHTML. It's been over 9 months since the working group began in March 2007 and this long awaited milestone has finally been achieved. '"HTML is of course a very important standard," said Tim Berners-Lee, author of the first version of HTML and W3C Director. "I am glad to see that the community of developers, including browser vendors, is working together to create the best possible path for the Web..." Some of the most interesting new features for authors are APIs for drawing two-dimensional graphics, embedding and controlling audio and video content, maintaining persistent client-side data storage, and for enabling users to edit documents and parts of documents interactively.' An updated draft of HTML 5 differences from HTML 4 has also been published to help guide you through the changes."
At least until some major browsers support it. And it really won't matter until IE supports it. Sad, but true, really.
My blog
Looks like this is what Mozilla, Apple, Microsoft, etc will need to begin supporting 5 in the future.
How long that takes, noone really knows. More importantly, how easy will this be to use and how useful will the semantic bindings be?
Finally, anyone know if HTML5 mandates any specific version of EMCA/Java-Script? That part seemed vague to me.
Make sure everyone's vote counts: Verified Voting
I can't be the only one who thinks the W3C is annoying as hell... So you're advocating holding back progress because a lot of sites authors don't bother to make their HTML compliant? With the new APIs, this hardly qualifies as "no reason at all".
Want to improve your Karma? Instead of "Post Anonymously", try the "Post Humously" option.
Large for-profit software giants must constantly make product to stay in business, pay programmers, and make profit...even if there's nothing REALLY to fix. Just make upgrades...sell new versions.
Consumers and businesses are constantly put on an upgrade-treadmill as older products are purposely torpedoed...even when they worked fine and did the job they needed to do.
now replace "for-profit software giants" with "design-by-committee standards organization" and "stay in business, pay programmers, and make profit" with "stay in charge and not have to get real jobs".
THL phish sticks
Still no client side include (no, object doesn't cut it...).
People are talking about browser support, it seems to be written in such a way as they should already be able to support it if they support either HTML 4 or XHTML.
It removes lots of sylistic tags, CSS way to go.
New section tag is good.
Overall, looks interesting, cleaning up HTML a bit more, forcing it to be more of a structure rather then presentation language.
Anyway, I'll start using it, when and if, it becomes useful for my work. Otherwise, XHTML and HTML 4 are it.
I wank in the shower.
And I must say, I like where this is going so far. It feels like a very natural progression from HTML4's ideology, while respecting authors' collective recent interests, such as media embedding, and .
What progress? With every new standard, I hardly see any improvement. Browsers still render compliant pages differently, web designers still use multiple standards, and all the while the W3C tries to convince everyone that their way is the right way.
The idea of concrete "standards" isn't really compatible with the open, ever-changing, free-for-all we know as the internet. To keep up, the W3C has to keep updating their "standard", which partially defeats the purpose. frankly, I'm sick of hearing about it.
End-users don't give a damn whether a page is compliant or not. As long as it works, it's fine.
One of these days, I'm going to cut you into little pieces.
I wonder what the support for HTML 1-4.0 was before 4.1 came out. I bet it was less than total. Standards support for HTML 4.1 is pretty damned good when you look at the big picture. The standard is only not followed (even in IE) for very few features when you look at the entire standard. Full support of HTML 4.1 isn't even a requirement to start on 5. Why would we wait for everybody to finish 4.1 then say "ok, now that you are done with that, lets go do something completely different that will make all of your former work obsolete."
HTML 5 will make it so we don't have to do crazy shit to tease the functionality we want out of a standard that wasn't meant to do what we have come to expect from websites.
So we have
At the start of every HTML document served with an text/html mime type? That's real rational. Let's get this tidied up once and for all and start html documents with
Is that such a difficult concept?
TWW
"Encyclopedia" is to "Wikipedia" what "Library" is to "Some people at a bus stop"
"Implementations that use ECMAScript to implement the APIs defined in this specification must implement them in a manner consistent with the ECMAScript Bindings for DOM Specifications specification, as this specification uses that specification's terminology. [EBFD]"
Their language indicates that ECMAScript isn't a requirement. Essentially, "if you use it, you must implement it in a certain way". They don't mention requirements for implementations that don't use ECMAScript.
Want to improve your Karma? Instead of "Post Anonymously", try the "Post Humously" option.
Good to see they're binning frames.
But - why has there never been an include mechanism in HTML?
Audio AND video on the same page? The mind boggles. And with 2-D graphics? I can barely conceive it.
And persistent client-side data storage has been a dream since the mythical cookie.
And editing of documents will just lead to anarchy.
This sounds like HTML Vista.
Concerning CSS, site authors don't write standard compliant code because most browsers aren't standard compliant. Just to emulate the standards across multiple browsers requires tons of hacks and alternate approaches that normally wouldn't have to be done if the damn browsers were compliant to begin with. It's not the authors' faults that they have to hack around non-compliant rendering engines.
:)
Sorry, I'm just a very frustrated CSS developer
In an effort to conform with internet communication standards, please note that the above comment is 100% biased opinion
What do you propse we do instead then? Wait for the browsers to implement new features on their own so we have 4 major browsers going their own way trying to do what they think is best and end up with 4 different sets of features and implementations so that no new features will be implemented cross browser? Yeah that is a great way to get the end user websites that work. God damn, the standards aren't for the people writing the HTML as they are for the people writing the browsers.
font, although it is allowed when inserted by a WYSIWYG editor due to limitations in the state of the art in user interface for these editors.
I know this is for ease of use, but seriously: if the people at W3C really want a "standard", doing stuff like this does nothing but make it ok to ignore the standard. So which is it, CSS or font? Pick one!
Many pages on the internet, are not well formed HTML.
One cannot force everybody to rewrite their pages.
HTML 5 defined the rendering behavior for pages where previously were "Implementation Defined".
In a way it describes the bahevior of the Mozilal program. Not because it is more reasonable. Simply it's what mozilla does.
On top of that, it adds a couple of new tags which help googlebots.
The problem is that a 10000 page standard that describes the bahevior of Mozilla, is not a useful standard.
Monopoly through complexity, etc...
I don't really keep up with the politics, but I think that HTML 5 is the W3C caving to exactly the sentiment that you are expressing. People weren't happy with the W3C and their pushing of standards that people weren't following (or at least not uniformly). They responded to outside pressure and HTML5 was born. So cut them some slack - they have seen the light and are attempting to be accommodating.
Anyway, the situation that you describe won't really be the case in a few years. Safari, Opera, Mozilla, and IE are all fairly standards-compliant these days. When IE6 decreases to 10% or so, the last of the really non-compliant browsers will be history.
Getting your site pixel-perfect on all of them is not and never will be trivial, because HTML is not supposed to do that. Certain sites do demand that, and for those sites we have things like Flash.
W..w..W - Willy Waterloo washes Warren Wiggins who is washing Waldo Woo.
title says it all really. basically they are not going for a default of ogg for audio and video by the looks of it...
comment first, facts later. http://chem.tufts.edu/AnswersInScience/RelativityofWrong.htm
What a lame duck HTML5 will be. These changes serve to only annoy current developers, little more. The only benefit here is for people looking to learn HTML from the source code. It will make a little more sense at a glance, but forgive me for not finding that worthwhile. Who learns HTML via notepad and source code anymore? All the rooks are going to keep using dreamweaver and thinking they understand what is actually happening. They don't.
:(
The only thing that might save me grief is going to be the small changes to form elements. Making something required is only half the battle though. If you are checking the data, you've gotta see if it empty anyways, so I guess this is good for the 'Name' and 'Company' fields
Invexi - a Phoenix, AZ based web design and web development company.
XML's syntax sucks. It's annoyingly verbose, and annoyingly lowercase (lowercase tags suck because they are harder to tell from normal text). I'm glad they're supporting HTML syntax.
On top of that, we get decent application controls such as grids, trees, better lists, and meters.
Though audio and video I can live without. I'll be the first to get rid of it in my user CSS.
Oh, and I hope they know what they're doing by removing CENTER. Currently, there's no way to replicate its behaviour from CSS (CSS2). (And no, text-align: center ain't the same.)
I was about to say 13256278887989457651018865901401704640, but it appears this number is private property.
4.1? And here I am, stuck on 4.01.
Gamingmuseum.com: Give your 3D accelerator a rest.
http://it.slashdot.org/article.pl?sid=08/01/21/0652248
Absurdity: A statement or belief manifestly inconsistent with one's own opinion. -- Ambrose Bierce
What progress?
If you RTFA you would have seen that there are a lot of interesting changes in HTML5 that integrate with what people are doing NOW and providing a seamless set of markup and APIs. The audio, video, and canvas tags are particularly interesting to me, as well as the host of new meta tags. HTML5 could really take the web to the next level (and I'm just talking about organizing content, here, not even web apps or anything - it has some neat features pertaining to those as well).
To be honest, after reading TFA, I thought that the response here would be mostly positive. These changes show that the w3c is committed to providing a standard that matches up with how the web is really used anymore, especially the new apis. While obviously writing sites to take advantage of them will have to wait for compliant browsers, it is pretty encouraging to me that they use the presence of implementations, rather than the finishing of the document, as the standard for completion. Personally, I look forward to the new way of handling server-side events, and the ability to ping uri's, which seems to promise a lot of power if sufficiently flexible.
All this means is that instead of using "td align=...", you'll get people using "td style='text-align:...;'". Where's the win, other than making documents larger?
That's the fault of all the dumb ass wannabe programmers out there who are getting by as corporate-paid web programmers. Most only learned it up to 2.0 spec; maybe 3.0. For further progress, they just shunted into Flash and that's it! It's not like there's compilers, nor pressure, to comply with the standard.
It's all about the lazy man's philosophy that as long as it works, on to the next project. Until browsers start failing bad syntax, the web will stay with the basics, and new HTML revisions are just more leavings of white tower masturbation.
Oh! I found the problem. You're looking for the article about PDFs. If you'll just follow me...
Dewey, what part of this looks like authorities should be involved?
If anyone involved in the spec reads this, for the love of god PLEASE include a 'value' on the "select" tag.
'as an alternative to flagging an option tag with selected="selected", a select tag may have a 'value' attribute. A renderer should select the first child option with a matching value attribute.'
Please, my servers are getting fed up with rendering an entire country list just to flag one with selected="selected".
The menu element is redefined to be useful for actual menus.
One of the requirement of the previous HTML5 was support of *at least* ogg/theora/vorbis.
It was merely shot by "important players" at last conference.
This is sabotage since those codecs are the ONLY ones to fulfill what's required for an open source royalty free W3C standard.
The net is now able to do video and audio, but some collectives do not want it to happen by forcing a crippled standard.
To (hopefully) anyone who understands and advocates XHTML and CSS, HTML5 is a tragic mistake. I can't believe TBL is supporting this garbage. It brings back some (but not all: <i> and <b>, but not <u>) presentational tags and gives them worthless definitions. It's full of concessions to lazy/unskilled developers. It makes XML compliance optional. It's full of niche tags which are so narrowly focused (aside, dialog) that they're almost certainly doomed to lousy browser support. It doesn't address the current inadequacies of forms. It has tons of design flaws and inconsistencies.
Until there are consequences for not following the standards, it doesn't matter what the W3C does: People will continue to make pages and sites that are "just good enough", and browsers will continue to render what they want how they want. In the past, now, and for the foreseeable future, there's no incentive for anyone to do things right other than ego.
I don't get it. The people designing this stuff are supposed to be experts in the field, yet they seem hell bent on force feeding everyone this drivel. If their true goal is the hurl the web into chaos, then they will certainly succeed.
That would cause older browsers to use quirks mode, but HTML 5 compliant browsers to use standards mode. causes both older and newer browsers to use standards mode, for an easy transition to HTML 5.
What a fool believes, he sees, no wise man has the power to reason away.
No more style attributes on any element.
*blink*
Idiocy. Abso-fucking-lute idiocy.
This by itself nearly renders in-browser dhtml applications (ajax or no) non-complaint and broken.
Somebody really needs to wrench the HTML spec out of the hands of the W3C and place it into the hands of somebody who spends a little time on other side of the ivory towers.
Ed R.Zahurak
You know, oblivion keeps looking better every day.
I didn't see anything new for uploading files. It would be great if improved support for uploads could be considered. Currently uploading 10 files requires 10 file widgets and performing the browse/select process for each one. It would be nice if the kind of interface found on sites like facebook for uploading multiple images/files could be achieved without the need for Flash or Java.
Most of HTML5 was actually done outside of the W3C.
However, to address your earlier point, one of the big things we're doing with HTML5 is we're going and specifying the bits that all the other specs avoided, like 'window', like 'setTimeout', like how to parse HTML in the face of errors, and so on, and saying exactly how they should work, based on how browsers do them now, so that we can get the browsers to converge on one interoperable set of behaviours.
I'm also working on the Acid tests, e.g. Acid2 and Acid3, to foster interoperability on the older specs. It's working pretty well so far.
http://ln.hixie.ch/
http://www.webstandards.org/action/acid3
So... HTML5 should actually help bring the browsers closer on the bits that weren't specified before, and the Acid tests are directly intended to do that with the bits that _were_ specified before. If you want to help out, please do -- see the links above for how to help with Acid3, and the links below for how to help with HTML5:
http://blog.whatwg.org/w3c-restarts-html-effort
Hey working group! Use CSS to pick a font. Give a method to get the various metrics of a layed out string and one to draw it. That will cover most uses.
Sadly they got rid of the inline style atribute i.e. span style="color: blue;" - http://www.w3.org/TR/2008/WD-html5-diff-20080122/#absent-attributes
"During My Service In The United States Congress, I Took The Initiative In Creating The Internet." -Al Gore
No really, what a waste of time
http://www.w3.org/TR/2008/WD-html5-20080122/#the-irrelevant
Henri Sivonen and his elitist friends really have outdone themselves.
Idiots, go back to 1999....
As someone who works in a LAMP environment on the back end and a HTML, CSS, and JavaScript (Prototype.js) front end on a daily basis I have to say that I feel pretty confident in the fact that with the current technological tools at my disposal, I can build just about any page with the right people.
:-D
However,
HTML 5 makes me excited purely on the basis that the new elements being introduced will speed up and increase my productivity to put out more and more high quality and interactive sites.
I can tell you this much:
HTML 5 is a giant leap.
HTML 5 won't be adopted over night but with it's high affinity towards binary multimedia content embedding it will certainly be pushed quicker then the previous HTML version ever were. There will be pressure on all the vendors to release a good browser for it as quickly as possible and as bug free as possible. This might force Microsoft to actually design a good browser since this would give them a fresh chance to do so as well. Furthermore, market forces are tending to push them towards that same goal so they probably will try.
For users this is amazing news because CSS 3 and JavaScript 2 are gonna be part of the same generation of web development. The possibilities for applications suddenly explode and the ways you can use this content will drive development.
Don't hate, celebrate. Good day for the Internet!
...and delightfully extensible and powerful...
...which is why I used one of the many open source and/or freeware text editors out there that support syntax highlighting. I can honestly say that I've never had a problem telling my tags and attributes from my content, and even when I'm not using case-sensitive markup, I never use asinine CAPITAL LETTERS to denote such things. I let my computer do that for me.
Sometimes choice is a good thing, such as when you decide which editor to use or which markup language you support. Sometimes though, it is a badge thing, such as when it leads to inconsistent and even ambiguous coding standards. Count me squarely in the lower-case tags camp.
Ogg is not the only freely available codec, and it didn't fulfill the requirements of all the Web browser vendors. We are still looking into a way to resolve this, though. Everyone agrees that the solution must be royalty free.
DOCTYPES tell a browser how to render content. Provided you use the HTML 4 doctype, your site will still render exactly the same as it did before. If you switch to the HTML 5 doctype, then it will read the document as HTML 5 and omit the redundant tags that have absolutely no place in HTML. It's not CSS's lack of object alignment that you're having difficulty with, it's a browsers lack of implementation of the CSS 2.1 spec. In this case it's IE which really should have been put down some time ago. If you actually use td align and text-align to position elements (you called them "boxes") in IE, you should strongly re-evaluate your occupation because no one with significant knowledge on the subject builds sites like that anymore. If you have similar issues with other browsers than I strongly suggest you read up on quirks mode and start using a doctype. Also check out CSS Zen Garden so you can see what CSS is really capable of.
I'm surprised you don't see much more of it. It's true that XSLT processing is well implemented in FF and IE (I haven't tried others) and almost nobody uses this feature. However I don't think many people would go into trouble of learning XSLT just to be able to compose pieces of a page on the client side.
Web development is not my forte, so excuse any ignorance, but as a user of the web, I have to be interested and curious. Didn't we sort of stumble into an html that eventually became a mishmash of structural and presentational elements and then decide that this was a mistake and split it out into a(n ideally) purely structural html4 and have css for the presentation? But isn't html5 a mishmash of (textual) structual elements and gui applications elements (in essence, a different, not especially textual/document sort of "presentation")?
I mean, isn't this what javascript and whatnot is for - and javascript can be disabled. I understand there are advantages with client-side input validation and so on, but this just seems like a mess to me, and a mess that can't be turned off. Seems like html/css/$app_lang should be the model rather than this html5 with css.
I have an old-fashioned "the web is the global library" textual/document-centric view of the web, so I'm sure I'm missing out on understanding the interactive Web 2.0 applications goodness and I'm just trying to get a handle on what's going on.
My greatest wish in HTML5 is a new password element. One that uses a standard hashing-algorithm with server-supplied salt (optional local pepper could be provided) and prevents the receiving site from ever getting the password that the user actually typed in. E.g.
Here the contents are of the above handled completely by the browser, without the possibility of the site to get access to the contents or record keystrokes (via event handlers like onChange) while in focus. The *submitted* password would then be a hash, with salt provided by the server, of the supersecretpassword.
While not foolproof, it would help immeasurably with password security on the web. Even if no local pepper were added, anyone who gained access to the password database of the server (e.g. the owners), it would force a brute-force attack on the password.
No longer would anyone with access to a password database from a random web server (e.g. forum) be able to access pretty much every other site the users are registered on - because we all know that only rarely does Regular Joe use anything but his one-and-only password. This is especially bad when financial sites are included, but even if it's just gmail/yahoo/hotmail/whatever, that's still plenty bad.
(BTW, all of the above should work even when Javascript is disabled, so you NoScript users get security _AND_ functionality)
http://www.mhall119.com
For the site that do not try to be like an application, html is fine.
for the rest that do try to be like an application, they use css for presentation.
If html says to use css for its markup, then why do we even have html any more?
Are you a part of the group working on the HTML5 spec? If so, I would like to make a suggestion. There are several new elements that will replace css/javascript hacks and libraries, like Menu and the new input types, but I was disappointed to not have any kind of "popup" element. I'm talking about more than just a floating div, an element with a title bar and close button (these could be optional I guess), and is movable and resizable.
There are lots of hacks out there that do this, but it seems like it could be something better done by the rendering engine directly, instead of having javascript libraries keeping z-index stack orders and capturing onmousemove events, which often cause problems like selecting portions of a page while "dragging" a popup.
Was there any discussion of adding such an element into the new spec?
http://www.mhall119.com
USE HOT GRITS WITH STATUE OF NATALIE PORTMAN (NAKED AND PETRIFIED)
(I'm the HTML5 spec's editor.)
What you describe seems more like a stylistic thing than a semantic thing (e.g. it wouldn't really make much sense in a speech browser, as far as I can tell). I recommend suggesting it to the CSS working group.
I think I first read about that theory six years ago at joelonsoftware.
The bulk of html code is styling info, which can be tucked into a common site-wide CSS file and then cached. Moving to HTML + CSS can save you a lot of bandwidth.
W..w..W - Willy Waterloo washes Warren Wiggins who is washing Waldo Woo.
All of that is true. But I have come to believe that perhaps the blame lies primarily with the standards themselves. They are just not very good.
I know this is not a popular opinion. Let me qualify it and try to explain briefly what I mean. There is of course a lot of theoretical and historical background to consider, but frankly it is a waste of time to drag all that into a Slashdot comment.
The first problem is with HTML. HTML abstracts at the wrong level. It should be a presentation language, not a structural markup language. There is no need for HTML as a structural markup language and frankly I am baffled by the religious zeal with which some people defend this notion. As a structural markup language, HTML is very poor. Structural markup is most useful for well-defined, domain-specific applications. That is not what HTML is used for and this causes numerous problems: ill-defined rendering behavior, poor querying and indexing abilities, poor feature set, relatively slow performance, not to mention poor reusability.
The second problem is with CSS. Although at its core a good idea, it is poorly implemented, with a pointlessly weird, C-inspired syntax. It is too feeble to express presentational structure and lacks a method to express generalized context-dependent relationships. The selector language is so baroque that it is poorly understood by authors and implementors alike. Most importantly, CSS simply does not solve many common layout and styling problems, except at the most trivial level. Efforts to address this have mostly just made CSS more complicated rather than more powerful.
The third problem is with Javascript. The language itself is not bad, but it exists in an environment that is so primitive and crude, that often the easiest way to accomplish anything is still to just stuff precalculated strings into a node's innerHTML. The web is littered with the corpses of Javascript libraries to provide simple services like data binding, templating, input validation and widget sets. None of which build on eachother, because there are no tools to enable this kind of workflow, and most of which fail on either correctness, performance or standards-compliance.
Why are there so many problems with these standards? Is it normal for standards to be so problematic? It is certainly true that numerous standards failed. But on the other hand, many other standards succeeded. PostScript and PDF are very successful standards that have been implemented dozens of times with minimal interoperability issues. The same goes for countless file format standards, such as GIF, PNG, JPG and ZIP, or standards such as ASCII or Unicode.
Of course the comparison between HTML (and all related tech) and, say, GIF, is not valid. In the case of HTML there are many reasons, some socio-economic, which have brought us to the point where we are today. But despite that, I believe it is possible to identify 2 key issues with the W3C family of tech:
Well, I tend to cynicism myself at times. But as a web programmer who doesn't desire to upgrade anything, the changes from HTML 4 to HTML 5 look like a nice batch of improvements. It looks like 85+% good stuff, and there is a decent handful of things that I wish we'd had ages ago and I'm bummed I can't start using today.
Just my two cents.
--LP
The following elements are not in HTML 5 because their effect is purely presentational and therefore better handled by CSS:
* basefont
* big
* center
* font (although it is allowed when inserted by a WYSIWYG editor due to limitations in the state of the art in user interface for these editors)
* s
* strike
* tt
* u
I can't see good things happening if they are going to move the effects of these tags to CSS, since this would require one to have CSS on a page. Notepad coders (you know who you are) who like simple, clean, easily manageable pages get a new layer of complexity.
Laughter is the Spackle of the Soul.
Thanks for your feedback hixie, how refreshing to see posts from someone actually knowledgeable on the subject at hand!
I agree with many of the posts, mainly on two points: 1) It's great that the browsers will show pretty much anything no matter how illegal the html, so who cares about a new spec? and 2) HTML5 looks like a great many changes and additions and deletions, to me anyway, and especially seems to strengthen form input fields and overall form usage. It appears to be a much larger creature than the html of the 90's. But I'm definitely behind the times, maybe all this is standard now.
Seems like a real job to me, fwiw.
Maybe someone can answer a question for me. I've looked at TFAs briefly, but from my reading the answer is no.
Q: Will this allow tables that can automagically:
I ask because I've had some amount of frustration with this in the past (and coincidentally in a current project), and it would be great to have an html table be a real first class table, rather than a dumb matrix of string data. Of course I realize my idea of a first class table isn't shared by everyone, but am I really the only one who would want some of these things?
Is the reason I don't see it here because it won't be done, or because it's supposed to be in another spec like the new xhtml or xforms (but I thought xforms is just input)?
On the bright side, I like the fact that the <input> tag gives you more choice of data types now. IMO, things such as this that move common functions into the standard to then be implemented once in the browser only are a Good Thing.
Billy Brown rides on. Yolanda Green bypasses Gary White.
This is so typical. Programmer mentality to the extreme. So much so that is disables functionality and ease of implementation for the cause of trying to separate every inkling of logic from UI. I know it sounds great in theory but a pain in the ass in reality.
I'm sure /. will cause tons of feedback; however, you should contact the working group about your concerns directly if you care about them. I have with the previous versions; although, my influence largely ended up in revisions of the wording.
One battle I'd like to see fought:
Using the OBJECT tag to support text/html file includes. Old browser support for it could be done using browser plug-ins for that MIME type. The intent for this (which I keep promoting with no success) is so you can develop a webpage in a frames-like fashion but have the client side combine it into a single HTML document (ideally having it extract only BODY on the includes.) The difference seems minor but it is HUGE and is how frames should have been handled in the 1st place!
You put your images, css, javascript, etc into external files (if you have any sense) and include them why not be able to include HTML files into your pages as well? Many people use PHP, JSON, AJAX, etc. just to change a section of a page much the same way frames let you do much easier (in general.) I've seen "AJAX" frameworks implemented as if it was a replacement for frames. Frames were a failure but saved so much work and bandwidth they refuse to die. Instead of trying to kill frames each standard, it should be reborn into something sensible and consistent with HTML:
EXTERNAL HTML file includes
Frankly I don't care what tag... just save me the bandwidth and labor of the frame work around! (which BTW, the current solutions increase server load and are less accessible than frames.) Security is no excuse (its a laughable one at that.)
Democracy Now! - uncensored, anti-establishment news
That's just very bad: HTML5 has no place in the XHTML Web. I am not going, ever, to put HTML5 crap on any of my sites.
Great! There go those fast coding tests in Perl where you can just add a Content-type: text/html, HTML, BODY and TITLE tag to get somewhere as output. .. so in which case is this an improvement ?
Now I've got to program in CSS sheets too even when I don't want them
I'm sure there are more people doing the same?
An improvement would fasten up the job, make it easier, not more ackwards to be obligated to do even more steps.
--- I am known for the ones who want to find me on the net. Is that a privacy risk or a privilege? One might wonder..
Finally - someone else who seems to be seeing some sense.
I read through some of the document describing differences between HTML 4 & 5, and my jaw nearly hit the floor. This spec means that at some point in the future I can stop pissing about with Javascript to create basic UI elements, and actually write applications instead.
I'm also looking forward to the video tag, which apparently will recommend ogg/theora as the default format. More open formats on the web sounds like an excellent idea, especially if it can break the stranglehold Flash seems to have on providing (poor quality) video across the web.
I am TheRaven on Soylent News
http://www.mhall119.com
The way I see it: If the programmer can't even be bothered to write code that properly escapes/sanitizes stuff before returning it to the user (or any internal function or db query, FWIW), it's correct for the UA to not display the result. It may as well contain malicious code or whatnot.
Who is General Failure and why is he reading my hard disk?
If your using the style attribute for everything
...
Who said that?
I'm talking about "align=". "style=" was the obvious workaround. There are others, like " ". They all end up bloating the size of the document for no good purpose.
But your scheme of creating a separate style for each table cell won't work for the kinds of situations that align= or style= is typically used for.
The problem is that each class is a separate name. This leads to an exponential explosion in the number of classes you need, and it completely breaks free-standing components.
First, if you have a table that has (say) three different cell styles, and two different data types, you now need to define six classes instead of three. Assuming they're going to remove other attributes like align, and you have (say) two other ways tables can differ, in (say) three ways, you need 54 classes instead of three. And you end up with
Second, when you have software-generated HTML, every place you have to expose details of one components classes to another you get more opportunity for things to break, so it makes sense to have typographic details set separately.
[speechless]
What's next, no more <div> and <span>?
The size bloatedness of tables compared to what?
You think they should make tables with <pre> and little ascii crosses and dashes?
I didn't say *anything* about layout. Tables are also used for, you know, tables...
No, you don't.
http://www.whatwg.org/specs/web-apps/current-work/multipage/section-embedded0.html#the-img That's funny: the colors are set up such that names of elements and attributes look like links to pages that haven't been written yet. Or maybe I'm just a Wikipediholic.
But if you want to get into CSS Zen Garden, and all the trickery you need to do to make CSS layout actually work, well... sheesh.
I've used a variety of applications and tools for doing programatic layout of documents over the years, with a variety of levels of functionality, some good, some bad, and CSS is one of the worst. It seems that the people who designed CSS hadn't any actual experience with more than one tool, if that.
In CSS you only have two layout mechanisms: absolute, with absolute scaling, and relative, with absolute scaling. If you want to create a web page containing three columns, you should be able to do it one of three ways:
(1) Define three elastic containers, and glue them to each other, right side of the first to the left of the second, right of the second to left of the first, and specify some basic constraints on each container. Adding a fourth column, you simply change where they're glued together. It would just happen, you wouldn't need to do a google search and look for a four-column model that's close enough to your existing three column code that it'll mostly work.
(2) Start with the full space, and pack containers into it, starting with one side, with constraints specified as they're packed. Pack the first on the left, the second on the left of the remaining space, and the third on the left of the remaining space. Adding a fourth column, you simply pack it in at the right place. It should just happen, you wouldn't need to do a google search and... oh, I mentioned that already.
(3) Specify a grid, with constraints on the grid, and place the containers in the appropriate parts of the grid.
No, instead, in CSS, you have to go back and readjust all the column widths, mentally allowing for the extra space you need for padding. You have a 4 column model, and you add a column, and it wraps, so you go back and look for the place where the column widths are specified, and reduce them all by about 20%, and then it's a little narrow because you forgot to add a spacer, so you do that, and it wraps again, so you reduce the spacer widths a bit, and it's narrow again,
Here's an example of how onother tool I use does four column layout: Adding another column is obvious, and it just works. Adding more text just works. Padding is an attribute of the layout, not extra invisible objects.
This is already more powerful than CSS, but sometimes it's not enough, so there's a third layout manager, the grid layout manager. Because sometimes you really do need to specify the layout in rows and columns like a table, which is why people still use tables for layout.
The only thing I'd like to add would be the idea of "space", so that you could have a space spread over two or more containers (frames) and have the content flow from one to the next when it fills up.
I'll make you a deal: you talk to the W3C and get them to drop this completely and utterly bass-ackward broken idea of creating new non-XML flavors of HTML, and I'll talk to the XML folks about dropping the DOCTYPE requirement.
Tell me you're not serious about W3C creating any new non-XML based versions of HTML!!! At least I assume they'll be smart enough not to create any non-namespaced ones.... When you go into a site that's still using 1997-or-earlier non-namespaced versions of HTML it's almost impossible to fix their HTML code - and cost-prohibitive to them... in most cases it's just as costly as rewriting the whole site, and so they just keep trying to "fix" the old code.When the HTML code is namespaced () it's a simple matter of adding an "xml-stylesheet" processing instruction - and much, much less costly.
Wish I could. Check this out:
From 8.1.2.3. Attributes:
And don't forget:
From 8.1.2.4. Optional tags:
So yes, right now, today, in 2008, people are seriously discussing rolling out another non-XML HMTL spec.
At least I assume they'll be smart enough not to create any non-namespaced ones....I direct you to 8.3. Namespaces:
I hope that's sufficient.
Dewey, what part of this looks like authorities should be involved?