Slashdot Mirror


Stop Standardizing HTML

pfignaux writes with an interesting view on the place of centralized standardization in modern browsers. From the article: "When HTML first appeared, it offered a coherent if limited vocabulary for sharing content on the newly created World Wide Web. Today, after HTML has handed off most of its actual work to other specifications, it's time to stop worrying about this central core and let developers choose their own markup vocabularies and processing." Instead, the author proposes that CSS, Javascript+DOM, the W3C's accessibility framework, and Web Components are sufficient to implement the rendering of smaller, domain-specific markups.

302 comments

  1. Nope by Anonymous Coward · · Score: 5, Informative

    How about "no"?

    1. Re: Nope by Anonymous Coward · · Score: 0

      Agreed, this guy is a whiner.

    2. Re: Nope by Pseudonym+Authority · · Score: 5, Funny

      He seemed to me like a proponent of XML. I hope he catches the flu.

    3. Re:Nope by poetmatt · · Score: 4, Informative

      close enough standards compliance?

      please. Microsoft tries to break standards by introducing their own. Don't blame HTML for that.

    4. Re: Nope by arfonrg · · Score: 1

      If I had mod points, you would get one!

      --
      Your thin skin doesn't make me a troll
    5. Re: Nope by simonstl · · Score: 2

      I've had the flu before, but you may be happy that I'm telling XML people similar things: put down the schemas...

    6. Re:Nope by cjjjer · · Score: 3, Interesting

      Since Google is forking Webkit I suspect that they will be doing the same thing in the near future or have not already to make their services work better in the browser.

    7. Re: Nope by Nerdfest · · Score: 4, Funny

      A flu? Have they been updating the moderation capabilities again?

    8. Re: Nope by hendridm · · Score: 2

      "His books include XML: A Primer, XML Elements of Style, Cookies, Office 2003 XML, and the XML Pocket Reference."

    9. Re:Nope by Nerdfest · · Score: 1

      As it's in Google and Opera's interest to have an open web, I'd have a closer look at people using the un-forked WebKit as being more likely to not play nice. I'm really hoping everyone keeps working together though. The 'defacto standard' approach seems to be working relatively well so far.

    10. Re: Nope by LifesABeach · · Score: 1

      I RTFA, (ya, I know). No support data, why?

      I can't help but wonder how much he was paid for his, "insight?"

    11. Re:Nope by LifesABeach · · Score: 2

      I've seen results of Close Source, and Open Souce. In actual practice, the champions of Closed Source have very short term goals.

    12. Re: Nope by sribe · · Score: 3, Funny

      He seemed to me like a proponent of XML. I hope he catches the flu.

      X7ML9?

    13. Re:Nope by SuperDre · · Score: 2

      Uhm.. the reason Google want to fork is also because they want more control over it, and it's Google who is trying to push their formats down our throats instead of using already available 'standards'.
      Also let's not forget at the moment that 'HTML5' is still in development (it's still not finalized), yet it's used in production now which ofcourse is actually a fubar thing to do..

    14. Re:Nope by Nerdfest · · Score: 1

      Both branches are still open-source. Have a look at what the commiter of the un-forked webkit has done with XMPP (iMessage), SIP (FaceTime), eBub (iBooks) to see how they feel about open standards. I think having another branch will be a good thing, if only for a little friendly competition.

    15. Re: Nope by K.+S.+Kyosuke · · Score: 3, Funny

      "His books include XML: A Primer, XML Elements of Style, Cookies, Office 2003 XML, and the XML Pocket Reference."

      This is what people who never encounter S-expressions early in their life end up doing. :-( Parenthetical vaccination would prevent him from developing a cancer of the angled brackets.

      --
      Ezekiel 23:20
    16. Re:Nope by jc42 · · Score: 1

      [L]et's not forget at the moment that 'HTML5' is still in development (it's still not finalized), yet it's used in production now which ofcourse is actually a fubar thing to do..

      Well, maybe, but not as fubar as trying to be compliant with all the various HTML "standards", including XHTML and MSHTML and iHTML and XML and ... ;-)

      Anyway, I'd expect that HTML5 is following google's lead, and will be in Beta until all of us have shuffled off this mortal plane. It worked for google; it'll probably work for HTML5.

      And so far, I've found that switching to HTML5 produces better compatibility than any other HTML version that various organizations and corporations have declared "standard". There are the usual insanities of trying to make pages work on MS browsers, of course, but if you're reasonable about dragging your feet WRT the newer HTML5 features, you tend to find that your pages work reasonably well with all the common browsers except IE6. (Well, OK -- and except for Safari on the iPhone. ;-)

      Basically, the HTML5 gang has done a fairly good job of figuring out ways to thumb our noses at the corporate powers who are constantly trying to throw monkey wrenches into the Web's inner workings. Going with the HTML5 approach, and encouraging them to keep up the good work, is a feasible strategy to make things work about as well as we can expect in an environment of government and corporate sabotage attempts.

      --
      Those who do study history are doomed to stand helplessly by while everyone else repeats it.
    17. Re:Nope by Anonymous Coward · · Score: 0

      Im probably naive and optimistic, but the proponents of the open web seems to have long term goals.

      I do not think of Google as an idealistic open source contributor, but they have done very well championing the open web.

    18. Re:Nope by spleendamage · · Score: 1

      Is this reply comment blinking?

    19. Re:Nope by Anonymous Coward · · Score: 0

      HTML5 never will be "finalized," since it's not a W3C recommendation. The whole idea is that it will be a living, evolving standard, with various features being adopted piecemeal in browsers. In other words, it will always be in development and there will never be an "HTML6."

    20. Re:Nope by Algae_94 · · Score: 1

      That's because the finalization of HTML5 is going at a glacial pace. Seriously, what are they doing?

    21. Re:Nope by SuperDre · · Score: 1

      And that's because they are still working out the details of what vendor-prefixed options should become a standard.. but even then, we're still stuck with the vendor-prefix options that are already available, making it the same crap as before where you have to keep in mind what browser you are targeting, and that's not what a good standard is about.. And Chrome/Opera/FF/Safari/IE all have their quircks, there is NO good browser which really sticks to the already set parts of the HTML5 standard (except from what I hear IE10).

    22. Re: Nope by bbsalem · · Score: 1

      But then he will talk with a Lisp?

    23. Re:Nope by bbsalem · · Score: 1

      Shhh.. if HTML5 is truly backward compatible with XHTML than you can code your own ad-hoc XML without a DTD. I did this for shits and grins once, and styled the XML. The browser didn't care. It didn't care if I mixed HTML and XML either. I don't know how strictly HTML5 can enforce its own data definition, but I'll bet you could code your own well-formed XML.

    24. Re:Nope by Anonymous Coward · · Score: 0

      Does this font make my ass look big?

    25. Re:Nope by anyanka · · Score: 1

      Also let's not forget at the moment that 'HTML5' is still in development (it's still not finalized), yet it's used in production now which ofcourse is actually a fubar thing to do..

      Well, you wouldn't want to finalize a standard that's never been tested in the real world, would you? Standardizing on something that isn't already in widespread use might very well lead to the same mess of vendor extensions, incompatibilities and poor compliance that got us into this situation in the first place.

  2. language by schneidafunk · · Score: 5, Insightful

    There is also a benefit to having people share a common vocabulary, such as communication in broader languages like English, Spanish, etc. I have a hard enough time communicating with people in the same language!

    --
    Some people die at 25 and aren't buried until 75. -Benjamin Franklin
    1. Re:language by gl4ss · · Score: 1

      well yeah, but standardizing html was always a fantasy.

      like, they're playing catch up with the standardizing anyways and arguably it has been proven that browser manufacturers do what the hell(what a product they have in the pipeline depends on!) they want anyways - including google and apple.

      --
      world was created 5 seconds before this post as it is.
    2. Re:language by simonstl · · Score: 1

      Part of the headache is that they're designing during the standardizing process, making their best guesses at what might work.

      Part of what I hope might come from this approach is that many people can try a variety things, and then standards can catch up to what actually worked. Browser vendors have sort of done that, but their experiments tend to have much larger consequences.

    3. Re:language by BForrester · · Score: 5, Funny

      You're overstating the meerfage of sharing a common briogib. As long as the sufrabork is cognatious, the central mordage doesn't need to be the same.

    4. Re:language by Bacon+Bits · · Score: 1

      Using words I recognize as nonsense isn't the sole problem. It's vocabulary collisions. What if I meant the exact same thing you did, but write it like this:

      There is also a benefit to having people share a common vocabulary, such as communication in broader languages like English, Spanish, etc. I have a hard enough time communicating with people in the same language!

      You're overstating the power of sharing a common rudder. As long as the mast is forestayed, the central keel doesn't need to be the same.

      Now you: a) can't use the context of the message you responded to (which is where we as the reader got the meaning), and b) you have no idea what I'm actually trying to say. Am I really talking about the construction of language, or the construction of a ship? If it's the former, well, I don't really understand what's being said, and if it's the latter, well, what was said still doesn't entirely make any sense. Yes, you can arrange words like that, and it's possible that might mean something in the correct conversation, but you've no idea what.

      Languages do work without strict oversight. English, for example, has no regulation at all. This is somewhat unusual, especially considering English's popularity. However, English is also notoriously difficult to learn and notoriously difficult to use correctly. The rules are contradictory and inconsistent, partially because it bastardizes so many words from other languages. English, but like the country it comes from, is part Scottish/Gaelic, part Welsh/Gaelic, part Norse, part Germanic, part French, and part Latin.

      Come to think of it, English is just as badly abused as web design: HTML, CSS, JavaScript, AJAX, JSON, XML plus all the media content types, plus back end technologies for dynamic sites like PHP, ASP, Ruby, Python, Perl, XSLT running on lighttpd, apache, IIS, nginx and databases like SQLite, MySQL, PostgreSQL, MS SQL Server, Oracle and so on. The web is made up of 10,000 different technologies all doing different things toward the same end. It's a huge pain in the ass already, to be honest. Making it worse by removing the base stability of HTML seems like people deciding that directly verbing nouns should replace more appropriate verbs.

      --
      The road to tyranny has always been paved with claims of necessity.
    5. Re:language by Freultwah · · Score: 1

      English difficult to use correctly? Well, yes, it is rife with all kinds of exceptions and traditions that throw you out of kilter (for instance, why would I omit the definite article in front of ‘kilter’?). English difficult to learn? No, sir. Memorising the 1000 basic words and spouting them out in almost the right order for somebody else to understand is not difficult at all. I myself was able to converse in a semi-meaningful way in about six months since I started to learn it.

    6. Re:language by fast+turtle · · Score: 1

      The problem with English is that it's borrowed words from so many different languages that the spelling rules are attrocious. As to learning to speak the language, with a meager 33 sounds (diph tongs) it's actually one of the easiest to learn unlike any of the tonal (mandarin, cantonese, japanese, swahili) to name just a few of them. It's this limited sounds that makes it very easy to learn to speak.

      Too reelee understand the problem, U need too look at english foenetically. Keep en mind that it brakes all of the rules spelling it as it sownds.

      Screws up your parsing of what I wrote doesn't it. Only thing is, it's phonetically correct. Look again and sound it out. It just might make enough sense to simply toss out the damn spelling rules and base the spelling on actual pronunciation even if it causes many of us to pull our hair out.

      --
      Mod me up/Mod me down: I wont frown as I've no crown
    7. Re:language by TheSeatOfMyPants · · Score: 1

      The metaphor goes even further: HTML was modeled after HyperCard, which was designed as a programming language geeks & non-geeks alike could use at their respective ability levels -- newbies/non-geeks could quickly learn to code the equivalent of a hand-written personal website (linked text+multimedia) while experts/geeks made professional standalone applications like today's major shopping sites or (literally) Myst. While HTML can't easily be used to hand-write a "good" site anymore, it's still very possible for a regular user to rapidly learn the basics, making it still on some level be a "language" potentially common among human beings, rather than being specific to the subset that are inclined towards programming.

      --
      Now mostly at Usenet:comp.misc & SoylentNews.org (it's made of people!)
    8. Re:language by Sigg3.net · · Score: 2

      Standards don't lead, development does. However, standards provide guides for how that development is carried through, resulting in greater adoption of them by new developers and a common goal among competing or conflicting interests.

      A dictionary is never at the forefront of development, but is it fair to say dictionaries are useless?

    9. Re:language by david.given · · Score: 1

      Using words I recognize as nonsense isn't the sole problem. It's vocabulary collisions.

      I had precisely this problem the other day, when talking to someone about DVCSes. It took about five minutes (of face-to-face conversation, mind; five minutes is a lot) to figure out that git and hg use the word 'revert' to refer to fundamentally different operations.

      It would have been less confusing if he'd just said 'I don't know what that word means'. It was the fact that he thought he knew what I meant, but didn't, which was causing the problems...

    10. Re:language by Anonymous Coward · · Score: 0

      I reported this comment as being innapropriate... ly funny.

  3. Yes, by all means! by clem · · Score: 4, Funny

    Stop making our job skills transferable!

    --
    Your courageous and selfless spelling corrections have made me a better person.
  4. Javascript by Anonymous Coward · · Score: 0, Offtopic

    I hope there's a special place in Hell for the folks in invented and promoted Javascript.

    Yeah, yeah, yeah, I know use NoSript. Unfortunately, my bank's, broker's, credit union's etc ... websites are unusable without it. And in today's day and age, the web is the only way to do most things now.

    1. Re:Javascript by GrumpySteen · · Score: 2

      This isn't some huge problem that hasn't been resolved. Whitelist the sites that actually need it and leave Javascript disabled for all other sites. It's not difficult and it takes only a few moments to do it and reload a site when you need it.

      Of course that would require a few minutes of work on your part and you seem to be too busy whining to do it.

    2. Re:Javascript by Pseudonym+Authority · · Score: 1

      Then enable Javascript then and stop bitching. You can even block scripts selectively these days! No one is out to get you, and if you stop using IE6, there won't be nasty code ready to install you a new botnet either.

    3. Re:Javascript by wiredlogic · · Score: 1

      Unfortunately, my bank's, broker's, credit union's etc ... websites are unusable without it

      Then use NoScript and temporarily allow those sites when you need to use them. Or just permanently whitelist them since your are screwed anyway if your banking sites have been compromised with malware.

      --
      I am becoming gerund, destroyer of verbs.
    4. Re:Javascript by Anonymous Coward · · Score: 0

      What makes JavaScript terrible isn't the user side...as others have pointed out, just whitelist the sites you need to allow to use it and be done with it.

      What makes it terrible is that it's the only option available. So when you need to do something dynamic on the client side, you're forced to use it. You can tell it's terrible just by the number of times people have tried to write something that allows you to program in some other language and compile to JavaScript. JavaScript, the rest of it (the diff between JavaScript and JavaScript, the good parts) is just too big.

    5. Re:Javascript by Khyber · · Score: 1

      " Whitelist the sites that actually need it and leave Javascript disabled for all other sites."

      Until, you know, some idiot bank goes lax in their security, and suddenly everyone visiting the bank not only gets their accounts hijacked and drained, but they become part of a botnet, all without their knowledge. And because people trust the bank (stupid) they don't even bother to think about it until it's too late.

      "Of course that would require a few minutes of work on your part and you seem to be too busy whining to do it."

      Seems like you're too short-sighted to even be participating in this conversation.

      --
      Still waiting on Serviscope_minor to wake up to fucking reality and realize that Jessica Price isn't going to fuck him.
    6. Re:Javascript by Arker · · Score: 1

      Of course that is possible, but far more likely what would happen is that the bank server wasnt serving out the malware directly, but had only been altered to inject references to code on other servers, dedicated to adware/malware themselves.

      The typical, braindead browser would get infected anyway. A more sanely configured, noscript-enabled browser would silently avoid the malware.

      Dont think anyone is pretending that is bulletproof but it's a good security layer and there is just no reason to skip it.

      --
      =-=-=-=-=-=-=-=-=-=-=-=-=-=-
      Friends don't let friends enable ecmascript.
    7. Re:Javascript by Khyber · · Score: 1

      You know what's a better layer of security?

      Not having Javascript at ALL.

      Gone are the days of standardized common gateway interfaces. Gone are the days of inherently more secure by simplicity web design. Now it's so much constantly updating and broken shit that security is nothing more than a joke in the first place. Flash and JavaScript are the top causes of malware infection and transmission. They need to be shut down permanently.

      --
      Still waiting on Serviscope_minor to wake up to fucking reality and realize that Jessica Price isn't going to fuck him.
    8. Re:Javascript by Anonymous Coward · · Score: 0

      Not sure what your point is here. You can run all javascript, no javascipt, or just run it on whitelisted sites. If you are concerned that a whitelisted site may be compromised in the future, I suggest you don't run any javascript. In that case, you can either find businesses that don't require javascript on their sites, or stop using the web for those types of tasks.

      Otherwise, you are just whining about people implementing sites with javascript.

    9. Re:Javascript by Khyber · · Score: 1

      " In that case, you can either find businesses that don't require javascript on their sites, or stop using the web for those types of tasks."

      Impossible and impossible again, for both statements.

      --
      Still waiting on Serviscope_minor to wake up to fucking reality and realize that Jessica Price isn't going to fuck him.
    10. Re:Javascript by Kielistic · · Score: 1

      So you honestly want the web to be a static, non-interactive system? I hope you know how much of a minority you are and understand the web wouldn't be where it is today without JavaScript.

      I want JavaScript to die but I want it to be replaced with a properly engineered language. I do not want a static internet and I'd say a high 90% of people agree.

    11. Re:Javascript by Khyber · · Score: 1

      "So you honestly want the web to be a static, non-interactive system?"

      I see you've never heard of a common gateway interface. This is how we used to interact with the internet, for live chats, forums, picture posting, and more, including 'interactive' sites.

      "I hope you know how much of a minority you are"

      Not very much of one, when you only count the people educated enough to know what they're talking about.

      "and understand the web wouldn't be where it is today without JavaScript."

      You mean to say, that without Javascript, the web wouldn't be the currently steaming pile of shit that heaps ads, malware, and hides content from me until I either pay or allow them to bombard me with advertisements, that it already is?

      Well then, not only does JavaScript need to go away, but every person that was responsible for its invention should be killed as well.

      --
      Still waiting on Serviscope_minor to wake up to fucking reality and realize that Jessica Price isn't going to fuck him.
    12. Re:Javascript by Arker · · Score: 1

      He's foaming at the mouth a little, but he's not entirely wrong.

      The web has been changing rapidly, and mostly for the worse.

      Javascript adds some minor convenience at a large cost in security and making parsing harder and so forth. There are cases where it's a good tool for the job, but they are rare. I constantly see it misused and abused. Slashdot, as an example, is almost completely unusable without disabling javascript. And yes, we had plenty interactivity long before the currently fashionable buzzwords were invented.

      --
      =-=-=-=-=-=-=-=-=-=-=-=-=-=-
      Friends don't let friends enable ecmascript.
    13. Re:Javascript by Medievalist · · Score: 1

      "So you honestly want the web to be a static, non-interactive system?"

      I see you've never heard of a common gateway interface. This is how we used to interact with the internet, for live chats, forums, picture posting, and more, including 'interactive' sites.

      .cgi didn't scale to facebook, amazon, etc. because we didn't have the hardware yet. ECMAscript, oh excuse me javascript was a kludge that was necessary at the time. Sort of like cookies.

    14. Re:Javascript by Kielistic · · Score: 1

      Not very much of one, when you only count the people educated enough to know what they're talking about.

      No true Scotsman fallacy.

      The masses want an interactive web. As do I and I know what I'm talking about (or do I not because I disagree with you?) Do you think we would be enjoying all the benefits of the web today and high bandwidth connections if we never made it past newsgroups and Gopher? No, the web exploded because we could use it for everything. Largely based on the fact that we kludged a bunch of crap together to make it work. Networks were malware infested long before Javascript.

    15. Re:Javascript by Kielistic · · Score: 1

      Slashdot is perfectly usable with Javascript- I do it every day. Should I really have to re-download/re-parse and re-display all X hundred comments so that I can post one? Absurd.

      Javascript is not a minor convenience it is a huge one. Why should I have to make a full post-back for every little change to the interface? What a waste of time and bandwidth. Without client side scripting there is no smooth user experience.

      All these people that want to get rid of interactivity of web apps sound more like stubborn old people that are angry because their car stereo has too many buttons now. There's no real rational it's just different and you don't like it. You all talk about how great the web was way back when. No ads blah blah blah. But you're wrong- the web sucked compared to today. You couldn't do half the things we take for granted today.

      Client side scripting needs to stay. But I'd prefer Javascript to be replaced; it's a terrible language.

    16. Re:Javascript by Anonymous Coward · · Score: 0

      This isn't some huge problem that hasn't been resolved. Whitelist the sites that actually need it and leave Javascript disabled for all other sites. It's not difficult and it takes only a few moments to do it and reload a site when you need it.

      Of course that would require a few minutes of work on your part and you seem to be too busy whining to do it.

      From your description, the problem hasn't even been resolved at all, rather, there's a labor-intensive workaround.

  5. HTML isn't anymore by Anonymous Coward · · Score: 2, Interesting

    What was once a standard for rendering text and images together in a single document has suffered from severe scope creep over the years. With the addition of multimedia, HTML crossed the line from static to active content markup, which in my opinion defeated its original purpose. HTML needs an active companion language, an actual programming language, one that will replace the disparate third-party technologies in use today. Just eliminating Flash and Javascript for example would eliminate a vast majority of the world's browsing headaches.

    We are so close to a Web-based operating system I can taste it.

    1. Re:HTML isn't anymore by telchine · · Score: 5, Funny

      HTML needs an active companion language, an actual programming language, one that will replace the disparate third-party technologies in use today. Just eliminating Flash and Javascript for example would eliminate a vast majority of the world's browsing headaches.

      I agree!

      I shall call this new language "Jscript"!

      -Bill

    2. Re:HTML isn't anymore by Lord+Lode · · Score: 4, Interesting

      You ask for a companion programming language and at the same time propose eliminating Javascript. I see a contradiction in there.

    3. Re:HTML isn't anymore by Anonymous Coward · · Score: 0

      You mean chromebook?

    4. Re:HTML isn't anymore by TWiTfan · · Score: 4, Insightful

      Just eliminating Flash and Javascript for example would eliminate a vast majority of the world's browsing headaches.

      If you know of a language that will do what Flash and Javascript will do with no headaches, please share it with us.

      --
      The cow says "Moo." The dog says "Woof." The Timothy says "Thanks, valued customer. We appreciate your input."
    5. Re:HTML isn't anymore by NoNonAlphaCharsHere · · Score: 0

      He said "PROGRAMMING LANGUAGE".

    6. Re:HTML isn't anymore by SJHillman · · Score: 1

      If by operating system, you mean one that loads from a remote location then look up PXE

      If by operating system, you mean desktop environment, look up anything ranging from RDP and VNC to Chrome OS to eyeOS, Cloudo, Glide or tons of others.

    7. Re:HTML isn't anymore by VortexCortex · · Score: 2

      You ask for a companion programming language and at the same time propose eliminating Javascript. I see a contradiction in there.

      As someone who uses JavaScript daily, I see no contradiction. Perhaps you've confused it with an programming language?

    8. Re:HTML isn't anymore by Ultra64 · · Score: 5, Funny

      Ok, I'll take the bait. How in the hell is JavaScript *not* a programming language?

      1. It is a language
      2. I write programs with it

    9. Re:HTML isn't anymore by istartedi · · Score: 5, Insightful

      We are so close to a Web-based operating system I can taste it.

      One of the things I like to say is, "In the long run, all file formats become programming languages". When somebody says they need a simple format for a config file or something, inevitably scope creep causes them to ask for something like a conditional (can you have a config setup so that if we're running offline it does this; but if the network is available it does that?). For the developer of the file format, *any* file format, it's a good idea to have a language developer's perspective.

      Now, once you look at programming languages you start to get drawn into operating systems. C was developed in conjunction with Unix. Forth tends to become an operating system. Lisp, although it runs in userspace is used as a shell via Emacs and some have compared that to an OS. They talked about building Java chips at one point, and a Java OS certainly would have been written to go with it--it's only natural.

      Thus I feel compelled to revise my little one-liner. "In the long run, all file formats become operating systems".

      The next time the boss says he needs a flat-text config file, think about what kind of scheduling algorithm you want to use.

      --
      For all intensive purposes, "whom" is no longer a word. That begs the question, "who cares"?
    10. Re:HTML isn't anymore by GrumpySteen · · Score: 3, Insightful

      Just eliminating Flash and Javascript for example would eliminate a vast majority of the world's browsing headaches.

      HTML needs an active companion language, an actual programming language

      The big problems inherent to Flash and Javascript are not that they don't work. It's that both involve letting arbitrary code run on your computer and their security isn't perfect.

      Replacing them with a new programming language that will run arbitrary programs on your computer is not going to solve that because a new language isn't going to have perfect security either.

      With a new, active language, you'd still get annoying ads, drive-by malware downloads, pages that load a several megabytes of crappy code to display three lines of text and all of the other problems that make people hate Flash and Javascript.

    11. Re:HTML isn't anymore by Lord+Lode · · Score: 1

      Yes. Javascript is Turing Complete.

    12. Re:HTML isn't anymore by HaZardman27 · · Score: 2

      I would like to see your argument for why Javascript is not a programming language. I would especially like to see an argument that doesn't make up arbitrary and personal definitions of "programming language".

      --
      Apparently wizard is not a legitimate career path, so I chose programmer instead.
    13. Re:HTML isn't anymore by Mordok-DestroyerOfWo · · Score: 2, Insightful

      Ok, I'll take the bait. How in the hell is JavaScript *not* a programming language?

      1. It is a language 2. I write programs with it

      There isn't enough snarky elitism associated with it yet for it to be a "real" programming language. As soon as you can get to the state of natural obfuscation that Perl enjoys, you'll see an uptake with the true nerds.

      --
      "Never let your sense of morals prevent you from doing what is right" - Salvor Hardin
    14. Re:HTML isn't anymore by oGMo · · Score: 0

      We are so close to a Web-based operating system I can taste it.

      Why yes, only a few simple modifications to the standard and soon we'll be writing kernel modules and drivers in HTML6. Joy!

      Blech.

      How can you go from "severe scope creep" to "hey let's add more scope!" with a straight face? Clearly, HTML is far beyond its original intent, and getting by on horrible hacks. Browsers can now do things on a shiny new 3.5GHz machine and $600 video card at nearly half the speed they could 14 years ago on a 200MHz P2 with a Voodoo2. Quake 3! Woo!

      Let's start talking about how we can replace browsers and HTML.

      --

      Don't think of it as a flame---it's more like an argument that does 3d6 fire damage

    15. Re:HTML isn't anymore by Anonymous+Cod · · Score: 1

      JavaSCRIPT is a scripting language.

    16. Re:HTML isn't anymore by phantomfive · · Score: 1

      We are so close to a Web-based operating system I can taste it.

      Technically, we're there. Runs on the iPhone, too, so if you ever dreamed of running Linux on your iPhone, there's your chance.

      --
      "First they came for the slanderers and i said nothing."
    17. Re:HTML isn't anymore by HaZardman27 · · Score: 1

      The only reason I could possibly see for someone saying that Javascript is not a programming language is that it is interpreted and generally only runs within an application (a web browser). Given the rise of Node.js, that distinction isn't necessarily true anymore, and Javascript is essentially in the same boat as other interpreted languages, or in my opinion, even JIT compiled languages.

      --
      Apparently wizard is not a legitimate career path, so I chose programmer instead.
    18. Re:HTML isn't anymore by phantomfive · · Score: 1

      The next time the boss says he needs a flat-text config file, think about what kind of scheduling algorithm you want to use.

      That's hilarious.

      --
      "First they came for the slanderers and i said nothing."
    19. Re:HTML isn't anymore by SuricouRaven · · Score: 2, Interesting

      So is lambda calculus. There's more than a passing simularity there, too.

    20. Re:HTML isn't anymore by Anonymous Coward · · Score: 0

      They did make Java chips. Embedded developers didn't fall for the pile of crap that Java is, so they failed.

    21. Re:HTML isn't anymore by NoNonAlphaCharsHere · · Score: 2

      So is Conway's Game of Life, that doesn't mean amateurs should be writing code that runs on client's machines with it.

    22. Re:HTML isn't anymore by serviscope_minor · · Score: 0

      JavaSCRIPT is a scripting language.

      Scripting language (noun) programming language lacking in elitism.

      OK for bonus points, please define scripting language, with reference to how interpretation doesn't matter given that there are C++ and even machine code interpreters.

      --
      SJW n. One who posts facts.
    23. Re:HTML isn't anymore by serviscope_minor · · Score: 1

      , and Javascript is essentially in the same boat as other interpreted languages, or in my opinion

      These days, other interpreted languages includes machine code and C++.

      --
      SJW n. One who posts facts.
    24. Re:HTML isn't anymore by grumbel · · Score: 1

      Just eliminating Flash and Javascript for example would eliminate a vast majority of the world's browsing headaches.

      CSS3 allows to do some animation effects that are currently done in Javascript, but that's probably the best you will ever get. I don't think we will ever get completely get rid of Javascript, it has just become to integral to what people do on the web these days.

      But it's not just the web developers that are to be blamed for this. Browser developers have done extremely little to actually derive benefit from the HTML markup. Stuff like Readability should have been a standard part of all browsers years ago, yet it's still missing in Firefox.

    25. Re:HTML isn't anymore by AvitarX · · Score: 1

      I agree, one could argue that of it requires a separate program to run it, rather than being compiled to a program, it could be called something else. Though personally, I believe that of It's Turing complete it is a programming language. The language remains the same whether compiled or interpreted, so I'd think that's a silly distinction to classify a language (additionally, a language can have a compiler or interpreter built, or even exist without either (though it wouldn't be so useful in the last case).

      --
      Wow, sent an e-mail as suggested when clicking on "use classic" banner, and got a fast response that addressed my msg
    26. Re:HTML isn't anymore by Anonymous Coward · · Score: 0

      We are so close to a Web-based operating system I can taste it.

      Ah yes, the time-honored "we just need to throw everything away and start with a new thing, which won't EVER acquire the same warts as the old one, and which everybody will simultaneously implement and deploy everywhere" gambit.

      That's not a Web-based OS you're tasting, it's YOUR OWN ASSHOLE. Try removing your head from your ass to get a clearer perspective.

    27. Re:HTML isn't anymore by fermion · · Score: 1
      Originally HTML was just to mark up bits of text which the browser would render in any way it deemed appropriate. So we would have level of headers, different identifiers for test we might want to emphasis, quote, etc. A bit of test might be marked a an adress to picture or whatever else we want, and if the browser knew what to do with it, could display it or whatever. This is to say the standard did not specify how anything might look, only what it is. This separated the presentation from the content, which was largely the style in the pre desktop publishing era.

      While this was useful, it was not what many people wanted. The first sign that all was not well was the blink tag which specified behavior. The everyone started using tables to position content, which was an effective but inelegant kludge. Then MS made a browser that was not intended to render generic HTML but was instead a application front end designed to allow integration between it's MS Windows platforms which had various levels of incompatibility. While many who wanted profitable business on the web designed for HTML, some did target MS IE, which lead to a great schism in the web. After much tumultuous transformations, we ended up with HTML and CSS.

      Really this is ideal. HTML needs to go back to just being a mark up language without a presentation component. For those who want or need to define the presentation that the browser will use, CSS allows that to happen. One thing that HTML anticipated, and CSS allows, is the variation in screen size. With proper markup and CSS, there is no reason why a page cannot be displayed on a 20' screen of 5' screen. Of course this is real victim of the legacy of control freaks killing the beauty of HTML. There are too many web pages that do not render well in any window size. Elements do not scale, do not fall off the edge. Some pages are even designed for only resolution. Madness.

      --
      "She's a scientist and a lesbian. She's not going to let it slide." Orphan Black
    28. Re:HTML isn't anymore by TheDarkMaster · · Score: 1

      You failed to see the irony... Yep, Javascript is a programming language and you can do many things with it. However, it is a language so defective, so bad, so WRONG that is possible to question if it is really a programming language.

      --
      Religion: The greatest weapon of mass destruction of all time
    29. Re:HTML isn't anymore by TheDarkMaster · · Score: 1

      The problem actually is not her being a programming language or not. The problem is that she is one of the most stupid and defective ways of creating a program. Works? It works, but at what price?

      --
      Religion: The greatest weapon of mass destruction of all time
    30. Re:HTML isn't anymore by osu-neko · · Score: 1

      Pointing out that something is X does not rebut the point that it is Y unless X and Y are mutually exclusive.

      --
      "Convictions are more dangerous enemies of truth than lies."
    31. Re:HTML isn't anymore by osu-neko · · Score: 2

      I agree, one could argue that of it requires a separate program to run it, rather than being compiled to a program, it could be called something else. Though personally, I believe that of It's Turing complete it is a programming language. The language remains the same whether compiled or interpreted, so I'd think that's a silly distinction to classify a language (additionally, a language can have a compiler or interpreter built, or even exist without either (though it wouldn't be so useful in the last case).

      Indeed. If "requiring a separate program to run it" was the qualifier for exclusion, the only thing a programming language could write is operating systems...

      --
      "Convictions are more dangerous enemies of truth than lies."
    32. Re:HTML isn't anymore by mwvdlee · · Score: 1

      Are you going to take the "Java" part of "JavaScript" literal too?
      Why aren't you complaining about "Python" being too snakey?

      --
      Slashdot social media options: AIM, ICQ, Yahoo, Jabber and Mobile Text. Why no MySpace?
    33. Re:HTML isn't anymore by osu-neko · · Score: 1

      You failed to see the irony... Yep, Javascript is a programming language and you can do many things with it. However, it is a language so defective, so bad, so WRONG that is possible to question if it is really a programming language.

      This question occurs for every real programming language. The only languages no one ever says this about, no one ever uses (outside of the Ivory Tower)...

      --
      "Convictions are more dangerous enemies of truth than lies."
    34. Re:HTML isn't anymore by Sir+or+Madman · · Score: 1

      Hey I got an idea, let's create some properly rigid and stodgy standard that sucks the life out of things and in 10 years pine for the old days when any little punk with some gumption could pick up a browser and start coding for the web using any of a plethora of techniques. Security, standardization, predictability, harrumph harrumph!

    35. Re:HTML isn't anymore by Anonymous Coward · · Score: 0

      This is the best comment I've read on Slashdot since last July. Thanks!

    36. Re:HTML isn't anymore by lgw · · Score: 5, Funny

      OK, honest question about JavaScript, since I don't know it. Does JavaScript enclose blocks of code in curly-braces?

      As we all know, curly braces are the One True Distinction between real profession programming languages and toy scripting languages. For example, everyone knows C# is a real profession programming language, but Visual Basic is a toy scripting language, despite offering nearly-identical functionality on top of the CLR. However, C# clearly encloses blocks of test in curly braces, and Visual Basic laughably doesn't, toy that it is!

      So, let's settle this JavaScript debate once and for all: on which side of the curly braces line does it lie?

      --
      Socialism: a lie told by totalitarians and believed by fools.
    37. Re:HTML isn't anymore by aix+tom · · Score: 4, Funny

      That's never gonna win against the implementation of COBOL* that I am about to release shortly.

      *CuteObjectBasedOnlineLolcode

    38. Re:HTML isn't anymore by skids · · Score: 1

      Unless you count Java Card based devices, which are pretty widespread. But yeah, why make hardware that does less than the least common denominator of practically every viable microprocessor ever designed?

    39. Re:HTML isn't anymore by skids · · Score: 1

      Replacing them with a new programming language that will run arbitrary programs on your computer is not going to solve that because a new language isn't going to have perfect security either.

      Why people seem to think security is something that can never be perfected is beyond me. Just because people fail at it regularly, does not mean it actually is impossible.

    40. Re:HTML isn't anymore by Anonymous Coward · · Score: 0

      Which is an attitude I've seen a lot, but never from someone who actually knows how to use Javascript properly. Typically it comes from someone who's trying to use it like PHP or Perl, or someone who doesn't actually realize there's a difference between Javascript and the DOM. In any case, poor craftsman who blames his tools, and all that.

    41. Re:HTML isn't anymore by Anonymous Coward · · Score: 0

      Batch scripting does the same 2 things... still it isn't a programming language.

    42. Re:HTML isn't anymore by garyebickford · · Score: 1

      These days even compiled and assembled languages actually run within a run-time environment (and actually is run on a virtual machine that is interpreted in firmware by the CPU and its friends), making the distinction even less clear or useful. It's been a long while but IIRC, just running "Hello World" in C brings in a dozen or two libraries and the running program will likely be 100K+. And I once worked on a FORTRAN system where the same code could be run using an 'Incremental Interactive Compiler' - effectively an interpreter, useful for composing and debugging, or a classic compiler that generated a monolithic runtime program. The latter was much faster, of course.

      --
      It's easier to be a result of the past, but more fun to be a cause of the future! http://www.spacefinancegroup.com/
    43. Re:HTML isn't anymore by Anonymous Coward · · Score: 0

      It's pretty common for people who don't know anything about programming languages to see Javascript as an inferior "scripting language", but that just means that you don't know much about programming languages in general. Javascript is not the DOM. Javascript can be compiled. It supports functional programming better than most modern languages because it has function literals and closures with a nice syntax. etc.

    44. Re:HTML isn't anymore by garyebickford · · Score: 1

      Replacing them with a new programming language that will run arbitrary programs on your computer is not going to solve that because a new language isn't going to have perfect security either.

      Why people seem to think security is something that can never be perfected is beyond me. Just because people fail at it regularly, does not mean it actually is impossible.

      No, Goedel's Incompleteness Theorem means it actually is impossible.

      Or, to put it another way, imagine two trees in a space of all possible 'statements' (programs) in any useful language. One covers all provably false/wrong statements, the other covers all provably true/correct statements. Not only will there be spaces not covered by either tree, there will be spaces covered by both trees.

      --
      It's easier to be a result of the past, but more fun to be a cause of the future! http://www.spacefinancegroup.com/
    45. Re:HTML isn't anymore by west · · Score: 1

      Ok, I'll take the bait. How in the hell is JavaScript *not* a programming language?

      It's not LISP.

    46. Re:HTML isn't anymore by Anonymous Coward · · Score: 0

      flash and javascript are top picks among alot of horrible languages... sorry to say but they give me a headache too... since they are frequently used more often than other less accomplished languages they are the ones I despise the most... Their popularity may also mean they are used by more horrible coders, and that horrible coders are the real problem.

    47. Re:HTML isn't anymore by davidbrit2 · · Score: 1

      He said browsing headaches, not development headaches. And I can't say I totally disagree on that point.

    48. Re:HTML isn't anymore by Anonymous Coward · · Score: 0

      When I first moved to C from Pascal, I did this:

      #define begin {
      #define end }

      Years later I found other people did this, and I no longer felt dirty.

    49. Re:HTML isn't anymore by DragonWriter · · Score: 2, Insightful

      So is Conway's Game of Life, that doesn't mean amateurs should be writing code that runs on client's machines with it.

      There is no language in which amateurs should be writing code that runs on client's machines.

    50. Re:HTML isn't anymore by Anonymous Coward · · Score: 0

      >Thus I feel compelled to revise my little one-liner. "In the long run, all file formats become operating systems".

      I'm gettng a tee shirt made with that.

    51. Re:HTML isn't anymore by Anonymous Coward · · Score: 0

      A script is what you give to the actors, a program is what you give to the audience.

    52. Re:HTML isn't anymore by Anonymous Coward · · Score: 0

      Just because a lot of pigs are rolling in the mud doesn't make the mud less muddy.

    53. Re:HTML isn't anymore by Anonymous Coward · · Score: 0

      For all intensive purposes, "whom" is no longer a word. That begs the question, "who cares"?

      You're obviously an intelligent person... I believe what you mean is "For all intents and purposes."

    54. Re:HTML isn't anymore by K.+S.+Kyosuke · · Score: 1

      So is lambda calculus. There's more than a passing simularity there, too.

      That's because Scheme was the intermediate stage here.

      --
      Ezekiel 23:20
    55. Re:HTML isn't anymore by K.+S.+Kyosuke · · Score: 1

      There is no language in which amateurs should be writing code that runs on client's machines.

      Why? You just need to provide some good pragmatics to the language (as in, it this piece of your code runs longer than half a second at a time, it will get killed mercilessly). Good pragmatics is what many of the sandboxed solutions miss.

      --
      Ezekiel 23:20
    56. Re:HTML isn't anymore by SavedLinuXgeeK · · Score: 1

      Pretty certain the tools for actionscript3 and actionscript3 itself (the language the flash runtime uses) is far more sophisticated and robust than javascript. AS3 is more comparable to Java and .NET, and would be a wonderful toolset for building web applications. It was everything Java attempted to be (in the browser).

      --
      je suis parce que j'aime
    57. Re:HTML isn't anymore by K.+S.+Kyosuke · · Score: 1

      These days even compiled and assembled languages actually run within a run-time environment (and actually is run on a virtual machine that is interpreted in firmware by the CPU and its friends), making the distinction even less clear or useful.

      Also, even if you write your code in assembly and run in on your CPU directly, the CPU still doesn't understand it and has to compile it again into a lower-level language (movs into register renamings for a larger register set, complex instructions into simple RISCy microops etc.) Your CPU is a hardware interpreter of a machine code ISA for which the actual machines don't exist anymore.

      --
      Ezekiel 23:20
    58. Re:HTML isn't anymore by K.+S.+Kyosuke · · Score: 1

      In any case, poor craftsman who blames his tools, and all that.

      Except when the tools are crappy. But that isn't the case of JS. I guess that JS has one crucial benefit that makes it bearable even in the presence of design faults: it's small. It's smaller than, say, Python or PHP, it's certainly smaller than C++ or Perl. Given the fact that there is some percentage of design faults in any language, the smaller the language in question is, the fewer things you have to care about. There aren't all that many in case of JS.

      --
      Ezekiel 23:20
    59. Re:HTML isn't anymore by Anonymous Coward · · Score: 0

      Woooooosh!

      That sig also includes a misuse of "begs the question". It's clearly intentional.

    60. Re:HTML isn't anymore by K.+S.+Kyosuke · · Score: 1

      Replacing them with a new programming language that will run arbitrary programs on your computer is not going to solve that because a new language isn't going to have perfect security either.

      ...unless the language and the exposed APIs are properly designed, you surely wanted to add.

      --
      Ezekiel 23:20
    61. Re:HTML isn't anymore by Anonymous Coward · · Score: 0

      First, you misstate Goedel's Incompleteness Theorem: it says either those trees don't cover the whole space or they overlap, not both (although both is certainly possible). That's important: we assume all logics we use are consistent and accept that they are incomplete.

      More importantly, when talking about programs you actually get three choices, not two: "good", "bad", and "I don't know". Incompleteness means you cannot ever make an analysis that doesn't answer "I don't know" sometimes, but you can guarantee that your analysis is never wrong. If you are trying to verify something is safe, then you reject any programs that you get "I don't know" for along with any that can be verified as "bad", then you can be certain (modulo the correctness of your analysis which can be formally proven correct) that every program you say is "good" is actually good.

      See Quark for a research prototype of a browser that is formally verified to have no security holes. There could still be a bug in the OS sandbox (uh, run it on seL4, I guess?) or, theoretically, in the theorem prover itself, but both are very unlikely. (The downsides of the current implementation are: (1) its security model is not precise enough to capture exactly how different domains are supposed to be allowed to interact and (2) is a slower than other browsers, although fast enough to run GMail and Facebook at acceptable speeds.)

    62. Re:HTML isn't anymore by DragonWriter · · Score: 1

      You just need to provide some good pragmatics to the language (as in, it this piece of your code runs longer than half a second at a time, it will get killed mercilessly). Good pragmatics is what many of the sandboxed solutions miss.

      I won't agree that that's all that is required, but there is no such thing as universally good pragmatics; pragmatics like this that would be good are intensely use-specific (and the web is general purpose), so there's no such thing as "good pragmatics" for a general-purpose web language. You could have dozens of narrow-focus, special purpose ones, but then you'd also need to have a common way of delivering them that would be useful if you wanted to use them on the web. Like tons of other things these days, this calls more for something that compiles to Javascript than something that replaces Javascript.

    63. Re:HTML isn't anymore by larpon · · Score: 1

      Yeah - oxymoron!

    64. Re:HTML isn't anymore by Anonymous Coward · · Score: 0

      Since Flash provides plenty of headaches, it's fair to consider a replacement that also has headaches.

    65. Re:HTML isn't anymore by maxwell+demon · · Score: 1

      Are you going to take the "Java" part of "JavaScript" literal too?
      Why aren't you complaining about "Python" being too snakey?

      It's not too snakey, it's just not monty enough. ;-)

      --
      The Tao of math: The numbers you can count are not the real numbers.
    66. Re:HTML isn't anymore by maxwell+demon · · Score: 1

      Ok, I'll take the bait. How in the hell is JavaScript *not* a programming language?

      It lacks goto. :-)

      --
      The Tao of math: The numbers you can count are not the real numbers.
    67. Re:HTML isn't anymore by Anonymous Coward · · Score: 0

      You beat me to it, thank you.

    68. Re:HTML isn't anymore by Anonymous Coward · · Score: 0

      Originally HTML was just to mark up bits of text which the browser would render in any way it deemed appropriate. ... This is to say the standard did not specify how anything might look, only what it is. This separated the presentation from the content, which was largely the style in the pre desktop publishing era.

      This is true. Originally, it was supposed to be up to the user how to present the marked-up content, but once the Web gained traction, designers and authors decided that it was their job to determine how the page looks to the user, including fonts, layout, and behaviors.

      So now we are stuck with this kludgey mishmash of technologies to cover content, semantics, layout, and logic, all of which work differently and manipulate each other like ham-fisted sushi chefs trying to make sushi while wearing boxing gloves.

    69. Re:HTML isn't anymore by Anonymous Coward · · Score: 0

      ...I didn't get a "harrumph" outta that guy!

    70. Re:HTML isn't anymore by SuricouRaven · · Score: 1

      I just looked at some Scheme code. I won't be doing that again for a while. I'll stick to good old fashioned C!

    71. Re:HTML isn't anymore by DragonWriter · · Score: 1

      CSS3 allows to do some animation effects that are currently done in Javascript, but that's probably the best you will ever get. I don't think we will ever get completely get rid of Javascript, it has just become to integral to what people do on the web these days.

      We may not get rid of JavaScript as a delivery vehicle for executable code, but there's no reason we couldn't isolate application developers from it, in a couple of ways:
      1. Application languages that compile to JavaScript for delivery, or
      2. Application languages that are either interpreted by JavaScript, or compiled to it after delivery, or
      3. (And this is, in a sense, a subset of #2, but worth calling out on its own) an HTML profile for executable content that can be interpreted and/or compiled to JS by a JS script.

      #1 and #2 are common now, and I think I've seen examples of #3.

    72. Re:HTML isn't anymore by Skrapion · · Score: 1

      You know, I'd be perfectly happy if HTML supported COBOL. My problem with JavaScript isn't that it's a terrible language, it's that it's the only language.

      I'd be much happier if HTML had a standard VM and a standard API, so that we could use whatever language we want.

      HTML is a software platform now, and being stuck with one programming language is stifling. Can you imagine if we were only allowed to use one language when writing Windows/Linux/Mac software?

      --
      The details are trivial and useless; The reasons, as always, purely human ones.
    73. Re:HTML isn't anymore by Anonymous Coward · · Score: 0

      The braces represent the mustache power of the language. Remember the Rule of Beard? Well, it's actually the language itself whose beard is important.

    74. Re:HTML isn't anymore by ewanm89 · · Score: 1

      You forgot to point out that most browsers don't interpret these days but JIT compile.

    75. Re:HTML isn't anymore by Algae_94 · · Score: 1

      Yes, blocks of code such as the body of a function go in curly braces in JavaScript. There are also curly braces in PHP, so I'm not set on the idea that curly braces are the One True Distinction.

    76. Re:HTML isn't anymore by gagol · · Score: 1

      Javascript is great, the client-side DOM sucks balls.

      --
      Tomorrow is another day...
    77. Re:HTML isn't anymore by gagol · · Score: 1

      A bad analogy is what gives you lack of credibility.

      --
      Tomorrow is another day...
    78. Re:HTML isn't anymore by gagol · · Score: 1

      You realise ActionScript is based on ECMAScript, right?

      --
      Tomorrow is another day...
    79. Re:HTML isn't anymore by GrumpySteen · · Score: 1

      Show me a language and API that has no flaws and I'll add it. So far, no such thing exists and it seems fairly unlikely that it ever will.

    80. Re:HTML isn't anymore by TapeCutter · · Score: 1

      A JIT compiler is just an interpreter that can see into the immediate future.

      --
      And did you exchange a walk on part in the war for a lead role in a cage? - Pink Floyd.
    81. Re:HTML isn't anymore by Anonymous Coward · · Score: 0

      It's been a long while but IIRC, just running "Hello World" in C brings in a dozen or two libraries and the running program will likely be 100K+

      I just tried compiling "hello world" in C and got an executable 8704 bytes in size, linking exactly one library. I agree bloat is a problem, but exaggeration doesn't help your case.

    82. Re:HTML isn't anymore by Common+Joe · · Score: 1

      I'm not the best person to comment about Flash specifically, but Javascript fails the KISS principle. Better, more secure languages adhere to the KISS principle. I suspect Flash fails because they they scope-creeped a video viewer into a programming language, but someone else can correct me if I'm wrong.

    83. Re:HTML isn't anymore by Anonymous Coward · · Score: 0

      Interpretation is in fact a benefit for web pages executing code on a client's machine anyway. I'd argue it could be more secure (restricted list of functions, no sneaking undefined opcodes in) and is infinitely more portable.

    84. Re:HTML isn't anymore by TripleE78 · · Score: 1

      If I had mod points, I'd mod the f**king sh*t out of this post so many times that you'd be the next editor of Slashdot.

      There should be a whole damn college curriculum around this post. So, so true.

    85. Re:HTML isn't anymore by Anonymous Coward · · Score: 0

      Where's BadAnalogyMan when you need him?

    86. Re:HTML isn't anymore by UtterCoward · · Score: 1

      JavaScript has first-class functions and closures. That makes it a fine programming language.

    87. Re:HTML isn't anymore by K.+S.+Kyosuke · · Score: 1

      This is about slightly deeper semantics, not about syntax. "I've looked at some Scheme code" and "I have no f*cking clue what you're talking about" are most likely identical sentences in the context of this discourse. (And N.B.: Scheme happens to be as old as C.)

      --
      Ezekiel 23:20
    88. Re:HTML isn't anymore by K.+S.+Kyosuke · · Score: 1

      Show me a language and API that has no flaws and I'll add it.

      You have to do them yourself for your task. Follow the principle of least power for the language (that's why you have to design it for your particular use to begin with) and the principle of least authority for the API and you should be safe. There are always cases for botching pragmatics horribly, such as in the case of leaking browser history via CSS styling, but if you know what you're doing, you ought to be able to control this.

      --
      Ezekiel 23:20
    89. Re:HTML isn't anymore by Anonymous Coward · · Score: 0

      HTML needs an active companion language, an actual programming language, one that will replace the disparate third-party technologies in use today.

      One companion? Only one?

      Which one is it? Is it Flash? Javascript? Java applets? Macromedia Shockwave? Silverlight? ActiveX?
      And I'm sure I am forgetting a few.

      You are not eliminating headaches by getting rid of any of those languages, you are just shifting the headache elsewhere (like how to do stuff you used to do before in a new way).

      Also, the W3C has thought about this since you actually can do games and what not in HTML5, so I guess HTML5 is the active companion language to HTML you wanted.

    90. Re:HTML isn't anymore by istartedi · · Score: 1

      TTAMF (Thanks To All My Fans). Not that I really pay much attention to that kind of thing.

      --
      For all intensive purposes, "whom" is no longer a word. That begs the question, "who cares"?
    91. Re:HTML isn't anymore by Anonymous Coward · · Score: 0

      > And N.B.: Scheme happens to be as old as C

      Almost. C is 3 years older, but if you want to count Scheme as the offspring of Lisp, that goes back to 1958. But then you'd have to count C as the offspring of Algol, also from 1958.

    92. Re:HTML isn't anymore by Anonymous Coward · · Score: 0

      Opium

    93. Re:HTML isn't anymore by badkarmadayaccount · · Score: 1

      Source to source compilers?

      --
      I know tobacco is bad for you, so I smoke weed with crack.
    94. Re:HTML isn't anymore by badkarmadayaccount · · Score: 1

      RDP and Wayland? Add SQLite and Google NaCl.

      --
      I know tobacco is bad for you, so I smoke weed with crack.
  6. what are you even saying? by fazey · · Score: 5, Insightful

    If you break the html standard... each browser will interpret things even more differently than they already do. This means you now have to give a crap about what browser the visitor of your site is using, because the developers went off and did their own thing. I'm glad the author found some toys he likes... but this hardly makes an html standard useless. For example, what does this do for tomcat? What does this do for ASP.NET? The answer is nothing.

    1. Re:what are you even saying? by Synerg1y · · Score: 5, Insightful

      Yep, the author doesn't truly understand WHY HTML works and that's because it's interpreted by the browser a certain way. There already exist a plethora of differences between IE and firefox/chrome, de-standardizing HTML would make it impossible to create websites that look consistent to all users.

    2. Re:what are you even saying? by jeti · · Score: 1

      Nope. Each element would use the relevant display properties defined in the CSS. If the value of a property is not explicitly defined, the default value of the property is used. Some of the inconsistencies between browsers stem from the fact that they assume different default properties (like margins) for specific elements.

      Personally, I like the clean minimalism of what I think is being proposed.

    3. Re:what are you even saying? by simonstl · · Score: 1

      Most of what actually mattered when HTML first appeared - presentation, behavior, and semantics - has already been refactored into CSS and JavaScript and WAI-ARIA.

      The question today is whether you want to live only inside that hollow shell, or whether you'd like to look into extending it to fit your needs. CSS, JS, and WAI-ARIA will work just as well for your own markup as they work for HTML.

      You're right that this shouldn't affect back-end technologies much at all. To them it's all just markup.

    4. Re:what are you even saying? by AvitarX · · Score: 1

      Without an html standard, how do we know what the display property means?

      --
      Wow, sent an e-mail as suggested when clicking on "use classic" banner, and got a fast response that addressed my msg
    5. Re:what are you even saying? by simonstl · · Score: 1

      The display property is in the CSS standard, not the HTML standard. You don't need the HTML standard to use it.

    6. Re:what are you even saying? by Kookus · · Score: 1

      The author doesn't seem to be a credible source of information for standards and compliance. Judging form his resume, he seems to just be a web developer by trial through fire. More of a technical writer if anything.
      http://www.simonstl.com/resume.htm

    7. Re:what are you even saying? by Anonymous Coward · · Score: 0

      And how will the browsers know how to interpret the CSS standard? That's right, you have to make a standard. All this proposal is doing is reinventing HTML and calling it something else. If you want to give a browser a document with your own XML and another document to interpret that, then you already can.

      Just provide a simple HTML document that bootstraps a JavaScript interpreter and your XML (or JSON or whatever else you fancy). Then you can play around all you like. This approach is not new or novel.

    8. Re:what are you even saying? by simonstl · · Score: 1

      No, it's not new or novel, but it's exactly what I proposed... you can already mix your own tags into HTML and style and process them.

      The article certainly made clear that I didn't expect CSS, JavaScript, the DOM, or a variety of other standards to go away. We just don't need to worry about HTML itself so much any more.

    9. Re:what are you even saying? by DragonWriter · · Score: 1

      Some of the inconsistencies between browsers stem from the fact that they assume different default properties (like margins) for specific elements.

      Why would you "stop standardizing HTML" to fix this problem? I mean, the obvious fix for this problem is to explicitly specify the default style properties of standard elements. Which HTML5 does.

    10. Re:what are you even saying? by DragonWriter · · Score: 1

      The display property is in the CSS standard, not the HTML standard. You don't need the HTML standard to use it.

      You need the HTML standard to understand that that the CSS standard should be applied to interpret the block of content contained by style tags in the HTML document, or referenced from the HTML document via a LINK tag with rel="stylesheet". The semantics of HTML, including the bits that link to or incorporate CSS stylesheets, are defined in the HTML standard.

    11. Re:what are you even saying? by Anonymous Coward · · Score: 0

      No, you're saying that we throw away standardization in one place but ignore the fact that it will need to be reimplemented elsewhere. Yes, you can make your own tags in HTML right now and style them in CSS but your just shifting the requirement for a standard from HTML to CSS.

      You're also advocating using CSS for something it was never designed for. This is they type of thing that happened to HTML a decade ago. You're just going around in circles. Leave the standards in the base of the web where they belong and build the non-standardized mess on top of that. At least then we have a solid base to work with and can ignore or rebuild the mess when we need to.

      Your proposal is unsound at its core and I'm not even sure you understand what it *is* you're proposing or what would happen if you tried to use it.

    12. Re:what are you even saying? by VortexCortex · · Score: 1

      If you break the html standard... each browser will interpret things even more differently than they already do.

      Yep, the author doesn't truly understand WHY HTML works and that's because it's interpreted by the browser a certain way.

      It's like folks are ignorant that PDFs use PostScript, which looks a lot more the same across devices and rendererers than HTML because that's what it was designed to do. The issue I have is that we could actually do that for the web. We could come up with a compact text / glyph rendering specification that gave proper down to the pixel instructions how things should be rendered, even at various resolutions. It could be very simple too, because you wouldn't have to define a hundred different tags to to the same thing: Apply color and positioning attributes to shapes. Once we have that low level definition system, you could re-implement HTML atop it if you wanted, or we could come up with domain specific markups -- And they can all compile down to the same standardized pixel perfect text & shape rendering system. I mean, we know how to do this. We've done it, we keep doing it. Look at SVG, that's what happens when you try to implement glyph systems atop HTML... Yeah, I know XML != HTML, but which came first? I know ECMA Script is supposed to be the definition of JavaScript, but guess which came first? These things weren't designed to do the jobs we're applying them to, and we all suffer for it. At the end of the day we're using a stateless protocol for document interchange and a static content display system along with a horribly slow and inefficient scripting language to create stateful dynamic web applications, and we demand performance. Look if you give me a picture frame made of wood, a canvas and some paint, and I produce your content then you say you want it to animate and remember who looked at it, and be strong as steel... Well, I'm going to tell you we need to start over, you fucking changed the project's parameters too much.... We need to start over. Things have changed, we're shoehorning in too much crap atop a shite standard that was okay for one thing, but isn't really geared towards what we want to do now.

      This is backwards standardization of BASIC features is all because we're using the web for applications. Crap, I JUST NOW in Firefox 20 am able to generate a data URL with client side javascript that allows you to click it and save your data to disk. Next up? Being able to load a file into the damn program. No, that's not even fucking there yet, yes the file reader API is somewhat existant in some browsers, but it's a BASIC fucking feature, but come the cunt on man! Why isn't it working and in the standard already?!?! Because, we're using HTML+JS for shit it was never intended to do, and when you keep bolting all these extra features instead of starting out with them, you wind up with something that's so horribly complex it's damn near impossible to maintain and is riddled with security problems -- Gee, just like the fucking Web.

      Customer changes the goalposts drastically, we scrap it all and re-engineer it. If we don't we KNOW what the crap will happen. We have PROOF. It's time to let HTML die.

    13. Re:what are you even saying? by simonstl · · Score: 1

      I haven't said throw away HTML - I've said stop standardizing it. The link tag is still fine. In cases where people want to obliterate even that, the xml-stylesheet processing instruction also lets you specify a stylesheet.

      None of this is difficult. It all works in browsers today.

    14. Re:what are you even saying? by DragonWriter · · Score: 1

      I haven't said throw away HTML - I've said stop standardizing it.

      If by "stop standardizing it" you mean "stop developing new standards", then, well, just no. No one is stopping you from using the existing standards and ignoring new ones, if that's what you want to do, but there are lots of good reasons for standardizing new functionality. (Most of which, you will notice, even when it is called part of "HTML5", isn't in the HTML standard proper anyway, but in separate standards that are maintained by the same groups.)

      None of this is difficult. It all works in browsers today.

      And its not likely to stop working with interoperable standards that eliminate the need to use nonstandard hacks to accomplish commonly-desired behaviors.

      Admittedly, people whose primary skills are focussed around building those non-standard hacks will need to update their skills or find them obsolete, but that's not a reason to stop improving the common platform provided by web standards.

    15. Re:what are you even saying? by AvitarX · · Score: 1

      I don't disagree on principal with what you're saying, but think rather than saying stop standardizing HTML, I think it makes more sense to have a very stripped down, but existing standard, and then use all of the other standards to extend it. Even if browsers support it, do they support these things well? I know that XHTML used to be supported, but it wouldn't display as parsing or loading, making it a poor experience (I assume this is fixed now, just an example).

      Even now, HTML is basically a set of tags that all browsers are expected to have similar defaults for display, I don't see how this is a terrible bad thing. Trying to force everone to use the canvas widget is good, making it part of the HTML standard encourages that.

      --
      Wow, sent an e-mail as suggested when clicking on "use classic" banner, and got a fast response that addressed my msg
    16. Re:what are you even saying? by goose-incarnated · · Score: 1

      No, it's not new or novel, but it's exactly what I proposed... you can already mix your own tags into HTML and style and process them.

      Did something like this and was meaning to write up a blog post about this but never got around to it (hey, there's a weekend coming up :)

      Feel free to read the rest of the directory for the actual implementation.

      --
      I'm a minority race. Save your vitriol for white people.
  7. Fix it.... by whizbang77045 · · Score: 2

    But it's working the way it is. The time-honored software way is to fix it.

  8. Just like the good ol' MSIE days! by femtobyte · · Score: 5, Insightful

    <_MSIE_XZ92 MS_FONT_TP = "comic sans" Q_BINARY_BLOB = "89FF372198A" BRWSR_FOO_P = "unidiv/flimblargle">Great idea!</_MSIE_XZ92>

    This post optimized for viewing with with MSIE 9.3.

  9. Please standardize more by concealment · · Score: 5, Insightful

    The web worked when it had a simple standard that worked in every situation.

    We've put layers on top of that, and now it's chaos. A bloated, irregular, often incomprehensible chaos designed to allow people to make custom interfaces out of the web.

    The whole point of the web, versus having an application for every specific task (like we did on desktops before the 1990s, and like we now do on smartphones), was to have a standard and simplified interface.

    The web grew and thrived under that goal. It's become more corporate, nuanced, isolated, sealed-off, etc. under our "new" way.

    1. Re:Please standardize more by pixelpusher220 · · Score: 1

      like we did on desktops before the 1990s, and like we now do on smartphones

      I get your point, but the above quote contradicts it. We've gone 'back' to the stovepipes of the pre 90s with phones and apps. I'd say it's a reasonable question to ask if technology has made stovepipe systems palatable and/or feasible now.

      Or putting it another way, see Apple's superbowl commercial...sometimes having differences is a good thing. Of course sometimes its not, but knowing the difference is tough to deduce sometimes.

      --
      People in cars cause accidents....accidents in cars cause people :-D
    2. Re:Please standardize more by Synerg1y · · Score: 1

      Not so much that as there's new ways to do things, you can still make a plain html / css / jscript site just fine, it's just that jQuery may solve a lot of jscript headaches for you & a server side language can allow you to data mine, as well as google who can keep track of your traffic.

      Those layers have made the web a lot more capable to the point where you can administrate an enterprise network through a browser.

      Why would you want to do that? Well, nobody wants to be attached to their work computer at the waist.

      Also, what standards aren't in place now that were then?

      I emphasize with you that there's so many plugins / add-ons / languages around now that it's hard to pick what's easiest / works the best, but remember that 99% of stuff can be done using basics.

    3. Re:Please standardize more by scamper_22 · · Score: 1

      The 'web' works as well as ever.

      HTML afterall was written back when they just wanted to show people documents. It 'hardly' worked in every situation. It worked in the very limited case of presenting a documenting.

      Then people wanted to do more with these documents and we end up with what we have now.

      It's really not unlike the various attempts to make word processors interactive.

      The author's point that many have chosen to ignore is that the actual 'markup' part of HTML is pretty much good enough. I think he is saying to leave the current HTML spec as is. Freeze it and use that as a standard.

      Everything 'new' has basically moved into CSS, javascript/DOM...

      In a sense, most of the new development has been in creating a unified framework to be used by everyone. Kind of like getting the world to use QT or .NET or whatever.

      We can then have any more HTML 'tags' be left to the end developer,

      For example, the web components framework by Google basically allows one to use 'custom' tags to use premade 'objects'.

      Something like this:

      This does something great

      Rather than being added to the HTML spec. It is 'linked' in or included as an object.

      I think it is more inline with what the 'web' programming environment has become... that is a general programming framework. And most such frameworks allow you to define your own 'objects' and bring in other libraries...

    4. Re:Please standardize more by scamper_22 · · Score: 1

      sorry... the google web component part appears to have been consumed by slashdot comment.
      It looks something like this:

      <link rel="components" href="x-mycomp.html">
      <x-mycomp>Dude, this is crazy</x-mycomp>

    5. Re:Please standardize more by gstoddart · · Score: 1

      The web worked when it had a simple standard that worked in every situation.

      Have we *ever* actually had that?

      For a long time, basic HTML was rendered differently in each browser, several of them added their own functionality and ignored others, CSS support came in pretty spotty and depended on which browser you had.

      I'm not so sure it ever 'worked in every situation' -- my memory is that it was anything but. It took literally years before IE even behaved close to what everyone else did.

      --
      Lost at C:>. Found at C.
    6. Re:Please standardize more by Anonymous Coward · · Score: 0

      Just like Word ruined Notepad?

    7. Re:Please standardize more by maxwell+demon · · Score: 1

      Well, HTML worked pretty well (and still does) for the purpose it was originally invented for: Presenting you text and images, without caring about the exact look of the presentation. It's just that few people are content with that.

      --
      The Tao of math: The numbers you can count are not the real numbers.
    8. Re:Please standardize more by Arker · · Score: 1

      Well, HTML worked pretty well (and still does) for the purpose it was originally invented for: Presenting you text and images, without caring about the exact look of the presentation. It's just that few people are content with that.

      This is the tragedy of the web. It worked pretty well, it still does, but it works less well because what it is actually IS is underappreciated, and people keep trying to make it something it is not. A means of distributing content based on semantics, leaving presentation decisions to the final display device, is pure genius. Yet every single major player in the html standards game has been focused on making something else entirely of it from day one.

      --
      =-=-=-=-=-=-=-=-=-=-=-=-=-=-
      Friends don't let friends enable ecmascript.
    9. Re:Please standardize more by Anonymous Coward · · Score: 0

      Well, nobody wants to be attached to their work computer at the waist.

      right, we want it the other way around, where's my wearable?

  10. Extending the DOM; WAI-ARIA in search engines by tepples · · Score: 3, Interesting

    "Instead, the author proposes that CSS, Javascript+DOM, the W3C's accessibility framework, and Web Components are sufficient to implement the rendering of smaller, domain-specific markups."

    In other words, implement everything new as polyfills. But how would one have implemented new HTML5 features, such as the 2D Canvas, WebGL, and the video tag as polyfills? Even if one doesn't standardize new extensions to HTML markup, one still needs to standardize new extensions to the DOM. In addition, no new elements means that user agents that do not process script or WAI-ARIA, such as robots used by search engines, won't be able to make sense of pages. Do any current web search engines process WAI-ARIA?

    1. Re:Extending the DOM; WAI-ARIA in search engines by fuzzyfuzzyfungus · · Score: 4, Interesting

      The author's proposal sounds suspiciously like he has fallen for the seductive path of elegant generalizations(that are too theoretical for the ugly details to yet be visible) instead of confronting the ugly details that our current attempt at standardization has made visible...

      To be sure, the sausage-by-comittee that tends to result when you try to standardize something is quite ugly and takes ages to settle down; but if the proposal is "Just let people use whatever shims they want for everything" you haven't really solved the problem, just comitted yourself to standardizing a suitably powerful interface for the shims to sit on, along with giant piles of shim-dependent code that crawlers and any other applications that break the shims' assumptions won't be able to make the slightest sense of.

      Heck, for maximum elegance in the core standards, we could just replace virtually everything with the "Object" tag, and let people embed whatever they want, or abandon this 'HTML' nonsense entirely and just make Native Client the standard, freeing developers to implement pretty much any conceivable structure, from a legacy browser engine, to a Flash client, to a TECO interpreter built entirely out of Minecraft redstone logic, as the shim for their 'site'. A glorious age of unfettered freedom!

    2. Re:Extending the DOM; WAI-ARIA in search engines by phantomfive · · Score: 5, Funny

      But how would one have implemented new HTML5 features, such as the 2D Canvas,

      Simple. Each pixel is a separate div.

      WebGL,

      Lots and lots of divs. Lots of divs.

      --
      "First they came for the slanderers and i said nothing."
    3. Re:Extending the DOM; WAI-ARIA in search engines by fuzzyfuzzyfungus · · Score: 1

      Hey, an X-by-Y 'table' object populated entirely with 1-pixel images is just waiting to be turned into a javascript-controlled framebuffer!

    4. Re:Extending the DOM; WAI-ARIA in search engines by dkf · · Score: 1

      But how would one have implemented new HTML5 features, such as the 2D Canvas,

      Simple. Each pixel is a separate div.

      I've seen that sort of monstrosity done for real. Apparently, it was the only way to make the code work reliably with IE6...

      --
      "Little does he know, but there is no 'I' in 'Idiot'!"
  11. Recent history by Anonymous Coward · · Score: 1

    Nonstandard HTML! Because remember, IE6 stands for "Is Excellent, 6"!

    I guess the kids today consider "ten years ago" to be "ancient history" and thus not worth learning?

    1. Re:Recent history by Anonymous Coward · · Score: 0

      You missed a pair of sixes there.

    2. Re:Recent history by gagol · · Score: 1

      I taught it stands for Incompetent Execution #6.

      --
      Tomorrow is another day...
  12. Standardize! by Murdoch5 · · Score: 4, Insightful

    CSS, HTML and JavaScript need to be standardized and built to work together. If you want to add your own libraries on then that is fine but I run into so many issues with different browsers handling my scripts differently, this is 100% due to nothing being standardized. I shouldn't have to use special operators or libraries to create the effects I want / need.

    1. Re:Standardize! by binarylarry · · Score: 1

      The only cool thing about the web is the delivery model.

      CSS, HTML and Javascript should be optional components you *can* use to build web apps, not "the one way" because they're horrifically shitty for anything but simple use cases.

      If the web was more bare bones, it would be a much richer, faster, better, diverse place... as long as the security model works. Something like Google's Nacl would be much better than web sites as we know them.

      --
      Mod me down, my New Earth Global Warmingist friends!
    2. Re:Standardize! by Anonymous Coward · · Score: 0

      CSS, HTML and JavaScript need to be standardized and built to work together.

      Or replaced.
      HTML isn't really suited as a description language for web-pages as they look today and CSS is pretty much a patch to make it work slightly smoother.
      I can't name a better description format at the moment but I suspect that you could get a cleaner code out of many pages if you rewrote them as SVG instead of HTML.

    3. Re:Standardize! by Anonymous Coward · · Score: 1

      The only cool thing about the web is the delivery model.

      CSS, HTML and Javascript should be optional components you *can* use to build web apps, not "the one way" because they're horrifically shitty for anything but simple use cases.

      If the web was more bare bones, it would be a much richer, faster, better, diverse place... as long as the security model works. Something like Google's Nacl would be much better than web sites as we know them.

      But isn't it part of the beauty of the web delivery model that it works across different devices and OS's without having to target them separately/distribute a new runtime environment (repeating Java/Flash..)? Good luck getting Nacl onto iOS devices fx.

      Native apps that just use the internet for communication really isn't new at all, have been quite common all along (I'm fx running streaming Spotify in the background here), but isn't the web.

    4. Re:Standardize! by CyprusBlue113 · · Score: 1

      The only cool thing about the web is the delivery model.

      CSS, HTML and Javascript should be optional components you *can* use to build web apps, not "the one way" because they're horrifically shitty for anything but simple use cases.

      If the web was more bare bones, it would be a much richer, faster, better, diverse place... as long as the security model works. Something like Google's Nacl would be much better than web sites as we know them.

      But isn't it part of the beauty of the web delivery model that it works across different devices and OS's without having to target them separately/distribute a new runtime environment (repeating Java/Flash..)? Good luck getting Nacl onto iOS devices fx.

      Native apps that just use the internet for communication really isn't new at all, have been quite common all along (I'm fx running streaming Spotify in the background here), but isn't the web.

      There is a great quote from a former coworker of mine.

      Anal works on both genders too, that doesn't make it great, or even less shitty, or that working on all genders in the same way is something you should strive for just because you can.

      --
      a handful of selfish greedy people are no match for millions of selfish, greedy people -u4ya
    5. Re:Standardize! by DragonWriter · · Score: 1

      CSS, HTML and Javascript should be optional components you *can* use to build web apps, not "the one way" because they're horrifically shitty for anything but simple use cases.

      We have that. Its called "the internet", you can use many different protocols, content formats, and languages there. We call it "the web" when we use certain tecnologies, mainly HTTP, HTML, CSS, and JavaScript, but we don't need any magical change to allow us to use other technical choices.

    6. Re:Standardize! by DragonWriter · · Score: 1

      But isn't it part of the beauty of the web delivery model that it works across different devices and OS's without having to target them separately/distribute a new runtime environment (repeating Java/Flash..)?

      The beauty is that there is a useful set of core technologies that are widely implemented, but that set of core technologies is delivered in a form of a fairly heavyweight runtime environment (called a "web browser"); if you want people to use your content, you have to still have to make sure they have the right runtime environment. (That's also why the standard feature set of the open web keeps growing, too; there is a constant tension between proprietary browser extensions -- either external or browser-specific internal extensions to standardized functionality -- or non-browser platforms providing new technologies, and those getting subsumed into the standard so that you don't need a proprietary runtime or particular browser to use them.)

    7. Re:Standardize! by binarylarry · · Score: 1

      Thank goodness you're here, Captain Obvious!

      --
      Mod me down, my New Earth Global Warmingist friends!
  13. People have short memories it seems. by PCK · · Score: 2

    Netscape navigator introduced the notorious BLINK tag and things like frames, back in the early days it pretty much was a free for all.

    1. Re:People have short memories it seems. by SteveFoerster · · Score: 1

      Yes, but as annoying as that was, at least a human being could still read the code.

      --
      Space game using normal deck of cards: http://BattleCards.org
    2. Re:People have short memories it seems. by mwvdlee · · Score: 1

      The only problem with the blink tag is that it was ugly. Too be fair, you really don't need a blink tag to create ugly websites and blinking effects are just one of many, many different ways to make websites ugly.

      --
      Slashdot social media options: AIM, ICQ, Yahoo, Jabber and Mobile Text. Why no MySpace?
    3. Re:People have short memories it seems. by frank_adrian314159 · · Score: 1

      But the good new is that, even if they do obsolete the BLINK tag, we can replicate it with a Javascript timer with little trouble. Hell, with the new CSS3 control of alpha, you can make it throb! That can be really annoying! BLINK forever!!!

      --
      That is all.
    4. Re:People have short memories it seems. by Anonymous Coward · · Score: 0

      And which do you prefer crappy websites use? A blink tag you can easily disable or a Javascript timer that you can't? Which one is safer? I'm sure all the Javascript timer developers won't care about people prone to seizures. A browser only needs to handle that case once.

      We want a blink tag specifically so we can ignore it.

    5. Re:People have short memories it seems. by Kielistic · · Score: 1

      You can make a blink tag entirely in css now with no Javascript needed. Progress :)

  14. No by Anonymous Coward · · Score: 0

    Nooooooo

  15. This rule should have a number: by eexaa · · Score: 2

    If in doubt, add one more complexity layer.

  16. No, Instead kill the Multimedia extension by denis-The-menace · · Score: 1

    Ever since Multimedia was added to HTML the spec has gone to shit:
    -What codec to choose
    -Patents
    -And now DRM

    Not of these are compatible with the idea to allow compatibility between all sites and all browsers

    --
    Obama's legacy: (N)othing (S)ecure (A)nywhere and (T)error (S)imulation (A)dministration
    1. Re:No, Instead kill the Multimedia extension by Anonymous Coward · · Score: 0

      By "multimedia" I presume you're not talking about the simple combinations of text and images which HTML was specifically designed to support in the first place? You must mean some narrower definition of multimedia.

      - What codec to choose (JPG, GIF, PNG?)
      - Patents (GIF patented)

      Not new problems.

    2. Re:No, Instead kill the Multimedia extension by SuricouRaven · · Score: 1

      The codec/patent issues aren't from HTML. HTML itsself is content neutral. Things like this have happened before - most noteably the GIF format was patent-encumbered for many years, and the PNG format many proposed as an alternative was not fully supported by Microsoft*.

      We're just repeating the same issues now that we already went through with image standards: HTML doesn't specify a media format, and there are no media formats that everyone can support. The open source side cannot support formats encumbered by patents (h264, ac3), while the commercial browser writers like Microsoft and Apple have a strong business incentive to support only their own technologies.

      Google is a bit of an odd one out.

      *This was back in the 'Linux is a cancer' years, which Microsoft were at their most openly evil regarding open standards.

    3. Re:No, Instead kill the Multimedia extension by Gavagai80 · · Score: 1

      These issues (except DRM) have existed since the IMG tag was added. GIFs were patent-encumbered, some browsers didn't support PNG, then there's JPEG2000, etc.

      --
      This space intentionally left blank
  17. Sure. by sidragon.net · · Score: 0

    You've just dismissed what is probably one of the most powerful and flexible languages ever put into practice. Congratulations on being impossibly boneheaded.

    1. Re:Sure. by Anonymous Coward · · Score: 0

      Javascript should be banshied to the pits of hell whence it came. it is a hateful, spiteful language. It practically mandates poor programming practices.
      Give me a better browser language.

    2. Re:Sure. by ArcadeMan · · Score: 1

      If you guys think Javascript and PHP are bad, you'll have a seizure if you ever look at ExpressionEngine's "parsing order" nightmare.

  18. just add an element by Anonymous Coward · · Score: 1

    There is already a way to do non standard tags. Take this and leave our html5 alone.

    document.createElement('someTag');

  19. Random idiot makes inflamatory remark by kwerle · · Score: 1

    News at 11.

    Thank you, /., for thinking this matters.

  20. It's he retired from lack of oxygen? by FuzzNugget · · Score: 1

    Everyone ought to see TFA and look at this fedora-wearing douche opining on subjects in which he clearly has no practical knowledge.

    As if browsers need to be an even more disarrayed kludge than they already are? Yeah, 5 or more browsers and rendering engines that all have their own unique languages and markups, great idea!

    Seriously, no. Just no.

  21. simplify by technosaurus · · Score: 1

    1. Parse xml/json to dom.
    2. Apply css (use css to make html tags behave as expect... But modifyable)
    3. Use any supported language to manipulate.

    1. Re:simplify by Anonymous Coward · · Score: 0

      1. Parse xml/json to dom.
      2. Apply css (use css to make html tags behave as expect... But modifyable)
      3. Use any supported language to manipulate.

      Hey! Hold it right there! Thought you could just slip that past us and we wouldn't notice? That's not a tiny little word you just brought up. That's a quite big problem of a word that you tried to handwave as a trivial problem. It's a big problem of a word that, without further definition and standardization, can easily turn that last step into "Use JScript to manipulate".

      And in case you're a little 12-year-old punk who didn't bother studying history and is wondering what's wrong with that, JScript and JavaScript are two very different things.

  22. I can relate to this way of thinking by puppybeard1257 · · Score: 1

    As somebody who's been avoiding standardisation of language for quite some time: rvt sdvrsv g stvvsr stbgvdyv rbuytynbdtyys bwrtybvey wrbywrtyrb brrbyrvyer tomato.

    1. Re:I can relate to this way of thinking by Anonymous Coward · · Score: 0

      MY MOTHER WAS A SAINT!

  23. Very much this. by Anonymous Coward · · Score: 1

    I hope there's a special place in Hell for the folks in invented and promoted Javascript.

    A place in Hell where they are forced to write documents in EBCDIC SGML. And active content in COBOL. With half a Visual Age IDE.

    Very much hate these marketing droids.

  24. Yes! by jonr · · Score: 2

    I like it. Let's just find a good name... lets see.. we can mark up everything now... so I guess we keep the "ML" part. And content authors can create new and unknown tags, the traditional symbol for unknown is X.. I know, lets call it XML!

  25. Re:It's the Islam folks by Anonymous Coward · · Score: 0

    Perhaps I'm just an American simpleton, but after fucking bombs go off in Boston, shouldn't the FBI have a really short list of who the fuck are suspected or known jihadis in this area?

    Why weren't warrants flying out and raids being conducted at all the relatives of these fucks immediately??? How many fucking radicals muzzies are in Boston anyway?? Russia contacted us MULTIPLE times about these fucks.

    The answer, dear reader, is the true incompetence and PC nature of this fucking government. Guarantee you they did not even have these fucks on a list of people who might be trouble in that area.

    Fucking. Filthy. Incompetent. Government.

  26. What's the point? by Anonymous Coward · · Score: 0

    Not standardizing HTML won't solve anything. Browser vendors implement new features all the time, standardization is what helps makes the new features tenable across platforms and devices. The situation's already bad enough, let's not seek to actively remove what little sanity is there just because things aren't already chaotic enough for some people.

  27. Summary by Anonymous Coward · · Score: 0

    Now there are standards so we can stop making standards. What an idiot.

  28. Re:Is he retired from lack of oxygen? by FuzzNugget · · Score: 1

    Damn you autocorrect. Sorry about the title typo.

  29. Search engine support for JavaScript by tepples · · Score: 1

    Then enable Javascript then

    Which web search engine supports indexing text added to the DOM by JavaScript? Otherwise, any web site that relies on JavaScript for basic functionality isn't going to get indexed well.

    1. Re:Search engine support for JavaScript by scot4875 · · Score: 2

      If someone is hiding their content behind JavaScript walls, they don't deserve to have it indexed.

      --Jeremy

      --
      Jesus was a liberal
    2. Re:Search engine support for JavaScript by osu-neko · · Score: 1

      You can also prevent indexing with robots.txt. Your point?

      --
      "Convictions are more dangerous enemies of truth than lies."
  30. HTML5 is a design by committee failure by exabrial · · Score: 4, Interesting

    HTML5 is the response by a bunch of whiners that normal xhtml is "too hard." Yes it's too hard to remember to close your tags. It's too hard to remember to put quotes around attributes. Why are humans checking your syntax? Have the danged computer check your syntax.

    "Pave the cowpaths" is an excuse to appease a bunch of zealots that are hellbent on pushing their personal preferences and egos into a standard rather than designing something that is quick/easy to parse and universally render across platforms. It's only going to get worse as the standard is never completed over the next decade.

    XML serialization of HTML sucks. It's verbose, and it's ugly. But it's effective because it's well defined and it leaves very little room for interpretation.

    Honestly, I'd like to see two standards. One, is XHTML5 Strict that follows the XML serialization. This will be left to the big boys who have real work to do. The other standard would be an extension to MarkDown to allow CSS customization with classes and ids. This would allow the path the cowpaths crowd to get things down as fast as possible and keep the verbosity of XML out of their way.

    1. Re:HTML5 is a design by committee failure by Anonymous Coward · · Score: 0

      "allow CSS customization with classes and ids"

      uhhh the 1990's called, and they want their technology back..

    2. Re:HTML5 is a design by committee failure by Anonymous Coward · · Score: 0

      This.

      "Pave the cowpaths" is an excuse to appease a bunch of zealots that are hellbent on pushing their personal preferences and egos into a standard rather than designing something that is quick/easy to parse and universally render across platforms.

      And not just a little bit of elitism thrown in for good measure; a lot of these guys really do think you're too stupid to use XHTML. As I was once told by Hickson: if you're using XHTML and you think things are working properly, you're wrong. You just haven't yet discovered how.

      Honestly, I'd like to see two standards. One, is XHTML5 Strict that follows the XML serialization. This will be left to the big boys who have real work to do. The other standard would be an extension to MarkDown to allow CSS customization with classes and ids. This would allow the path the cowpaths crowd to get things down as fast as possible and keep the verbosity of XML out of their way.

      It seems there may be a little shoving in this direction in HTML5. In the early days of that spec there wasn't even going to be an XML serialization; pushback from developers using XHTML forced that. The current action around polyglot documents may mean that this is indeed the direction things end up going.

    3. Re:HTML5 is a design by committee failure by exabrial · · Score: 1

      How then do you propose enhancement of markdown then to produce visually appealing designs?

    4. Re:HTML5 is a design by committee failure by exabrial · · Score: 1

      And not just a little bit of elitism thrown in for good measure; a lot of these guys really do think you're too stupid to use XHTML. As I was once told by Hickson: if you're using XHTML and you think things are working properly, you're wrong. You just haven't yet discovered how.

      Yes and no. XHTML removes the "how to parse" question. It only leaves the "how to render" question.

    5. Re:HTML5 is a design by committee failure by DragonWriter · · Score: 1

      HTML5 is the response by a bunch of whiners that normal xhtml is "too hard."

      No, its not. The issue wasn't that XHTML was too hard, it was that it wasn't backwards-compatible with most existing HTML on the web. (There might have been a concern with verbosity of the serialization, as well, though I don't know that it was a motivation.) WHATWG HTML Living Standard/W3C HTML5 makes HTML well-defined in a way which is consistent with most of the existing HTML in the wild and the way most browsers were handling HTML.

      XML serialization of HTML sucks. It's verbose, and it's ugly. But it's effective because it's well defined and it leaves very little room for interpretation.

      WHATWG HTML provides an unambiguous parsing of HTML that leaves no room for interpretation, without the verbose ugliness of XML. Of cousre, if you have an irrational attachment to XML, WHATWG HTML also provides an XML serialization as opposed to the HTML form. Feel free to use it.

    6. Re:HTML5 is a design by committee failure by Anonymous Coward · · Score: 0

      You, kind sir, do not deserve your +4.

      If you understood the HTML5 proposal, you would know that XHTML5 is part of it. Send your document with a MIME type of text/xml and every major browser will treat it as xhtml. But then you would have to know how to configure your servers. Do big boys like you understand how to configure their servers or is that something exclusive to PHP-using cows like me?

    7. Re:HTML5 is a design by committee failure by bussdriver · · Score: 1

      The web was popular because it was accessible and it worked reasonably well despite most people messing their HTML up; this is a concern and some think that XHTML 1 being extremely slow (arguably a failure) and that XHTML 2 died in part because of they lacked that understanding.

      Most the web is STILL in HTML 4.

      As one of the volunteers, I can tell you that pretty much every angle on such topics has been covered by somebody. The best decision is not always made but there is not much trouble in the opinion dept. HTML5 complicates things slightly by using MIME types to indicate an XML or HTML parser - defaulting to the HTML parser. There is an XML form of HTML5 look at the top of the spec, then configure your webserver to send the proper http header; meta tags with http data is a lame work around and I frankly do not know how successful that will be in practice.

      I suggest the parent see section 1.6 of the HTML5 spec: http://www.w3.org/html/wg/drafts/html/master/introduction.html#html-vs-xhtml

    8. Re:HTML5 is a design by committee failure by Anonymous Coward · · Score: 0

      What is a realistic benefit of XML compliance?

    9. Re:HTML5 is a design by committee failure by Algae_94 · · Score: 1

      What web are you looking at? This is the way to change the style of elements in HTML.

    10. Re:HTML5 is a design by committee failure by Common+Joe · · Score: 1

      I honestly don't know why every language doesn't include something like. Default to strict syntax. Add a line if you don't want strict. During compilation, a strict programmer knows that every file will be strict. (There's no way to forget to add the "compile strict because it doesn't exist.) If a programmer doesn't want strict compilation (think untyped variables and undeclared variables and no closing tags), they'll see a syntax error if they forgot the "don't want strict" thing. One line added and they are on their way. Simple. Easy. Everyone goes home happy.

  31. To be fair... by Junta · · Score: 3, Insightful

    His point was about web content being more dynamic than he thinks is required. A fair point, nowadays a straightforward web form with very limited scope is frowned upon if it neglects to do some sort of javascript trickery or another. He isn't after *more* capability, he seeks a more constrained experience and to have more developers exhibit a shred of restraint rather than mandate moderately more open ended access to the client facilities for superfluous bells and whistles. If a browser hangs up nowadays, it's almost certainly due to badly written javascript or javascript implementation gone insane in the face of valid javascript. Simplistic content doesn't choke up browsers and in a lot of cases, that simplicistic content model *could* suffice for the purpose. There are cases where javascript can enrich the experience beyond what is reasonable without it, but web developers immediately jump to the deep end without a second thought today.

    Now, in terms of 'powerful and flexible', I'd argue that inherently it cannot hold that crown precisely because javascript is restricted from doing things like opening arbitrary filehandles and such. This isn't a bad thing, but it means the claim of 'most powerful' is flawed. Javascript is a popular language not due to having 'the' best set of capabilities or the best syntax (everyone bundles some sort of 'library' precisely to bandaid over javascripts failing at the low level), it's popular by virtue of being ubiquitous.

    --
    XML is like violence. If it doesn't solve the problem, use more.
    1. Re:To be fair... by Anonymous Coward · · Score: 0

      (everyone bundles some sort of 'library' precisely to bandaid over javascripts failing at the low level)

      That's not really fair, or true. Everyone bundles some sort of library to hide what they consider the ugliness of the DOM (which has nothing to do with Javascript) and/or to deal with the fact that they refuse to learn to use Javascript properly. It's actually quite a nice language, but if you approach it as just another interpreted language with its roots in C (which everybody seems to insist on doing) you'll never get to see that.

    2. Re:To be fair... by Anonymous Coward · · Score: 0

      Unironically this.

      Remember how, a few years ago, people were talking about how the web was going to make powerful home computers obsolete? Web apps meant all the heavy processing would be done in the cloud, and your computer would just be a simple display terminal. Netbooks were all the rage, tablets were just round the corner.

      Fast forward to today, and it's like even the simplest-looking websites run like molasses unless you have the very latest browser running on the fastest computer money can buy, because of how much basic stuff is being pushed into JavaScript. And I can't say I've noticed anything being more powerful, or easier to use. It's pretty much exactly the same as it always was, just ... slower. And with infinite scrolling and more "Poke this on twitbook" buttons.

  32. Stop treating anecdotes from 13 year olds as news by Anonymous Coward · · Score: 0

    It gets old seeing "Here is my hastily considered opinion, with purely anecdotal support, based on my six months of experience in IT" bullshit treated as worthy a replication.

  33. Difference between scripts and programs by tepples · · Score: 4, Insightful

    A computer program is defined as "a set of statements or instructions to be used directly or indirectly in a computer in order to bring about a certain result," and a programming language defines the syntax and semantics of computer programs. So what makes a scripting language not a programming language? What makes a script not a computer program? For all I can see, JavaScript is like Lua and Python: a dynamically typed programming language that is transmitted over the wire in source code form.

    1. Re:Difference between scripts and programs by Anonymous Coward · · Score: 0

      The problem is that the definition you quoted is too broad. I am typing these words (statements) and will then click some buttons in order to cause a post to appear on this topic (bringing about certain result). Am I programming right this second, right now as I type this?

      Nope. :)

    2. Re:Difference between scripts and programs by K.+S.+Kyosuke · · Score: 1

      Am I programming right this second, right now as I type this?

      According to Matthias Felleisen, you are. Or, as the proverb says, "a data structure is just a stupid programming language". There's a smooth continuum here. Also, sufficiently complex library APIs form languages and languages become libraries of functionality. Another smooth continuum.

      --
      Ezekiel 23:20
    3. Re:Difference between scripts and programs by Anonymous Coward · · Score: 0

      Best definition I've heard is: "Programming languages tell computers what to do. Scripting languages tell programs what to do."

    4. Re:Difference between scripts and programs by khakipuce · · Score: 1

      See there's the thing - "a certain result" - Javascript brings about uncertain results!

      --
      Art is the mathematics of emotion
  34. We need better web tech PERIOD. by scorp1us · · Score: 1

    I find it rather abhorrent that the "Web Development" has become a mish-mash of technologies: HTTP, HTML, JS, CSS and extensions: DOM, AJAX.

    As a software developer this is a nightmare scenario. When we program computers, we should be programming for the web or directly on the client in a unified way that hides the intricacies of the base technologies from the developer. Imagine writing a program not knowing where it was going to run? Because you just wrote what it should do, and some compiler took care of mapping the concepts to whatever tech the client had available. C# kind of delivers this, but it is way too translucent that you're writing a web app when you are.

    There is a toolkit called Wt (http://www.webtoolkit.eu/wt) that is C++. What is Wt doing with C++ on the web? It's allowing you to program your application in an object-oriented way, and the koolhit takes care of mapping things to HTML, JSS, CSS for you! Now, C++ isn't what I would have chosen, but it's a good start. But the fact that you can effortlessly write a WebApp in C++ is nothign short of amazing. And on top of that you can have your functions exported to JS for execution by the client for Ajaxing. (Not ideal that you see that, [leakage] but very cool that you don't have to know JS or AJAX)

    If we stop standardizing, fine, but whatever we evolve to has to be (mandate, not conlcusion) a metric fuckton better than what er have now.

    --
    Slashdot's rate-of-post filter: Preventing you from posting too many great ideas at once.
    1. Re:We need better web tech PERIOD. by Rob+Riggs · · Score: 1

      I find it rather abhorrent that the "Web Development" has become a mish-mash of technologies: HTTP, HTML, JS, CSS and extensions: DOM, AJAX.

      Has become? Back in the day HTML was a mish-mash of tags and (eventually) DOM models that were abhorrent and incompatible across browsers.

      As soon as you standardize one thing, then the big boys are on to the next big thing. You still have a myriad ways to generate web content, all of which should shield the developer from most of the madness. Standards are good for taking a snapshot of the state of the art at a point in time, allowing developers to say "I support this version" and browsers to guarantee they will render standardized versions correctly. I expect every browser on the market today to correctly render all standardized versions of HTML.

      --
      the growth in cynicism and rebellion has not been without cause
    2. Re:We need better web tech PERIOD. by scorp1us · · Score: 1

      Agreed

      --
      Slashdot's rate-of-post filter: Preventing you from posting too many great ideas at once.
  35. Over engineering in Slashdot too by damaki · · Score: 1

    Let's stop standardizing stories to get better stories on Slashdot.
    First, we'll stop using tags and titles, it's a clear case of over categorizing
    Then, let's stop using english as a standard. Letters were meant to be used freely, not rigidly as used in english.
    Finally, we should remove links in stories, so that people can freely search these in the web.

    --
    Stupidity is the root of all evil.
  36. Web? Not anymore by Todd+Knarr · · Score: 1

    I notice that these days the pendulum is swinging again. Away from thin clients that just render what the software sent them. Towards thick clients running on the user's PC that handle the bulk of the processing, talking to a remote server to get the data and then using that data in a local program. The programs are written in different languages, Javascript instead of C/C++, and the data's XML rather than the various formats of a couple decades ago, but we're swinging back to the PC running the programs instead of them running on the server.

    So why aren't we just admitting it and saying "Our data's XML, you're going to need our software running locally to interpret it."? That's what non-standard application-specific "markup" languages would be, data that's meaningless without the accompanying program to interpret it.

  37. How about you just make your browser by Gripp · · Score: 1

    How about you make your own browser that doesn't follow any standards rather than making the rest of our lives hell?

  38. standards are good imo. by musixman · · Score: 1

    Yesterday I saw a piece of code a former employee wrote. The variable was declared as $starttheriot I dont' think anyone can imagine how out of control domain specific markup would get if this was allowed. i already spend WAAAAY to much time just getting things working for just IE.

  39. Extensible by BradleyUffner · · Score: 1

    Isn't this was the entire point of XHMTL is? "X" as in extensible.

  40. Re:Stop treating anecdotes from 13 year olds as ne by Anonymous Coward · · Score: 0

    FWIW, the writer of TFA is most likely 43 years old. That's assuming he graduated college at 22 as most do. Source: his CV

    Of course that doesn't mean he's right or wrong. Argument from authority is a fallacy, and conversely argument against a position based on inexperience is also a fallacy. If a math professor tells you 2+2=5 and a kindergartner tells you it's 4, it's up to you to evaluate their arguments based on something other than their experience.

  41. Stop Standardizing HTML Badly by Dracos · · Score: 3, Interesting

    HTML5 is riddled with faulty logic, flawed reasoning, and bad semantics. Even reading the spec gives the impression that the writing is of lesser quality than pervious versions. Why this is the case after 9 years completely baffles me.

    Selected points:

    • The b and i elements are presentational, no matter how the authors try to claim otherwise. Let them stay dead.
    • Sectioning is a mess, and whether related elements are sections is dependent on context. "Strongly Suggesting" that developers use h1 for every headline within sectioned content dilutes its semantic value. Just create a level-less h element, like XHTML2 did, that inherits its level based on depth and context.
    • There is still no way to clearly associate dd elements with their dt. Wrapping these sets with li would fix this.

    Last but not least: enough with the XML hatred. XHTML5, with proper XML syntax, should be the focus instead of an afterthought. XML syntax compliance isn't that hard or time consuming. Markup languages are for machine consumption, not human readability. Not requiring tags to be closed, bare unary attributes (ie, checked instead of checked="checked") and all the other shortcuts are asinine and only foster laziness and sloppiness... which would not be tolerated in any compiled or interpreted language.

    1. Re:Stop Standardizing HTML Badly by Tailhook · · Score: 1

      Markup languages are for machine consumption, not human readability

      Machines have no trouble with <option checked>foo</option>. The desire to force XML compliant checked="checked" on HTML is not rooted in parsing difficulty or performance or any other machine processing rationale. The only actual problem with <option checked> is that it offends the sensibilities of XML advocates. Writing interpreters capable of handling "unclosed" tags or valueless attributes is a solved problem.

      which would not be tolerated in any compiled or interpreted language.

      Among the common compiled languages we have C++ which "is ambiguous, context-dependent, and potentially requires infinite lookahead to resolve ambiguities," * and which precludes the use of parsers based on formal grammers. Perl is an example of an interpreted language that can't be parsed. Here is a thousand or so words on the implications of Javascript semicolon insertion.

      In short, your appeal to the rigor of compiled or interpreted languages is not credible.

      --
      Maw! Fire up the karma burner!
    2. Re:Stop Standardizing HTML Badly by Anonymous Coward · · Score: 0

      Pretty much every new-ish programming language does its best to minimize the amount of syntactical noise added to it. Even something Like Scala, a language that is not afraid of letting you create operators that look like ascii art, allows you to get rid of semicolons altogether.

      XML's closing tags are semicolons on steroids.

    3. Re:Stop Standardizing HTML Badly by Anonymous Coward · · Score: 0

      Not requiring tags to be closed, bare unary attributes (ie, checked instead of checked="checked") and all the other shortcuts are asinine and only foster laziness and sloppiness... which would not be tolerated in any compiled or interpreted language.

      May I introduce you to my friend "Perl"?

  42. Stop: I need to sell more JS/CSS O'Reilly Books! by tyrione · · Score: 1

    Piss off Simon.

  43. Then let's define computer program by tepples · · Score: 1

    A computer program is defined [in the U.S. copyright statute] as "a set of statements or instructions to be used directly or indirectly in a computer in order to bring about a certain result"

    The problem is that the definition you quoted is too broad.

    Tell that to Congress. In any case, I'm willing to work with any other reasonable definition of "computer program" that you can cite.

    I am typing these words (statements) and will then click some buttons in order to cause a post to appear on this topic (bringing about certain result).

    Ow. Mind screw. By your interpretation of the copyright definition, any HOWTO for an app or walkthrough of a video game is itself a computer program.

    1. Re:Then let's define computer program by jc42 · · Score: 1

      Ow. Mind screw. By your interpretation of the copyright definition, any HOWTO for an app or walkthrough of a video game is itself a computer program.

      Heh. One of my favorite programming experiences is the numerous times that people have noticed the entries in some of my Makefiles that run various "man ..." commands, pipe the results to various little perl programs, and drop the output into various .c and/or .h files. "WTF; your code reads the online manuals to generate the code?" "Yeah; you got a problem with that?"

      So we'd also conclude that the online man pages are in fact programs. Or actually, they're subroutines that just need a bit of preprocessing to convert them to the language in use on your project. Any competent perl (or python) programmer should be able to write such preprocessors. Extracting machine-readable information from human-readable documents was one of the original design goals of perl, and the python crowd also sees that as a significant niche for their favorite language.

      Do you think some people here might have a problem with that? ;-)

      --
      Those who do study history are doomed to stand helplessly by while everyone else repeats it.
  44. DOM for new input devices by tepples · · Score: 1

    Apart from the horrid time and memory inefficiency of your solution (which was the joke), how would you have implemented access to the joystick, camera, microphone, and various other peripherals with just divs? As more devices are brought into the scope of web applications, their components will need to be made available through new DOM APIs.

    1. Re:DOM for new input devices by diamondmagic · · Score: 1

      Because those are ECMAScript APIs which have nothing to do with HTML.

    2. Re:DOM for new input devices by phantomfive · · Score: 1

      Nah, for those I would use commas, not divs. Commas for 1s, periods for 0s. You could hack up a whole binary protocol going to the joystick.

      --
      "First they came for the slanderers and i said nothing."
  45. Until user agents by tepples · · Score: 1

    My point is that if someone wants to make something accessible with semantics, he'll have to find some way to express those semantics to search engine robots. Relying on WAI-ARIA to provide semantics won't work until user agents support WAI-ARIA. Wait, where have I heard "until user agents" before? Oh wait, that was WCAG from the same organization that made WAI-ARIA.

  46. Once a standard, now a crowd of sub-standards by waterbear · · Score: 1

    What was once a standard[...]

    Mod parent up.

    Yes, IMO it's realistic right to talk of the 'standard' in the past tense. Now many web-pages seem to have been affected by a 'tower of Babel' syndrome, with everyone asking their visitors to use their favorite subsidiary language upgrade -- but each new 'sub-standard' seems to have its undocumented variants.

    -wb-

  47. Oh god by SmallFurryCreature · · Score: 2

    Yeah, and if people just used the amount of car they need to get from A to B, polution would plummet and fuel prices would go down and the roads wouldn't need so much maintenance. You FIRST!

    The original web was designed as a gigantic book where instead of footnotes, you could click on a reference and read it from there. Everything else is fluff but it is that fluff that made the web. Want to see the original web, just browse wikipedia. It is very useful, even essential perhaps BUT it is not all of the web. All of the web is content sites that don't want you to leave for other sites. It is games, it is forums, it is applications that are on the web despite being better suited to a desktop. The web has far outgrown its original vision.

    BUT it could only do this because there WAS a standard to follow. A web application being so easy to install (runs on any browser equipped machine) only works if whatever browser is installed follows a standard. The reason Gmail has long since replaced outlook express is that you need to install outlook express and configure it. With the gmail web application, you just go to the url and it just works. That could NEVER have happened if there were a dozen different browsers out there with a dozen different markup languages. Proof?

    There are PLENTY of markup languages, I remember one from an old color matrix printer where you could insert color codes. .rtf is a markup language. xml is a horrid collection of them.

    HTML works because anyone can look up the specs and the spec doesn't constantly change. We KNOW what happens when you let everyone create their own version, it is called IE and I will kill you before we go back to those days and not a jury in the world will convict me.

    And if you want a markup language that does more? CREATE YOUR FUCKING OWN ONE! You are perfectly free to create a new type of "browser" with a new way to getting it to render data files into whatever you bloody well please. Plenty gone before you. And you know why you know of so fucking few? Because everytime somebody says "this should be a new standard" ten other people say exactly the same thing.

    You can't create a new standard without getting everybody onboard and that means making compromises.

    You can already extent HTML all you want, create a new element if you must but just don't claim to follow the standard strict and you are free to use whatever means you want to then render those new elements. Many common librabries already do this.

    But this guy wants to take the strict standard and then add to it and then have it become the new standard. That won't work.

    --

    MMO Quests are like orgasms:

    You may solo them, I prefer them in a group.

    1. Re:Oh god by Junta · · Score: 1

      My point was that the GP was saying too much javascript is used such that disabling javascript is infeasible in scenarios where, really, javascript is superfluous.

      --
      XML is like violence. If it doesn't solve the problem, use more.
    2. Re:Oh god by TapeCutter · · Score: 1

      You can't create a new standard without getting everybody onboard and that means making compromises.

      This is slashdot, take your "people problems" elsewhere. /jk

      --
      And did you exchange a walk on part in the war for a lead role in a cage? - Pink Floyd.
  48. subject by poor_boi · · Score: 2
    He basically wants to drop tag names and just have tags create generic dom nodes which get sculpted by CSS and JS.

    <html6style>
    .myCoolTag { act-like-html: br }
    .heyThisIsFun { act-like-html: p }
    .canWeDropTheHtmlStandardNow { act-like-html: i }
    </html6style>
    <html>
    This is the first line.
    <html class="myCoolTag">
    This comes after a newline
    <html class="heyThisIsFun">
    This comes after a paragraph break.
    <html class="canWeDropTheHtmlStandardNow">And this is italicized.</html>
    </html>

    That's too verbose for him though, so he wants to be able to write this:

    <html6style>
    .myCoolTag { act-like-html: br }
    .heyThisIsFun { act-like-html: p }
    .canWeDropTheHtmlStandardNow { act-like-html: i }
    </html6style>
    <html>
    This is the first line.
    <myCoolTag>
    This comes after a newline
    <heyThisIsFun>
    This comes after a paragraph break.
    <canWeDropTheHtmlStandardNow>And this is italicized.</canWeDropTheHtmlStandardNow>
    </html>

    You'll notice that all this does is push the HTML spec into the CSS spec. I don't see much of an advantage to that. And it makes it impossible to get even a basic understanding of HTML document structure without constantly referring back to the CSS.

    He also wants all new features that would previously have been implemented by adding tags to the HTML specification to be implemented by way of shims (polyfills). But who standardizes the behavior of shimmed constructs? Well, nobody. People just pick the shims they like. And because the shims are JS + CSS, the W3C is in charge of making sure the browsers execute them properly. Kind of like how today the W3C is in charge of making sure browsers execute HTML properly.

    I think this guy might be happy if we got rid of every tag except <canvas> and all reusable components (e.g. <button>) came from third party vendors. E.g. <include src="http://html6.google.com/button.polyfill">. Oh boy I can't wait.

    1. Re:subject by Shados · · Score: 1

      Wasn't that exactly what XHTML was supposed to become?

    2. Re:subject by Animats · · Score: 1

      Wasn't that exactly what XHTML was supposed to become?

      Sort of. In XHTML you can add new tags. But the web development community can't handle XHTML. Open and close tags must match, and they can't do that consistently.

      (Real-world HTML is incredibly bad. Most major sites still won't go through an HTML validator. Even superficial parsing is hard. Incorrect comment delimiters are all over the place. HTML5 has well-defined parsing of bogus HTML, so now all major browsers interpret bad HTML the same way. Just trying to figure out what character set a page is really in requires a huge amount of machinery.

      The W3C should have specified that browsers, upon detecting a syntax error in HTML, should put an error message bar in the document, and from that point forward, render in a "basic default mode", where all the content is displayed in the default font, color, and size. That would have cleaned up the web.)

  49. absolutely by CFD339 · · Score: 2

    The person who came up with the way xml signatures work clearly already had some kind of disease. I'm thinking late stage syphilis.

    --
    The problem with quotes on the internet, is that nobody bothers to check their veracity. -- Abraham Lincoln
  50. I love open standars by Anonymous Coward · · Score: 0

    Fuck you pfignaux!!! everybody want standars!!!

  51. Why not do it like desktops? by Anonymous Coward · · Score: 0

    Have web browsers act as virtual environments for any language to run on. That way as long as it can compile into some base programming language (whether that is bytecode or assembly) any language can be used and anything can be done.

  52. Standard Generalized Markup Language by Anonymous Coward · · Score: 0

    STANDARD Generalized Markup Language.

    If you personally do not like the Document Type Description developed in accordance with the agreed upon rules of the ISO STANDARD, then write and use your own.

    IF yours is so much better than the rest, maybe then you can also provide the document interpreter software and make a whole bunch of money with your PROPRIETARY system.

    HMMMMM, wait a minute, is this not what Microsoft is still trying to do unto the world with little success outside of the corporations and government IT offices?

    Guess the business model for moving Navigator out of the University research laboratory had something to be recommended after all.

  53. Precedence by Anonymous Coward · · Score: 0

    This almost seems similar to what DITA has achieved. http://dita.xml.org/ You have an XML standard and you can specialize with domain specific semantic tags.

    It's incredibly powerful but comes with a steeper learning curve.

    Add RelaxNG into the mix (instead of DTD/XSD) and I think it's doable and a cool idea.

  54. So you want to rename the standard? by BitZtream · · Score: 1

    Why exactly do we need to abstract our abstraction layer ... AGAIN?

    Anyone making this sort of suggesting can not have more than a few years real world experience

    --
    Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
  55. The 90's called by guruevi · · Score: 1

    They want their browsers back. Seriously, who thought that we should go back to non-standardized, browser-specific websites? Blink tag, marquee anyone? How about bgsound?

    --
    Custom electronics and digital signage for your business: www.evcircuits.com
  56. The Fundamental Problem with HTML/JS/CSS by Anonymous Coward · · Score: 0

    Is that's it's a round peg (presentation oriented technology) trying to fit in a square hole (applications development).

    HTML5 is just more of the same. The entire paradigm of the web (and thus the tools) was built around simple, presentation oriented UIs. Nothing wrong with that: in fact it does a *great* job, all things considered at what it was designed for. Problem is, it wasn't ever designed with rich UI applications in mind, which is why it takes ungodly hacks (i.e. JQuery, Dojo, etc.) to get anything done.

  57. Roll Your Own Tags = ColdFusion by Tablizer · · Score: 1

    let developers choose their own markup vocabularies

    Sounds almost like Adobe ColdFusion, except more on the client-side. It can be quite useful for pre-packaging your shop's UI idioms and handy short-cuts for non-programming web designers.

  58. W3C HTML5 vs. WHATWG HTML Living Standard by DragonWriter · · Score: 1

    HTML5 never will be "finalized," since it's not a W3C recommendation.

    Its a W3C Candidate Recommendation that is scheduled to reach Recommendation status next year.

    The whole idea is that it will be a living, evolving standard, with various features being adopted piecemeal in browsers.

    You are likely confusing the WHATWG HTML Living Standard (which has no number) with W3C HTML5. They are two different things.

    In other words, it will always be in development and there will never be an "HTML6."

    There may or may not be an HTML 6, but there is already an HTML 5.1 in development.

    1. Re:W3C HTML5 vs. WHATWG HTML Living Standard by Anonymous Coward · · Score: 0

      Thanks for the update. I had only heard about WHATWG's efforts.

      (captcha: rotten)

  59. Stop trying to make everything XML gratuitously by DragonWriter · · Score: 2

    Last but not least: enough with the XML hatred. XHTML5, with proper XML syntax, should be the focus instead of an afterthought. XML syntax compliance isn't that hard or time consuming. Markup languages are for machine consumption, not human readability.

    Markup languages are for both, that's what distinguishes markup languages from, say, binary data formats. And HTML5 has parsing rules that are just as unambiguous for machine reading as XMLs, defined in the standard, and don't need the verbosity of XML to acheive it.

  60. Re:Stop treating anecdotes from 13 year olds as ne by Anonymous Coward · · Score: 0

    Reading his CV and his arguments (both the article and his posts in this story) I would say that he appears to have made a career out of knowing how to write HTML, XML, CSS and a handful of other frontend web dev technologies but lacks any real understanding of how they, or the web, actually work.

  61. program = algorithm + data by TapeCutter · · Score: 1

    So we'd also conclude that the online man pages are in fact programs.

    From a computer science POV the classical definition of "program" comes from Knuth; program = algorithm + data, in your makefile scenario the man pages are data.

    And yes, my build + package infrastructure is written in python, I specifically set out to learn python because after an afternoon of tinkering I strongly suspected it would be better than batch files and shell scripts we were using. I've been using it for a few years now in production, works well on windows and the four flavors of unix we officially support. Python's portability also makes it easy to write scripts for developers to handle the old growth forest we affectionately call our CVS repository (~30 active project/version combinations and a thicket of legacy projects).

    How do we handle the 3.0 fork I hear you say? - we don't, we picked 2.5 and stuck with it but most the stuff would run happily of the latest 2.x should we find a valid reason to update. And yes, on the surface it looks like we should also be using git or subversion but none of us see the effort of conversion to be worth it when most of the practical deficiencies of CVS can be over come with a few lines of python.

    --
    And did you exchange a walk on part in the war for a lead role in a cage? - Pink Floyd.
  62. Program = Algorithm + Data. by TapeCutter · · Score: 1

    The OS depends on the bios, ie: a program to load the bootstrap program. Following the turtles further down we find the line between hardware and software starts to blur. As I said elsewhere, Donald Knuth defined "program" as, program = algorithm + data, it's the definition 9 out of 10 computer scientists recommend.

    Disclaimer: IAACS.

    --
    And did you exchange a walk on part in the war for a lead role in a cage? - Pink Floyd.
  63. This is so slashdot... by Anonymous Coward · · Score: 0

    Why all the hate? He makes a valid point: the semantics of HTML does not fit the given task anymore. The HTML5 people are desperately trying to keep up, but face it! This is not your grandaddy's internet anymore. HTMLs primary purpose isn't to render scientific documents anymore, it is to provide all kind of services and data to the users. And in the face of this change, the current HTML semantics just don't work anymore.

    Now, extending HTML by your own is not a problem. Every modern browser handles unknown HTMLElements just fine - go try it. And this is good, because it allows to code into the future, not into the past. As a web developer, I constantly struggle to match the semantics of the data I want to present to the user to the semantics of HTML.
    Let's say have to render a web basket here in HTML. Ok, let's see what HTML offers. Eh.. div, yeah, great. Article? Better. But then I have to render the individual items in the basket as well. Should I render this as Article as well? Yeah, I could use classes to provide semantics, but that just gets unreadable, and HTML (as are all SGML descenants) is a real pain to read. It's simply to verbose.

    So why not simply use 'basket' and 'item' elements to render my basket and items? It's not as if I would lose functionality; Article is not associated with behaviour. Also, 'Article' isn't styled, so I still have to style it using CSS. So I'm not gaining anything either. Quite the contrary; I'd have to use css classes for freakin' semantics, now that's just stupid.

    Now I could propose a webshop extension to HTML6, with 'basket' and 'item' sanctified by the holy HTML sea. And along with the other 999,999 specified use cases for the web, each with its own elements and semantics we'll create a uncomprehensible monster that nobody ever's gonne understand anyway. Big win, yeah.

    By using custom 'basket' and 'item' HTML elements, I gain semantics and don't lose anything. It's time to accept that and make a last and final change to HTML once and forever; "Ever unknown HTML element is rendered as an unstyled block level element."

    Cheers,
    AC

  64. Re:http://www.linuxadvocates.com/p/support.html by Anonymous Coward · · Score: 0

    I will not donate to an organization that spams the comments section of Slashdot or any other website. It's pathetic. Go away.

  65. JavaScript differences or DOM differences by tepples · · Score: 1

    In my experience, JavaScript is pretty much identical across browsers. It's the HTML DOM (everything under document and most under window) that's inconsistent.

  66. Machine language is a scripting language by tepples · · Score: 1

    "Programming languages tell computers what to do. Scripting languages tell programs what to do."

    Under the definition that you propose, machine language for a CISC microprocessor is a scripting language because it tells microcode in the processor, which is a program, what to do. As is Java or .NET bytecode because it tells the VM what to do. As is C because it tells the compiler what to do.

    1. Re:Machine language is a scripting language by Anonymous Coward · · Score: 0

      Well, yes, there is some gray area. The distinction lies in how you use the language, not in the language itself. As other people have pointed out, you can write self-contained applications with "scripting" languages and you can use fully functional programming languages for scripting.

      I'm not sure I would call microcode a "program," exactly. At least not the kind of general-purpose program you would want to script.

  67. Language vs. libraries by tepples · · Score: 1

    Because those are ECMAScript APIs which have nothing to do with HTML.

    In what part of ECMA-262 are joystick, camera, microphone, accelerometer, etc. defined? If they're defined only by some spec on w3.org or whatwg.org, then they're APIs that HTML adds to ECMAScript.

    1. Re:Language vs. libraries by diamondmagic · · Score: 1

      You don't need HTML to use any of the APIs, they're just APIs that any library could choose to implement. DOM, WebRTC, IndexedDB, Canvas, RDF Interfaces, and plenty more all have notable non-Webbrowser implementations. You don't actually even need ECMAScript, the definitions are specified with WebIDL specifically so they can be implemented in Java and C++, too: DOM API is pretty much the standard API for reading XML data in any programming language that has an XML parser (it's the one that specifies getElementById, etc).

      And bear in mind there's other ECMAScript APIs too. Khronos Group defines UInt8Array, etc, designed for use with GL. But you don't find that in ECMA-262.

  68. Site-specific browsers? by MikeBabcock · · Score: 1

    I can't wait for sites to claim I need their private browser release to browse their data.

    Oh I'm sorry, you can't use the nasa.gov site without the RedCow* browser, because RedCow's sponsoring us to make you use it.

    Blah

    *RedCow not related to actual energy drink company.

    --
    - Michael T. Babcock (Yes, I blog)