Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×
Programming IT

How To Use HTML5 Today 155

Posted by CmdrTaco from the but-i-wanted-it-yesterday dept.
snydeq writes "InfoWorld's Dori Smith offers developers a hands-on guide to using HTML5 today. 'Many of the media reports about HTML5 have focused on the politics, the "not until 2022" sound bite, or on HTML5's prospects as a "Flash killer." The reality of HTML5 is simply that it's the long-needed and long-overdue update to HTML4 — and you can start to implement it today,' Smith writes. Video, semantic tags, smart form input validation — Smith steps through several HTML5 features that can already be implemented, while noting several other presentation features that will soon be on their way. Smith also discusses IE work-arounds, such as HTML 5 Shiv and Google Chrome Frame."
This discussion has been archived. No new comments can be posted.

How To Use HTML5 Today More

How To Use HTML5 Today

Comments Filter:

  • heh (Score:5, Funny)

    by Pojut ( 1027544 ) on Monday July 12, 2010 @10:47AM (#32875146) Homepage

    Smith also discusses IE work-arounds, such as HTML 5 Shiv

    Shanks a lot for the info ::fft fft::

    • Re:heh (Score:5, Informative)

      by mcgrew ( 92797 ) * on Monday July 12, 2010 @01:53PM (#32877264) Homepage Journal

      Pardon the interruption, and sorry I'm a little late to the party, but I wish they would link the quick loading single page version [infoworld.com] of TFA rather than five ad-laden three paragraph apiece pages.

      I avoid infoworld and many other such sites because of this cluelessness. Annoying your readers is a grat way to keep them from coming back. This is the first infoworld article I've read in quite some time; now I remember why I quit going there.

  • Meanwhile, back at the ranch ... (Score:3, Insightful)

    by Infernal Device ( 865066 ) on Monday July 12, 2010 @10:58AM (#32875248)

    We wait around while the W3C tries to pull it's thumb out of it's ass.

    How hard is it to decide on a new standard? Do the members not check their email more than once a year?

    • Re:Meanwhile, back at the ranch ... (Score:5, Interesting)

      by bunratty ( 545641 ) on Monday July 12, 2010 @11:01AM (#32875302)
      Why wait? I use HTML5 today. I start documents with <!DOCTYPE html> and code away. The W3C validator even validates HTML5 documents. What are you waiting for? Maybe for Internet Explorer, but that's Microsoft's responsibility to update.

      • Re: (Score:3, Insightful)

        by geminidomino ( 614729 )

        Maybe for Internet Explorer, but that's Microsoft's responsibility to update.

        And it's web developers' responsibility to make sure that their shit works for its target audience, even if that means holding back because the clueless masses that comprise said audience insist on using Microsoft's cripple-ware.

        • Yes, of course, but we can't blame the W3C for deficiencies in Internet Explorer, now can we? If we're waiting on Internet Explorer to catch up, we should blame Microsoft for lagging behind.

          • Re: (Score:3, Insightful)

            by elrous0 ( 869638 ) *
            Blame whomever you want, I still have to go to a client and explain to them why the webpage I designed for them doesn't work right in the most popular browser on the market (and then explain to them why they shouldn't fire me).
            • Yes, you should test your page on Internet Explorer. But you can't blame the W3C for Internet Explorer's deficiencies, can you? My point was that we're waiting around for Microsoft to support HTML5 in IE, not waiting for the W3C to do something.

          • I wasn't blaming them. I thought that referring to IE as "cripple-ware" would make it clear where I place the blame.

            I was just offering another POV on what seemed to me to be a rather cavalier attitude towards supporting what is, for better or for worse (mostly worse), still the majority browser.

            • I made no comment about supporting or not supporting a browser. I said that if we're waiting on anyone to do something, we're waiting on Microsoft to add HTML5 support to Internet Explorer before we can use HTML5 features. We're not waiting on the W3C to do something.

        • Re: (Score:3, Informative)

          by GreyWolf3000 ( 468618 )

          You can include a tiny bit of javascript and have IE7+ (and 6 as well), "understand" all of the new elements. Google it.

          • Re: (Score:2)

            by Korin43 ( 881732 ) *
            You don't need Javascript, just add some CSS telling it what the new tags are (article{ display:block; }, etc.). Of course, the tags that are easy to include aren't the interesting part.
            • That doesn't work. IE doesn't add the new tags to the DOM properly; tags withing the <article> tag will be added as siblings to the <article>, rather than children. The only way I've found to make an HTML5 site work in IE is to surround all the new tags with old tags, and reference the old tags in the CSS.
              For example: <div class="article"><article>...

              • Have you tried the shiv technique mentioned in TFS?

                • Only just now. It works. I'm a little hesitant to rely on it though, as the styling would be completely messed up for IE users with javascript disabled. But then again, the percentage of IE users with javascript disabled is probably very low.

        • Re: (Score:3, Insightful)

          by cervo ( 626632 )
          This is not flame bait. A site that doesn't work with Internet Explorer is ignoring a huge chunk of the market. Most businesses cannot afford to ignore the IE users...

        • Maybe for Internet Explorer, but that's Microsoft's responsibility to update.

          And it's web developers' responsibility to make sure that their shit works for its target audience, even if that means holding back because the clueless masses that comprise said audience insist on using Microsoft's cripple-ware.

          Those with mod points... you may not like his message, you may not like the way he worded it... but if you've ever been a web developer for any company that needs a web presence everyone can use, then you know what geminidomino says is true. So... why is it modded flamebait?

      • Why wait? I use HTML5 today. I start documents with <!DOCTYPE html> and code away. The W3C validator even validates HTML5 documents. What are you waiting for? Maybe for Internet Explorer, but that's Microsoft's responsibility to update.

        By writing that you don't use "HTML5", you only use the HTML5 recommended doctype. As you know, it largely does nothing, except kick in "standards" mode in all browsers, and yes, including Microsoft browsers as well, so you've proactively blamed them for nothing.

        That doctype working doesn't mean all in the HTML5 recommendations will work, including even in browsers like Safari, Opera and Firefox, given HTML5 is still a spec in progress, and it's highly modular, meaning we may not see the entirety of it for

    • Re:Meanwhile, back at the ranch ... (Score:5, Insightful)

      by fuzzyfuzzyfungus ( 1223518 ) on Monday July 12, 2010 @11:27AM (#32875524) Journal
      The problem isn't "deciding on a new standard"(though there certainly can be engineering challenges and whatnot), the problem is that the W3C doesn't have any power beyond a modicum of respect and whatever consensus it can hammer out.

      They could pump out purely theoretical standards, either with no real implementations, or an alpha implementation stashed on somebody's git repo somewhere, all they like, as fast as their merry little legs could carry them; but that would be basically meaningless.

      The delay comes out of the fact that, unless enough parties from the various browser makers can be convinced to care, the standard is dead on arrival. Politicking is slow.

      • Re: (Score:2)

        by hkmwbz ( 531650 )
        What are you talking about? There are multiple implementations of various parts of HTML5. Opera, Chrome, Firefox, Safari, IE9 all implement parts of it. Often the same parts. HTML5 is a result of browser makers getting together.

    • Re: (Score:3, Insightful)

      by shentino ( 1139071 )

      Politics is never easy.

      Especially when the various members have a way to profit from making things proprietary at the expense of everyone else.

      The recent wrangle on a standard video codec is a prime example with everyone pushing their own pet patented algorithm.

    • We wait around while the W3C tries to pull it's thumb out of it's ass.

      How hard is it to decide on a new standard? Do the members not check their email more than once a year?

      The standard is basically decided upon. Most of the important parts look about the same now as they did two years ago. What we're waiting for is implementation. It's all very well to write a spec, but implementing it efficiently and correctly takes far more time. This is why every new browser release touts all the new parts of the HTML5 standard they implemented: the spec is mostly stable, and browsers are in the process of implementing it.

      I do think you're underestimating the difficulty and complexit

    • Re: (Score:3, Informative)

      by BZ ( 40346 )

      > How hard is it to decide on a new standard?

      Generally, not much harder than writing any piece of technical writing of the same length which has multiple authors with different (and generally conflicting) agendas. The time will also depend on the desired quality of the standard, of course. Writing a standard that says "do something here" or "behavior is not defined" takes less effort than one that carefully describes what a conforming implementation is supposed to do.

      The length in this case is order of

  • Is HTML 5 still structured as XML? (Score:5, Interesting)

    by Crazy Taco ( 1083423 ) on Monday July 12, 2010 @10:58AM (#32875254)

    Is HTML 5 still structured like XHTML? I hope that it is, because one of the biggest pains in the HTML standard was the inconsistent syntax. I think a strength of strict XHTML was that it could be easily parsed by an XML parser, and if we are going back to the syntax of HTML 4 I think that's a step backwards.

    • Re:Is HTML 5 still structured as XML? (Score:5, Informative)

      by GreyWolf3000 ( 468618 ) on Monday July 12, 2010 @11:01AM (#32875294) Journal

      There is an XML syntax for HTML5 that you can optionally use.

      • Re: (Score:2)

        by dzfoo ( 772245 )

        So, if a developer opts to not use it, what does he use? Are we back to the days of un-balanced paragraph and table cell tags, with each web browser making its own assumptions regarding conflicting layout possibilities?

                -dZ.

        • Then he uses the SGML binding instead of the XML one. As with HTML, this has well-defined semantics. Each tag indicates in the DTD whether it requires closing, overlapping tags (e.g. <b><i></b></i>) are not permitted, just as they were not with HTML. The parser needs to be aware of tag semantics, so self-closing tags (e.g. br) must be used carefully and you can not use other XML formats (e.g. SVG) inline.
        • The HTML syntax. While it is allowed to do, e.g., <!doctype html><p>foo<p>bar, there are (as there were in HTML 4) strict rules about when a tag can be omitted. As for parsing, HTML5 defines how to map any character stream into a DOM (from which normal CSS rules can be applied, without knowledge of the raw source, consistent with how browsers are already architectured) -- defining this was a large part in the reason for HTML5 existing at all.

      • Re: (Score:3, Insightful)

        by shutdown -p now ( 807394 )

        I don't think that it helps in a sense GP implies. If HTML5 was XML-only, that means that any automated tools (such as web scrapers) can just use XML parsers to process content. If it's up to the author, that means we'll have to keep dealing with special parsers for tag soup for decades to come.

        • Yet realistically if HTML5 was purely XML, how would it help with all the existing content on the web? What would be the roadmap for transitioning to XML from HTML? XHTML 1.0 became a REC over ten years ago now, and we're not much closer to a pure XML web now than we were then. The big advantage of HTML5 with dealing with arbitrary content is that it has defined parsing rules for any input stream, mapping it to a DOM. This means libraries that parse XML into a DOM can be interchanged with libraries that pa

          • Re: (Score:3, Insightful)

            by shutdown -p now ( 807394 )

            Yet realistically if HTML5 was purely XML, how would it help with all the existing content on the web? What would be the roadmap for transitioning to XML from HTML? XHTML 1.0 became a REC over ten years ago now, and we're not much closer to a pure XML web now than we were then.

            The main reason why XHTML didn't help was because it didn't add anything on top of HTML4 except for XML syntax. Consequently, most browsers didn't even bother properly supporting it back then - they simply added a few more kludges to their existing HTML parsers to handle XHTML as a kind of "broken HTML" that they realistically had to deal with, anyway.

            HTML5 is different in that it adds a lot of new features. If it also mandated that anyone using them (and, in general, "DOCTYPE html") must serve well-formed

            • What major browser just added a few kludges? Gecko and Presto always used an XML parser. KHTML is the only UA I'm aware of that used their HTML parser for XHTML, but that never had much marketshare (WebKit has always used an XML parser, once it came into existence). I'm not convinced uptake would be much quicker: most content nowadays comes through a CMS of some sort, almost all of which are nowhere near capable of guaranteeing their output will be well-formed (just try throwing in a U+FFFF character into

              • Gah, I always expect paragraphs to be added automatically in CMSes; to repost with paragraphs (albeit probably still with too few):

                What major browser just added a few kludges? Gecko and Presto always used an XML parser. KHTML is the only UA I'm aware of that used their HTML parser for XHTML, but that never had much marketshare (WebKit has always used an XML parser, once it came into existence).

                I'm not convinced uptake would be much quicker: most content nowadays comes through a CMS of some sort, almost

                • Gah, I always expect paragraphs to be added automatically in CMSes

                  "Options -> Comment Post Mode -> Plain Old Text" will make every blank line count as paragraph.

                  What major browser just added a few kludges? Gecko and Presto always used an XML parser. KHTML is the only UA I'm aware of that used their HTML parser for XHTML, but that never had much marketshare (WebKit has always used an XML parser, once it came into existence).

                  IE, as usual...

                  Anyway, I consider "use XML parser first, fall back to HTML one if XML is not well-formed" a hack as well, since the end result is the same.

                  Overall, I guess you're right, anyway. Still, a geek isn't a geek without bitching about the missed opportunity for making something more elegant every now and then... ~

    • Re: (Score:2)

      by mcgrew ( 92797 ) *

      ...one of the biggest pains in the HTML standard was the inconsistent syntax.

      Can you elaborate, or give examples?

      • Re: (Score:3, Insightful)

        by Denis Lemire ( 27713 )

        HTML had far too many ways to do things relative to XHTML

        * Uppercase or lower case tags, who cares, they're case insensitive
        * Single quote or double quote attributes values, take your pick or mix them, who cares
        * Do attributes even have a value? Sometimes...
        * Close your tags, don't close your tags... It varies, who cares?
        * Etc...

        All of these made parsing HTML a pain cause you couldn't make any assumptions about the syntax. Often you would find inconsistencies with the above within one document. XHTML was fa

    • Re:Is HTML 5 still structured as XML? (Score:4, Interesting)

      by Nadaka ( 224565 ) on Monday July 12, 2010 @11:56PM (#32883524)

      Unfortunately, No. HTML5 was designed by the guys that thought that XML was to hard, So they wrote a 5000 page spec that codified all the ways that browsers tried to handle broken syntax and made that the standard...

      You think I am joking. I am not.

      My hat of html05 know no limit. (ok, so thats a joke, but few here will get it.)

  • Dive into HTML5 (Score:5, Informative)

    by 0100010001010011 ( 652467 ) on Monday July 12, 2010 @10:59AM (#32875262)

    Is also a great resource. With less ads, things broken up by chapter, examples, how to detect if something is enabled, etc.

    http://diveintohtml5.org/ [diveintohtml5.org]

  • I predict that in a single year from now, the vast majority of browsers being run will be html5 ready; it's only been in the past few years that the browsers began self-updating; everyone wants html5, and so developers will be firmly able to count on it existing very soon.

  • Standards (Score:2, Interesting)

    by Irick ( 1842362 )
    HTML is not a finished standard. Should this prevent people from starting to use it? No, in fact, hell no, we should start using it right now to increase the uptake and motivate the developments of better technologies for utilizing it. A trial by fire will by itself weed out the un-needed portions of HTML 5 and perhaps show the usefulness of features that would otherwise be left out. Should IE's abysmal standards compliance prevent you from writing properly formated code? No, again, you should always motiva

  • Minor improvements (Score:5, Interesting)

    by Animats ( 122034 ) on Monday July 12, 2010 @11:36AM (#32875656) Homepage

    (Read the "print" version [infoworld.com] of the article, instead of the "tiny blocks of text spread over many pages of ads" version.)

    I have misgivings about HTML5. It gives the page more control, and the user less. That's been a trend in HTML for years, and it's getting worse.

    I'm dreading "canvas". Ad blockers need to get smarter. Noticed that popups are winning over Firefox's popup blocking? We're also going to see pages that use 100% of the CPU just for display. We're going to need a browser option for "don't run canvas code for windows that aren't on top.

    The "input type" [w3.org] mechanism for forms is lame. There are a number of standard types like "tel", but it's just text with no line breaks. They should have provided for either regular expressions or syntax like the COBOL Picture clause ("CREDIT_CARD_NUMBER PIC 9999-9999-9999-9999").

    Dynamically-loaded fonts have been working for some time now in all the mainstream browsers. (IE6 and Firefox 3.5 were the last mainstream browsers not to have it.) We've been playing with that for our steampunk site [aetherltd.com]. Downloadable fonts without anti-aliasing turn out to look ugly for small font sizes, because most of the display-type fonts have too much detail and not enough hinting for small font sizes. (In an annoying piece of Apple incompatibility, the iPad requires fonts in SVG, of all things. Everybody else, including Microsoft, is going to Web Open Font Format.) I'd recommend against using this feature much unless you have a good sense of typography. (Bad example: our steampunk search engine. [sitetruth.com])

    • The iPad does not require fonts in svg. Like other modern browsers it supports @font-face using standard OTF fonts. iPhone does the same with ios 4.

      Not sure if web open font is required personally, but if catches on I'm sure weblog will support it.

      • Meant to say I'm sure weblog will support it, not weblog!

        • Re: (Score:3, Funny)

          by e4g4 ( 533831 )

          I'm sure weblog will support it.

          Meant to say I'm sure weblog will support it, not weblog!

          Yeah - that really clears it up...

      • Re: (Score:2)

        by Animats ( 122034 )

        The iPad does not require fonts in svg. Like other modern browsers it supports @font-face using standard OTF fonts.

        Typophile [typophile.com], TypeKit [typekit.com] and Fast Company [fastcompany.com] all say the iPhone/iPad don't support TTF or WOFF downloadable fonts, just SVG. Also, selection doesn't work right for SVG fonts on the iPad, and loading multiple weights of the same font is said to crash the browser.

        Please disable Jobs Reality Distortion Field before using.

      • Re: (Score:2)

        by lee1 ( 219161 )
        iPhone does the same with ios 4.

        I just tried it on this font-face demonstration site [craigmod.com] and it didn't work. Do you have an example of a url that I can load in mobile safari that will show me font-face working?

    • Re:Minor improvements (Score:5, Informative)

      by 99BottlesOfBeerInMyF ( 813746 ) on Monday July 12, 2010 @12:00PM (#32875900)

      I have misgivings about HTML5. It gives the page more control, and the user less. That's been a trend in HTML for years, and it's getting worse.

      I disagree. HTML5 gives the user more control. Right now we're hampered by proprietary plug-ins to provide functionality, like Silverlight and Flash. With HTML5 taking over those functions, the browser codes it, so you can choose which browser you want based upon how well it lets you control the elements on the page. It's basically moving parts of Web pages from single vendor closed implementations to open implementations that compete to serve you best.

      Well, that and a lot more nice tags to break up pages into sections, add support for custom fonts, etc. But that doesn't mean the user loses control. These are markup languages meant to be interpreted. If you don't like custom fonts, noting stops a browser from offering an option of rendering the all as a font of your choosing in the color of your choosing, etc.

      We're going to need a browser option for "don't run canvas code for windows that aren't on top.

      And we can add it. Moreover, we can add a lot more finely grained controls than that, since it is now specified in the canvas element instead of a Flash movie. It's no longer just "run" or "don't run". It can be "run but never let the sound get above this volume, confine it to the page, and modify the way it runs so it never overlaps any text". Hell, we could add the option of making canvas elements that overlap other elements 90% transparent by default and always having a close and display button.

      They should have provided for either regular expressions...

      They did. It's even demonstrated in the article.

      • HTML5 gives the user more control. Right now we're hampered by proprietary plug-ins to provide functionality, like Silverlight and Flash

        The grandparent's point, I think, is that Flash is not integrated into the main content of the page, so it's easy to turn off. With canvas, the JavaScript used for the animated ads is run in the same context as the JavaScript used for essential page functionality. It's much harder to disable the intrusive ads without disabling the rest of the page.

        • The grandparent's point, I think, is that Flash is not integrated into the main content of the page, so it's easy to turn off.

          I guess that depends upon the page, doesn't it? On some pages Flash is added for ads and is not related to the main content. In others, like Hulu, Flash IS the main content of the page. For still others, (like Homestarrunner) the whole page including navigation is built in Flash.

          If you only use Flash on sites that only use it for ads, then I agree this will make it more complex to block those ads. On the other hand, for those that rely upon content currently in Flash and other closed plug-in formats, this i

        • The grandparent's point, I think, is that Flash is not integrated into the main content of the page, so it's easy to turn off. With canvas, the JavaScript used for the animated ads is run in the same context as the JavaScript used for essential page functionality. It's much harder to disable the intrusive ads without disabling the rest of the page.

          No, it would be trivial. Just display all canvases as blank, and don't display their contents until the user lets them. You can treat canvas operations as no-ops, or have them execute but not draw the results to the screen until the user requests it.

          This won't stop pages from using 100% CPU, but they can do that anyway. They usually don't, and I don't expect canvas to change that.

    • Actually, that page is an excellent example of why you shouldn't use a display font for normal text. It immediately went on my list of What you don't want your site to look like websites that I show to my customers.

      • Actually, that page [aetherltd.com] is an excellent example of why you shouldn't use a display font for normal text.

        With a system that does anti-aliasing of text (Windows 7, Vista(?), newer MacOS, newer Linux, etc.) it's not too bad. If your system doesn't, it looks awful. It looks terrible in Windows XP and earlier, even if you have a current browser. It's definitely not something ready for wide scale deployment given the current state of client platforms. I'm trying it for the amusement of the steampunk community.

        • Looks terrible on windows 7 64bit, in chrome, FF and opera here.
          I'm not being a troll, I'm just telling you how it is :)

    • Re: (Score:3, Informative)

      by rockNme2349 ( 1414329 )

      The "input type" [w3.org] mechanism for forms is lame. There are a number of standard types like "tel", but it's just text with no line breaks. They should have provided for either regular expressions or syntax like the COBOL Picture clause ("CREDIT_CARD_NUMBER PIC 9999-9999-9999-9999").

      If you had RTFA you would have seen that one of the new validation types IS regex in the HTML 5 draft.

      <input type="text" pattern="REGEX HERE">

  • Thanks, no (Score:4, Insightful)

    by thePowerOfGrayskull ( 905905 ) <marc,paradise&gmail,com> on Monday July 12, 2010 @11:51AM (#32875788) Homepage Journal
    I've learned long ago that developing against standards that are not yet official is the road to pain. This is demonstrated even in the summary itself:

    Smith steps through several HTML5 features that can already be implemented, while noting several other presentation features that will soon be on their way.

    So - I'm supposed to start implementing cutting edge changes for my production sites, when the browsers that support those changes are "soon to be released"?

    Smith also discusses IE work-arounds, such as HTML 5 Shiv and Google Chrome Frame."

    Soo... now I'm already having to code workarounds before the standard is even official? Again - thanks, no. I'll wait until it's ratified as a standard, and the first revision of major browsers offers compliance.

    • Smith steps through several HTML5 features that can already be implemented, while noting several other presentation features that will soon be on their way.

      So - I'm supposed to start implementing cutting edge changes for my production sites, when the browsers that support those changes are "soon to be released"?

      This is something of a straw man. No one recommends you implement the features that aren't readily available in all major browsers. It just goes through a list of features that seem likely to soon be available in all browsers. You're the only one saying you should implement those particular items.

      Smith also discusses IE work-arounds, such as HTML 5 Shiv and Google Chrome Frame."

      Soo... now I'm already having to code workarounds before the standard is even official?

      Yes, since everyone in their right mind can see IE does not now and is unlikely to soon implement standards compliance. You implement work arounds for IE now in all your pages don't you, just like all the rest of t

    • HTML 5 is being developed incrementally. Some parts of the standard are final, some are considered early drafts (you can see which by checking the spec - it's annotated with this information). For something to be final, it must have feedback from two independent implementations.

      Things like HTML 5 Shiv are part of the design of HTML 5. It is intentionally designed in such a way that it can be implemented in legacy browsers using a combination of plugins and JavaScript. This is not a workaround, it's a m

      • Things like HTML 5 Shiv are part of the design of HTML 5. It is intentionally designed in such a way that it can be implemented in legacy browsers using a combination of plugins and JavaScript. This is not a workaround, it's a migration path

        I have read about that -- but it still reads like a workaround. You're still doing twice the work to implement the same feature for different platforms; there's no way around that.

    • Re: (Score:2)

      by afabbro ( 33948 )

      I've learned long ago that developing against standards that are not yet official is the road to pain. This is demonstrated even in the summary itself. So - I'm supposed to start implementing cutting edge changes for my production sites, when the browsers that support those changes are "soon to be released"? Soo... now I'm already having to code workarounds before the standard is even official? Again - thanks, no. I'll wait until it's ratified as a standard, and the first revision of major browsers offers compliance.

      Well then you can enjoy the wait until 2022 [whatwg.org], because that's when it will reach W3C Recommendation, which is the current status of HTML4.

      Of course, by that time the rest of us will all be enjoying HTML9.

      The real standard is "what do 80% of browsers support?" Browser support for HTML5 [deepbluesky.com] will be added piecemeal, just like they did with HTML4.

      • ANd until then, I have to keep coding browser-based workarounds for a given feature that is implemented on platform "A" and not platform "B". This does not seem like a good solution.

        I'm ok with using things that are already implemented... but trying to use features that are not implemented completely across all platforms is a major step backwards.

  • Multi-column! Multi-column!! (Score:3, Insightful)

    by mozumder ( 178398 ) on Monday July 12, 2010 @12:15PM (#32876054)

    Multi-column (even with basic support), and full support of font-face, is going to go finally enable real layout.

    Can you imagine inDesign, or Quark (or Pagemaker, etc..) without multi-column support?

    Are there ANY newspapers that don't support multi-column layout?

    Meanwhile, I'd like to see varying width/varying shape columns, with reflows, and proper column break hints.

    The current support in Firefox/Safari/Chrome is much appreciated, though. (IE doesn't have it at all!)

    Example multi-column layout with font-faces: http://www.futureclaw.com/articles/visionary-futurist-syd-mead.html [futureclaw.com]

    • Re:Multi-column! Multi-column!! (Score:4, Insightful)

      by RJFerret ( 1279530 ) on Monday July 12, 2010 @08:50PM (#32882064)

      Huh? That would be a scrolling nightmare.

      Sure enough, looking at the link provided, it's totally unreadable. The information on the page is out of context with the rest of the information on the page, the text providing context is off screen below. Instead of being able to quickly read or skim any of it, I gave up and closed the tab, returned here to report.

      You might only have a hammer in your toolbox, and believe everything you see is a nail, but it's not. Newspapers needed the crutch of multiple columns because their format was hopelessly wide. Web pages have the opposite problem, they are infinitely tall. (One of the wonderful attributes of the Readability tool is to increase a web pages width to fill the screen.)

      Worse, more web access is being done on mobile devices, thankfully that site was one column in Opera mini, I suppose we'll have to spoof to make it readable on other browsers?

      It's not a mistake to think that print properties do not apply to the web, it's a mistake to misapply properties designed to overcome one liability, to media that has the opposite liability!

      PS: Below you claim, "Multi-column can actually prevent scrolling entirely, by using the horizontal space instead of forcing you to scroll vertically." Seemingly to overlook the obvious extra white space required between multiple columns that isn't normally wasted--multiple columns add length.

  • It is quite simple and always error free! Ideal for blogs and flash pages where content is not paramount.

    <!doctype html>
    <html />

    • Re: (Score:2)

      by afabbro ( 33948 )

      It is quite simple and always error free! Ideal for blogs and flash pages where content is not paramount.

      Yeah, for most blogs I've seen, "content is not paramount" is an understatement...

  • Are there any good photo / video web albums that use HTML5 to good effect yet?

    I'm kinda hooked on http://marginalhacks.com/Hacks/album/ [marginalhacks.com] , which has the simplest, most straightforward interface of all the other things I've tried. And it makes a good attempt at handling video. I have a simple shell script that imports pics from my Canon camera, converts the mjpegs to .mp4, and tosses it into my ~/public_html/pictures directory indexed by Album.

    http://gallery.menalto.com/ [menalto.com] is also one of my favorites, but it

Slashdot Top Deals

"The vast majority of successful major crimes against property are perpetrated by individuals abusing positions of trust." -- Lawrence Dalzell

Close