Forgot your password?
typodupeerror
Programming

Stop Standardizing HTML 302

Posted by Unknown Lamer
from the remember-xhtml-2.0 dept.
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.
This discussion has been archived. No new comments can be posted.

Stop Standardizing HTML

Comments Filter:
  • Nope (Score:5, Informative)

    by Anonymous Coward on Wednesday April 24, 2013 @11:32AM (#43537015)
    How about "no"?
  • language (Score:5, Insightful)

    by schneidafunk (795759) on Wednesday April 24, 2013 @11:34AM (#43537037)
    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!
    • by gl4ss (559668)

      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.

      • by Sigg3.net (886486)

        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?

    • Re:language (Score:5, Funny)

      by BForrester (946915) on Wednesday April 24, 2013 @02:33PM (#43539021)

      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.

  • by clem (5683) on Wednesday April 24, 2013 @11:34AM (#43537047) Homepage

    Stop making our job skills transferable!

  • HTML isn't anymore (Score:2, Interesting)

    by Anonymous Coward

    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

    • by telchine (719345) on Wednesday April 24, 2013 @11:39AM (#43537097)

      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

    • by Lord Lode (1290856) on Wednesday April 24, 2013 @11:40AM (#43537109)

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

      • 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?

        • by Ultra64 (318705) on Wednesday April 24, 2013 @11:55AM (#43537297)

          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

          • Re: (Score:3, 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.

          • by lgw (121541) on Wednesday April 24, 2013 @01:11PM (#43538279) Journal

            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?

        • 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.
          • , 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++.

      • 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.
    • by TWiTfan (2887093) on Wednesday April 24, 2013 @11:48AM (#43537179)

      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.

    • 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.

    • by istartedi (132515) on Wednesday April 24, 2013 @11:57AM (#43537313) Journal

      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.

      • 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.

    • by GrumpySteen (1250194) on Wednesday April 24, 2013 @11:59AM (#43537335)

      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.

      • by skids (119237)

        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.

        • 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 [wikipedia.org] 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.

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

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

    • by grumbel (592662)

      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, y

    • by fermion (181285)
      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,
    • 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-

  • by fazey (2806709) on Wednesday April 24, 2013 @11:37AM (#43537071)
    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.
    • by Synerg1y (2169962) on Wednesday April 24, 2013 @11:55AM (#43537293)

      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.

      • by Kookus (653170)

        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 [simonstl.com]

  • by whizbang77045 (1342005) on Wednesday April 24, 2013 @11:38AM (#43537077)
    But it's working the way it is. The time-honored software way is to fix it.
  • by femtobyte (710429) on Wednesday April 24, 2013 @11:38AM (#43537083)
    <_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.
    • Netscape navigator introduced the notorious BLINK tag and things like frames, back in the early days it pretty much was a free for all.

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

      • by mwvdlee (775178)

        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.

      • 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!!!

  • by concealment (2447304) on Wednesday April 24, 2013 @11:39AM (#43537089) Homepage Journal

    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.

    • 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.

    • by Synerg1y (2169962)

      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 a

    • 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 i

      • 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>

  • "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 [wikipedia.org]. 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?

    • by fuzzyfuzzyfungus (1223518) on Wednesday April 24, 2013 @11:57AM (#43537315) Journal

      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 [google.com] 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!

    • by phantomfive (622387) on Wednesday April 24, 2013 @01:07PM (#43538229) Journal

      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.

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

      • 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 [arewemobileyet.com] 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.
  • Standardize! (Score:5, Insightful)

    by Murdoch5 (1563847) on Wednesday April 24, 2013 @11:41AM (#43537119)
    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.
  • by eexaa (1252378) on Wednesday April 24, 2013 @11:53AM (#43537257) Homepage

    If in doubt, add one more complexity layer.

  • 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

    • 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

    • 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.
  • News at 11.

    Thank you, /., for thinking this matters.

  • 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.

  • by jonr (1130) on Wednesday April 24, 2013 @12:07PM (#43537433) Homepage Journal

    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!

  • by exabrial (818005) on Wednesday April 24, 2013 @12:11PM (#43537477)
    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.
  • 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 m

    • by Rob Riggs (6418)

      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

  • 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.
  • 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 in

  • How about you make your own browser that doesn't follow any standards rather than making the rest of our lives hell?
  • by Dracos (107777) on Wednesday April 24, 2013 @01:30PM (#43538455)

    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.

    • 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 ach

  • by poor_boi (548340) on Wednesday April 24, 2013 @02:18PM (#43538895)
    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.

"Stupidity, like virtue, is its own reward" -- William E. Davidsen

Working...