| 00:01 | <jcranmer> | is bigendian 0xabcd or 0xcdab? |
| 00:01 | <jcranmer> | I can honestly never remember |
| 00:01 | <AryehGregor> | It's the one that major architectures aren't, that's the relevant bit. |
| 00:01 | <AryehGregor> | But as it happens, it's also the one that makes sense. I.e., 0xabcd is stored with first byte 0xab and second byte 0xcd. |
| 00:02 | <jcranmer> | it's the one that makes sense to people reading it |
| 00:02 | <jcranmer> | however it makes pointer conversion a little harrier |
| 00:02 | <AryehGregor> | How so? |
| 00:02 | <jcranmer> | since converting between byte and int in little endian does not change the one you're reading |
| 00:03 | <AryehGregor> | Well, if the upper bytes happen to all be zeros, I guess. |
| 00:03 | <jcranmer> | well |
| 00:03 | <AryehGregor> | But that seems like an edge case. |
| 00:03 | <jcranmer> | if I have a value stored as |12|34|56|78| |
| 00:03 | <jcranmer> | the pointer is to the first byte |
| 00:03 | <jcranmer> | if I want to look at it as a short |
| 00:03 | <jcranmer> | I have to add 2 to the pointer |
| 00:04 | <AryehGregor> | You mean if you want to cast it to a short, truncating it. |
| 00:04 | <jcranmer> | not necessarily truncating it |
| 00:05 | <AryehGregor> | On the other hand, if you want to (for instance) convert an array of words to a hexadecimal string, you can't just cast to a string of chars and do it byte by byte (supposing you want to print it big-endian, which would be normal). |
| 00:06 | <AryehGregor> | That's actually come up for me in the last few days. |
| 00:06 | <AryehGregor> | (Yay for OpenCL not having most C standard library functions) |
| 00:08 | <jcranmer> | how often do you really need to that, though? |
| 00:08 | <AryehGregor> | But anyway, big-endian is going to be less efficient on all the common web-browsing machines out there, unless I'm missing something. |
| 00:08 | <AryehGregor> | Regardless of how useful one is relative to the other. |
| 00:09 | <AryehGregor> | So little-endian would make a lot more sense as a default. |
| 00:09 | <jcranmer> | printf("%x\n", val); prints out a hex string really well |
| 00:09 | <AryehGregor> | Except printf() and sprintf() don't exist in OpenCL, which is what I've been doing the last few days. :) |
| 00:09 | <AryehGregor> | Well, printf() exists if you run it on the CPU, but that kind of blows your performance out the window. |
| 00:14 | <AryehGregor> | I guess I could have just copied the raw bytes to an output array and then formatted them on the host side. |
| 00:14 | <AryehGregor> | Oh well, maybe next time. |
| 00:20 | <Hixie> | AryehGregor: big-endian is network byte order, so it makes sense to be the default |
| 00:20 | <AryehGregor> | Hixie, network byte order in what protocol? |
| 00:20 | <Hixie> | pretty much everything, but tcp, ip, etc |
| 00:21 | <Hixie> | let me rephrase that |
| 00:21 | <AryehGregor> | Okay, but what relevance does that have to typed arrays? |
| 00:21 | <Hixie> | "tcp, ip, and pretty much everything" |
| 00:21 | <AryehGregor> | That's not likely to contain protocol-level data. |
| 00:21 | <AryehGregor> | It's likely to contain GPU data, and my NVIDIA GPU appears to be little-endian (at least for the purposes of OpenCL). |
| 00:21 | <Hixie> | well presumably the data you're manipulating is coming from the network or going to the network... i'm assuming the api doesn't expose the platform's byte order |
| 00:21 | <Hixie> | since that would be crazy |
| 00:22 | <Hixie> | in terms of getting interoperability |
| 00:22 | <AryehGregor> | The question is being able to implement the array efficiently on native hardware. If you have a typed array of length 1024, with one uint32 view and one uint8 view, then if the endianness of the views matches that of the host architecture, you can implement that at no performance cost. |
| 00:23 | <AryehGregor> | But if they don't match, then you'd presumably have to do extra conversions on access. |
| 00:23 | <AryehGregor> | I don't know if that's a big deal in practice, admittedly. |
| 00:24 | <Hixie> | well it's the web, you want the same code to work the same on all architectures |
| 00:25 | <Hixie> | so either way, someone's gonna be screwed |
| 00:25 | <Hixie> | seems like having the api default to the network byte order makes sense |
| 00:26 | <AryehGregor> | If having the byte order match the architecture makes sense for efficiency, then you should make it little-endian to match virtually every web-enabled device out there. |
| 00:26 | <Philip`> | The Portable NaCl approach to portability seems to be to declare that all the platforms anyone cares about are little-endian so that's all it'll support |
| 00:26 | <AryehGregor> | The default may as well be efficient. |
| 00:26 | <AryehGregor> | That sounds sensible. |
| 00:26 | <Philip`> | At least the typed arrays don't appear to stop you from supporting wrong-endian platforms if you care enough |
| 00:27 | <Philip`> | but it's not exactly great :-( |
| 00:30 | <AryehGregor> | Is that because LLVM doesn't support big-endian, or because the authors of PNaCl didn't want to bother making their code endian-independent? |
| 00:32 | <AryehGregor> | Hixie, bzbarsky said in a November 15 whatwg e-mail that typed array views depends on the endianness of your hardware, but it looks like either they fixed it since then or he was wrong or I'm misreading the spec. |
| 00:32 | <AryehGregor> | Or possibly more than one of those. |
| 00:33 | <Hixie> | if it varies based on the architecture then that's a disaster waiting to happen |
| 00:33 | <AryehGregor> | That's more or less what I said. |
| 00:34 | <AryehGregor> | Have I mentioned that LLVM has the coolest logo of any open-source project I know of? |
| 00:34 | <Philip`> | The LLVM bitcode format isn't portable across architectures (by design), so it looks like PNaCl basically defines its own architecture (32-bit, 1GB address space, little-endian) which everyone compiles to |
| 00:35 | AryehGregor | notes that Firefox freezes for several seconds when he visits <http://upload.wikimedia.org/wikipedia/en/4/4c/LLVM_Logo.svg>;, while Chrome renders it instantly |
| 00:35 | <Philip`> | and assumes that that's sufficiently compatible with the user's physical architecure that it's able to compile down to machine code |
| 00:35 | <AryehGregor> | Interesting. |
| 00:36 | <Rik`> | AryehGregor: scrolling is bad in both |
| 00:36 | <Philip`> | At least they've recognised that x86+x86_64+ARM machine code is not sufficiently portable for the web |
| 00:38 | <Philip`> | Maybe they'll eventually develop a Really Portable Native Client system which involves compiling your code into JavaScript so it'll work anywhere and will even run in legacy browsers |
| 00:52 | <brendaneich> | Hixie: typed arrays expose byte order |
| 00:52 | <Hixie> | of the platform? |
| 00:52 | <Hixie> | so the same JS will act differently on different computers? |
| 01:09 | <brendaneich> | Hixie: it's not good and we're not going to standardize typed arrays in Ecma |
| 01:10 | <brendaneich> | Hixie: we hope to supersede them with http://wiki.ecmascript.org/doku.php?id=strawman:binary_data |
| 01:10 | <brendaneich> | which does not expose byte order via aliasing "views" of a single buffer |
| 01:10 | <Hixie> | ah, that seems much better |
| 01:11 | <brendaneich> | Hixie: by the time we got in the loop, the WebGL people had pushed to their 1.0, or near it -- it was out of the lab |
| 01:11 | <brendaneich> | they really wanted arrays of structs, structs with member arrays, etc., using packed machine representations |
| 01:11 | <Hixie> | yeah they seem to be moving kinda fast and in without much public input |
| 01:11 | <Hixie> | s/in// |
| 01:11 | <brendaneich> | but they couldn't figure out how to do that, so they fell back on fortran .common ! |
| 01:20 | <Philip`> | It's been over 3 years since the first public release of a web GL implementation, so it doesn't seem like they've been rushing through it extremely fast |
| 01:22 | <l4rk> | brendaneich: i just came into say hi, and that i'm a big fan |
| 01:22 | <tmzt> | anybody know of a non-minified example of a camera in webgl? |
| 01:30 | <bga_> | brendaneich what about my question? |
| 01:45 | <tmzt> | apropos, there is a 3d remake of Gulliver's Travels coming out |
| 01:52 | <bga_> | heh http://wiki.ecmascript.org/doku.php?id=strawman:private_names |
| 06:23 | <MikeSmith> | hsivonen: you have a typo in a method name in the htmlparser source |
| 06:23 | <MikeSmith> | http://hg.mozilla.org/projects/htmlparser/file/c1eb6d6f5c49/src/nu/validator/htmlparser/sax/HtmlParser.java#l538 |
| 06:24 | <MikeSmith> | setTransitionHander should be setTransitionHandler |
| 07:00 | <nielsle> | Are the videos from webgl camp available in a non-flash format? |
| 07:20 | <hsivonen> | MikeSmith: thanks |
| 07:49 | <roc> | the perils of super-smart autocomplete |
| 10:24 | <MikeSmith> | hsivonen: I ran into another problem with the parser |
| 10:25 | <MikeSmith> | if in my code I do: |
| 10:25 | <MikeSmith> | HtmlParser parser = new HtmlParser(); |
| 10:25 | <MikeSmith> | and then Locator locator = parser.getDocumentLocator(); |
| 10:26 | <MikeSmith> | … I get a null pointer exception when I try to compile it |
| 10:27 | <MikeSmith> | the reason being that that method just does "return driver.getDocumentLocator()" |
| 10:29 | <MikeSmith> | but driver is always going to be null if you call getDocumentLocator() just after instantiating a parser |
| 10:30 | <MikeSmith> | but if I take you private |
| 10:30 | <MikeSmith> | if I take the private lazyInit() method there and make it public in the source |
| 10:31 | <MikeSmith> | which is what seems to be the code that actually initializes the driver |
| 10:32 | <MikeSmith> | and I call that from my code before calling parser.getDocumentLocator() |
| 10:32 | <MikeSmith> | then it seems to work as expected |
| 10:32 | <MikeSmith> | at least, I don't get the null pointer exception |
| 12:26 | <MrWax> | how can I find out since what time a certain API is included in the HTML5 standard? |
| 12:26 | <MrWax> | For example, I would like to know this about web workers |
| 12:27 | <Dashiva> | You could check the svn history, I guess |
| 12:29 | <MrWax> | where can i? |
| 12:29 | <MrWax> | where can i check* |
| 12:30 | <MikeSmith> | MrWax: there's a mercurial mirror of the svn repo here: |
| 12:30 | <MikeSmith> | https://bitbucket.org/validator/html-spec |
| 12:33 | <MikeSmith> | but I don't think it has any useful change-history search feature |
| 12:33 | <MikeSmith> | so you probably want to check out the svn sources |
| 12:33 | <MikeSmith> | svn checkout http://svn.whatwg.org/webapps/ |
| 12:34 | <MikeSmith> | then do "svn log" in your workspace |
| 12:34 | <MikeSmith> | oh but you want to know about workers |
| 12:35 | <MikeSmith> | workers started out as separate spec |
| 12:35 | <MikeSmith> | iirc |
| 12:35 | <MikeSmith> | http://svn.whatwg.org/webworkers/ |
| 12:37 | <MikeSmith> | r1 | ianh | 2008-07-09 19:52:54 +0900 (Wed, 09 Jul 2008) | 1 line |
| 12:37 | <MikeSmith> | [] (0) Initial checkin (skeleton) |
| 12:38 | <MrWax> | MikeSmith: thanks |
| 12:39 | <MrWax> | MikeSmith: oh, but if it's not part of the htlm5 specification, how come so much people present it as in the html5 spec? |
| 12:39 | <MikeSmith> | the spec normatively references it |
| 12:39 | <MikeSmith> | I think |
| 12:40 | <MikeSmith> | or maybe it doesn't |
| 12:40 | <MrWax> | http://www.whatwg.org/specs/web-workers/current-work/ |
| 12:40 | <MikeSmith> | but anyway people present all kinds of things as being part of html5 |
| 12:41 | <MrWax> | I'm helding a small presentation in some days, and specifically i talk about what HTML5 can do for a web app (such as the CMS I develop some additions for) |
| 12:41 | <MrWax> | and now I'm trying to filter what's most appropriate |
| 12:42 | <MrWax> | I'm trying to give examples etc, but since the short duration of it (20 mins) i decided to just speak through the syntax changes (why and for what important etc) and in the second 10 mins discuss the 5 (HTML5) APIs that I consider as most valueable potential addition to the CMS |
| 12:43 | <MikeSmith> | sounds great |
| 12:43 | <MikeSmith> | 20 minutes is not a lot of time for a presentation |
| 12:43 | <MrWax> | So far, 1 part that is final to present, is Offline Webapps (localStorage, IndexedDB, App Cache) |
| 12:44 | <MrWax> | actually 3 seperate APIs |
| 12:44 | <MikeSmith> | yeah |
| 12:44 | <MrWax> | WebWorkers is the 2nd thats final |
| 12:44 | <MrWax> | and about the other 3 parts im still considering |
| 12:44 | <MrWax> | i think contenteditable right? |
| 12:44 | <MikeSmith> | it doesn't seem like 10 minutes is enough time to discuss 5 apis |
| 12:45 | <MrWax> | i was more thinking to limit the syntax changes to 4-5 minutes and then leave 15 mins for the apis |
| 12:45 | <MikeSmith> | contenteditable would seem relevant |
| 12:46 | <MikeSmith> | though i think the current interoperability of it is not great |
| 12:47 | <MikeSmith> | anyway, I need to step away for a bit |
| 12:47 | <MikeSmith> | talk to you later |
| 12:47 | <MrWax> | MikeSmith: ok later |
| 12:49 | <bga_> | ohlol. i need *rounded corners* in canvas 2d api %) |
| 12:53 | <bga_> | seems CanvasRenderingContext2D.prototype is supported in all modern UA. |
| 12:53 | <bga_> | good |
| 14:01 | <MrWax> | MikeSmith: you're still there? |
| 14:44 | <MikeSmith> | MrWax: here now |
| 15:20 | <MrWax> | MikeSmith: ah ok |
| 15:20 | <MrWax> | still now :p ? |
| 15:47 | <MrWax> | MikeSmith: well anyway, the APIs I like to list that make a positive difference to the CMS are now: Offline Webapps (localStorage, IndexedDB, App Cache), File API, Contenteditable, Drag & Drop |
| 15:47 | <MrWax> | 6 total, I think I'm going to list 10 total and then go into deeper detail on 3 or 5 (considering 10-15 mins is not long) |
| 15:47 | <MikeSmith> | sounds good |
| 15:47 | <MrWax> | you maybe have any idea for another 4 ? |
| 15:48 | <MrWax> | for a modern CMS system improved by HTML5 |
| 15:49 | <MikeSmith> | drag and drop interoperability is also not great yet |
| 15:50 | <variable> | MrWax, just do 5 -> I can't imagine a 15 minute talk explaining 10 APIs |
| 15:51 | <MrWax> | variable: and then just go into deeper detail on those 5? |
| 15:51 | <variable> | MrWax, yes. |
| 15:51 | <MrWax> | ok |
| 15:51 | <variable> | either that or do a top 10 - but don't go really deep on any of them |
| 15:51 | <MikeSmith> | I don't think you have time to go into deep detail on anything in that amount of time |
| 15:52 | <MrWax> | yea thanks i think i might do this |
| 15:52 | <MrWax> | yea 5 is even a lot if you want to go into deep detail |
| 15:52 | <MrWax> | variable: but you think those 5 represent a good potential presentation about what HTML5 APIs can improve in our CMS ? |
| 15:52 | variable | is not usually a fan of very short talks for this reason |
| 15:52 | <MikeSmith> | and localstorage and indexedDB are not strictly for offline apps only |
| 15:53 | <MrWax> | no, but for example a CMS indexedDB could store the page rigths etc in tables and link this to page contents right? |
| 15:53 | <variable> | MrWax, ContentEditable is a key one |
| 15:54 | <MrWax> | i mean, this would improve the CMS remarkeable right? making it offline compatible |
| 15:55 | <variable> | MrWax, well - for offline editing - like google docs type things |
| 15:55 | <MrWax> | variable: how you mean? |
| 15:56 | <MrWax> | and drag & drop i ment, that now for our pages we use a lib extension called jsTree |
| 15:56 | <variable> | MrWax, the offline stuff isn't particularly useful for the display side of a CMS - but it is quite useful for the editing |
| 15:56 | <MrWax> | variable: sorry i might sound dumb, but can you explain a bit? |
| 15:57 | <variable> | MrWax, what are the offline APIs (indexedDB, localStorage, App Cache) useful for in a CMS? |
| 15:58 | <MrWax> | being able to work offline, have data stored in a more structured and efficient way than usually was possible with cookies, and being able to sync the data later |
| 16:03 | <webr3> | MrWax, would be nice to cover http caching in their too, it's v underestimated and underconsidered by most dev's |
| 16:04 | <MrWax> | webr3: you mean App Cache? |
| 16:04 | <MrWax> | where you define which files should be cached |
| 16:05 | <webr3> | in addition to app cache, serving static templates, populating them via content editable then PUTting them back to the server as static documents, it's v nice for cms users and ultimately optimized for the network |
| 16:06 | <webr3> | localStorage for session stuff rather than using HTTP like it's stateful, indexeddb and app cache leveraged for offline usage etc etc |
| 16:08 | <MrWax> | webr3: you mean so you avoid to upload/process anything but the text filled in through CE ? |
| 16:09 | <webr3> | yes, and if you use microdata/rdfa/data-* attributes in your templates you can have them entering the machine data (like product names and prices) right in to the template, then your server side apps just lifts the data right from the user-edited product view page as google rich snippets bot etc does. |
| 16:10 | <webr3> | effectively, CMS's are a thing of the past, you don't really need them any more, you can just edit an HTML document in browser and PUT it back to the server, hell even shopping baskets etc can all be client side in js now - server apps are needed far less than people think |
| 16:10 | <MrWax> | yep |
| 16:11 | <MrWax> | but i think the conversion to this new style of content management won't go so fast i mean, look at how much companies edit their data through traditional CMS systems |
| 16:11 | <webr3> | so perhaps show how to make a blog/cms using HTML5 and no server side app (other than something to serve and save files) |
| 16:11 | <MrWax> | I think this would require to much detail |
| 16:12 | <MrWax> | I also have some other subjects to discuss, like syntax / markup (in the light of parsing by search engines, mobile devices etc) which also should take a me some min utes to explain |
| 16:12 | <webr3> | i don't.. just a static html page on the server, make the title and the article contenteditable, local storage to cache the draft, then ajax to PUT it back |
| 16:12 | <MrWax> | thanks a lot for your input btw |
| 16:12 | <webr3> | np |
| 16:12 | webr3 | said ajax, yuck - meant xhr (& cors...) |
| 16:15 | <MrWax> | I mean, its maybe something to optinally offer, but the essence now is presenting the above |
| 16:15 | <MrWax> | File API pretty much speaks for itself and is not so hard to explain i think |
| 16:16 | <MrWax> | same for content editable and drag/drop |
| 16:16 | <MrWax> | actually, content editable, how do you think people create in the end the same user experience as with popular inline text editors like TinyMCE ? |
| 16:16 | <MrWax> | people=developers |
| 16:17 | <MrWax> | Given content editable offers good new functionality but not a rich text editing app |
| 16:21 | <MikeSmith> | MrWax: I think the File API is not quite so simple |
| 16:21 | <dglazkov> | roc: yt? |
| 16:22 | <MikeSmith> | it's three APIs really |
| 16:23 | <MrWax> | MikeSmith: i highlight FileReader |
| 16:23 | <MikeSmith> | and it is quite a powerful API with some potentially pretty sophisticated applications |
| 16:23 | <MikeSmith> | ok |
| 16:23 | <MrWax> | MikeSmith: you maybe have any other important things of the FileAPI that could bne explained for a CMS? |
| 16:25 | <MikeSmith> | no |
| 16:28 | <MikeSmith> | like variable said, I'm not sure how much of any of this has specific relevance to a CMS |
| 16:29 | <MrWax> | ok |
| 16:29 | <MikeSmith> | which of it |
| 16:30 | <MrWax> | hmm |
| 16:30 | <roc> | dglazkov: email me, I gotta run |
| 16:50 | <MrWax> | MikeSmith: well, the dropping files from the normal file system browser to the CMS is at least 1 |
| 16:51 | <MikeSmith> | ok |
| 16:51 | <MrWax> | and I think it could also be quite logical a CMS executes an operation on a batch of local files i think? i.e. tagging them one by one with canvas |
| 16:51 | <MrWax> | (image files for example) |
| 17:03 | <webr3> | MrWax, you've seen aloha editor ya? |
| 17:04 | <MrWax> | i didn't but im checking it out now |
| 17:04 | <MrWax> | thnaks |
| 17:06 | <MrWax> | webr3: you think Aloha editor could be of any meaning ? apart from mentioning it as example ? |
| 17:08 | <MrWax> | webr3: i mean, could it be seriously considerable for example to write some beta CMS part with aloha as text editor implemented? |
| 17:08 | <MrWax> | like TYPO and Drupal did? |
| 18:28 | <webr3> | MrWax, yes (sorry not really here), aloha can be, and is used in commercial and opensource projects, it's just as viable as tinymce etc, although less feature rich of course, for now |
| 18:34 | <AryehGregor> | brendaneich, where does the current draft of Typed Arrays have endian dependencies? It looks like it contains an endianness flag to the constructor for multibyte views: https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/doc/spec/TypedArray-spec.html#6 |
| 18:47 | <bga_> | typed arrays is good but it do not allows store references to Object and strings |
| 18:47 | <bga_> | native Array kills js perfomance |
| 18:48 | <bga_> | bacause in 99% cases nobody uses holed arrays |
| 18:48 | <bga_> | only solid |
| 19:25 | <brendaneich> | AryehGregor: DataView is not the issue, aliasing Uint8Array and Uint16Array (e.g.) views of a single buffer are |
| 19:25 | <AryehGregor> | Ah. |
| 19:27 | <AryehGregor> | Well, worst case is it's de facto required to be little-endian even though that's not specced anywhere yet, and the three people still using big-endian machines to view the web get a performance hit, assuming anyone is still maintaining browsers for those architectures . . . (I guess a few people still use PowerPC Macs?) |
| 19:27 | <AryehGregor> | Now, can anyone tell me what "[whatwg] Fwd: Session Management" is about? |
| 19:29 | <bga_> | PowerPC is deading |
| 20:00 | <jgraham> | /me notes that TVs and things have web access and it isn't all x86/ARM |
| 20:01 | <AryehGregor> | Well, some ARM is big-endian anyway. |
| 20:02 | <AryehGregor> | But the point is that if you don't specify it, it will wind up being de facto little-endian, because that's what everyone will write for and test on. |
| 20:02 | <AryehGregor> | So browsers on big-endian architectures will have to treat it as little-endian anyway. |
| 20:04 | <jgraham> | That could be true, but the point is that it's not (yet) a non-issue since e.g. MIPS sill exists |
| 20:09 | <bga_> | i guess, automatic convert to big endian is best way |
| 20:10 | <hsivonen> | MikeSmith: clearly, I haven't tested the locator stuff enough :-( |
| 20:10 | <bga_> | but it like XHR always encode data to utf8 :( and you can not send binary data |
| 20:12 | <bga_> | keep in mind, there are processors where bit can be 0, 1, 2 :) |
| 20:14 | <bga_> | ie we can not standartize even 1 bit :) |
| 20:20 | <jgraham> | bga_: Note that in many cases js arrays will be optmised if they are not sparse |
| 20:21 | <bga_> | jgraham it desing fail |
| 20:21 | <MrWax> | webr3: here? |
| 20:22 | <bga_> | invent some super abstract and try to optimize it |
| 20:27 | webr3 | is here |
| 20:27 | webr3 | , but only for 2 minutes |
| 21:05 | <AryehGregor> | The Firefox 4 beta just crashed yet again, and this time it ate the long post I was writing. That's a hanging offense. |
| 21:05 | AryehGregor | switches back to Chrome |
| 21:44 | <dglazkov> | AryehGregor: don't worry, we'll let you down too at some point or another :) |
| 21:57 | <AryehGregor> | Doubtless. :) |
| 22:12 | <hsivonen> | MikeSmith: so should <annotation-xml encoding="text/html"> be valid in both HTML and XHTML (now only encoding="application/xhtml+xml" validates)? |
| 22:31 | <bga_> | lol webkit "bug". ctx.arc(...); ctx.stroke(); in chrome line visualy is thinner than in ff :) |
| 22:37 | <hsivonen> | Does Chrome anti-alias canvas drawing yet? |
| 22:40 | <bga_> | hsivonen http://funkyimg.com/u2/558/025/ff4.png http://funkyimg.com/u2/245/712/ch10.png |
| 22:41 | <bga_> | ff version looks better imho |
| 22:44 | <david_carlisle> | hsivonen: yes (If I understand the question) |
| 22:47 | <david_carlisle> | hsivonen: but of course in the xhtml case it would also need to be well formed |
| 22:56 | <MikeSmith> | hsivonen: what david_carlisle said :) |
| 22:59 | <MikeSmith> | this reminds me, I have the updated MathML2 rnc files in my workspace uncommitted still |
| 23:04 | <MikeSmith> | the ones that are based on the canonical MathML3 RNCs but from that I used david_carlisle script to remove the MathML3 only features and get a proper MathML2 subset |
| 23:05 | <david_carlisle> | MikeSmith: I did those in about 5 minutes, I recently passed something similar yo Meil Soiffer who wanted a diff mml2 to mm3 for updating daisy and he spotted a couple of extra mml3 attributes I should have filtered out |
| 23:05 | <MikeSmith> | oh |
| 23:05 | <david_carlisle> | Neil |
| 23:06 | <MikeSmith> | which attributes? |
| 23:06 | <david_carlisle> | I'll dig out the email... |
| 23:12 | <david_carlisle> | actually it wasn't as bad I'd remembered, but he wanted a more exact diff of exactly which attributes had changed on each element, my conversion script took a cruder approach of just throwing out all the completely new attributes |
| 23:12 | <david_carlisle> | see thread |
| 23:12 | <david_carlisle> | http://lists.w3.org/Archives/Member/member-math/2010Nov/0053.html |
| 23:13 | <MikeSmith> | ok |
| 23:13 | <MikeSmith> | thanks |
| 23:13 | <david_carlisle> | So that "mathml2" schema will let a few attributes on math that previously were only allowed on children of math for example, but think probably it's OK for the purpose |
| 23:17 | <MikeSmith> | david_carlisle: yeah |
| 23:18 | <david_carlisle> | 'cause you should be using mml3 anyway:-) |
| 23:21 | <MikeSmith> | using mml2 is consistent with we are handling other vocabs |
| 23:21 | <MikeSmith> | e.g., using SVG 1.1 instead of 1.2 |
| 23:22 | <MikeSmith> | it's just that for mml2 validator.nu is still currently using the schema from Furubayashi-san |
| 23:23 | <MikeSmith> | which is great mostly but after I fixed a number of bugs in it and figured out there were very likely more waiting that I hadn't found yet, I figured we should replace it with hopefully fewer bugs |
| 23:30 | <david_carlisle> | html 4 instead of html5, to be consistent? |
| 23:30 | <MikeSmith> | heh |
| 23:31 | <david_carlisle> | MikeSmith: Actually if you are going to base the validator around that, probably I ought to give in and admit it exists and distribute it from teh w3.org/math area , grmble |
| 23:31 | <david_carlisle> | the |
| 23:32 | <MikeSmith> | well, I'd certainly prefer that |
| 23:32 | <MikeSmith> | would take it guesswork out of it for us |
| 23:33 | <david_carlisle> | I suppose so.... |
| 23:33 | <david_carlisle> | not tonight though |
| 23:33 | <MikeSmith> | ok |
| 23:33 | <MikeSmith> | you want me to find a bug or send mail about it or anything? |
| 23:34 | <david_carlisle> | nah I'll just do it, but probably best to wake up first |
| 23:34 | <MikeSmith> | heh |
| 23:34 | <MikeSmith> | OK |
| 23:51 | <david_carlisle> | MikeSmith: do you think it should be real mathml2, or should iI fail to filter out the new mathml3 href attribute (which is allowed pretty much everywhere and makes a link. xlink:href support is a bit thin on the ground and I'd like to push adding href rather than pushing to get xlink fixed |
| 23:54 | <MikeSmith> | david_carlisle: I think it should be real mathml2, and if downstream users of the schema want to change it to allow the href attribute, they can |
| 23:54 | <david_carlisle> | OK I suppose that's a clearer story:-) |
