| 00:08 | <Philip`> | Does anyone know if there's been work on relatively comprehensive tests for parts of <canvas>, more than the random collections on Hixie's and Anne's and Opera's sites? |
| 00:09 | <Philip`> | I don't pretend to know what I'm doing, but I played around a bit with some tests for the first testable feature and found a case that gives six different results between four implementations and [my interpretation of] the spec |
| 00:09 | <Dashiva> | Which feature is that? |
| 00:09 | <Philip`> | so it seems like it could be a fruitful direction, if it's not repeating other people's work |
| 00:10 | <Philip`> | Just width/height |
| 00:11 | <Philip`> | (particularly when setting it to invalid values) |
| 00:11 | <Philip`> | (...which isn't very relevant in practice, but at least it's easy to test :-) ) |
| 00:12 | <zcorpan_> | i don't know of any tests other than hixie's and anne's |
| 00:12 | <zcorpan_> | on <canvas> |
| 00:13 | <Dashiva> | I did some tests for Opera, but those were just to see which features were buggy during early implementation |
| 00:13 | <Dashiva> | They're probably long gone |
| 00:14 | <Philip`> | Ah, okay |
| 00:15 | <Philip`> | http://tc.labs.opera.com/html/canvas/ has a few more (~135), but that's the most I've found |
| 00:15 | <othermaciej> | we have some in the WebKit layout tests |
| 00:20 | <Hixie> | re the video states, i understand the proposed states |
| 00:21 | <Philip`> | http://trac.webkit.org/projects/webkit/browser/trunk/LayoutTests/fast/canvas - that looks like them |
| 00:21 | <Hixie> | i just need to look at them closely to see if the current proposal can be made better :-) |
| 00:21 | <othermaciej> | it wasn't obvious to me at first why some were needed |
| 00:21 | <Hixie> | taking into account everyone's feedback, etc |
| 00:21 | <othermaciej> | which is why I offered |
| 00:22 | <Hixie> | well e.g. ERROR could easily be merged with UNINITIALIZED, it doesn't have to be a separate state |
| 00:22 | <Hixie> | ERROR is an event, not a state |
| 00:22 | <Hixie> | it's a failure to enter another state. |
| 00:23 | <othermaciej> | part of the reason for the states is so that you can catch up if you attach a controller to an already in-use element |
| 00:23 | <Hixie> | sure |
| 00:24 | <Hixie> | you don't need ERROR for that |
| 00:24 | <othermaciej> | a controller would want to know if something hasn't started loading yet, or tried and failed |
| 00:24 | <Hixie> | i don't understand the use case for that particular one |
| 00:24 | <Hixie> | when would you have a controlled join something and then itself decide to start playback if nothing else had? |
| 00:25 | <othermaciej> | I mean for display, not for deciding to play |
| 00:25 | <othermaciej> | "haven't loaded anything" would presumably show different UI than "tried to load this and it broke" |
| 00:25 | <Hixie> | when would you have a controller join a video element and then display a generic error message? |
| 00:25 | <Hixie> | i can't imagine a case where that would happen |
| 00:26 | <othermaciej> | well, if you could have one join after the fact at all, you need to be able to represent the current state of the element enough to continue |
| 00:27 | <othermaciej> | maybe currentSrc being empty or not is enough to distinguish UNITIALIZED from ERROR, but that's a little weird |
| 00:27 | <Hixie> | i could see one join in order to catch cue points for advertising, but i couldn't see that controller care about error state vs not loaded state |
| 00:27 | <Hixie> | currentSrc wouldn't be initialised either |
| 00:27 | <Hixie> | there was an error |
| 00:27 | <Hixie> | thus there's no currentSrc |
| 00:28 | <othermaciej> | so in case of error you couldn't even tell what you tried and failed to load |
| 00:28 | <Hixie> | the error is almost certainly going to have been that you couldn't load anything in the first place |
| 00:28 | <Hixie> | but anyway |
| 00:28 | <Hixie> | like i said |
| 00:28 | <Hixie> | i need to look at this |
| 00:28 | <Hixie> | i haven't specced anything yet |
| 00:29 | <Hixie> | one possible solution is to have the state be STOPPED, but to have a lastError attribute |
| 00:29 | <Hixie> | (or UNINITIALISED, though i hate typing that) |
| 00:30 | <othermaciej> | STOPPED implies that it is what a media control "stop" button would put you in, which does not seem right to me (though most media controls these days don't even have stop really, just pause) |
| 00:36 | <Lachy> | UNINITIALISED is a bad name, the webkit proposal actually spells it UNINITIALIZED |
| 00:41 | <Lachy> | does the load() method need to be called by a script before the video will begin downloading? |
| 00:41 | <Hixie> | play() calls load() in the current proposal |
| 00:42 | <Lachy> | ok |
| 00:42 | <othermaciej> | I would expect auto-loading to be a more desired use case than load-on-demand |
| 00:43 | <Lachy> | how much space is the UA supposed to allocate to the video before it's begun loading it? |
| 00:43 | <Lachy> | without height and width attrs |
| 00:44 | <othermaciej> | you could use CSS, but we also proposed width and height attrs (in part for the before-it's-loaded case, and in part because you want a way to size that excludes controls) |
| 00:44 | <Lachy> | there are cases where autoloading isn't desired by the user |
| 00:45 | <Hixie> | (current spec doesn't yet define autoload="", but note that so for we've read requests for numerous users asking to NOT have load on demand, and only requests from authors asking for it) |
| 00:46 | <zcorpan_> | Kid looks nice. |
| 00:46 | <othermaciej> | having autoload be UA behavior instead of script leaves open the possibility of a UA preference |
| 00:46 | <Hixie> | regarding sizing, we'll have default size, css will size the content area, controls will be a pseudo or something, and i have to go |
| 00:46 | <Hixie> | bbl |
| 00:46 | <Lachy> | zcorpan_, what kid? |
| 00:46 | <othermaciej> | I don't think a UA could reasonably have a pref to ignore an explicit .load() call from script |
| 00:46 | <zcorpan_> | http://www.kid-templating.org/ |
| 04:56 | zcorpan_ | updated http://simon.html5.org/test/html/embedded/ to match current spec |
| 05:09 | <Lachy> | zcorpan_, we should add SVG to those tests |
| 05:09 | <zcorpan_> | Lachy: is it any different from application/xml? |
| 05:10 | <Lachy> | the XML you've used is XHTML, which isn't an image. SVG is. |
| 05:10 | <zcorpan_> | so svg should work with <img>? |
| 05:10 | <Lachy> | SVG should render inside <img> |
| 05:11 | <Lachy> | it should render in all of them |
| 05:12 | <zcorpan_> | what is svg? any xml with the root svg:svg? |
| 05:13 | <Lachy> | yes |
| 05:13 | <Lachy> | well, you should check the SVG spec to be sure |
| 05:15 | <othermaciej> | svg should have an image/svg+xml mime type |
| 05:15 | <othermaciej> | I don't think <img> should render application/xml with an SVG root element |
| 05:15 | <Lachy> | does it need that MIME type to work in <img>? |
| 05:15 | <othermaciej> | of course at present no browser renders SVG in <img> |
| 05:16 | <othermaciej> | we had experimental code to do it in WebKit but it is off for now |
| 05:16 | <othermaciej> | I think MIME type should be the trigger, yes, you should not have to parse just to know whether to display |
| 05:17 | <Lachy> | hmm. I guess switching on the MIME is more efficient in this case |
| 05:18 | <zcorpan_> | so xhtml as image/svg+xml should render in <img>? |
| 05:18 | <zcorpan_> | or would that be an invalid image, and thus fallback would be used? |
| 05:19 | <Lachy> | it should render the fallback. What happens with image/png using somehting that isn't an image? |
| 05:21 | <zcorpan_> | well, it will try to parse it as png or gif or jpeg or other supported image formats, if that fails render fallback |
| 05:21 | <zcorpan_> | but svg is just xml |
| 05:22 | <zcorpan_> | so you'd have to check the root element anyway |
| 05:22 | <zcorpan_> | no? |
| 05:22 | <othermaciej> | zcorpan_: SVG can legitimately include xhtml content |
| 05:22 | <zcorpan_> | oh sure |
| 05:22 | <zcorpan_> | but what if the root is not svg:svg? |
| 05:23 | <othermaciej> | I dunno |
| 05:23 | <othermaciej> | is that illegal per the MIME type? |
| 05:23 | <Lachy> | then it's another type of XML that includes SVG |
| 05:23 | <othermaciej> | if you send application/xhtml+xml and have a different namespace element as the root, should that not render? |
| 05:23 | <Lachy> | the root element determines the host langugage |
| 05:23 | <othermaciej> | in, say, an iframe? |
| 05:23 | <Lachy> | othermaciej, yes |
| 05:23 | <othermaciej> | the mime type determines what Document interfaces are present |
| 05:24 | <othermaciej> | so there might be legit reasons to use one that does not match your root element |
| 05:24 | <Lachy> | really? I thought the API was determined by the actual element used |
| 05:24 | <zcorpan_> | is there a spec for svg in <img>? |
| 05:25 | <Lachy> | not a good one |
| 05:25 | <Lachy> | HTML4 says <img> is for use with any image type, and lists a few examples like GIF and JPG |
| 05:26 | <zcorpan_> | othermaciej: i thought the idea was as of html5 that the document would implement all interfaces supported, e.g. both HTMLDocument asd SVGDocument if the browser supports both HTML and SVG |
| 05:27 | <othermaciej> | zcorpan_: I do think we should do that, though I'm not sure HTML5 calls for it |
| 05:27 | <Lachy> | zcorpan_, are the interfaces compatible? |
| 05:27 | <othermaciej> | though I have not read super thoroughly |
| 05:29 | <zcorpan_> | 2.1. Documents |
| 05:29 | <zcorpan_> | "Document objects must also implement the document-level interface of any other namespaces found in the document that the UA supports. For example, if an HTML implementation also supports SVG, then the Document object must implement HTMLDocument and SVGDocument." |
| 05:30 | <Lachy> | what if the 2 APIs define methods or properties with the same name, but which do different things |
| 05:31 | <othermaciej> | Lachy: I don't think they do at present, and presumably in such a case we would beat SVG WG over the head with a cluebat |
| 05:31 | <Lachy> | http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C%21DOCTYPE%20html%3E%0A%3Cimg%20src%3D%22http%3A//hixie.ch/tests/adhoc/svg/shapes/path/001.xml%22%20height%3D%22400%22%20width%3D%22400%22%20alt%3D%22FAIL%22%3E%0A%3Ciframe%20src%3D%22http%3A//hixie.ch/tests/adhoc/svg/shapes/path/001.xml%22%20height%3D%22400%22%20width%3D%22400%22%3EFAIL%3C/iframe%3E%0A%3Cembed%20src%3D%22http%3A//hixie.ch/tests/adhoc/svg/shapes/path/001.xml%22%20he |
| 05:31 | <Lachy> | ight%3D%22400%22%20width%3D%22400%22%3E%3C/embed%3E%3Cnoembed%3EFAIL%3C/noembed%3E%0A%3Cobject%20data%3D%22http%3A//hixie.ch/tests/adhoc/svg/shapes/path/001.xml%22%20height%3D%22400%22%20width%3D%22400%22%3E%3C/object%3E |
| 05:32 | <Lachy> | the SVG working group have done some stupid things in SVG. Who knows what they might do |
| 05:33 | <othermaciej> | Lachy: they would probably take feedback from HTML WG more seriously than from individuals |
| 05:33 | <othermaciej> | because they are all procedural like that |
| 05:33 | <Lachy> | I heard they ignored feedback from the CSS WG, regarding some incompatibilites with their use of font-size |
| 05:40 | <zcorpan_> | if we want svg to work in <img>, we need a spec for how it should work |
| 05:41 | <Lachy> | it should be addressed in HTML5 |
| 05:41 | <zcorpan_> | yeah |
| 05:43 | <zcorpan_> | should it be able to run scripts? should scripts be able to access the parent document? what happens if the dom is modified so that the root is no longer svg:svg? |
| 05:43 | <Lachy> | good question |
| 05:53 | <othermaciej> | zcorpan_: (1) I don't think there should be any requirement on the root element, just the MIME type |
| 05:54 | <othermaciej> | zcorpan_: (2) I don't think user events should be passed in |
| 05:54 | <othermaciej> | zcorpan_: not sure about animation and scripting |
| 05:54 | <othermaciej> | zcorpan_: I am inclined to say to declarative SMIL animations and no to scripting |
| 05:54 | <othermaciej> | my 2c anyway |
| 05:54 | <othermaciej> | Lachy: I'm on the SVG WG now, so I can beat them from within if needed |
| 05:55 | <othermaciej> | although I hope olliej can do most of the dirty work and I can just register needed Formal Objections |
| 05:56 | <zcorpan> | so what happens with xhtml as image/svg+xml? render it or use fallback? |
| 05:58 | <othermaciej> | render it |
| 05:58 | <zcorpan> | ok |
| 05:58 | <othermaciej> | or generic xml as image/svg+xml |
| 05:58 | <othermaciej> | I know that is kind of crazy |
| 05:58 | <othermaciej> | but if SVG is allowed at all, you can already do <svg:svg><svg:foreignObject><html:whatever...>... |
| 05:59 | <othermaciej> | so ruling out other root elements does not achieve much, unless you ban foreignObject in SVG as IMG |
| 05:59 | <othermaciej> | ideally you also want SVG to work for CSS background images |
| 05:59 | <othermaciej> | we had code for that but it's off for now |
| 06:00 | <zcorpan> | but when the svg is root it's still defined how it should render as an image... having xhtml as a background image doesn't make sense |
| 06:01 | <othermaciej> | how is it more or less defined based on root? |
| 06:03 | <zcorpan> | svg says how to render svg images, and if it includes xhtml as fogeignObject doesn't affect the image's width/height etc |
| 06:04 | <othermaciej> | where does svg say how to render svg images? |
| 06:05 | <zcorpan> | dunno, i haven't read the svg spec carefully, but if it doesn't, what does it say? |
| 06:05 | <othermaciej> | it doesn't say how to render SVG in an html <img> as far as I know |
| 06:06 | <othermaciej> | no spec does |
| 06:06 | <othermaciej> | or as a CSS background image |
| 06:06 | <zcorpan> | indeed |
| 06:06 | <zcorpan> | but it says how svg images should render in general, ignoring <img> |
| 06:06 | <zcorpan> | right? |
| 06:06 | <othermaciej> | it says how SVG should render |
| 06:07 | <othermaciej> | when processed as a top-level XML document |
| 06:07 | <othermaciej> | but of course, xhtml+css already say that for xhtml |
| 06:09 | <zcorpan> | hmm, i guess you could specify a width and height of <html> and let it happily render as a background image, but i thought the intent was that document formats like html shouldn't work as backgrounds in css |
| 06:18 | <othermaciej> | yes, well, it's hard to draw bright lines |
| 06:19 | <othermaciej> | SVG WG would say that SVG isn't an image, it's an animation |
| 06:19 | <othermaciej> | even when static |
| 06:19 | <othermaciej> | so they wouldn't even want that as a background image |
| 06:19 | <zcorpan> | animated gifs work fine as backgrounds, fwiw |
| 06:20 | <zcorpan> | both opera and firefox render xhtml as image/svg+xml in <embed> (and run scripts) |
| 06:25 | <othermaciej> | <embed> is pretty free-wheeling |
| 06:25 | <othermaciej> | but in general browsers don't compare root element to server-reported mime type |
| 06:27 | <zcorpan> | you're right, i thought however we didn't want to render xhtml as backgrounds in css, and thus it would be required to check the root element. the mime could then be any xml, not just image/svg+xml |
| 06:29 | <othermaciej> | I think keying off the mime type and letting people cheat is ok |
| 06:29 | <zcorpan> | is it expensive to check the root? |
| 06:40 | <othermaciej> | well, you have to fire up the XML parser and let it run and know to bail out at some point |
| 06:40 | <othermaciej> | not that expensive but you go much deeper than purely by MIME type |
| 06:41 | <othermaciej> | here's the MIME type regsitration for image/svg+xml, you figure it out: http://www.w3.org/TR/2005/WD-SVGMobile12-20050413/mimereg.html |
| 06:41 | <othermaciej> | "Because SVG is extensible, conformant "image/svg+xml" processors must expect that content received is well-formed XML, but it cannot be guaranteed that the content is valid to a particular DTD or Schema or that the processor will recognize all of the elements and attributes in the document." |
| 06:42 | <othermaciej> | it's pretty vague |
| 06:43 | <zcorpan> | yeah... pretty much "this is xml" |
| 06:45 | <zcorpan> | thing is if you allow xhtml to be rendered as background, how should repeated backgrounds be handled, etc? can you interact with <input>s? while it may be more expensive to check the root you get less cases you have to define |
| 06:46 | <zcorpan> | if it will be discarded then authors won't use it, so you can expect all xml as <img> or background to be svg anyway... |
| 07:10 | <webben> | i should think xhtml should be rendered in backgrounds, since xhtml is one way of including text in svg |
| 07:11 | <webben> | as for controls, i would render them as static backgrounds |
| 07:11 | <webben> | (assuming we're talking background-image here) |
| 07:13 | <zcorpan> | if you can render xhtml as a background, why not text/html too? text/plain? |
| 07:14 | <webben> | zcorpan, i'd have no objection to either |
| 07:14 | <webben> | zcorpan, but i don't think people are likely to use text/plain |
| 07:14 | <webben> | (no way to apply css to it, so the look is /totally/ unpredictable) |
| 07:16 | <webben> | basically i think anything can be a background, but it should be non-interactive |
| 07:16 | <zcorpan> | i don't think text/html should be usable as a background (as it is today in css) |
| 07:17 | <webben> | why? |
| 07:17 | <zcorpan> | it doesn't make sense |
| 07:17 | <webben> | how come? |
| 07:18 | <webben> | (i mean i agree one's unlikely to /want/ to use it, but that's different) |
| 07:18 | <zcorpan> | because it's a document with semantics, something you would apply css *to* |
| 07:20 | <webben> | AFAIK SVG can be a document with semantics which you apply CSS too as well, separating content (e.g. a diagram, buttons, text) from presentation. |
| 07:20 | <webben> | hence http://www.w3.org/TR/SVG/styling.html |
| 07:20 | <zcorpan> | yes. hence, using svg as a background is slightly bogus too :P |
| 07:21 | <othermaciej> | SVG at least *can* be used as a vector graphics format |
| 07:21 | <webben> | well, what one's really saying is make an image from this. |
| 07:21 | <othermaciej> | and the web could use a scalable vector format for use in images |
| 07:21 | <webben> | i don't see anything intrinsically wrong about making an image from anything |
| 07:21 | <othermaciej> | WebKit supports PDF for that, but PDF is surprisingly bloated |
| 07:22 | <othermaciej> | even simple PDFs are huge |
| 07:23 | <webben> | by definition if used as a background then the semantics are irrelevant clientside |
| 07:23 | <webben> | (although they might be relevant serverside, e.g. i18n of colors in a SVG graphic) |
| 07:51 | <Lachy> | allowing any format to be used as a background would be a nightmare for implementors |
| 07:51 | <othermaciej> | allowing SVG to be used as a background is a nightmare |
| 07:51 | <othermaciej> | but it's still useful |
| 07:52 | <Lachy> | even if it did make sense (which it doesn't), why would anyone want to use text/html, etc. as an image? |
| 07:52 | <webben> | Lachy, I dunno. Basically just requires the ability to fake a screenshot of displayed content. |
| 07:52 | <Lachy> | I realise SVG has implementation issues too, but it at least has a use case |
| 07:52 | <webben> | as screen capture type programs seem common, it doesn't sound like a huge nightmare |
| 07:54 | <webben> | Lachy, I'm not arguing anyone would want to. But they might possibly wish to use svg+xhtml, which amounts to something similar |
| 07:54 | <webben> | more to the point, if you can solve the probs with svg as background, then i think the text/html probs would be easy to resolve in the same way |
| 07:54 | <Lachy> | so the browser would have to render it, produce an image out of it and then use the resulting image as a background. That seems like a huge performance issue |
| 07:55 | <Lachy> | but why would it be worth the time of implementors trying to solve it, when no one will ever use it? |
| 07:55 | <webben> | Lachy, why is it different to SVG ... which the browser also has to render and produce a static image from? |
| 07:56 | <webben> | Lachy, I suspect we should be speccing support for a subset of formats for backgrounds, and allow implementors to support additional formats if they choose. |
| 07:56 | <webben> | text/html should be one of those additional formats |
| 07:57 | <webben> | my point is just that SVG actually has text/html's problems anyway |
| 07:57 | <webben> | and that svg+xhtml probably should be part of speced support |
| 07:58 | <Lachy> | I agree with SVG, but until there are use cases for other formats, arguing about whether or not they can or should be supported is pointless |
| 07:59 | <webben> | Lachy, well zcorpan was arguing in the opposite direction (you can't support text/html, therefore not xhtml either) |
| 08:00 | <webben> | but xhtml can be part of svg content |
| 08:06 | <othermaciej> | man, I love watching people try to educate Eric Carlsson about media |
| 08:07 | <Lachy> | othermaciej, who's Eric Carlsson? |
| 08:07 | <othermaciej> | he's probably forgotten more about media than they ever knew |
| 08:08 | <othermaciej> | I misspelled his name though |
| 08:08 | <othermaciej> | one s |
| 08:09 | <Lachy> | ok, still don't know who he is |
| 08:09 | <hsivonen> | othermaciej: are you referring to seeking over HTTP? |
| 08:10 | <othermaciej> | longtime QuickTime developer |
| 08:11 | <othermaciej> | that's the thread I was reading just now |
| 08:12 | <Lachy> | which mailing list? URL? |
| 08:12 | <Lachy> | oh, found his emails |
| 08:13 | <webben> | The ability to separate content from presentation in background graphics formats should ultimately help make authoring more accessible, so it's not all bad. |
| 08:14 | <webben> | (or perhaps i should say: form from style) |
| 08:16 | <KevinMarks> | Eric Rocks |
| 08:16 | <KevinMarks> | seeking over HTTP? |
| 08:16 | <KevinMarks> | hm |
| 08:25 | <KevinMarks> | http://lists.xiph.org/pipermail/vorbis-dev/2001-October/004846.html |
| 08:29 | <hsivonen> | a general problem with media files is that they are hairy and there's little expertise outside the group of actual implementors |
| 08:29 | <hsivonen> | so I wouldn't be too harsh on someone getting something wrong once in a while |
| 08:35 | <othermaciej> | it's ok to be mistaken based on lack of expertise, but not so much to be persistent about an error |
| 08:35 | <hsivonen> | sure |
| 08:35 | <othermaciej> | Silvia Pfeiffer is apparently a media expert of sorts however, per google |
| 08:46 | <KevinMarks> | OK, replied to that |
| 08:48 | <othermaciej> | wow, QuickTime vs Ogg circa 2001 |
| 08:49 | <othermaciej> | KevinMarks: did you and I ever both work at Apple at the same time? |
| 08:49 | <KevinMarks> | Ogg owes more to WMV than to QT |
| 08:49 | <KevinMarks> | I was there 1998 to 2003 |
| 08:49 | <othermaciej> | I started in 2001 |
| 08:49 | <othermaciej> | so quite a while |
| 08:50 | <othermaciej> | I guess you must have been there when Safari came out then |
| 08:50 | <KevinMarks> | yes, though I was more on the hardcore video stuff by then |
| 08:53 | <hsivonen> | this whole thing with Ogg family vs. MPEG-4 family isn't about technical merit but about patentlessness merit. |
| 08:53 | <hsivonen> | and patentlessness trumps technical merit |
| 08:53 | <hsivonen> | as with Huffman coded JPEG vs. arithmetic coded JPEG |
| 08:54 | <KevinMarks> | thats not the level I was arguing on |
| 08:54 | <othermaciej> | we're not debating technical merit of Ogg |
| 08:54 | <KevinMarks> | well, I was |
| 08:54 | <othermaciej> | oh |
| 08:54 | <KevinMarks> | Both ogg and QT can intheory include arbitrary codecs |
| 08:54 | <othermaciej> | I see your mail now |
| 08:55 | <KevinMarks> | however, QT can do it in practice too |
| 08:55 | <hsivonen> | s/patentlessness/only having RF-licensed or chronically unenforced patents/ |
| 08:55 | <KevinMarks> | So QT with JPEG video and u-law audio would satisfy you? |
| 08:56 | <hsivonen> | KevinMarks: no. there has to be some level of technical suitability as well |
| 08:56 | <othermaciej> | QT isn't patentless, is it? |
| 08:57 | <hsivonen> | but sadly, royalty-free and not so efficient has to win over royalty-bearing and more efficient as the baseline format |
| 08:57 | <othermaciej> | (thought Apple has the only patents so in theory could donate them) |
| 08:57 | <KevinMarks> | the file format is as long as you leave out the pointless hint tracks |
| 08:57 | <webben> | what are hint tracks? |
| 08:57 | <othermaciej> | are there any other patents relevant to the MPEG-4 container format? |
| 08:58 | <othermaciej> | I know it is based on QT's format but no one has yet explained to me what is different |
| 08:58 | <KevinMarks> | which Singer patented, then watched Apple lawyers destroy interop by suing the 2 other server makers |
| 08:58 | <KevinMarks> | Singer can tell you |
| 08:58 | <KevinMarks> | broadly, C strings instead of P strings in several places |
| 08:58 | <KevinMarks> | and some extra headers that override the QT ones |
| 08:59 | <hsivonen> | FWIW, when Electronic Frontier Finland (EFFI, like EFF) gave recommendations about video formats for the Web, I was the principal author and the two formats we recommended were Ogg/Theora/Vorbis on licensing grounds and MP4/H.264/AAC on standard/installed base/quality combo grounds |
| 08:59 | <othermaciej> | too bad there is not one format that meets all those criteria |
| 09:00 | <hsivonen> | oh, and besides patents, there's another consideration in Theora's favor |
| 09:00 | <KevinMarks> | There is a plausible argument that Vorbis and Theora are unchallenged on licensing grounds because no-one big enough to be worth suing has adopted them |
| 09:00 | <hsivonen> | H.264 has an insane repertoire of profiles and levels |
| 09:00 | <hsivonen> | whereas with the currents impls if you say Theora, it is Theora |
| 09:01 | <hsivonen> | but QuickTime won't play all H.264 |
| 09:01 | <webben> | hmm that does sound like a big advantage |
| 09:01 | <hsivonen> | and PSP and iPod play even less |
| 09:01 | <KevinMarks> | certainly when I was at Apple, my many attempts to get Vorbis into QT were rebuffed because of fears that Fraunhofer or Dolby would sue us |
| 09:01 | <webben> | keep things simple |
| 09:01 | <hsivonen> | and figuring the parameters out without it being your dayjob is *hard* |
| 09:01 | <othermaciej> | it's not that big, because you can pick a subset of H.264 profiles if you want |
| 09:02 | <othermaciej> | Simple and Advanced Simple are probably good enough |
| 09:02 | <hsivonen> | KevinMarks: the manager of Nokia's Maemo operation said that they are afraid of shipping Vorbis until their own people investigate whether there's some Fraunhofer stuff in there after all |
| 09:03 | <webben> | Maybe the key is to make sure that whatever formats we spec support for, the most obvious people who might sue should sign up to the WHATWG patent policy |
| 09:03 | <othermaciej> | people at Apple are still worried about Ogg patent risk |
| 09:04 | <hsivonen> | othermaciej: I assure you, that interoperating with QuickTime is *hard* if you don't have documented parameters that someone else has spent hours and hours testing |
| 09:04 | <hsivonen> | with e.g. x264 that is |
| 09:04 | <othermaciej> | interoperating in what way? |
| 09:04 | <webben> | othermaciej, from being sued by who? |
| 09:04 | <othermaciej> | encoding something qQuickTime can play? |
| 09:05 | <hsivonen> | othermaciej: using QuickTime as a decoder for stuff encoded using encoders that can potentially use optional features not supported by QuickTime |
| 09:05 | <KevinMarks> | who was it who submarined an mp3 patent on microsoft recently? |
| 09:05 | <othermaciej> | webben: lots of people have patents on audio/video codecs, and no one knows all the ones they exist or what they might apply to |
| 09:05 | <hsivonen> | Alcatel/Lucent |
| 09:06 | <othermaciej> | it's true that you'd have to define an H.264 profile set and not just the codec family |
| 09:06 | <othermaciej> | like 3GPP does |
| 09:06 | <KevinMarks> | see, phone companies a) have a lot of patents b) have a lot of lawyers and c) are getting desperate for revenue |
| 09:06 | <hsivonen> | I'm sorry to say, but I got a feeling like QuickTime was like the Internet Explorer of MPEG-4 |
| 09:06 | <hsivonen> | when trying to interoperate, that is |
| 09:06 | <webben> | othermaciej, Well yes. I can see that. But do you mean Apple is worried about /any/ external format? Or are there special fears peculiar to Ogg? |
| 09:07 | <KevinMarks> | thats a little unfair, especially when the alternative is DiVX |
| 09:08 | <hsivonen> | KevinMarks: well, the DivX and XviD stuff is uncool in the sense that they don't use ISO packaging |
| 09:08 | <KevinMarks> | what they do with mp3 framing is particularly ugly as I recall |
| 09:08 | <hsivonen> | but anyway, the profiling and levels of H.264 are bad, bad, bad |
| 09:09 | <KevinMarks> | but yes Apple should do a better job of playing stuff back anyway |
| 09:09 | KevinMarks | has perian installed |
| 09:11 | <othermaciej> | I would like it if a Mac could play all video formats commonly found on the web out of the box |
| 09:12 | <webben> | o/t: indeed, it would be nice if Apple could licence the Windows Media stuff and distribute OSX with all that stuff preinstalled. |
| 09:13 | <KevinMarks> | when Apple first did mpeg4 I said that it wsn't done until it played divx avi's |
| 09:13 | <KevinMarks> | however I was ignored |
| 09:14 | <webben> | it's rather weird since free *nix'es get criticized for not being desktop ready for not playing these formats as distributed. |
| 09:16 | <othermaciej> | wow, http://www.apple.com/quicktime/ is down |
| 09:16 | <KevinMarks> | it's up for me |
| 09:17 | <othermaciej> | it's alive now |
| 09:17 | <othermaciej> | that was weird |
| 09:19 | <KevinMarks> | akamai glitch? |
| 09:19 | <othermaciej> | could be |
| 09:23 | <Lachy> | I like Dean's idea of renaming <source> to <content>, it's a much better name |
| 09:24 | <KevinMarks> | no it isn't |
| 09:24 | <Lachy> | why not? |
| 09:24 | <KevinMarks> | content implies containment |
| 09:24 | <KevinMarks> | or happiness |
| 09:25 | <Lachy> | <content src> implies the content can be retrieved from the given location |
| 09:26 | <othermaciej> | if we have both a sequence of items and alternative items, I'd like it if the element names reflected that |
| 09:26 | <othermaciej> | if you wanted to overengineer it you could have both playlists and alternative lists which could nest each other |
| 09:26 | <Lachy> | <alt> is also better choice |
| 09:26 | <KevinMarks> | I liked your alt stuff maciej |
| 09:27 | <Lachy> | I'm not sure we need a way to markup playlists in HTML |
| 09:27 | <KevinMarks> | yes we do |
| 09:27 | <Lachy> | we have XSPF and a number of other playlist formats |
| 09:27 | <othermaciej> | some current uses of video want to play two videos in a row |
| 09:27 | <KevinMarks> | and it's called <li> |
| 09:28 | <hsivonen> | othermaciej: uses other than playing an ad from a different file first/last? |
| 09:28 | <othermaciej> | I'm not really sure <li> is good, as I suggested there, because it would render a list marker in non-<video> user agents |
| 09:28 | <hsivonen> | (though ads pay for stuff, so they are important) |
| 09:28 | <KevinMarks> | audio playlists are more common |
| 09:28 | <othermaciej> | hsivonen: first, last, between segments |
| 09:28 | <othermaciej> | it might not be needed, I dunno |
| 09:29 | <othermaciej> | but you can definitely do a smoother transition if you cue up the next item before the current one finishes |
| 09:29 | <KevinMarks> | playing ads is a crappy usecase |
| 09:29 | <Lachy> | it's a popular one though |
| 09:29 | <othermaciej> | on the one hand, kinda, on the other hand, I'd rather people play ads using HTML than using Flash |
| 09:29 | <othermaciej> | if they are going to do so anyway |
| 09:29 | <KevinMarks> | you are confusing common with popular there |
| 09:29 | <Lachy> | yes, sorry |
| 09:30 | <KevinMarks> | IE is common, Firefox is popular |
| 09:30 | <hsivonen> | :-) |
| 09:30 | <KevinMarks> | replace IE and Firefox with your own alt-cred badge of honour |
| 09:30 | <othermaciej> | well if you put it like that, I don't want to be common |
| 09:31 | <KevinMarks> | I choose my words very carefully... |
| 09:32 | <KevinMarks> | “10 percent of computer users are Mac users, but remember, we are the top 10 percent.” - Douglas Adams |
| 09:32 | <othermaciej> | hah |
| 09:32 | <othermaciej> | only the top 5 percent these days |
| 09:32 | <othermaciej> | or 6 |
| 09:32 | <othermaciej> | depending on which survey you believe |
| 09:33 | <KevinMarks> | has cameo been getting to you again? |
| 09:34 | <KevinMarks> | when we were inventing XSPF argued for it being HTML then |
| 09:35 | <KevinMarks> | Actually, i think there may be a broader use case than just playlists for a well-defined alternatives container |
| 09:35 | <Lachy> | This site uses javascript to let the user create their own play list of news videos (requires IE, sorry mac users) http://ninemsn.video.msn.com/v/en-au/v.htm |
| 09:36 | <Lachy> | it also plays an ad before the video |
| 09:38 | <KevinMarks> | You know, it's a shame Apple didn't patent popping up annoying ads up before playing the video; that would have discouraged everyone else... |
| 09:48 | <KevinMarks> | and we could then have rejected that usecase |
| 09:51 | <KevinMarks> | o O (hm, lets set up an organisation to patent things we don't want in standards) |
| 09:52 | <othermaciej> | we could call it MPEG FU |
| 09:57 | <met_> | whatwg.org has database problem http://forums.whatwg.org/ http://blog.whatwg.org/ doesn't work |
| 09:58 | <met_> | 'mysql_connect() () Lost connection to MySQL server during query' |
| 09:59 | <Lachy> | I'm not able to lget anything, it's still trying to load |
| 10:00 | <Lachy> | the wiki is down too |
| 10:00 | <Lachy> | Hixie, yt? |
| 10:10 | <annevk> | I think that if you want to support SVG in <img> you probably have to support everything as image |
| 10:10 | <annevk> | including HTML, etc. |
| 10:11 | <othermaciej> | hello annevk |
| 10:11 | <annevk> | Though I think an initial implementation could do a check on the root element to just support SVG or something... |
| 10:11 | <othermaciej> | supporting svg in image opens the door to html in one way or another |
| 10:11 | <othermaciej> | but that doesn't mean you have to accept text/html |
| 10:12 | <annevk> | Well, you'd already support XHTML so supporting text/html... But yes, you wouldn't have to |
| 10:12 | <othermaciej> | even with an svg root element you can easily just fill it with a 100% by 100% foreignObject containing HTML |
| 10:12 | <annevk> | (And regarding the Document stuff. Both HTMLDocument and SVGDocument have a .title member.) |
| 10:13 | <othermaciej> | are they incompatible? |
| 10:13 | <othermaciej> | hmm |
| 10:13 | <Lachy> | hmm. it does seem like trying to turn <img> into <object>, which isn't a good idea |
| 10:13 | <othermaciej> | I guess they have different rules for where to get the title |
| 10:13 | <othermaciej> | that sucks |
| 10:13 | <annevk> | Lachy, no, you wouldn't support scripting etc. I think |
| 10:13 | <annevk> | othermaciej, I think they can be made compatible in some way |
| 10:14 | <annevk> | maybe by doing a check on the root element or something |
| 10:14 | <Lachy> | annevk, that would need to be defined. But if that is, then could <foreignObject> be ignored too? |
| 10:15 | <Lachy> | maybe the SVG working group should define a subset of SVG that UAs would need to support for use in <img> and CSS backgrounds, that excludes all the problematic stuff |
| 10:16 | <annevk> | That doesn't make sense for UAs |
| 10:16 | <othermaciej> | compatibility with HTML/CSS has not been that high on their list of priorities |
| 10:16 | <annevk> | Maybe for authors, but not for UAs |
| 10:16 | <othermaciej> | I am a member of the SVG WG now |
| 10:16 | <annevk> | Because UAs would be forced to render SVG in some different way depending on the context... |
| 10:16 | <othermaciej> | but I don't know if I will have time to make them do anything |
| 10:16 | <Lachy> | yeah, true |
| 10:16 | <annevk> | othermaciej, I saw, I hope you'll be controversial :) |
| 10:16 | <othermaciej> | olliej joined too |
| 10:17 | <othermaciej> | annevk: aren't I always? |
| 10:17 | <annevk> | :) |
| 10:17 | <Lachy> | othermaciej, if they never planned on being compatible with HTML/CSS, then how do they expect SVG to be adopted on a wide scale? |
| 10:17 | <othermaciej> | Lachy: by replacing HTML for all uses |
| 10:17 | <Lachy> | ha! |
| 10:18 | <othermaciej> | I'm slightly parodying their position |
| 10:18 | <othermaciej> | but not by much |
| 10:18 | <annevk> | They do want to replace CSS I believe for layout stuff |
| 10:18 | <annevk> | I saw some things on www-svg iirc talking about layout systems in SVG etc. |
| 10:19 | <hsivonen> | aargh. they really should focus on expressing the PDF imaging model in XML and leave it at that |
| 10:19 | <hsivonen> | I wonder if MARS has sane text/font support kludged into SVG |
| 10:20 | <annevk> | The W3C was initially against presentational formats and now they're doing it all over again with SVG... |
| 10:20 | <annevk> | Well, if they proceed with that plan anyway. |
| 10:20 | <annevk> | "SVG is the new <font>." would be my headline the day that happens. |
| 10:21 | <hendry> | annevk: nice |
| 10:21 | <met_> | Lachy database on whatwg.org works now |
| 10:23 | <othermaciej> | SVG already has text/font support kludged into itself |
| 10:23 | <othermaciej> | doesn't need any additiona kludging |
| 10:27 | <annevk> | Oh right, SVG fonts... |
| 10:27 | <hsivonen> | othermaciej: the problem with SVG's text is that it is the worst of both worlds (both being CSS and PDF) |
| 10:27 | <hsivonen> | othermaciej: no interop |
| 10:27 | <hsivonen> | othermaciej: OTOH, the PDF approach is actually interoperably implementable |
| 10:27 | <annevk> | Maybe we should introduce scripted fonts by means of a <canvas-font> element |
| 10:28 | <othermaciej> | hsivonen: unless you define all your own fonts in SVG! |
| 10:28 | annevk | wonders if a <script> can mutate the font on the fly |
| 10:28 | <othermaciej> | I agree though, SVG text is not so great |
| 10:28 | <annevk> | in SVG |
| 10:28 | <othermaciej> | annevk: that depends on if their spec carefully defined the conformance requirements for dynamic updating |
| 10:28 | <othermaciej> | what do you think the odds of that are? |
| 10:29 | <hsivonen> | othermaciej: I thought SVG fonts are not per-glyph positioned by the generator but the interglyph layout is still left to the renderer |
| 10:31 | <othermaciej> | hsivonen: you define the glyphs, advances and kerning pairs, not sure what freedom that leaves to the renderer |
| 10:31 | <hsivonen> | with all the CTL stuff these days, there are two approaches that work for text in graphics: 1) standardising on the binary blob renderer implementation or 2) the generator sending an array of glyphs and the exact glyph positions |
| 10:32 | <hsivonen> | #1 doesn't work, because none of Microsoft, Apple and Adobe wants to freeze their renderer and share the source |
| 10:32 | <othermaciej> | I'm happy that in HTML you get to compete on text rendering quality |
| 10:32 | <hsivonen> | it works for HTML |
| 10:33 | <hsivonen> | but not for graphics where the text layout and the graphics need to coincide |
| 10:33 | <othermaciej> | I haven't actually seen an SVG where it is a practical problem |
| 10:33 | <othermaciej> | but I guess textArea is new and more potentially problematic |
| 10:33 | <hsivonen> | I have |
| 10:33 | <hsivonen> | Jacques Distler has use cases as usual |
| 10:33 | <othermaciej> | SVG does let you individually position each glyph if you want |
| 10:34 | <hsivonen> | also, in the summer, I tried to publish a diagram as SVG myself |
| 10:34 | <othermaciej> | although you can't control the rasterization of the glyphs (unless you are using an SVG font, and even then, only to the extent that path rendering is defined) |
| 10:34 | <hsivonen> | the only way to get sane results would have been converting text to paths |
| 10:35 | <othermaciej> | surprisingly, the SVG spec is not precise enough to tell you what bitmap results from displaying a particular SVG file at a particular size, even without any text involved |
| 10:35 | <hsivonen> | othermaciej: is it just antialiasing or something bigger? |
| 10:35 | <hsivonen> | bézier tesselation? |
| 10:36 | <othermaciej> | antialiasing and filters are two of the obvious issues |
| 10:36 | <hsivonen> | I'd expect implementations to want to be able to compete on anti-aliasing implementation details and performance |
| 10:37 | <met_> | annevk, do you know why <input type="number"> is different in Opera on Mac than on PC? On Mac it is missing the buttons Up/Down |
| 10:37 | <othermaciej> | method of scaling embedded raster images also not defined |
| 10:38 | <annevk> | met_, no |
| 10:39 | <met_> | annevk, just making some examples of WF2 and found this difference |
| 10:39 | <met_> | annevk, same for <input type="time"> |
| 10:40 | <annevk> | maybe it's because on the Mac we're tied to native widgets or something? |
| 10:40 | <annevk> | I haven't done much UI testing |
| 10:40 | <othermaciej> | it's weird to me that WF2 has so many date/time controls and none for credit cards |
| 10:41 | <met_> | it's the only lack I have found |
| 10:41 | <annevk> | Actually, most of what we did went into technical testing |
| 10:41 | <othermaciej> | I know which I've had to input more times into web forms |
| 10:41 | <webben> | othermaciej, hmm ... but don't CC formats differ |
| 10:41 | <webben> | (e.g. codes on the back, expiry dates, start dates etc) |
| 10:42 | <webben> | and might they not change even more in the future? |
| 10:42 | <Lachy> | met_, I get the up/down buttons in Opera on Mac |
| 10:42 | <annevk> | I think those are pretty standard at the moment |
| 10:42 | <met_> | Lachy, what Opera version? |
| 10:42 | <othermaciej> | yes, most credit card inputs have at least three bits, the actual number, the security code, and the expiration date |
| 10:42 | <annevk> | otherwise I wouldn't be able to use my credit card accross the globe... |
| 10:43 | <Lachy> | credit cards are handled with <input type=text pattern=...> |
| 10:43 | <annevk> | Lachy, that doesn't help with auto-input by the UA |
| 10:43 | <othermaciej> | how does that let the UA put up a list of my credit cards instead of a text field? |
| 10:43 | <Lachy> | fine, <input role="credit-card"> ;-) |
| 10:43 | <annevk> | <input type=cc> |
| 10:43 | <hsivonen> | Lachy: hey, don't reinvent the eCom RFC! |
| 10:44 | <annevk> | prolly eCom could be used I suppose |
| 10:44 | <annevk> | giving meaning to name attribute values... |
| 10:44 | <hsivonen> | RFC 3106 |
| 10:45 | <Lachy> | oh, sure, that RFC has been a huge success in the real world! |
| 10:45 | <hsivonen> | immense |
| 10:45 | <Lachy> | oh, </sarcasm> |
| 10:45 | <webben> | why has it failed? |
| 10:45 | <annevk> | Opera supports it iirc |
| 10:45 | <Lachy> | webben, do you know of any sites that use it? |
| 10:46 | <annevk> | I believe sites use it too, not entirely sure which though |
| 10:46 | <webben> | Lachy, No, I don't mean "hasn't it succeeded?" I mean /why/ has it failed. |
| 10:46 | <hsivonen> | webben: few people know about it. and the names are really ugly and non-obvious too |
| 10:47 | <hsivonen> | this one of those namespacing things |
| 10:47 | <webben> | one could solve problem 1 be mentioning it on the WHATWG microformat wiki |
| 10:47 | <Lachy> | I think microformats should come up with a way of identifying specific form semantics |
| 10:47 | <hsivonen> | can't standardize name='creditcard' because someone might use that field name for telephone numbers |
| 10:47 | <webben> | the namespacing seems non-problematic but the inconsistency is annoying: Ecom_BillTo_Postal_CountryCode |
| 10:47 | <othermaciej> | using class would be better than name |
| 10:47 | <webben> | note the weird use of underscores |
| 10:48 | <othermaciej> | you also want to relate the different controls that are related to one credit card |
| 10:48 | <annevk> | in that case we might as well use the type attribute |
| 10:48 | <othermaciej> | but <input type="something"> seems better when you may want a custom control though |
| 10:48 | <othermaciej> | having a non-heuristic way to identify related username and password fields on login and registration forms would be cool too |
| 10:48 | <webben> | a custom control that does what? |
| 10:49 | <annevk> | enables semantics the UA can use |
| 10:49 | <annevk> | for input and validation |
| 10:49 | <othermaciej> | the UA might be able to store your credit cards in secure storage |
| 10:49 | <othermaciej> | like the Keychain on Mac OS X |
| 10:49 | <othermaciej> | and let you pick one |
| 10:50 | <othermaciej> | instead of making you type |
| 10:50 | <webben> | oh i thought you meant a widget that looks different |
| 10:51 | <webben> | you'd still want additional fields for the other bit of the credit card |
| 10:51 | <webben> | so we really mean "creditcardnumber" |
| 10:51 | <othermaciej> | it might look different too, who knows |
| 10:51 | <annevk> | it doesn't really matter how you call it |
| 10:52 | <othermaciej> | anyway, now's not the time to make such suggestions |
| 10:52 | <annevk> | expiry date is <input type=month> |
| 10:52 | <annevk> | not sure about the three digit number, maybe <input type=password> |
| 10:52 | <othermaciej> | you would want to link it to the credit card number |
| 10:53 | <webben> | the problem is really that you need different sets of data for different cc's |
| 10:53 | <othermaciej> | field |
| 10:53 | <othermaciej> | so when you pick a credit card it can fill all three |
| 10:53 | <othermaciej> | (maybe not the 3-digit code, for security reasons) |
| 10:53 | <annevk> | that could be done through some extension i suppose |
| 10:53 | <othermaciej> | anyway if I were really proposing it I would work it out in more detail |
| 10:53 | <webben> | if we want fields linked together a microformat seems the way to go |
| 10:53 | <annevk> | there have been some suggestions for grouped fields |
| 10:54 | <othermaciej> | webben: you want them to be linked w/o constraining markup containership |
| 10:54 | <othermaciej> | microformats are bad at that, since there's no widely applicable HTML attribute that accepts an id of a related element |
| 10:55 | <hsivonen> | sadly, so far, rel='license' and XFN are the only microformats that are approachable without a longtime investment in gathering tacit knowledge inside the microformats community |
| 10:55 | <annevk> | yeah, too bad |
| 10:55 | <webben> | othermaciej, what's the usecase for not containing these controls in the same fieldset? |
| 10:55 | <othermaciej> | I wish they would write specs with meaningful conformance requirements and such |
| 10:56 | hsivonen | too |
| 10:56 | <met_> | Lachy, just upgraded Opera to last weekly build and Up/Down are here, thanks |
| 10:56 | <webben> | well, one could make such specs a requirement for registering microformats with the WHATWG wiki |
| 10:56 | <annevk> | oh ok |
| 10:56 | <annevk> | cool |
| 10:56 | <webben> | and provide a spec template |
| 10:56 | <annevk> | prolly was a known issue then :) |
| 10:57 | <hsivonen> | webben: I think the microformats spec template is part of the problem |
| 10:57 | <hsivonen> | webben: usually the frustration comes when you take away the boilerplate and see what is left |
| 10:57 | <webben> | hsivonen, Do you mean a) having a template is bad; or b) that template is bad? |
| 10:58 | <hsivonen> | webben: the microformats wiki template is |
| 10:58 | <hendry> | cd |
| 10:58 | <hendry> | woops, wrong terminal |
| 10:58 | <webben> | well, WHATWG could improve on it |
| 10:58 | <webben> | maybe one could also require a conformance checker? |
| 10:59 | <Lachy> | microformats have a spec template? |
| 10:59 | <hsivonen> | webben: haha. good luck with that. |
| 11:00 | <webben> | hsivonen, Or, alternatively, maybe require an implemented reader for that format? |
| 11:01 | <webben> | (of course that works better for data formats than humanities ones) |
| 11:01 | <hsivonen> | webben: I specifically made sure I don't promise anyone that I'd implement an hCard or hCal checker, because I couldn't figure out what the conformance requirements are |
| 11:01 | <hsivonen> | webben: not good enough |
| 11:01 | <hsivonen> | webben: hint: RSS |
| 11:01 | <Lachy> | hsivonen, there aren't any conformance criteria. |
| 11:01 | webben | doesn't get the hint |
| 11:01 | <hsivonen> | Lachy: whoo! implementation done :-) |
| 11:02 | <hsivonen> | webben: do with RSS whatever Radio Userland does is not good enough |
| 11:02 | <Lachy> | microformats seem to just describe what class names can be used with vague descriptions of their meaning, not specify how they should be used |
| 11:02 | <webben> | ah I see |
| 11:02 | <Lachy> | it's like XHTML2! |
| 11:03 | <webben> | well, HTML5 is also wary of telling agents what to do. |
| 11:03 | <Lachy> | HTML5 has very specific processing requirements |
| 11:03 | <webben> | for parsing, sure |
| 11:03 | <Lachy> | it doesn't define things like specific UIs |
| 11:03 | <webben> | doesn't XML have specific processing requirements in that sense too? |
| 11:04 | <annevk> | webben, it defines specific processing requirements for all things |
| 11:04 | <annevk> | not just parsing |
| 11:04 | <webben> | i'm not sure what we mean by "processing" here |
| 11:04 | <annevk> | At least, to me it's clear what Opera should implement (unless a part of the spec is not done) |
| 11:05 | <hsivonen> | webben: XML doesn't spec tree construction from the parse. it is implied |
| 11:06 | <annevk> | (and if it's unclear I mostly e-mail the list, although that's not the sole reason I e-mail the list) |
| 11:06 | <webben> | well, i suppose two things would be very useful with a microformat spec: define what fields must be present + suggest default styles (if any) for all currently speced CSS media types |
| 11:07 | <webben> | much the same as with HTML elements |
| 11:07 | <annevk> | that doesn't help much |
| 11:07 | <annevk> | it needs to define what happens when things are in error too |
| 11:08 | <annevk> | or when not all required fields are present, etc. |
| 11:08 | <webben> | hmm ... that's true |
| 11:08 | <webben> | well, one can't really extract data if not all required fields are present |
| 11:09 | <annevk> | that doesn't negate my argument |
| 11:10 | <webben> | you mean the spec needs to say whether to display the content or display an error? |
| 11:10 | <webben> | one could define a sane default for microformat treatment |
| 11:10 | <webben> | or maybe for unrecognized microformats |
| 11:11 | <webben> | and include erroneous ones in that treatment |
| 11:11 | <webben> | that would reduce the burden on spec creators |
| 11:12 | <annevk> | errors are almost the wrong solution (except in script) |
| 11:12 | <annevk> | read the HTML5 spec for an idea of what it could say |
| 11:17 | <webben> | well, should WHATWG require such definitions for wiki inclusion? |
| 11:17 | <annevk> | the wiki stuff is just an experiment at this point |
| 11:18 | <annevk> | HTML5 itself doesn't even define what happens with competing class values |
| 12:12 | <annevk> | apparently we're old school: http://natalian.org/archives/2007/03/23/invasion-of-the-invited-experts/ |
| 12:14 | <Lachy> | heh |
| 12:15 | <annevk> | for a bunch of students who weren't around when HTML4 evolved that's quite funny |
| 12:16 | <Lachy> | I started getting into the web around the time HTML4 came out, so I'm kind of old school, but not really old |
| 17:14 | annevk2 | wonders how error handling works for <img> with APNG... |
| 17:16 | <annevk> | as in, what would it do for the error event and how would it effect .complete |
| 17:16 | <Dashiva> | For UAs that don't support it? |
| 17:17 | <annevk> | the APNG spec itself is pretty vague about the subject: http://wiki.mozilla.org/APNG_Specification#Error_Handling |
| 17:17 | <annevk> | Dashiva, that's prolly clear |
| 17:17 | <annevk> | but not really relevant as I'd expect all UAs to adopt this |
| 17:18 | <Dashiva> | APNG looks like a regular PNG with lots of trash data to non-supporting ones, as I understand it |
| 17:19 | <Dashiva> | So you're thinking it errors during the animation, and how the UA should handle that? |
| 17:19 | <annevk> | yes |
| 17:20 | <Dashiva> | As I see it, the apng spec defines internal error handling: display the default image if animation fails. Displaying the default image is then displaying the APNG according to spec, and not an error as far as the document is concerned |
| 17:33 | <Dashiva> | Hm, nobody replied to the call for a versioning doctype on public-html. Remarkable restraint :) |
| 17:35 | <gsnedders> | Dashiva: there are issues with what he says anyway… he talks about a SGML dialect of HTML5, and seeming we're not writing a delta spec… |
| 17:57 | <annevk> | versioning is silly on the web |
| 17:59 | <annevk> | as such, i don't want to get into silly versioning debates every other week |
| 17:59 | annevk | wonders whether the guy who posted actually knows why doctypes are useful himself - as they're not |
| 17:59 | <Lachy> | oh gosh, the abbr vs. acronym debate has started on www-html now too! |
| 18:00 | annevk | isn't subscribed to www-html anymore |
| 18:01 | <Lachy> | it's not too high volume, sometimes it's entertaining to see what the XHTML2 WG are up to |
| 18:01 | <annevk> | oh, I do read it |
| 18:01 | <annevk> | well, the threads with interesting titles |
| 18:02 | <annevk> | XHTML2 is better followed on w3c-html-wg (member only) though and soonish on public-xhtml2 I suppose |
| 18:02 | <Lachy> | ah, well I'll have to subscribe to that one when I get access |
| 18:03 | <annevk> | you can't, but you can download the mboxes or read it through the online interface |
| 18:03 | <Lachy> | mboxes? |
| 18:04 | <annevk> | http://lists.w3.org/Archives/Public/public-html/mboxes/ for instance |
| 18:04 | <Lachy> | oh, I see. that's member only too |
| 18:04 | <annevk> | interesting |
| 18:05 | <annevk> | the URI architecture of the W3C site is confusing |
| 18:05 | <annevk> | it's cool in the sense that they actually keep them all working, but still... |
| 18:06 | <Lachy> | yeah, that's cool, though some of the really old ones are dead |
| 18:07 | <annevk> | gsnedders, http://php-html5lib.dashslot.net/trac/browser/trunk/src requires silly access to view the source code... |
| 18:07 | <annevk> | gsnedders, "FILE_VIEW privileges are required to perform this operation" |
| 18:07 | <annevk> | (the files in that directory, I mean) |
| 18:08 | <gsnedders> | annevk: work now? |
| 18:09 | <annevk> | gsnedders, yeah, cool |
| 18:16 | <Dashiva> | Hixie is a rather cunning fellow |
| 18:17 | <Dashiva> | Shooting my poor little green guys by blending into the darkness |
| 18:17 | <met_> | http://glazman.org/weblog/dotclear/index.php?2007/03/24/3375-html-wg-fun |
| 18:18 | <annevk> | help |
| 18:19 | <annevk> | oh well :) |
| 18:19 | <Dashiva> | I don't get which part of it is the fun |
| 18:20 | <Lachy> | Dashiva, I downloaded that game earlier to try it out. He told me about it once before, but never actually tried it |
| 18:20 | <Lachy> | I'm still trying to learn the rules |
| 18:21 | <Dashiva> | I've got the rules down, I'm working on how to play |
| 18:21 | <Dashiva> | In my first game, I focused too much on surviving, but you don't get any points for that... |
| 18:30 | annevk | wonders why <audio> doesn't request Ogg Vorbis to be supported |
| 18:33 | <Lachy> | Dashiva, did you play against the computer first, or against real people? |
| 18:33 | <Lachy> | annevk, Vorbis is already a SHOULD requirement for video, there's no need to state it again for audio |
| 18:34 | annevk | doesn't think that's obvious |
| 18:40 | <Dashiva> | Lachy, annevk: Hixie said he was taking up the shared media interface apple's suggestion had. Could Vorbis be associated with that one, maybe? |
| 18:40 | <annevk> | he already did |
| 18:40 | <annevk> | and yes, I suppose... |
| 18:42 | <Dashiva> | Lachy: I did the tutorial, then a game with the guy who keeps putting up "play this if you're a newbie" challenges |
| 18:43 | <Lachy> | I only played the first level against the computer |
| 18:43 | <Lachy> | are you sure it wasn't Hixie you played against? He said he was looking for newbies |
| 18:45 | <Dashiva> | Yeah, it's Wolff's Flying Tigers doing it |
| 20:52 | annevk | sort of agrees with <html version=5> for validation purposes |
| 20:52 | <annevk> | otherwise it seems quite pointless |
| 20:53 | <annevk> | but even validation evolves... |
| 20:56 | <othermaciej> | when HTML6 comes out, even if it's 100% compatible, it won't be the case that valid HTML6 is valid HTML5 if it adds anything at all |
| 20:56 | <othermaciej> | so I guess I agree there |
| 20:58 | <Dashiva> | The main use I see for versioning is archaeology, if someone decides they want to parse an archaic HTML 3.2 document 50 years from now |
| 20:59 | <Dashiva> | For practical use, I don't see any browsers keeping parsers for older versions around |
| 21:01 | <othermaciej> | browsers don't currently have parsers for older versions |
| 21:18 | <hsivonen> | aargh. versioning again and conformance checking as an excuse |
| 21:18 | <hsivonen> | I guess I should say something after a night's rest |
| 21:19 | <othermaciej> | sorry to feed the flames, I just don't actually get entirely why not versioning is good |
| 21:19 | <othermaciej> | to be fair, other people also raised profiling as an excuse |
| 21:20 | <hsivonen> | othermaciej: if HTML6 is so badly designed that *it* needs to be distinguished from HTML5, then HTML6 should have a version flag. HTML5 shouldn't pre-emptively |
| 21:21 | <hsivonen> | and when HTML6 is out, authors should check new documents against it |
| 21:21 | <othermaciej> | hsivonen: I'm not sure it would be bad design - if any new elements or attributes are added, or the content model of any element is made looser, then you can't check an HTML6 document against an HTML5 checker |
| 21:21 | <hsivonen> | so if someone wants to deliberately check against HTML5 once HTML6 is current, it is reasonable to make them jump though a pop-up menu hoop |
| 21:22 | <othermaciej> | if it also deprecates HTML5 elements or attributes then vice versa would apply |
| 21:22 | <hsivonen> | othermaciej: well, the checkers would have to be updated to be HTML6 checkers once HTML6 is out |
| 21:22 | <gsnedders> | how many people here validate against HTML 3.2? |
| 21:22 | <othermaciej> | can we promise that all valid HTML 5 will remain valid HTML n for all future values of n? |
| 21:23 | <jkj2> | Hi, specifying version is especially important for HTML/XHTML editing tools, not for validation |
| 21:23 | <hsivonen> | if there's a good reason to deprecate something in HTML6, surely the burden of choosing something from an override pop-up should be on those who insist on using the deprecated stuff? |
| 21:23 | <gsnedders> | I think we mark something as a different version when there is need, when it isn't backwards compatible. HTML5 is backwards compatible, so there is no issue |
| 21:23 | <othermaciej> | gsnedders: HTML 4 is itself 10 years old |
| 21:23 | <gsnedders> | othermaciej: I'm well aware |
| 21:24 | <othermaciej> | I don't think versioning is very important, just not sure how people expect this to work with validation |
| 21:24 | <hsivonen> | jkj2: assuming that you want to artificially limit your authoring tool to a subset of what the authoring tool can support |
| 21:24 | <othermaciej> | "choose from a pop-up" or "link to a different validator url" seems reasonable |
| 21:24 | <gsnedders> | I think it's not enough just for validation |
| 21:24 | <othermaciej> | I can't believe it's 10 years old |
| 21:25 | <gsnedders> | it's a problem for the validator, to allow validating against an obsolete spec, how you add a UI |
| 21:25 | <othermaciej> | no new HTML standard for a decade |
| 21:25 | <gsnedders> | 10 years seems so long for me… but I'm only 14 years old :P |
| 21:25 | <hsivonen> | jkj2: as far as the editor use case goes, the discussion reduces to the RELAX NG schema PI discussion |
| 21:26 | <hsivonen> | I think (X)HTML5 should not limit what PI you put on top to give guidance to your editor |
| 21:27 | <gsnedders> | why does it matter that much for the editor anyway? |
| 21:27 | <gsnedders> | how is the editor different from any other UA? |
| 21:27 | <jkj2> | hsivonen: if you are using some variant/version of HTML -- for example subset known to work on mobile devices or in your company CMS -- you want your editor to not to generate "unsupported" markup |
| 21:27 | <hsivonen> | gsnedders: suppose you have a CMS that bans you from including forms and you want to configure your editor to remove form features from the auto-complete options |
| 21:28 | <hsivonen> | jkj2: right. but that's the PI discussion. and I think the (X)HTML5 spec should neither forbid nor require such a PI |
| 21:29 | <hsivonen> | jkj2: BTW, I think the CMS case is legitimate but mobile profiles are a no-no in the WHATWG philosophy |
| 21:31 | <jkj2> | hsivonen: PI is not solution, because it links to particular schema. Schema selection should be possible to do in indirect way. Namespace + @version is good enough. NVDL can already assign schema based on namespace, and it is likely it will be extended to support namespace + attribute value dispatching. |
| 21:32 | <hsivonen> | jkj2: would you allow user-defined values in the version attribute, then? |
| 21:32 | <hsivonen> | version='foobar-cms-subset' |
| 21:32 | <jkj2> | hsivonen: I suppose that WHATWG and W3C philosophies will be merged somehow (if this is even possible) in HTML-WG |
| 21:32 | <hsivonen> | a priori prescribed modules and version subsets don't work |
| 21:32 | annevk | would be entirely fine with having no versioning whatsoever |
| 21:33 | <hsivonen> | if someone wants to subset XHTML5 in a non-prescribed way, they will |
| 21:33 | <jkj2> | sure, something like http://www.docbook.org/tdg5/en/html/ch05.html#s-notdocbook |
| 21:33 | annevk | was previously convinced validation was a usecase (when CSS2 versus CSS2.1 was debated iirc) |
| 21:33 | <hsivonen> | enumerating permitted subsets normatively in advance is pointless |
| 21:34 | <annevk> | I'm not sure what the use of normative profiles is anyway |
| 21:34 | <hsivonen> | precedent: XHTML Mobile Profile does not follow the Modularization module boundaries but does its own thing |
| 21:34 | <jkj2> | I'm not enumarating anything. There should be just same basic syntax for content of version attribute |
| 21:34 | <jkj2> | s/same/some/ |
| 21:35 | <hsivonen> | jkj2: so this version attribute vs. a PI between you and your editor is about whan NVDL can dispatch on? |
| 21:35 | annevk | is convinced that we don't need to worry about versioning until HTML6 and that even then it's unlikely to be an issue |
| 21:36 | <annevk> | (as it would just point out a problem with HTML5 if there was a usecase) |
| 21:36 | <jkj2> | annevk: you are forgetting about XHTML serialization, aren't you? |
| 21:36 | <annevk> | no |
| 21:36 | <annevk> | that's handled by the namespace |
| 21:37 | <jkj2> | You expect that XHTML5 will have different namespace then XHTML 1? |
| 21:37 | <annevk> | no |
| 21:37 | <annevk> | XHTML1 still requires some silly DOCTYPE |
| 21:37 | <annevk> | so if you really want to distinguish that should be possible |
| 21:37 | <jkj2> | So, how you will recognize XHTML 1 from XHTML 5? |
| 21:37 | <hsivonen> | jkj2: a browser doesn't need to. |
| 21:37 | <annevk> | is this about browsers? |
| 21:38 | <jkj2> | I'm not talking about browser, browser doesn't take care. |
| 21:38 | annevk | thought we already agreed that versioning is only relevant for conformance checkers (if it's relevant) |
| 21:38 | <hsivonen> | jkj2: an online conformance checker in the common case should be able to assume XHTML5 (unless the user manually overrides), because an online checker is an authoring aid and new authoring should use XHTML5 once it is out |
| 21:38 | <jkj2> | annevk: and content creation tools |
| 21:39 | <annevk> | content creation doesn't need to care about versions |
| 21:39 | <hsivonen> | jkj2: with content creation tools, you'd use a tool-specific PI if the tool wants to see one |
| 21:39 | <annevk> | it should just create content that fits the target audience |
| 21:39 | <annevk> | anyway, got to go |
| 21:39 | <jkj2> | hsivonen: so if I will use three different tools in my toolchain I will use 3 different PIs? Cool |
| 21:40 | <jkj2> | hsivonen: Moreover PIs doesn't survive SOAP transport |
| 21:41 | <hsivonen> | jkj2: I'd be willing to consider an authoring toolchain that includes SOAP transport badly astronauted |
| 21:42 | <hsivonen> | jkj2: and assuming a single PI or a single attribute without a priori enumerated subset names, your three tools will have to know about your particular subset name |
| 21:43 | <jkj2> | hsivonen: I'm also not big fan of WS stuff, but you would be surprised what you can see at various customer sites :-( |
| 21:44 | <jkj2> | hsivonen: sure, good tool has means of specifying which schema should be used depending on combination od namespace + root element name + attribute value + ... |
| 21:45 | <hsivonen> | jkj2: I am less opposed to an optional attribute with user-specified content for the benefit of the users tool chain. I am more opposed to <html version='5'> as a normative requirement or as a solution to a perceived non-problem. |
| 21:46 | <hsivonen> | s/users/user's/ |
| 21:46 | <Dashiva> | Putting the versioning in the document rather than the editor seems backwards to me. The versioning can only work if the editor supports the given version, which means the editor should be the place to choose a version |
| 21:46 | <hsivonen> | Dashiva: I also consider polluting the document instance with this stuff ugly |
| 21:47 | <Dashiva> | Hello dreamweaver |
| 21:50 | <jkj2> | Ugly, backwards -- ok, but many XML based languages specify its version and it works well |
| 21:52 | <hsivonen> | works well for what? for schema binding in editors? |
| 21:53 | <jkj2> | also, but mainly for language evolution (e.g. XSLT 1.0 & 2.0, XSL-FO 1.0 & 1.1) |
| 21:54 | <hsivonen> | I am not familiar enough with the version differences on those cases |
| 21:55 | <hsivonen> | are XSLT transformers expected to change their treatment of particularly named elements depending on what version was declared on the root element? |
| 21:56 | <hsivonen> | that is, will an XSLT 1.0 transformation execute wrongly on a transformer that implements 2.0 semantics? |
| 21:56 | <hasather> | hsivonen: I think so, yes, but I can't remember exactly |
| 21:56 | <hsivonen> | (I think I've see warnings to that effect in SAXON 8, but I don't remember the details) |
| 21:57 | <hsivonen> | hasather: strikes me as bad design of the new version then (on the face of it without knowing what was changed) |
| 21:57 | <jkj2> | XSLT 2.0 implementation will process XSLT 1.0 stylesheet in backward compatibility mode, which is 99,999999999% same as XSLT 1.0 processing |
| 21:57 | <hsivonen> | jkj2: why couldn't the last corner cases be made compatible and versioning trashed? |
| 21:58 | <jkj2> | complex problems doesn't always have simple solutions |
| 22:00 | <hsivonen> | well, if the quirks mode has taught us anything about this issue with HTML, the conclusion should not be that more versioned modes are the solution. the conclusion should be that future versions of HTML and CSS must not make changes that are incompatible with real legacy content |
| 22:01 | <jkj2> | In HTML this is not as big problem, because HTML it is expected that unknown elements are ignored. And in case of semantics change, namespace should be changed. |
| 22:02 | <hsivonen> | or, rather, the element names, because boiling the whole language is bad |
| 22:02 | <hasather> | hsivonen: yea, that would've been bad design, but I might have been wrong about that |
| 22:03 | <met_> | XSLT history is much cleaner than HTML big chaos, not sure if HTML can go near it anyway |
| 22:03 | <jkj2> | met: you can't change history, of course, but you can prepare for future ;-) |
| 22:03 | <hsivonen> | oh, and SAXON 8 is evidence that versioning does not work with XSLT |
| 22:04 | <jkj2> | hsivonen: could you explain? |
| 22:04 | <Dashiva> | Has there been any discussion about adding crypto stuff to the spec, specifically some kind of common hash algorithm? |
| 22:04 | <hsivonen> | since SAXON 8 does not support both XSLT 1.0 and 2.0 but just says that it uses the 2.0 semantics and its your problem if you rely on 1.0 semantics |
| 22:04 | <hsivonen> | jkj2: so basically, XSLT versioning goes hand in hand with SAXON versioning |
| 22:05 | <hsivonen> | jkj2: if you want XSLT 1.0, you should use SAXON 6. if you want XSLT 2.0, you should use SAXON 8 |
| 22:05 | <hsivonen> | but SAXON 8 appers not to do semantic switching on the version |
| 22:06 | <met_> | hsivonen, don't you mean XSLT 1.1 ? |
| 22:06 | <hsivonen> | met_: well, something like that. I looked at this stuff in November |
| 22:07 | <met_> | hsivonen, Saxon > 6 dropped XSLT 1.1, not XSLT 1.0 |
| 22:07 | <hsivonen> | oh |
| 22:07 | <met_> | XSLT was not finished draft, part of history wich was dropped |
| 22:07 | <hsivonen> | well, my point stands that XSLT versioning is not a success of switching on a version attribute |
| 22:07 | <jkj2> | You use Saxon8 also on XSLT 1.0 stylesheets. You can even mix and match stylesheets modules in XSLT 1.0 and 2.0 together. |
| 22:08 | <met_> | met_ correction: XSLT *1.1* was draft |
| 22:09 | <jkj2> | hsivonen: you should compare with XSL-FO rather. It's usage is much more closer to HTML. (Some even think that it could replace HTML ;-D) |
| 22:09 | met_ | do not think this way 8-) |
| 22:10 | <hsivonen> | well, either XSLT doesn't really need versioning, because the versions are compatible. or the versioning story is broken because SAXON tells me it doesn't guarantee that old semantics work. either way, not a versioning success. |
| 22:10 | <hasather> | hsivonen: the versions aren't compatible |
| 22:10 | <hsivonen> | jkj2: XSL-FO is also a no-no in WHATWG philosophy :-) |
| 22:11 | <hasather> | hsivonen: but you can use backwards compatible mode |
| 22:11 | <hasather> | btw, XPath may be incompatible even in backwards compatible mode, see http://www.w3.org/TR/xpath20/#id-incompat-in-true-mode |
| 22:12 | <hasather> | s/XPath/XPath 2.0/ |
| 22:12 | <jkj2> | Yes, that's why I have said 99,999999999 instead od 100 % compatible |
| 22:13 | <hasather> | jkj2: I see, I wondered what you meant :) |
| 22:13 | <hsivonen> | cute. I try to avoid dealing with XSLT too deeply. I switched to SAXON 8 underneath Jing, saw warnings and switched back to SAXON 6 and decided not no use whatever performance goodness SAXON may have obtained in between |
| 22:15 | <hsivonen> | s/not no/not to/ |
| 22:15 | <jkj2> | hsivonen: if you can live without key() function, you can try good old XT from Clark -- it is still fastest for many operations |
| 22:15 | <hsivonen> | jkj2: does it support TrAX? |
| 22:16 | <hsivonen> | there has to be a reason why Clark himself did not support XT in Jing |
| 22:16 | <hsivonen> | only SAXON 6 and Xalan |
| 22:17 | <jkj2> | hsivonen: good question -- I don't remember, but it was probably released before TrAX was standardized |
| 22:20 | <othermaciej> | if the W3C believes in the Semantic Web so much, why do they keep trying to replace HTML with purely presentation languages like SVG and XSL-FO? |
| 22:22 | <jkj2> | XSL-FO is not about Web, it's about print composition. (OK, yes there are features like collapsible menus meant for interactive display, but they were never implemented.) |
| 22:25 | jkj2 | have to go |
| 22:30 | <Hixie> | othermaciej: same reason they're doing HTML5. The W3C leadership is more influenced by the desires of member companies than by their ideals. |
| 22:31 | <Hixie> | (not necessarily a bad thing) |
| 22:31 | <othermaciej> | Hixie: but a lot of advocates of SVG or XSL-FO are also proponents of things like RDF |
| 22:33 | <hsivonen> | othermaciej: separation of semantics and presentation: semantics in RDF and presentiation in XSL-FO :-) |
| 22:34 | <othermaciej> | that would be so awesome that I can't even think of anything to say |
| 22:40 | <Dashiva> | Where's the behavior? XSLT? |
| 22:52 | <tantek> | othermaciej, it's a natural tendency to create as many complex layers as possible so that each member company that has a particular expertise can build and sell a horribly complex solution that is too hard/obtuse for individual developers to build on their own. |
| 22:53 | <tantek> | in otherwords, inverses of both the explicit (and implicit) principles behind URL, HTTP, HTML. |
| 22:54 | <Dashiva> | OT: Oh man, 6-player lggwg. This is going to take weeks. |
| 23:05 | <othermaciej> | Dashiva: the behavior would be in SMIL of course |
| 23:05 | <Dashiva> | Oh, right. Silly me. |
| 23:06 | <othermaciej> | so the full stack would be to take your RDF and apply an XSLT transform to get XSL-FO + SMIL |
| 23:06 | <Dashiva> | Anyone know if there would be licencing issues in including, say, a SHA-1 function in the spec? |
| 23:08 | <othermaciej> | as in patent licensing? |
| 23:08 | <othermaciej> | I don't believe SHA-1 is patented |
| 23:08 | <Dashiva> | Any kind that would mean trouble for inclusion. |
| 23:09 | <Dashiva> | When doing web applications, having a built-in reliable hash function could be useful for some basic security without having to turn to https |
| 23:13 | <Philip`> | Would performance be the only benefit of it being built in, compared to using an implementation in JavaScript? |
| 23:15 | <Dashiva> | I was actually thinking convenience as the main benefit. And less to download for users, for that matter |
| 23:30 | <Hixie> | SHA-1 isn't reliable is it? I thought it had been cracked. |
| 23:31 | <Dashiva> | It's cracked in the academic sense |
| 23:33 | <othermaciej> | is there a one-way hash that is well tested and doesn't have even theoretical flaws? |
| 23:34 | <Philip`> | It's weak enough for people to not recommend its use in the future - http://csrc.nist.gov/hash_standards_comments.pdf says NIST planned to phase out SHA-1 (and similar strength algorithms) by 2010 |
| 23:42 | <Philip`> | http://www.csrc.nist.gov/pki/HashWorkshop/ is still looking for a better hash function (to be standardised around 2012), but I assume they're still not expecting one with no theoretical flaws - the only known flawless algorithms are only usable in theory |
| 23:45 | <othermaciej> | why only usable in theory? |
| 23:45 | <othermaciej> | are they too slow to compute? |
| 23:48 | <Philip`> | They're ideas like having a man in a box with a lookup table of (message, hash) pairs, and some dice so he can generate hashes for any message you give him that he hasn't seen before |
| 23:48 | <hasather> | hehe |
| 23:49 | <Philip`> | (as an implementation of http://en.wikipedia.org/wiki/Random_oracle) |
| 23:51 | <othermaciej> | Philip`: so basically it depends on having a huge, constantly updated shared secret |
| 23:51 | <Hixie> | that's just a centralised dictionary service |
| 23:52 | <othermaciej> | Philip`: I was thinking of just strong in the collision resistance sense |
| 23:52 | <othermaciej> | Philip`: not the random oracle sense |
| 23:53 | <othermaciej> | SHA256 is believed to have good collision resistance still I think |
| 23:53 | <nickshanks> | hixie: do you know what percentage of IMG elements have a longdesc attribute ? |
| 23:54 | <nickshanks> | random oracle == http://en.wikipedia.org/wiki/Special:Random :-) |
| 23:55 | <nickshanks> | "The Outerbridge Crossing is a cantilever bridge over the Arthur Kill connecting Perth Amboy, New Jersey with Staten Island, New York." see, i learnt something new ;-) |