# [00:17] <cardona507> Philip`: or tabatkins - now that I have my svg code - how do I view it? Of course I can look at it in AI - but when I make it code and put it online it only looks like code in my browser http://cardonadesigns.com/butt.svg (yeah it says butt tab)

# [00:18] <TabAtkins> cardona507: Your webserver is sending it with a content-type of text/plain.

# [00:19] <cardona507> so I need to change htaccess to allow the mime type?

# [00:45] <Philip`> I think it's nice to have these things in SVG partly since scalability is good (particularly when printing) and partly because it's good to have in an editable format

# [00:45] <cardona507> cool - I"ll make the other 2 correct and in svg - do you recommend that I do any future graphics for the spec in svg?

# [00:45] <Philip`> so someone can make further changes without having to start from scratch

# [00:46] <Philip`> (though I think the spec still needs a PNG fallback for obsolete browsers, like IE8)

# [00:47] <Philip`> I'd prefer SVG, but my opinion has no particular weight so there's no reason to take it into account :-)

# [00:50] <AryehGregor> Philip`, when I pointed out a Unicode character that didn't render on Firefox/Chrome on the latest Ubuntu, Ian told me to get better fonts and didn't change the text. So to heck with fallbacks? :)

# [00:54] <Philip`> AryehGregor: Given that Microsoft people have asked questions about canvas, and assuming that Microsoft people use IE, there would be practical benefits to having fallbacks for those diagrams

# [03:06] <AryehGregor> It just randomly occurred to me that you could avoid compatibility problems and still encourage Flash to die by using <video> as fallback for Flash, instead of the other way around.

# [03:06] <AryehGregor> So your site still works even if Flash isn't installed, even if not quite how you'd like it.

# [03:10] <cardona507> interesting thought ---- the part about encouraging flash to die that is :)

# [03:17] <AryehGregor> I should say, your site might still work if Flash isn't installed.

# [14:30] <Lachy> Hardware vendors for blu-ray players are issued device keys that are stored somewhere in the firmware, usually in a way that's difficult for end users to access.

# [14:30] <hsivonen> I don't even know what the threat scenarios are here

# [14:31] <Lachy> The blu-ray discs have information on them pertaining to the set of keys that are valid. (This isn't just a simple list, it uses some complicated mathematics that I won't even try to explain)

# [14:31] <Lachy> The AACS have a way to blacklist device keys by altering that information on future discs

# [14:37] <hsivonen> I have one that could accept updates, but the TV works now as a display for a Mac Mini, so I haven't taken any chances with updates

# [14:38] <hsivonen> I've never tried the built-in networking or the widget engine on the TV

# [14:38] * Philip` vaguely remembers an explanation that the complicated mathematics is kind of like there's a binary tree with device keys as leafs, and the disc can contain a set of keys corresponding to nodes in the tree, where each node key can be combined with a device key in a subtree of that node, in order to decode the disc

# [14:38] <hsivonen> in fact, I've never even connected it to a TV antenna cord

# [14:38] <Philip`> and so the first discs just need a key at the root node, and later you can blacklist any arbitrary device key by only giving node keys at the nodes that aren't its ancestors (i.e. by giving O(depth of tree) keys)

# [14:41] <Lachy> mandatory updates when DRM is involved can be a real pain. I've been affected by Spotify's mandatory DRM updates, which wouldn't allow me to play my songs on my iphone till I upgraded the spotify app

# [14:42] <Lachy> that's what made me decide to stop paying for spotify

# [14:48] <gsnedders> "To simplify the tasks of applications, the XML processor MUST behave as if it normalized all line breaks in external parsed entities (including the document entity) on input, before parsing, by translating both the two-character sequence #xD #xA and any #xD that is not followed by #xA to a single #xA character."

# [17:24] <adactio> hsivonen: well, I haven't actually used the <details> element itself but I imagine it wouldn't be too tricky to test for native support in JavaScript (in a similar way to checking for native input types).

# [17:24] <TabAtkins> It's not difficult. <details> has an open method you can test for.

# [17:25] <adactio> As I said, it's the *pattern* that I use all the time. It would be nice to see such a common pattern move from a scripted to a declarative solution (much like all those new input types).

# [17:30] <brucel> I added a request to un-kill details Found this the other day by clicking the tabs at the top of labs.opera.com and wondered if you minded if I give it a spring clean to mention HTML5, widgets, mobile best practices etc.

# [17:30] <brucel> I saw " Opera provides experimental support for some types of Compound Documents, leading this work which is still in development at W3C with practical implementations that people can use." and had to look up Compound Documents - is this something still actively used today (and I'm too thick to have heard of it?)

# [17:30] <brucel> Opera Software does not believe innovation in the software industry is protected or encouraged by software patents. In particular, we believe interoperability on the Internet should be encouraged, and we actively work to ensure that software patents do not stand in the way of interoperability.

# [17:30] <brucel> As a highly innovative company, Opera Software comes up with many ideas and concepts that are patentable. In some situations, we will apply for software patents as a way to protect ourselves from attacks by other aggressive patent holders.

# [17:30] <brucel> I added a comment in the bug tracking thang to undelete <details>. Dunno what the proper process is... the fact that Shelley had filed a bug to kill it had passed me by or I'd;'ve protested before it was drowned in a bucket

# [17:31] <brucel> I added a comment in the bug tracking thang to undelete <details>. Dunno what the proper process is... the fact that Shelley had filed a bug to kill it had passed me by or I'd;'ve protested before it was drowned in a bucket

# [17:49] <AryehGregor> Re <details>: I realize it's very common, but there are zillions of common things people use JS for. Why should we add this one to HTML and not all the others?

# [17:49] * AryehGregor will now be challenged to provide examples, which he'll be forced to come up with off the top of his head, so they'll be easily shot down and everyone else will smugly claim victory.

# [17:51] <adactio> So, just to get this straight in my own head: there is no longer a spec named HTML5 at the WHATWG. There is a spec named HTML5 at the W3C. There is a WHATWG spec named HTML.

# [17:59] <adactio> For. Fuck's. Sake. As if this stuff wasn't confusing enough for authors already. Now they have to put up with stupid spec obfuscation for the sake of some minor semantic victory for someone somewhere.

# [18:01] <AryehGregor> And are still complaining the spec is too big.

# [18:01] <cardona507> one spec to rule them all - and one spec to bind them....

# [18:01] <Philip`> Someone should make a Venn diagram of all the spec documents

# [18:01] <adactio> AryehGregor: the design principles would seem to indicate to me that the spec is supposed to be easy to use (as well as precise).

# [18:01] <hsivonen> adactio: looks like Hixie can't do what you like and what Shelley likes at the same time :-(

# [18:02] <AryehGregor> adactio, no, the features it specifies are supposed to be easy to use. It's not meant for ordinary authors to use it to learn HTML, you can't do that and be a good reference at the same time.

# [18:02] <AryehGregor> People will still need separate tutorials to actually learn how to use HTML, unless they're crazy spec-reading people like us.

# [18:02] <adactio> hsivonen: I didn't realise that I was supposed to the bug tracker as my own personal bitching space. There are plenty of things I question in HTML5, but I would never file my personal issues as "bugs": I take them to the list for discussion.

# [18:02] <hsivonen> now HTML5 is something for everyone: a series of small hard-to-track specs or one big cross-referenced thing

# [18:03] <AryehGregor> Rather than, you know, saying it doesn't matter and so who cares, let's just let the editor do what he feels like.

# [18:05] <Dashiva> And the issue tracker is the only way to force a non-technical solution...

# [18:06] <AryehGregor> Or a technical one the editor doesn't agree with.

# [18:06] <Philip`> The issue tracker is the only way to get a solution that differs with the conclusions that Hixie reaches based on the available evidence

# [18:07] <adactio> I understand why all this childish splitting of specs is going on (HTML, HTML5, whatever) but this isn't just about the WHATWG and the W3C. It's harmful to authors trying to understand this stuff. Why bother publicly publishing this stuff at all if it's going to be made as confusing as possible to figure out exactly what is published where.

# [18:12] <webben> daedb: Most of the authorship is not interested in specs anyway. <video> being on MDC or in Mark's Dive Into book, for instance, is more important than which of W3C's/WHATWG's docs it sits in.

# [18:13] <Dashiva> It seems to fail many of the same criteria as microdata did

# [18:13] <adactio> I would like to point people at the spec called HTML5. If the WHATWG want to have an ongoing internal masterspec called HTML that's fine, but it shouldn't take precedence over what authors are interested in reading i.e. the current spec.

# [18:13] <AryehGregor> The only thing that differs is it has no competitor.

# [18:18] <adactio> I realise that my anger is probably misplaced here. I understand *why* this silly spec-splitting is going onâ€”it's driven by forces outside the WHATWG. But from my perspective, which is primarily as an evangelist, it makes it really bloody hard to explain this mess to my peers.

# [18:18] <daedb> AryehGregor: Sure, but when all the sugar is removed the spec becomes boring for everyone who doesn't publish videos or use canvas.

# [18:36] <Philip`> Each web browser is expected to implement all of CSS3, whereas no software is expected to implement all those IP protocols

# [18:37] <itpastorn> You have obviously not heard of an operating system - well perhaps we could say it does not have to implement all routing protocols, but a few hundred others I did not mention instead.

# [18:37] <Philip`> (...as long as you don't consider something like IOS to be a single piece of software)

# [18:38] <itpastorn> Which I did, as well as the *nix's and Windoze and the BSD's, etc.

# [18:39] <Philip`> The modularity of an OS seems completely different to the modularity of a web browser implementation

# [21:12] <navap> Is there a difference between the whatwg and w3c specs for html5?

# [21:13] <Hixie> the "whatwg html" spec is a superset of the w3c html5 spec -- it has features that aren't yet in the w3c copy, like <device>, and it puts everything in one document instead of several

# [21:14] <Hixie> (the whatwg currently also has an "html5" spec that's identical to the w3c "core and vocabulary" one, but i think that's just causing confusion so i might just drop it)

# [21:41] <Hixie> Lachy: i'm not convinced the changes to the FAQ actually made matters better.. in particular, i think the IETF might take offence, for instance, at being described as part of the W3C HTML WG.