The Ajax Experience
October 15, 2009 11:37 AM Subscribe
There's lots going on with HTML5. Get the latest from the folks at Ajaxian. First, find out What's New in HTML5 (The WHATWG Blog), then look into the new Microdata Spec. There's a Sticky Notes Tutorial, and an examination of the Canvas Tag. Getting the nitty gritty details right.
My first link: What's New in HTML5
My first thought: Yeah, but when.
My second thought: Especially if we have to wait for IE.
My first link after that: Heh.
posted by DU at 11:54 AM on October 15, 2009
My first thought: Yeah, but when.
My second thought: Especially if we have to wait for IE.
My first link after that: Heh.
posted by DU at 11:54 AM on October 15, 2009
That's a neat idea to use subversion to track revisions to the standard with revision numbers.
I always thought about how it would be nice and easy to use Subversion to track changes to lengthy contracts. Lawyers seem to really like Adobe PDF sticky notes though.
The client-side database stuff is pretty cool, I assume it is in similar vein to Gmail's Offline feature (which I'm guessing works off an SQlite instance). The point being if you are using the web for everything, high latency or intermittent connections should be expected. I'm always ra-ra never develop for the desktop again until I visit a friend who, when I asked what WiFi they use, let me know that its the unprotected neighbors network with a 5% signal strength.
posted by geoff. at 11:58 AM on October 15, 2009
I always thought about how it would be nice and easy to use Subversion to track changes to lengthy contracts. Lawyers seem to really like Adobe PDF sticky notes though.
The client-side database stuff is pretty cool, I assume it is in similar vein to Gmail's Offline feature (which I'm guessing works off an SQlite instance). The point being if you are using the web for everything, high latency or intermittent connections should be expected. I'm always ra-ra never develop for the desktop again until I visit a friend who, when I asked what WiFi they use, let me know that its the unprotected neighbors network with a 5% signal strength.
posted by geoff. at 11:58 AM on October 15, 2009
You can use HTML5 with IE right now using the HTML5 Shiv. Here's a gallery of working sites that are built using HTML5. You don't have to wait.
posted by sciurus at 12:09 PM on October 15, 2009 [2 favorites]
posted by sciurus at 12:09 PM on October 15, 2009 [2 favorites]
HTML5 can do some fancy 2d and 3d rendering, but surely the web has had this in the form of Java Applets for years?
posted by jamesj629 at 12:45 PM on October 15, 2009
posted by jamesj629 at 12:45 PM on October 15, 2009
HTML5 can do some fancy 2d and 3d rendering, but surely the web has had this in the form of Java Applets for years?
And "years" is often how long it took for the applet to load and launch.
posted by device55 at 12:54 PM on October 15, 2009 [3 favorites]
And "years" is often how long it took for the applet to load and launch.
posted by device55 at 12:54 PM on October 15, 2009 [3 favorites]
Java is like Silverlight for old people.
posted by Artw at 1:10 PM on October 15, 2009 [4 favorites]
posted by Artw at 1:10 PM on October 15, 2009 [4 favorites]
The current trend is that plugins are evil and everything should be rolled into HTML. That the benefits of extendability just lead to real-world issues that the browser developers then have no control over. This has the side-effect that coding a new browser that fully supports HTML5 is basically an impossible undertaking, but that's life.
posted by smackfu at 1:20 PM on October 15, 2009
posted by smackfu at 1:20 PM on October 15, 2009
HTML 5 from the mobile perspective
Will HTML 5 Break Apple's Stranglehold on Apps?
posted by donovan at 1:30 PM on October 15, 2009
Will HTML 5 Break Apple's Stranglehold on Apps?
posted by donovan at 1:30 PM on October 15, 2009
HTML5 can do some fancy 2d and 3d rendering, but surely the web has had this in the form of Java Applets for years?
Yes, who could possibly prefer a standardized and open method over a slow, buggy, secret one that didn't integrate well?
posted by DU at 2:28 PM on October 15, 2009 [1 favorite]
Yes, who could possibly prefer a standardized and open method over a slow, buggy, secret one that didn't integrate well?
posted by DU at 2:28 PM on October 15, 2009 [1 favorite]
Will HTML 5 Break Apple's Stranglehold on Apps?
Well, they've already got CANVAS (because they invented it) and Javascript/AJAX, which is really what most of the fuss is over, and iPhone "web apps" still suck, so my guess is no.
posted by Artw at 2:30 PM on October 15, 2009
Well, they've already got CANVAS (because they invented it) and Javascript/AJAX, which is really what most of the fuss is over, and iPhone "web apps" still suck, so my guess is no.
posted by Artw at 2:30 PM on October 15, 2009
Quite a bit of discussion about various browser types, support of various tags and so on and so forth at the bottom of this thread.
posted by Artw at 2:41 PM on October 15, 2009
posted by Artw at 2:41 PM on October 15, 2009
Will it get us the img tag back?
posted by jfuller at 2:54 PM on October 15, 2009 [3 favorites]
posted by jfuller at 2:54 PM on October 15, 2009 [3 favorites]
It gets us a new VIDEO tag they'll have to filter*!
I'm a bit hazy on the details of how that actually works.
* Yes, yes, I'm sure it's actually a whitelist.
posted by Artw at 3:01 PM on October 15, 2009
I'm a bit hazy on the details of how that actually works.
* Yes, yes, I'm sure it's actually a whitelist.
posted by Artw at 3:01 PM on October 15, 2009
The details of the VIDEO tag are, apparently, a little controversial.
But assuming the browser supports whatever video format it is you are pointing at then the usage couldn't be simpler.
posted by Artw at 3:04 PM on October 15, 2009
But assuming the browser supports whatever video format it is you are pointing at then the usage couldn't be simpler.
posted by Artw at 3:04 PM on October 15, 2009
Gah. We still have OBJECT and EMBED.
/shudders at horrible memories of doubling up nasty tags.
posted by Artw at 3:08 PM on October 15, 2009
/shudders at horrible memories of doubling up nasty tags.
posted by Artw at 3:08 PM on October 15, 2009
Actually EMBED is something new. I'd question how sensible calling it EMBED is in that case.
posted by Artw at 3:14 PM on October 15, 2009
posted by Artw at 3:14 PM on October 15, 2009
Another way to do HTML5 on IE is with ChromeFrame .
posted by wildcrdj at 3:17 PM on October 15, 2009
posted by wildcrdj at 3:17 PM on October 15, 2009
I loves me some HTML5. I made a cool canvas experiment with the javascript Processing library you can see here.
It was submitted it as a google chrome experiment, and I got an email that it was accepted. But then it never appeared anywhere on the google chrome experiment site. Oh well.
The fact that HTML5 is not supported by IE really makes it hard to pursuade clients that we should use it. Thanks sciurius for mentioning HTML5shiv, I'll definitely be looking into that. Hopefully that is the solution to bringing HTML5 into production use!
posted by localhuman at 3:20 PM on October 15, 2009 [1 favorite]
It was submitted it as a google chrome experiment, and I got an email that it was accepted. But then it never appeared anywhere on the google chrome experiment site. Oh well.
The fact that HTML5 is not supported by IE really makes it hard to pursuade clients that we should use it. Thanks sciurius for mentioning HTML5shiv, I'll definitely be looking into that. Hopefully that is the solution to bringing HTML5 into production use!
posted by localhuman at 3:20 PM on October 15, 2009 [1 favorite]
<video src="http://www.metafilter.com/somethingNSFW.wmv">
your browser does not support the video tag
</video>
posted by blue_beetle at 3:20 PM on October 15, 2009
your browser does not support the video tag
</video>
posted by blue_beetle at 3:20 PM on October 15, 2009
Nothing like a fucking FLASH Movie showing me how great HTML Canvas is.
posted by Benny Andajetz at 3:21 PM on October 15, 2009 [4 favorites]
posted by Benny Andajetz at 3:21 PM on October 15, 2009 [4 favorites]
Here's a dumb question: does this test page work in anyone else's Safari? It uses an Ogg file, and I thought Apple was only support h264 video. I even get the Quicktime controls on it. I wonder if I have a plug-in or something to support ogg that Safari is picking up.
posted by smackfu at 3:31 PM on October 15, 2009
posted by smackfu at 3:31 PM on October 15, 2009
I don't like the aside tag. IT should be "sidebar," which is already commonly used in web and print publishing to mean the same thing as the aside tag is meant to. "Aside" is a theatrical term that's meaningless in publishing. (And it's no semantic improvement since they both imply something to the side.)
posted by kirkaracha at 3:40 PM on October 15, 2009
posted by kirkaracha at 3:40 PM on October 15, 2009
Probably they didn't like the way "sidebar" would imply a particular layout. They don't like that sort of thing. They practically had to have their heads beaten against a wall before they modified footer so that it would actually work as a footer.
posted by Artw at 4:03 PM on October 15, 2009
posted by Artw at 4:03 PM on October 15, 2009
Java is like Silverlight for old people.
Silverlight is like Flash for lame people.
posted by JHarris at 4:12 PM on October 15, 2009 [3 favorites]
Silverlight is like Flash for lame people.
posted by JHarris at 4:12 PM on October 15, 2009 [3 favorites]
No, Flash is like neither Java nor Silverlight since people actually want Flash.
posted by Artw at 4:14 PM on October 15, 2009 [2 favorites]
posted by Artw at 4:14 PM on October 15, 2009 [2 favorites]
See also: Shockwave
(It'll be under some dust and cobwebs somewhere)
posted by Artw at 4:15 PM on October 15, 2009
(It'll be under some dust and cobwebs somewhere)
posted by Artw at 4:15 PM on October 15, 2009
HTML 5 for building stand alone iPhone apps
(just seen on Daring Fireballs RSS feed)
posted by device55 at 4:16 PM on October 15, 2009 [3 favorites]
(just seen on Daring Fireballs RSS feed)
posted by device55 at 4:16 PM on October 15, 2009 [3 favorites]
Every time I scan "HTML5" I read it as HTMLS, as if my grandma is trying to describe what she sees if she accidentally opens a web page in Notepad.
"Oh mercy, there's all these HTMLS all over!"
posted by rokusan at 4:48 PM on October 15, 2009 [4 favorites]
"Oh mercy, there's all these HTMLS all over!"
posted by rokusan at 4:48 PM on October 15, 2009 [4 favorites]
rokusan, I'm reading it that way now. I hope you're satisfied!
posted by brundlefly at 5:26 PM on October 15, 2009
posted by brundlefly at 5:26 PM on October 15, 2009
I'm a web developer. I absolutely hate HTML5. It's fucking stupid. The new tags are dumb. There are old tags & properties (that were fine, I might add) that are still in "deprecated" limbo. But now we have a <PROGRESS> tag? What in the fuck does that even mean? We've got a <FOOTER> tag, oh great. So, can I use a footer inside a table? Does that override <TFOOT>? And speaking of that, do <TFOOT> tags still need to be declared before <TBODY> tags, or can we finally get rid of that relic? They got rid of <CENTER> tag because, "waaah, that's for display!" but they're keeping <EM> and <STRONG>? That makes plenty sense. We get <ASIDE> and <DIALOGUE>? No, wait, scratch that. <DIALOG>. Why is a <DATAGRID> any different than a <TABLE>?
Stupid, stupid, stupid. Hammer in search of a nail, with a search pattern of wildly swinging around at things. It's needlessly complicated and offers no solution to the real problem, which is that HTML 4.01 isn't anywhere-near standardized across browsers. But what the major browser folks can't do in 15 years, they'll suddenly get right in a couple?
This is the way it should work:
Any tags is fine. Anything. Because it's just semantics, right? So, keep your <PROGRESS> tag. And keep your <CAPTION> tag (oh, are they going to fucking fix that shit as well or what?)
But if you want a <SUPRECALAFRAGILISTIC> tag, that's fine. It's all just XML node names. If we're really being serious about separating presentation and structure, all presentation would be in style sheets, all function would be through properties, and all semantics would be allowed.
Something like this:
<ARTICLE action = "http://www.yo.com;">
The tag is irrelevant. It's the action property that signals the browser there's a form in play. HTML5 adds about an order of magnitude more complexity to a problem that still hasn't been resolved! I mean, how's about all the browser-makers agree on a single way of getting round borders (border-radius? -moz-border-radius? -webkit-border-radius? WHAT!!?) before we start adding fucking <ASIDE> tags?
posted by Civil_Disobedient at 6:08 PM on October 15, 2009 [6 favorites]
Stupid, stupid, stupid. Hammer in search of a nail, with a search pattern of wildly swinging around at things. It's needlessly complicated and offers no solution to the real problem, which is that HTML 4.01 isn't anywhere-near standardized across browsers. But what the major browser folks can't do in 15 years, they'll suddenly get right in a couple?
This is the way it should work:
Any tags is fine. Anything. Because it's just semantics, right? So, keep your <PROGRESS> tag. And keep your <CAPTION> tag (oh, are they going to fucking fix that shit as well or what?)
But if you want a <SUPRECALAFRAGILISTIC> tag, that's fine. It's all just XML node names. If we're really being serious about separating presentation and structure, all presentation would be in style sheets, all function would be through properties, and all semantics would be allowed.
Something like this:
<ARTICLE action = "http://www.yo.com;">
The tag is irrelevant. It's the action property that signals the browser there's a form in play. HTML5 adds about an order of magnitude more complexity to a problem that still hasn't been resolved! I mean, how's about all the browser-makers agree on a single way of getting round borders (border-radius? -moz-border-radius? -webkit-border-radius? WHAT!!?) before we start adding fucking <ASIDE> tags?
posted by Civil_Disobedient at 6:08 PM on October 15, 2009 [6 favorites]
Sounds like we've got a waiverer in the war against tables.
posted by Artw at 6:35 PM on October 15, 2009
posted by Artw at 6:35 PM on October 15, 2009
Disclaimer: I work for Mozilla.
The Mozilla Hacks blog is tracking a lot of the newest support for HTML5 in Firefox 3.5, Firefox 3.6 and beyond. We've got over 30 demos showcased, and the developers who are implementing support for HTML5 and CSS3 features are posting information about their implementations. If you're interested in HTML5, I think you'd appreciate the Hacks blog.
posted by gen at 7:00 PM on October 15, 2009
The Mozilla Hacks blog is tracking a lot of the newest support for HTML5 in Firefox 3.5, Firefox 3.6 and beyond. We've got over 30 demos showcased, and the developers who are implementing support for HTML5 and CSS3 features are posting information about their implementations. If you're interested in HTML5, I think you'd appreciate the Hacks blog.
posted by gen at 7:00 PM on October 15, 2009
>Java is like Silverlight for old people.
>Silverlight is like Flash for lame people.
>No, Flash is like neither Java nor Silverlight since people actually want Flash.
>See also: Shockwave
Snark snark snarkity snark...
Java applets died an untimely death partly because a kewl animation-style IDE didn't appear early on, but mainly because one or two left-coast makers of operating systems didn't take kindly to accommodating a "virtual machine" layer that promised to ultimately break their hammerlock on application developers, so they did their utmost to make Java VM installation a headache.
Ok, early Java came with some headaches too, but applets were essentially smothered in the crib. Flash started out rough too, but no-one had a hate on for its parents, so it and its plugin were able to mature into that omnipresent nuisance that it now is.
(I was doing Java applet banner ads in 2000 or so)
posted by Artful Codger at 7:01 PM on October 15, 2009
>Silverlight is like Flash for lame people.
>No, Flash is like neither Java nor Silverlight since people actually want Flash.
>See also: Shockwave
Snark snark snarkity snark...
Java applets died an untimely death partly because a kewl animation-style IDE didn't appear early on, but mainly because one or two left-coast makers of operating systems didn't take kindly to accommodating a "virtual machine" layer that promised to ultimately break their hammerlock on application developers, so they did their utmost to make Java VM installation a headache.
Ok, early Java came with some headaches too, but applets were essentially smothered in the crib. Flash started out rough too, but no-one had a hate on for its parents, so it and its plugin were able to mature into that omnipresent nuisance that it now is.
(I was doing Java applet banner ads in 2000 or so)
posted by Artful Codger at 7:01 PM on October 15, 2009
Civil_Disobedient: "I'm a web developer. I absolutely hate HTML5. It's fucking stupid. The new tags are dumb."
I want to disagree with you on one point: the video tag, when combined with cue ranges, provides a nice universally agreed upon semantic. I doubt Youtube will embrace it quickly, since it means one can easily separate the video from the rest of their content, but over time it will build referential value. Imagine blogs using a cue range to quote a specific part of a keynote address. Given enough of these you can start to discover the meaning of the video. At least enough to make it searchable.
Without a standard, your crazy video search tool will have to be customized for every search engine. With a standard, the millions of videos not yet uploaded and hundreds of video sites not yet written have a decent format to borrow, and no internal inertia to fight. You can poo on the rest, but you must at least admit that the video tag is relevant to the future.
posted by pwnguin at 7:29 PM on October 15, 2009 [1 favorite]
I want to disagree with you on one point: the video tag, when combined with cue ranges, provides a nice universally agreed upon semantic. I doubt Youtube will embrace it quickly, since it means one can easily separate the video from the rest of their content, but over time it will build referential value. Imagine blogs using a cue range to quote a specific part of a keynote address. Given enough of these you can start to discover the meaning of the video. At least enough to make it searchable.
Without a standard, your crazy video search tool will have to be customized for every search engine. With a standard, the millions of videos not yet uploaded and hundreds of video sites not yet written have a decent format to borrow, and no internal inertia to fight. You can poo on the rest, but you must at least admit that the video tag is relevant to the future.
posted by pwnguin at 7:29 PM on October 15, 2009 [1 favorite]
Imagine blogs using a cue range to quote a specific part of a keynote address.
Undocumented but easy: you can already do this, at least for the start point, by adding #t=XmYs to the two URLs in the <embed> tag. That's usually enough to direct readers to the part of a video you're talking about.
I can't embed here, but an example of the URL equivalent of such a jump is here, which obediently starts at 0:20. Do the same in an <embed> and your embedded version will start where you specify.
posted by rokusan at 8:04 PM on October 15, 2009
Undocumented but easy: you can already do this, at least for the start point, by adding #t=XmYs to the two URLs in the <embed> tag. That's usually enough to direct readers to the part of a video you're talking about.
I can't embed here, but an example of the URL equivalent of such a jump is here, which obediently starts at 0:20. Do the same in an <embed> and your embedded version will start where you specify.
posted by rokusan at 8:04 PM on October 15, 2009
It's needlessly complicated and offers no solution to the real problem, which is that HTML 4.01 isn't anywhere-near standardized across browsers
HTML5 is a spec written as an algorithm for implementation, to address precisely that problem. The whole reason it'll take so long to be considered done is that a full browser implementation is what they consider done. Can you point to specific examples of where other specs have done a better job at addressing the implementation problem? Frankly, you don't seem to know what you're talking about.
The tag is irrelevant. It's the action property that signals the browser there's a form in play.
Browsers aren't the only consumer of markup. Search engines, for example, rely heavily on standard tag semantics that simply wouldn't be published as readily if shared semantics were restricted to attributes. Ian Hickson, the editor of the HTML5 spec, works for Google, who is interested in that kind of thing.
Something a bit less extreme than completely open tags is XHTML's namespaced extensibility, which allows arbitrary tags provided you point to some source where someone might figure out what the heck your tags mean. HTML5 includes XHTML5, so you can actually do that in the very spec you're complaining about.
the video tag ... I doubt Youtube will embrace it quickly
You're wrong. Google, of course, owns YouTube.
posted by scottreynen at 8:28 PM on October 15, 2009
HTML5 is a spec written as an algorithm for implementation, to address precisely that problem. The whole reason it'll take so long to be considered done is that a full browser implementation is what they consider done. Can you point to specific examples of where other specs have done a better job at addressing the implementation problem? Frankly, you don't seem to know what you're talking about.
The tag is irrelevant. It's the action property that signals the browser there's a form in play.
Browsers aren't the only consumer of markup. Search engines, for example, rely heavily on standard tag semantics that simply wouldn't be published as readily if shared semantics were restricted to attributes. Ian Hickson, the editor of the HTML5 spec, works for Google, who is interested in that kind of thing.
Something a bit less extreme than completely open tags is XHTML's namespaced extensibility, which allows arbitrary tags provided you point to some source where someone might figure out what the heck your tags mean. HTML5 includes XHTML5, so you can actually do that in the very spec you're complaining about.
the video tag ... I doubt Youtube will embrace it quickly
You're wrong. Google, of course, owns YouTube.
posted by scottreynen at 8:28 PM on October 15, 2009
rokusan: "Undocumented but easy: you can already do this, at least for the start point, by adding #t=XmYs to the two URLs in the tag."
Does this work in general, or only for youtube? I was under the impression it was the latter, but would be happy to hear the former!
posted by pwnguin at 10:17 PM on October 15, 2009
Does this work in general, or only for youtube? I was under the impression it was the latter, but would be happy to hear the former!
posted by pwnguin at 10:17 PM on October 15, 2009
Frankly, you don't seem to know what you're talking about.
Can you point to specific examples of where in my comments you might get that idea? Frankly, you seem like a fucking troll.
posted by Civil_Disobedient at 10:40 PM on October 15, 2009
Can you point to specific examples of where in my comments you might get that idea? Frankly, you seem like a fucking troll.
posted by Civil_Disobedient at 10:40 PM on October 15, 2009
Sounds like we've got a waiverer in the war against tables.
I'll see his wavering and raise it some serious backsliding. The idea that tables-for-layout are harmful has been way overblown.
posted by weston at 10:49 PM on October 15, 2009 [1 favorite]
I'll see his wavering and raise it some serious backsliding. The idea that tables-for-layout are harmful has been way overblown.
posted by weston at 10:49 PM on October 15, 2009 [1 favorite]
> You're wrong. [about HTML5 adoption and YouTube] Google, of course, owns YouTube.
I've looked at the YouTube HTML5 test page with Firefox on both Windows and Linux. Is there *supposed* to be no functional videos and/or UI elements on that page? If so what, exactly are they testing?
posted by simoncion at 10:55 PM on October 15, 2009
I've looked at the YouTube HTML5 test page with Firefox on both Windows and Linux. Is there *supposed* to be no functional videos and/or UI elements on that page? If so what, exactly are they testing?
posted by simoncion at 10:55 PM on October 15, 2009
You have to use FF3.5. And like watching the same video over and over.
posted by pwnguin at 11:26 PM on October 15, 2009
posted by pwnguin at 11:26 PM on October 15, 2009
Can you point to specific examples of where in my comments you might get that idea?
That's exactly what I did in my previous comment, which you seem to have entirely ignored save for the least substantive part. To repeat, it was the part where you complained about the implementation problem and the part where you suggested tags don't matter, both issues addressed by the spec you called stupid.
posted by scottreynen at 5:17 AM on October 16, 2009
That's exactly what I did in my previous comment, which you seem to have entirely ignored save for the least substantive part. To repeat, it was the part where you complained about the implementation problem and the part where you suggested tags don't matter, both issues addressed by the spec you called stupid.
posted by scottreynen at 5:17 AM on October 16, 2009
TABLES for layout are great. I'm not a professional web designer, so I don't have to do CSS-based layouts to show off to my peers and clients. Without that driver I can happily knock up a layout with TABLEs that works in every browser in no time at all.
In fact, TABLEs are so great that there's a proposal to rename them and shove them in CSS 3! CSS Grid Positioning
My real fear with CANVAS is that it's the next step to "the desktop OS in your browser" and I don't know how we're going to handle the accessibility for screenreader users...
posted by alasdair at 5:20 AM on October 16, 2009
In fact, TABLEs are so great that there's a proposal to rename them and shove them in CSS 3! CSS Grid Positioning
My real fear with CANVAS is that it's the next step to "the desktop OS in your browser" and I don't know how we're going to handle the accessibility for screenreader users...
posted by alasdair at 5:20 AM on October 16, 2009
I doubt Youtube will embrace it quickly, since it means one can easily separate the video from the rest of their content, but over time it will build referential value.
I do wonder how they are going to deal with that. It is trivial to rip videos with the video tag.
Is something like Hulu ever going to switch to the new tag?
posted by smackfu at 6:17 AM on October 16, 2009
I do wonder how they are going to deal with that. It is trivial to rip videos with the video tag.
Is something like Hulu ever going to switch to the new tag?
posted by smackfu at 6:17 AM on October 16, 2009
I do wonder how they are going to deal with that. It is trivial to rip videos with the video tag.
If you're just hosting a flat video file on a server, yeah it would be trivial to yoink it out without watching it on the page.
But if your video is delivered via a proxy application, that application could easily check for a session cookie which is only set by the web page, or even the loading of an advertisement.
It would be easy enough to make taking the video without consuming it from its desired context difficult enough that only nerds will bother to do it.
There's no reason a video tag implementation wouldn't work with DRM'ed video like you find on iTunes either. Apple could cobble up an extension to quicktime which grabbed your itunes credentials out of your iTunes library or wherever and use that to authorize playback of the video.
posted by device55 at 10:05 AM on October 16, 2009
If you're just hosting a flat video file on a server, yeah it would be trivial to yoink it out without watching it on the page.
But if your video is delivered via a proxy application, that application could easily check for a session cookie which is only set by the web page, or even the loading of an advertisement.
It would be easy enough to make taking the video without consuming it from its desired context difficult enough that only nerds will bother to do it.
There's no reason a video tag implementation wouldn't work with DRM'ed video like you find on iTunes either. Apple could cobble up an extension to quicktime which grabbed your itunes credentials out of your iTunes library or wherever and use that to authorize playback of the video.
posted by device55 at 10:05 AM on October 16, 2009
In fact, TABLEs are so great that there's a proposal to rename them and shove them in CSS 3! CSS Grid Positioning
CSS Grid Positioning looks like it's intended to do what Tables shouldn't be doing but often are. So while you're sort of correct there, you're sort of not.
posted by Artw at 10:24 AM on October 16, 2009
CSS Grid Positioning looks like it's intended to do what Tables shouldn't be doing but often are. So while you're sort of correct there, you're sort of not.
posted by Artw at 10:24 AM on October 16, 2009
Probably they didn't like the way 'sidebar' would imply a particular layout.
Sure, but "aside" implies the exact same thing.
posted by kirkaracha at 11:23 AM on October 16, 2009
Well, these are people who will tell you that bold is bad but that strong is completely semantic and acceptable, so I'm sure they'd be able to argue you in circles over it until you dropped dead of boredom.
posted by Artw at 11:28 AM on October 16, 2009
posted by Artw at 11:28 AM on October 16, 2009
Tables are great for layout (he mumbled, exposing himself to the ridicule of the true nerds)
The only good argument against tables as layout is that it can only produce a good layout for the window size range of the standard computer-based web browser. It doesn't gracefully handle smaller formats like mobile.
But I think a one-format-does-all page solution isn't necessarily the grail anyway. If mobile is as important as standard browser, it deserves its own layout and page structure. The server should serve the appropriate page based on browser identity.
posted by Artful Codger at 11:31 AM on October 16, 2009
The only good argument against tables as layout is that it can only produce a good layout for the window size range of the standard computer-based web browser. It doesn't gracefully handle smaller formats like mobile.
But I think a one-format-does-all page solution isn't necessarily the grail anyway. If mobile is as important as standard browser, it deserves its own layout and page structure. The server should serve the appropriate page based on browser identity.
posted by Artful Codger at 11:31 AM on October 16, 2009
The only good argument against tables as layout is that it can only produce a good layout for the window size range of the standard computer-based web browser.
I'm not a standardista, but I can give you some more good arguments.
1. To define three basic columns an HTML table needs 10 tags, where with CSS and say DIV tags you only need 6.
Assuming you're not insane, the styling of your columns, tables or otherwise, is done in CSS where it can be cached and reused by every page, and that you don't write CSS like a retard (or Adobe Dreamweaver) you've reduced file size and rendering complexity on every page by using CSS. You may scoff at this as being infinitesimal, but at my previous job I shaved about 1GB of bandwidth use off an extranet site by de-tabling the home page. Bandwidth costs money.
2. With CSS you can reorder page elements based upon the display. You can have, for example, your company name appear first, your content second, and your navigation third in your HTML but display it in whatever order is appropriate. This is impossible with table layouts.
The benefit of placing your content first in your HTML output is that Google generally treats it as more relevant, and this places you higher in search results. Companies pay lots of money to get higher search results.
3. Using CSS based layout you can remove elements from your print view that are extraneous. User's don't need a navbar on a printed page, or a footer, or whatever. In a print view, you can easily hide these elements via CSS. Technically this can be done with tables....but it's not as reliable (e.g. if you hide one TD out of a table in order to hide the navigation, you could get screwy rendering results by some browsers)
Table layouts are fine for limited use or quick and dirty layout or for HTML email (where the HTML rendering capabilities are all over the map) but they are quite limiting and clunky for any serious use.
With modern web-kit based mobile browsers, serving up a 'mobile' version of a website is becoming less and less important - but if you want to truly optimize for one or mobile platforms, I agree it's probably wise to target those platforms directly.
posted by device55 at 12:09 PM on October 16, 2009 [1 favorite]
I'm not a standardista, but I can give you some more good arguments.
1. To define three basic columns an HTML table needs 10 tags, where with CSS and say DIV tags you only need 6.
Assuming you're not insane, the styling of your columns, tables or otherwise, is done in CSS where it can be cached and reused by every page, and that you don't write CSS like a retard (or Adobe Dreamweaver) you've reduced file size and rendering complexity on every page by using CSS. You may scoff at this as being infinitesimal, but at my previous job I shaved about 1GB of bandwidth use off an extranet site by de-tabling the home page. Bandwidth costs money.
2. With CSS you can reorder page elements based upon the display. You can have, for example, your company name appear first, your content second, and your navigation third in your HTML but display it in whatever order is appropriate. This is impossible with table layouts.
The benefit of placing your content first in your HTML output is that Google generally treats it as more relevant, and this places you higher in search results. Companies pay lots of money to get higher search results.
3. Using CSS based layout you can remove elements from your print view that are extraneous. User's don't need a navbar on a printed page, or a footer, or whatever. In a print view, you can easily hide these elements via CSS. Technically this can be done with tables....but it's not as reliable (e.g. if you hide one TD out of a table in order to hide the navigation, you could get screwy rendering results by some browsers)
Table layouts are fine for limited use or quick and dirty layout or for HTML email (where the HTML rendering capabilities are all over the map) but they are quite limiting and clunky for any serious use.
With modern web-kit based mobile browsers, serving up a 'mobile' version of a website is becoming less and less important - but if you want to truly optimize for one or mobile platforms, I agree it's probably wise to target those platforms directly.
posted by device55 at 12:09 PM on October 16, 2009 [1 favorite]
I've looked at the YouTube HTML5 test page with Firefox on both Windows and Linux. Is there *supposed* to be no functional videos and/or UI elements on that page? If so what, exactly are they testing?
Well, we don't support the Ogg codec for viewing on the site currently (by which I mean we're not transcoding into Ogg, we do support Ogg uploads). So you need a browser with both <video> support and h264 support (Safari or Chrome, or possibly IE with ChromeFrame might work).
(That page was put up as a demo a while ago though, and you're right that its pretty uninteresting right now)
We should have some new stuff around HTML5 very soon. [I'm working on HTML5 stuff (among other things) at YouTube, so I can assure you we're looking at it]
posted by wildcrdj at 12:38 PM on October 16, 2009 [1 favorite]
Well, we don't support the Ogg codec for viewing on the site currently (by which I mean we're not transcoding into Ogg, we do support Ogg uploads). So you need a browser with both <video> support and h264 support (Safari or Chrome, or possibly IE with ChromeFrame might work).
(That page was put up as a demo a while ago though, and you're right that its pretty uninteresting right now)
We should have some new stuff around HTML5 very soon. [I'm working on HTML5 stuff (among other things) at YouTube, so I can assure you we're looking at it]
posted by wildcrdj at 12:38 PM on October 16, 2009 [1 favorite]
If mobile is as important as standard browser, it deserves its own layout and page structure. The server should serve the appropriate page based on browser identity.
What you're describing is pretty much WAP, which is how mobile browsers generally worked a few years ago. But today's mobile browsers work fine with full HTML, so no one's really doing new WAP anymore. It's much easier said than done to maintain full copies of site content for each device type. Stylesheet targetting is trivial in comparison.
posted by scottreynen at 1:38 PM on October 16, 2009
What you're describing is pretty much WAP, which is how mobile browsers generally worked a few years ago. But today's mobile browsers work fine with full HTML, so no one's really doing new WAP anymore. It's much easier said than done to maintain full copies of site content for each device type. Stylesheet targetting is trivial in comparison.
posted by scottreynen at 1:38 PM on October 16, 2009
WAP was always fucking horrible. I think the the ascent of the iPhone and it's decent in-phone browser with really quick and intuitive zooming pretty much kills it off forever. And anything that doesn't work well with that becomes natural fodder for an app (more likely a native app than a phone specific web app - as noted above those have pretty much been a failure so far.) It's very rarely that I visit a site and get shunted into some special iPhone ghetto that I don;t immediately start hunting for the full web view and, should I not be able to find it, I stop visiting the site.
posted by Artw at 1:44 PM on October 16, 2009
posted by Artw at 1:44 PM on October 16, 2009
I'm going to say much, other than the HTML5 process has turned into a giant mess, CANVAS isn't ready for prime time, and there are massive accessibility problems littered all over the two standards, not to mention a pitched battle over semantics that's not being cooled by the XHTML5/HTML5 split or the proposed HTML5+RDFa standard.
But the video and audio tags, about time. Except there's no captioning embedding options with video; they'll either have to be burned in or retrofit on top with JavaScript.
That's still too much to write. And I haven't even gotten into what a pompous git Ian Hickson has turned into. I'll let Mr. Last Week do that instead.
posted by dw at 3:51 PM on October 16, 2009
But the video and audio tags, about time. Except there's no captioning embedding options with video; they'll either have to be burned in or retrofit on top with JavaScript.
That's still too much to write. And I haven't even gotten into what a pompous git Ian Hickson has turned into. I'll let Mr. Last Week do that instead.
posted by dw at 3:51 PM on October 16, 2009
That's exactly what I did in my previous comment
No, what you said was...
"HTML5 is a spec written as an algorithm for implementation, to address precisely that problem. The whole reason it'll take so long to be considered done is that a full browser implementation is what they consider done."
Which, I'm sorry, is about a non-answer an answer as I've ever seen.
Then there's...
"Search engines, for example, rely heavily on standard tag semantics that simply wouldn't be published as readily if shared semantics were restricted to attributes."
Search engines can parse attributes just as easily as they can parse node names. For christ's sake, you should know that.
Ian Hickson, the editor of the HTML5 spec, works for Google, who is interested in that kind of thing.
With apologies to Mr. Hickson, who gives a flying fuck what Ian Hickson thinks?
posted by Civil_Disobedient at 4:36 PM on October 16, 2009
No, what you said was...
"HTML5 is a spec written as an algorithm for implementation, to address precisely that problem. The whole reason it'll take so long to be considered done is that a full browser implementation is what they consider done."
Which, I'm sorry, is about a non-answer an answer as I've ever seen.
Then there's...
"Search engines, for example, rely heavily on standard tag semantics that simply wouldn't be published as readily if shared semantics were restricted to attributes."
Search engines can parse attributes just as easily as they can parse node names. For christ's sake, you should know that.
Ian Hickson, the editor of the HTML5 spec, works for Google, who is interested in that kind of thing.
With apologies to Mr. Hickson, who gives a flying fuck what Ian Hickson thinks?
posted by Civil_Disobedient at 4:36 PM on October 16, 2009
All the people who think he has too much power in deciding what HTML5 will be?
posted by smackfu at 4:47 PM on October 16, 2009
posted by smackfu at 4:47 PM on October 16, 2009
OK since I reopened the can of table-worms, I at least owe them a shot of compost:
1. To define three basic columns an HTML table needs 10 tags, where with CSS and say DIV tags you only need 6.
Assuming you're not insane, the styling of your columns, tables or otherwise, is done in CSS where it can be cached and reused by every page, and that you don't write CSS like a retard (or Adobe Dreamweaver) you've reduced file size and rendering complexity on every page by using CSS. You may scoff at this as being infinitesimal, but at my previous job I shaved about 1GB of bandwidth use off an extranet site by de-tabling the home page. Bandwidth costs money.
Who you calling sane??
If a site makes intelligent use of templates, refactored common elements like navs, scripts and footers, and dynamic insertion of content, these address the reuse/maintenance issues. File compression further reduces the size gap. I don't for one second believe that a table layout is appreciably slower or harder for a browser to render than a CSS-based layout.
PS I'm no fan of Dreamweaver.
2. With CSS you can reorder page elements based upon the display. You can have, for example, your company name appear first, your content second, and your navigation third in your HTML but display it in whatever order is appropriate. This is impossible with table layouts.
That's useful how? Any separation of layout and content makes the content "order" irrelevant.
Even on static pages I've not had much trouble editing tabled layouts. Anecdata, I know.
The benefit of placing your content first in your HTML output is that Google generally treats it as more relevant, and this places you higher in search results. Companies pay lots of money to get higher search results.
Sure, but content placement is just one of many factors in SEO. Also, when you're working with clients who already have national prominence and market share, SEO is less important than other traffic drivers.
3. Using CSS based layout you can remove elements from your print view that are extraneous. User's don't need a navbar on a printed page, or a footer, or whatever. In a print view, you can easily hide these elements via CSS. Technically this can be done with tables....but it's not as reliable (e.g. if you hide one TD out of a table in order to hide the navigation, you could get screwy rendering results by some browsers)
Again - trivial in a dynamic site, and simple enough even with JavaScript. CSS ain't the only tool in the drawer.
Table layouts are fine for limited use or quick and dirty layout or for HTML email (where the HTML rendering capabilities are all over the map) but they are quite limiting and clunky for any serious use.
Come on.... While waiting around for CSS, at least a few of us managed to produce attractive, flexible, resizable layouts.
CSS & HTML Email -cringe-
With modern web-kit based mobile browsers, serving up a 'mobile' version of a website is becoming less and less important.
...exactly! Which makes the choice of layout technique less critical - a competent layout will work more places, tables or otherwise.
Ok enough. I accept that CSS is a better-organized way to deal with layout. I am just tired of the shitting-on of tables.
</td></tr></table>
posted by Artful Codger at 10:52 AM on October 18, 2009
1. To define three basic columns an HTML table needs 10 tags, where with CSS and say DIV tags you only need 6.
Assuming you're not insane, the styling of your columns, tables or otherwise, is done in CSS where it can be cached and reused by every page, and that you don't write CSS like a retard (or Adobe Dreamweaver) you've reduced file size and rendering complexity on every page by using CSS. You may scoff at this as being infinitesimal, but at my previous job I shaved about 1GB of bandwidth use off an extranet site by de-tabling the home page. Bandwidth costs money.
Who you calling sane??
If a site makes intelligent use of templates, refactored common elements like navs, scripts and footers, and dynamic insertion of content, these address the reuse/maintenance issues. File compression further reduces the size gap. I don't for one second believe that a table layout is appreciably slower or harder for a browser to render than a CSS-based layout.
PS I'm no fan of Dreamweaver.
2. With CSS you can reorder page elements based upon the display. You can have, for example, your company name appear first, your content second, and your navigation third in your HTML but display it in whatever order is appropriate. This is impossible with table layouts.
That's useful how? Any separation of layout and content makes the content "order" irrelevant.
Even on static pages I've not had much trouble editing tabled layouts. Anecdata, I know.
The benefit of placing your content first in your HTML output is that Google generally treats it as more relevant, and this places you higher in search results. Companies pay lots of money to get higher search results.
Sure, but content placement is just one of many factors in SEO. Also, when you're working with clients who already have national prominence and market share, SEO is less important than other traffic drivers.
3. Using CSS based layout you can remove elements from your print view that are extraneous. User's don't need a navbar on a printed page, or a footer, or whatever. In a print view, you can easily hide these elements via CSS. Technically this can be done with tables....but it's not as reliable (e.g. if you hide one TD out of a table in order to hide the navigation, you could get screwy rendering results by some browsers)
Again - trivial in a dynamic site, and simple enough even with JavaScript. CSS ain't the only tool in the drawer.
Table layouts are fine for limited use or quick and dirty layout or for HTML email (where the HTML rendering capabilities are all over the map) but they are quite limiting and clunky for any serious use.
Come on.... While waiting around for CSS, at least a few of us managed to produce attractive, flexible, resizable layouts.
CSS & HTML Email -cringe-
With modern web-kit based mobile browsers, serving up a 'mobile' version of a website is becoming less and less important.
...exactly! Which makes the choice of layout technique less critical - a competent layout will work more places, tables or otherwise.
Ok enough. I accept that CSS is a better-organized way to deal with layout. I am just tired of the shitting-on of tables.
</td></tr></table>
posted by Artful Codger at 10:52 AM on October 18, 2009
With CSS you can reorder page elements based upon the display. You can have, for example, your company name appear first, your content second, and your navigation third in your HTML but display it in whatever order is appropriate. This is impossible with table layouts.
On the face of it this is good for screenreader (blind) users. You can present your site with the useful content first, and the navigation at the end.
In practice, however, (1) no-one does this, so screenreader users have learned to use header tags instead and (2) where some people do it's actually confusing because it's so rare, so trusty techniques like "skip all the links" don't work.
posted by alasdair at 11:26 AM on October 20, 2009
On the face of it this is good for screenreader (blind) users. You can present your site with the useful content first, and the navigation at the end.
In practice, however, (1) no-one does this, so screenreader users have learned to use header tags instead and (2) where some people do it's actually confusing because it's so rare, so trusty techniques like "skip all the links" don't work.
posted by alasdair at 11:26 AM on October 20, 2009
« Older Steve Jobs interview | UP Newer »
This thread has been archived and is closed to new comments
posted by smackfu at 11:47 AM on October 15, 2009