Haven't you heard of spacetime granularity? The real world only has a framerate of about 18500000000000000000000000000000000000000000Hz. You'll have to buy a newer model universe if you want truly want infinite.
The point is that Firefox, Safari, and Opera will all have implementations within a few years, and there is a library being made that an author can include in the page to make IE work. So implementation won't be a problem for long.
There's also the use case of people who wouldn't bother with client-side validation in the first place, but will with WF2. After all, typing <input type='email'> is just as hard as easy as typing <input type='text'>, and will fall back to a normal text input in older browsers. Nothing lost, some gained.
Okay. So design that standard. Seeing as you have prior knowledge of what works well and what doesn't ('cause you've seen the successes and failures of current web languages), we'll give you 10 years--a little less than what current bodies have taken so far.
Only caveat? It has to be good. It has to include any feature there's significant market demand for. (No, you don't get to find out ahead of time what market demand's going to be. That would be cheating.) It has to scale well. It has to be easy to author and easy to implement.
And by your own request, once the time's up you can make no more changes at all.
...or we could just keep on the current track. Revising things as market demand changes, as new things are invented. I think I like that plan better.
As a side note, you're obviously not familiar with CSS's versioning. Anything that worked in CSS 1 worked identically in CSS 2, and anything that worked in CSS 2 will work identically in CSS 3 (with a few exceptions where the spec was bad and the browsers did something different, so the new spec standardized on what browsers already did). Simliarly, WHATWG's Web Forms 2 (and where it makes sense, WA1) are being designed to fall back gracefully to what HTML 4 already does. Anything made for WF2 will still work in an HTML 4 browser (and in IE), just without WF2's special features.
Re:Everything since HTML has been too complex
on
The Future of HTML
·
· Score: 4, Insightful
No.
The only reason "a child could do" HTML is that it doesn't matter if they screw it up, the browser will still display things, and do a pretty good approximation of what they want. With XML, one misplaced & or < kills the whole page, and plenty of people who use it professionally still mess up, especially in dynamic environments, and especially when outside content is being used, like allowing comments.
A child, you'll find, can also do CSS. It takes a small bit of tutorial, and a lot of looking things up or asking around or copying and pasting when they need to do something, but they do it, and it works. This is because CSS has well-defined error handling. The spec says what to do in (nearly) every situation, so all browsers do it the same way, and it's not draconian--one mistake only kills the rule you're working with.
CSS hasn't "standardized across browsers", because the largest-marketshare browser hasn't been updated in 7 years, since around the time CSS 2 first came out. In all modern browsers, all but the most obscure and least tested features of CSS render the same.
Decent overview of WHATWG
on
The Future of HTML
·
· Score: 4, Interesting
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".
Seigenthaler is not sufficiently notable to have been on many peoples' watchlists, whatever he may or may not have done 40 years ago; if the Christina Aguilera article had been vandalised it would have been noticed and reverted in minutes.
...Or any of the math articles, or most of the science articles, or anything people actually looked at, or etc. etc. etc.. Vandalism like this is limited to things that no one cares about, and this guy fits squarely in that category.
Would be interesting to see the page hits for the article; it'd be kind of disheartening to see that more people looked up, say, Lebesgue Integration on any given day than you in 4 months.
Burning edge hasn't updated, but from my own trawlings through bonsai, the following checkins were made:
Bug 313335 Update the URL bar before showing security warnings r+sr=jag a=asa
Fix bug 316025 -- no need to create a wrapper on plugin teardown if we don't have one already. r+sr=jst, a=mscott
Bug #315189 --> Loading this url crashes [@ nsHTMLDocument::MatchLinks] Camino and Firefox Fix a probme with inline style rules on innerDiv elements that was breaking Yahoo! webmail. patch by bz r/sr=jst a=me
bug 316674, compare-locales should support reasonable numbers of ordered search engines, r=gandalf, sr=bsmedberg, a=mscott,chase
The end user visible ones would be the first, second, and third.
For those wondering why this is called Firefox 1.5 and not Firefox 1.5 RC2, it's because this is a genuine release candidate. The build you have, if no problems are found, will be Firefox 1.5. If we called it RC2 in the actual client, it wouldn't be a real release candidate because we'd have to make changes to the name and then create new builds.
What are you talking about? We just got our third sewer put in last week! And the great part is, when one of them's having a sale you just head down to the basement, put on a gas mask, and redo the piping, and you're all set!
Here's an idea: patent the process of failing to get a patent approved. Then give a royalty-free, non-revocable license to use it to everyone except, say, your friend John. It's now illegal for him to not get patents approved, so he sends in anything he can think of and it gets fast-tracked on through. Instant money....Yeah, it wouldn't work. But it could probably be adapted to work. Any ideas?
Hmm... that slow script dialog is supposed to come up after 5 seconds. Some of the devs have actually been doing/thinking about doing things to change that dialog, so they'd probably be interested to hear about your case. You should file a bug, the sooner the better.
This crash wasn't a buffer overflow, though, it was (according to the bug, I don't really know what it means) a stack overflow. And it wasn't exploitable.
The "pumping in loads of data" that you mention I assume is fuzz testing.
First off, I want to say that most (not all, I'll get to them) of your points are valid. However, you probably fall under Appendix B of that document: You're advanced enough to know what you're doing and how to solve all the problems you'd encounter moving to XHTML. The document is targeted at people who aren't that advanced--people who are likely to copy and paste their code from other sites, people who claim something's XHTML when it's not even well-formed (but it still displays in browsers because it's sent with a text/html mime type), or people slightly more advanced than that, but who will be hit by certain problems switching to XHTML as XML and won't know what to do.
(If I don't reply to a point, I agree for you, but not for normal authors.)
I can't remember ever seeing a non-contrived case where the first was an issue.
You left out part of your quote: "The <body> element is not magical in XHTML." What this means is that body{background:...;} in XHTML only applies to the actual body, where in HTML it applied to the entire canvas. Plenty of people have trouble grasping this fact (bugzilla gets "bugs" on this relatively often) and some go even farther:
Web developers are going to hate W3C for this, and it's going to make
the transition to an xml based internet more difficult. The arguments
for such a radical new approach better be good or the new approach will
help undermine the authority of the W3C.
* Current UAs are, for text/html content, HTML4 user agents (at best) and certainly not XHTML user agents. Therefore if you send them XHTML you are sending them content in a language which is not native to them, and instead relying on their error handling. Since this is not defined in any specification, it may vary from one user agent to the other.
And this is different from sending your document as HTML 4 how?
If you send valid HTML4, everything is defined, and there is an exact, specific way it should be parsed. If you send XHTML as text/html, it is parsed as HTML. However, it is not valid HTML. Because HTML does not have well-defined error handling, two browsers could do different things with your document and still both be correct. In most cases they act the same (they have to emulate IE an anything with significant usage), but in many edge cases these differences show up.
To end, I'll summarize the document. You can't use true XHTML unless you don't care about IE. Unless you really know your stuff, XHTML as HTML will just confuse you and give you wrong impressions about true XHTML. XHTML as HTML has no advantages over HTML. Therefore, most people should use HTML.
Why bother with PHP? Just use content negotiation in Apache. Just point your users to pages without a.html extension (you should be doing that anyway, more future proof and more correct as what a URI is supposed to be). Then, server side, have the main page be named whatever.xhtml, and symlink whatever.html to it. Or vice versa, if you prefer.
That's what I do on my site. Some of the pages, anyway. Some of them I just don't bother, and let IE be locked out. Not much of a problem, my target audience doesn't use IE anyway.
(If you're already using PHP to modify HTTP accept headers, though, you might as well keep using it.)
Um, no. Amaya is not the standard. It's an implementation of the standard, and like every other implementation is buggy, incomplete, and imperfect. In fact, I believe the last time I saw a comparison, both Gecko (Mozilla/Firefox) and Opera had better support for CSS (don't know about KHTML/Safari).
And you please read the bit above that: Response to some reader notes. The grandparent was posted before it was responded to (that's generally the way time works in this universe).
Read that again, there is a </b>, it's just two lines down. And neither b nor strong is deprecated (though b should be, IMO...), though you're right that mixing them like that is a little odd, to say the least. Probably leftovers from some story posting UI or something.
I was on irc.mozilla.org at the time, watching the conversation. It was immediate. The article may be referring to the time between placement and discovery, or else it's just wrong.
Slashdot Mirror
Haven't you heard of spacetime granularity? The real world only has a framerate of about 18500000000000000000000000000000000000000000Hz. You'll have to buy a newer model universe if you want truly want infinite.
The point is that Firefox, Safari, and Opera will all have implementations within a few years, and there is a library being made that an author can include in the page to make IE work. So implementation won't be a problem for long.
There's also the use case of people who wouldn't bother with client-side validation in the first place, but will with WF2. After all, typing <input type='email'> is just as hard as easy as typing <input type='text'>, and will fall back to a normal text input in older browsers. Nothing lost, some gained.
SVG has support for it, and it's not even a programming language.
Of course, one could argue whether that's a good thing or not...
Okay. So design that standard. Seeing as you have prior knowledge of what works well and what doesn't ('cause you've seen the successes and failures of current web languages), we'll give you 10 years--a little less than what current bodies have taken so far.
Only caveat? It has to be good. It has to include any feature there's significant market demand for. (No, you don't get to find out ahead of time what market demand's going to be. That would be cheating.) It has to scale well. It has to be easy to author and easy to implement.
And by your own request, once the time's up you can make no more changes at all.
...or we could just keep on the current track. Revising things as market demand changes, as new things are invented. I think I like that plan better.
As a side note, you're obviously not familiar with CSS's versioning. Anything that worked in CSS 1 worked identically in CSS 2, and anything that worked in CSS 2 will work identically in CSS 3 (with a few exceptions where the spec was bad and the browsers did something different, so the new spec standardized on what browsers already did). Simliarly, WHATWG's Web Forms 2 (and where it makes sense, WA1) are being designed to fall back gracefully to what HTML 4 already does. Anything made for WF2 will still work in an HTML 4 browser (and in IE), just without WF2's special features.
No.
The only reason "a child could do" HTML is that it doesn't matter if they screw it up, the browser will still display things, and do a pretty good approximation of what they want. With XML, one misplaced & or < kills the whole page, and plenty of people who use it professionally still mess up, especially in dynamic environments, and especially when outside content is being used, like allowing comments.
A child, you'll find, can also do CSS. It takes a small bit of tutorial, and a lot of looking things up or asking around or copying and pasting when they need to do something, but they do it, and it works. This is because CSS has well-defined error handling. The spec says what to do in (nearly) every situation, so all browsers do it the same way, and it's not draconian--one mistake only kills the rule you're working with.
CSS hasn't "standardized across browsers", because the largest-marketshare browser hasn't been updated in 7 years, since around the time CSS 2 first came out. In all modern browsers, all but the most obscure and least tested features of CSS render the same.
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".
...Or any of the math articles, or most of the science articles, or anything people actually looked at, or etc. etc. etc.. Vandalism like this is limited to things that no one cares about, and this guy fits squarely in that category.
Would be interesting to see the page hits for the article; it'd be kind of disheartening to see that more people looked up, say, Lebesgue Integration on any given day than you in 4 months.
I think they're turning off the new XBox,too.
Burning edge hasn't updated, but from my own trawlings through bonsai, the following checkins were made:
The end user visible ones would be the first, second, and third.
Or "People are actually trying to do work there, and they can't if the server's down".
To quote Asa Dotzler,
...which is completely irrelevant, as what's in question here is accessibility.
What are you talking about? We just got our third sewer put in last week! And the great part is, when one of them's having a sale you just head down to the basement, put on a gas mask, and redo the piping, and you're all set!
To me it reads like a 2*2*3 matrix of choices. Yes/no, yes/no, yes/no/partly. Leaving the no/no/no option out just seems weird, unbalanced.
Here's an idea: patent the process of failing to get a patent approved. Then give a royalty-free, non-revocable license to use it to everyone except, say, your friend John. It's now illegal for him to not get patents approved, so he sends in anything he can think of and it gets fast-tracked on through. Instant money. ...Yeah, it wouldn't work. But it could probably be adapted to work. Any ideas?
Hmm... that slow script dialog is supposed to come up after 5 seconds. Some of the devs have actually been doing/thinking about doing things to change that dialog, so they'd probably be interested to hear about your case. You should file a bug, the sooner the better.
This crash wasn't a buffer overflow, though, it was (according to the bug, I don't really know what it means) a stack overflow. And it wasn't exploitable.
The "pumping in loads of data" that you mention I assume is fuzz testing.
First off, I want to say that most (not all, I'll get to them) of your points are valid. However, you probably fall under Appendix B of that document: You're advanced enough to know what you're doing and how to solve all the problems you'd encounter moving to XHTML. The document is targeted at people who aren't that advanced--people who are likely to copy and paste their code from other sites, people who claim something's XHTML when it's not even well-formed (but it still displays in browsers because it's sent with a text/html mime type), or people slightly more advanced than that, but who will be hit by certain problems switching to XHTML as XML and won't know what to do.
(If I don't reply to a point, I agree for you, but not for normal authors.)
You left out part of your quote: "The <body> element is not magical in XHTML." What this means is that body{background:...;} in XHTML only applies to the actual body, where in HTML it applied to the entire canvas. Plenty of people have trouble grasping this fact (bugzilla gets "bugs" on this relatively often) and some go even farther:
If you send valid HTML4, everything is defined, and there is an exact, specific way it should be parsed. If you send XHTML as text/html, it is parsed as HTML. However, it is not valid HTML. Because HTML does not have well-defined error handling, two browsers could do different things with your document and still both be correct. In most cases they act the same (they have to emulate IE an anything with significant usage), but in many edge cases these differences show up.
To end, I'll summarize the document. You can't use true XHTML unless you don't care about IE. Unless you really know your stuff, XHTML as HTML will just confuse you and give you wrong impressions about true XHTML. XHTML as HTML has no advantages over HTML. Therefore, most people should use HTML.
Why bother with PHP? Just use content negotiation in Apache. Just point your users to pages without a .html extension (you should be doing that anyway, more future proof and more correct as what a URI is supposed to be). Then, server side, have the main page be named whatever.xhtml, and symlink whatever.html to it. Or vice versa, if you prefer.
That's what I do on my site. Some of the pages, anyway. Some of them I just don't bother, and let IE be locked out. Not much of a problem, my target audience doesn't use IE anyway.
(If you're already using PHP to modify HTTP accept headers, though, you might as well keep using it.)
Um, no. Amaya is not the standard. It's an implementation of the standard, and like every other implementation is buggy, incomplete, and imperfect. In fact, I believe the last time I saw a comparison, both Gecko (Mozilla/Firefox) and Opera had better support for CSS (don't know about KHTML/Safari).
You don't need an extension for that, you can just put it in userContent.css.
@-moz-document domain(slashdot.org){rules here)
...Though I suppose you could package it as an extension to make it easier to install.
And you please read the bit above that: Response to some reader notes. The grandparent was posted before it was responded to (that's generally the way time works in this universe).
Read that again, there is a </b>, it's just two lines down. And neither b nor strong is deprecated (though b should be, IMO...), though you're right that mixing them like that is a little odd, to say the least. Probably leftovers from some story posting UI or something.
Because.
I was on irc.mozilla.org at the time, watching the conversation. It was immediate. The article may be referring to the time between placement and discovery, or else it's just wrong.