| 01:43 | <MikeSmith> | and Microdata and RDFa seem to be a case where both could exist and find widespread use in the same way that Relax NG and XML Schema (or whatever) have |
| 01:47 | <TabAtkins> | On that note, every time I look at RDFa I become more convinced that it's a technically worse solution in general. |
| 01:50 | <MikeSmith> | well, I'm not personally taking any position on that, but I will say that was the view that James Clark and Murata-san expressed about XML Schema, and why they came up with Relax NG |
| 01:50 | <MikeSmith> | and I realize I'm harping on about XML Schema and Relax NG and that those are somewhat esoteric |
| 01:50 | <MikeSmith> | but to me at least that seems like the most relevant precedent |
| 04:32 | <roc> | did Richard Schwerdtfeger ever explain *why* his people are using canvas instead of SVG? |
| 07:10 | <hsivonen> | hmm. http://www.xanthir.com/demos/collidingcircles/ doesn't work for me in the Firefox build I happen to have |
| 07:10 | <hsivonen> | clicking the canvas does nothing |
| 07:27 | hsivonen | is reading 10 days of public-html email |
| 07:28 | <hsivonen> | the accessibility rhetoric does not seem to help with finding solutions |
| 09:41 | <annevk5> | XML Schema vs Relax NG is a nice one |
| 09:42 | <annevk5> | manu-db, despite what you suggest, people have did think CSS should be removed in favor of XSL-FO |
| 09:42 | <annevk5> | manu-db, same with Selectors and XPath |
| 09:43 | <annevk5> | manu-db, and again with Media Queries vs some XPath-based syntax |
| 12:01 | <Zeddy> | when accessing the page using http://www.kokonniemi.fi/guide/index.php/view/map/1/1 the manifest file saves 0kb |
| 12:01 | <Zeddy> | when accessing using http://kokonniemi.fi/guide/index.php/view/map/1/1 it saves 602kb |
| 12:04 | <Philip`> | The &lang= would probably be a validator error in the HTML, but shouldn't affect the behaviour of browsers |
| 12:04 | <Zeddy> | ok, had the html tag defined twice |
| 12:04 | <moo-_-> | Zeddy: I suggest you contact your CMS authors and file a bug ;) |
| 12:04 | <Zeddy> | that might explain some problems x) |
| 12:04 | <Zeddy> | im using codeigniter |
| 12:06 | <Zeddy> | god damnit, now that i fixed my html the site isn't caching anything |
| 12:06 | <Zeddy> | is it working for you? |
| 12:06 | <Zeddy> | chrome again tells me the following: Application Cache Error event: Failed to parse manifest http://www.kokonniemi.fi/guide/index.php/manifest?map=1&lang=2 |
| 12:06 | <Zeddy> | x) |
| 12:07 | <Zeddy> | oh, chrome doesn't like comments it seems |
| 12:08 | <Zeddy> | haha, neither did firefox, works in all browsers now :) |
| 12:08 | <annevk> | did you have a comment as first line? |
| 12:08 | <annevk> | because that is bogus |
| 12:09 | <annevk> | read http://www.whatwg.org/specs/web-apps/current-work/complete/offline.html#manifests |
| 12:10 | <Zeddy> | hmm, yeah just above Cache manifest x) |
| 12:10 | <Zeddy> | moved it beneath the line and it works |
| 12:13 | <annevk> | well of course |
| 12:13 | <annevk> | CACHE MANIFEST is the file signature |
| 12:13 | <annevk> | if you replace that with something random it is no longer a cache manifest |
| 12:13 | <Zeddy> | yeah, i realised that |
| 12:13 | <Zeddy> | i didn't even notice i had that line beneath the comment |
| 12:14 | <Zeddy> | i also noticed that i cannot output time() in the comments, because the manifest file changes during the download process and gets corrupt |
| 12:15 | <Zeddy> | wont the browser re-cache everything if a single file is added or deleted to the manifest? |
| 12:15 | <annevk> | it will |
| 12:15 | <Zeddy> | because i could have some kind of version number in the database which would be updated everytime the admin makes changes to text data |
| 12:16 | <Zeddy> | in most cases there will probably be changes in the list of files aswell, but sometimes there might be tiny corrections to the main page, and that won't automatically cause a re-cache, will it? |
| 12:17 | <annevk> | no |
| 12:17 | <annevk> | everything is loaded from cache |
| 12:17 | <annevk> | the manifest is then fetched and compared to the current copy |
| 12:17 | <annevk> | if it is changed new stuff is fetched |
| 12:17 | <Zeddy> | so whenever an admin makes any changes i just increment a version number which is updated in the database and i should always have everything up to date as long as the user visits the page in online mode |
| 12:17 | <annevk> | the next time a refresh happens the new app is loaded |
| 12:18 | <annevk> | if the user just keeps a tab open you might have to indicate a new version is available and a refresh is required |
| 12:18 | <annevk> | or some such |
| 12:18 | <Zeddy> | echo "#version".$map_version."\n"; |
| 12:18 | <Zeddy> | yeah but thats a bit far fetched since the data wont be updated that often |
| 12:20 | <Zeddy> | Another thing i was wondering, since my pages will be dynamic aswell as the manifest file, is it possible to clear everything cached by my domain even though the url is different? Or will it perhaps do that automatically |
| 12:20 | <Zeddy> | Since the user might switch from http://www.kokonniemi.fi/guide/index.php/manifest?map=1&lang=2 to http://www.kokonniemi.fi/guide/index.php/manifest?map=1&lang=3 |
| 12:20 | <Zeddy> | and i don't want it to cache both |
| 12:24 | <hsivonen> | now that Zakim supports SIP, what's a good way to get a provider? |
| 12:26 | <annevk> | does it work with Skype? |
| 12:28 | <Zeddy> | i don't get this, i visit my page with the manifest file, it caches the manifest, i visit it again and it also loads javascript and css not included in the manifest, but if i go offline once and visit the page again the css and javascript are obviously no there, the weird part is that when i go online again and refresh, it doesn't even attempt to load the css and javascript |
| 12:28 | <Zeddy> | why does it load the javascript and css when refreshing in online mode in the first place then? |
| 12:28 | <annevk> | because it has not seen the manifest yet |
| 12:29 | <Zeddy> | Huh, the first time i visit it sees the manifest and download everything, then i press F5, shouldn't it have seen the manifest at that point? |
| 12:30 | <annevk> | yes |
| 12:30 | <annevk> | oh wait |
| 12:30 | <annevk> | not sure what is going on there |
| 12:33 | <Zeddy> | you can try it yourself here: http://www.kokonniemi.fi/guide/index.php/view/map/1/1 |
| 12:33 | <Zeddy> | it seems to be the same with both chrome and firefox |
| 14:35 | <hsivonen> | annevk: were we supposed to have an HTML-XML call today? |
| 14:41 | <manu-db> | annevk5, annevk: re: CSS should be removed in favor of XSL-FO - I hope that 'removal' of Microdata isn't the intention with the Microdata/RDFa TF. I think that they could be merged successfully (with a number of changes to Microdata or RDFa). I think this discussion could positively impact Microformats as well. I want to see that dialog start. If all of us end up in a place that we can agree... |
| 14:42 | <manu-db> | ...on, all the better. I think we're not there today because the Microdata, the Microformats and the RDFa camp haven't been communicating as much as they should have been. |
| 14:43 | <manu-db> | So, yes - I agree that there was a contingent of people that wanted a black and white decision on CSS and XSL-FO, Selectors and X-Path, etc. - Personally, I'm not looking for that to happen. I want to know if the changes we're proposing to RDFa could find common ground, or if changes to Microdata could find common ground. |
| 14:44 | <AryehGregor> | manu-db, I don't think the syntaxes can be merged at this point, realistically. The data models, maybe, and that would be productive. |
| 14:44 | <manu-db> | If the use cases are supported, I don't think that it matters which one ends up "winning". |
| 14:44 | <AryehGregor> | I don't see why a committee is going to be remotely useful, though. It seems like a case of "when in doubt, form a committee". |
| 14:45 | <AryehGregor> | It would seem more productive for people to propose specific changes in the form of bugs. |
| 14:45 | <manu-db> | AryehGregor: People don't really care that much about the syntaxes - both are equally confusing to some, both are reasonable to others. The data models are important and yes, I do think a discussion about that would be productive. |
| 14:46 | Philip` | imagines the main danger is that merging two different systems will result in greater complexity than either of the systems by itself, since it's easier to argue for features than for simplicity |
| 14:46 | <AryehGregor> | I think the syntaxes aren't going to change substantially because both have too much existing content. |
| 14:46 | <manu-db> | AryehGregor: I don't see this as a "design by committee" exercise - maybe it'll turn into that, but I want this to primarily be a meeting between people that are in the same area (structured data), but who have not had the chance to talk to each other and express their pain points. |
| 14:46 | <Philip`> | (and the complexity of RDFa was one of the main reasons for designing Microdata as a replacement) |
| 14:47 | <hsivonen> | manu-db: is there a Web reference for removing CSS to pave way for XSL-FO? |
| 14:47 | <manu-db> | Philip`: yes, more complexity is one of the concerns. Now, I'm talking about stripping stuff out of RDFa (just me, not the WG) to see if that could create consensus. |
| 14:47 | <AryehGregor> | manu-db, well, good luck. |
| 14:47 | <manu-db> | hsivonen: annevk said that, not I. I just trusted that he was correct. :) |
| 14:48 | <hsivonen> | manu-db: It sounds plausible, sure. |
| 14:48 | <AryehGregor> | I don't think there are going to be strong enough incentives for compromise here. The W3C can't exert much pressure on RDFa because it has too much entrenched support, and can't exert much pressure on microdata because the microdata people would be happy to tell the W3C to drop dead and only publish at the WHATWG. |
| 14:48 | <karlcow> | "do not fear death" |
| 14:48 | <hsivonen> | manu-db: in fact, I believe the CSS vs. XSL situation was more combative initially, but I haven't read up on that story enough |
| 14:49 | <manu-db> | AryehGregor: I don't think that logging bugs will do much at this point, because there are pockets of people that don't think there is a problem - or that two syntaxes isn't causing confusion. Those folks need to speak to implementers - implementers are getting increasingly agitated that they're having to put both types of markup into their pages. |
| 14:49 | <AryehGregor> | Theoretically everyone agrees that having only one solution is better, but in practice both sides think that solution should be theirs. |
| 14:49 | <hsivonen> | manu-db: anyway, I suspect it's not correct that XSL-FO has always been an XML print thing |
| 14:49 | <karlcow> | hsivonen: if I remember there were a few contentious |
| 14:49 | <AryehGregor> | manu-db, you mean authors, I guess, not implementers? One way to solve that problem is to just decide on one or the other, as schema.org has done. |
| 14:49 | <karlcow> | xpath vs css selectors |
| 14:49 | <karlcow> | was one |
| 14:49 | <hsivonen> | manu-db: why would howcome have written the Considered Harmful essay if there wasn't a threat of FO leaking to the Web? |
| 14:50 | <hsivonen> | manu-db: which people don't care about the syntaxes? |
| 14:50 | <manu-db> | hsivonen: I didn't mean to say that XSL-FO has always been a "print" thing - I meant that it was /one/ of the targets - which made it a bit different than CSS. If you guys think XSL vs. CSS was a better example of something like this happening in the past, I'd be happy to use that as an example - especially if it resulted in some sort of consensus. |
| 14:50 | <AryehGregor> | So I don't think there's a huge problem right now. Compromising on the syntax seems like a bad idea -- it will just result in something that's worse than either of the existing ones. |
| 14:50 | <hsivonen> | manu-db: do we get to kill CURIEs now if syntax isn't cared about? :-) |
| 14:51 | <AryehGregor> | I think the only productive thing to do at this point is to make sure you can mechanically transform microdata to RDFa and vice versa to the greatest extent possible. |
| 14:51 | <manu-db> | hsivonen: killing CURIEs - it's a possibility (in my mind, at least) |
| 14:52 | <AryehGregor> | The microdata spec has a conversion algorithm, but it's not targeted at allowing you to reuse existing RDFa vocabularies, without some translation layer -- e.g., it can only create a very specific sort of vocabulary URL. |
| 14:52 | <manu-db> | hsivonen: "which people don't care about syntaxes": Regular web devs (theory). In practice those that I've been able to talk to at the International Press Telecommunications Council, Good Relations, etc. |
| 14:52 | <AryehGregor> | So I think the best thing to do is acknowledge that microdata and RDFa will both continue to exist for now, and try to make sure they can interoperate as much as possible. |
| 14:52 | <karlcow> | xpath vs css selectors, xml query vs xslt, cassoulet vs choucroute, pepsi vs coke, css and fo, xml vs rdf, xhtml vs html, |
| 14:53 | <manu-db> | AryehGregor: The problem isn't interoperability - that's fairly easy *wild hand waving* |
| 14:53 | <AryehGregor> | Microformats is a separate thing, that should just be ignored. It's a legacy hack designed to embed data in pages while still being valid HTML 4. |
| 14:53 | <scor> | AryehGregor: that assumes that those consuming this structured data can parse both syntaxes |
| 14:53 | <manu-db> | AryehGregor: The problem is that implementers are having to put /both/ Microdata /and/ RDFa into their markup to placate different folks: Facebook OGP and Google schema.org, for example. |
| 14:53 | <AryehGregor> | scor, yes, exactly. Put work into making sure that the same libraries support both interchangeably without extra work, as much as possible. |
| 14:54 | <manu-db> | AryehGregor: We're working on that now, with the Structured Data API in the RDF Web Apps WG - it's meant to be syntax agnostic. |
| 14:54 | <AryehGregor> | manu-db, yeah, that's a pain. But a compromise syntax is no more likely to resolve it than just trying to get everyone to converge on one or the other. |
| 14:54 | Philip` | thought every big company made up their own 'standard' vocabularies, so you'd have to insert two separate sets of metadata anyway |
| 14:54 | <AryehGregor> | I mean, if you announce a great new compromise tomorrow, Facebook probably isn't going to instantly support it for OGP. |
| 14:54 | <manu-db> | AryehGregor, but again - that's not the real problem. The real problem is that Web devs are having to put /both/ types of markup in their pages. |
| 14:55 | <AryehGregor> | It would probably be just as easy to get them to support microdata. |
| 14:55 | <AryehGregor> | The reason people have to use both isn't because there's no compromise, it's because some organizations have gone with one and some have gone with another. |
| 14:55 | <manu-db> | Philip` - yes, the whole NIH vocabularies are a pain. We're trying to get the large companies to converge on vocabularies, there is some progress on that front. |
| 14:55 | <AryehGregor> | That's not something that can be resolved in standards-land, we have to talk to the organizations. |
| 14:56 | <manu-db> | AryehGregor: I think you would find Google, Facebook, etc. more willing to support a unified way forward than you imagine. At least, that's my read on them. |
| 14:56 | <AryehGregor> | Yes, but that unified way forward may as well just be microdata. It's not like Facebook is using RDFa because they think it's better, they're using it because nobody had heard of microdata when they introduced OGP. |
| 14:57 | <linclark> | AryehGregor: just catching up on this... there are some implementers of tools for authoring RDFa/microdata. we're probably a small bunch, but there are some none-the-less ;) |
| 14:57 | <karlcow> | hmm the convergence of vocabularies will happen through business practices. I'm pretty sure. Where and when it matters. Community of interests with business needs, requirements aka profitability |
| 14:57 | <manu-db> | AryehGregor: That's what I meant - we /are/ talking to the organizations and there seems to be a desire to work together on vocabs. |
| 14:59 | <manu-db> | AryehGregor: I think that's a fairly wild claim, to say that you understand why Facebook picked RDFa. I'm just pointing that out - I don't think any one of us can clearly understand why they picked one or the other. |
| 14:59 | <AryehGregor> | When was OGP introduced, and when was microdata first published? |
| 14:59 | <manu-db> | I think something that does hold true is that all of the companies that have picked one or the other, have not clearly understood /both/ RDFa or Microdata when they adopted it. |
| 15:00 | <manu-db> | OGP was announced April 21st 2010 |
| 15:00 | <AryehGregor> | Oh, sure. But that's true for basically every web technology. Almost nobody gets anything except the very most concrete aspects. |
| 15:00 | <manu-db> | Yes, exactly |
| 15:01 | <manu-db> | Which is why I think that people making the argument from the standpoint of the adopting organizations /completely/ understanding the options is a very difficult argument to make. |
| 15:01 | <AryehGregor> | So microdata had been around for a while, but nobody actually used it until schema.org came around, and that might have been related to internal decisions within Google. (I have no idea, I'm an outside contractor.) |
| 15:01 | <AryehGregor> | Whereas RDFa had been gaining traction for years. |
| 15:02 | <AryehGregor> | Unless you were a standards aficionado, if you heard of any technology in this area it would be RDF. |
| 15:03 | <AryehGregor> | Also, didn't Facebook already use RDFa in the form FBML before OGP? |
| 15:04 | <AryehGregor> | Anyway, this really isn't a subject I'm particularly knowledgeable about or interested in. All I'll say is that no one seems to prefer RDFa to microdata unless they were committed to RDFa before microdata was developed, and at least one major organization (Google) that previously used RDFa is transitioning to microdata, so I'm going to bet the best way to get standardization is just to standardize on microdata. I think the worst way to proc |
| 15:04 | <AryehGregor> | eed is to try introducing yet another markup language that will complicate matters still further. Regardless, good luck. |
| 15:05 | <karlcow> | the walmart effect |
| 15:05 | <karlcow> | the elephant in the room changing the business practice for everyone else |
| 17:13 | <annevk> | AryehGregor, I once worked on that too btw, in my first summer here in Norway: http://annevankesteren.nl/projects/whatwg/spec |
| 17:13 | <annevk> | AryehGregor, I never got really far |
| 17:14 | <AryehGregor> | annevk, interesting. |
| 17:14 | <AryehGregor> | Never saw that. |
| 17:14 | AryehGregor | will take a look |
| 17:14 | <annevk> | be careful, six years ago, I didn't really know how stuff worked |
| 17:15 | <AryehGregor> | You'll probably have at least one angle on something that will be interesting to me. |
| 17:16 | <AryehGregor> | I've gotten next to no feedback on the spec so far from anyone. |
| 17:16 | <annevk> | that always sucks :/ |
| 17:16 | <annevk> | you basically need to find someone that either implements or writes tests |
| 17:16 | <annevk> | for good feedback |
| 17:16 | <annevk> | otherwise it just gets stuck until reviewed |
| 17:17 | <annevk> | the same is true with lots of the HTML specification |
| 17:17 | <annevk> | the parts that were already implemented have had way less review |
| 17:17 | <AryehGregor> | Once I'm done polishing up the spec, hopefully within a couple of weeks, I'll publicize it and try to encourage implementers to respond speedily. |
| 17:17 | <annevk> | let me know how that goes :) |
| 17:22 | <TabAtkins> | AryehGregor: Make sure you pull in Ryosuke (rniwa@) as soon as you're ready. He's the "editting guy" on Chrome. |
| 17:22 | <AryehGregor> | TabAtkins, I know, he's been my WebKit contact. |
| 17:22 | <TabAtkins> | Excellent. |
| 17:23 | <AryehGregor> | I always CC him when I have specific questions that I ask on whatwg. |
| 17:23 | <AryehGregor> | Ehsan is my Mozilla person, and Hallvord is my Opera person, although the latter hasn't given much feedback. |
| 17:24 | <AryehGregor> | When I'm ready, I'll post to public-html and CC Adrian Bateman also. |
| 17:25 | <TabAtkins> | annevk: When can the Origin header contain multiple origins? |
| 17:34 | <AryehGregor> | This is what I love about functional programming: |
| 17:34 | <AryehGregor> | / "Fix disallowed ancestors of each member of sublist." |
| 17:34 | <AryehGregor> | sublist.forEach(fixDisallowedAncestors); |
| 17:34 | <AryehGregor> | s!^/!//! |
| 17:35 | <Philip`> | That looks like you're mutating the list |
| 17:35 | <Philip`> | That's not functional :-p |
| 17:36 | <AryehGregor> | It's not mutating the list. |
| 17:36 | <Philip`> | What's it doing, then? |
| 17:37 | <AryehGregor> | It's calling fixDisallowedAncestors on each member of sublist. |
| 17:37 | <AryehGregor> | That mutates the DOM, but not the list. |
| 17:38 | Philip` | counts mutating things reachable from the list as mutating the list, in order to keep his statement valid |
| 17:41 | <AryehGregor> | In that case, mutating any global variable or anything accessible from a global variable counts as a mutation, because of ownerDocument.defaultView. |
| 17:42 | <AryehGregor> | Hey, wait. Why can't we use instanceof like if (foo instanceof foo.ownerDocument.defaultView.Node) to avoid multiple-global problems, at least for Nodes? |
| 17:42 | <AryehGregor> | Our use-case for testharness.js was mostly DOMException, admittedly. |
| 17:46 | <TabAtkins> | Who's "we" here? Because that's pretty verbose and horrible for authors. |
| 17:46 | <Philip`> | If you really like functional programming, you should replace all global variables and DOM mutation functions with a monad system |
| 17:46 | <AryehGregor> | TabAtkins, I was specifically thinking of testharness.js, where we want to test things like "foo is a Node". |
| 17:47 | <AryehGregor> | But can't because of the multiple-global problem. |
| 17:47 | <AryehGregor> | But actually the major thing we wanted to test is "foo is a DOMException", and this idea doesn't help for that. |
| 17:47 | <AryehGregor> | Philip`, I never said *pure* functional. |
| 17:47 | <TabAtkins> | Ah, kk. Then I dunno, because the DOM is confusing. But sure, sounds reasonable. |
| 17:48 | <Philip`> | Impure functional isn't really functional :-p |
| 17:48 | <TabAtkins> | Sure it is. |
| 17:48 | <TabAtkins> | Otherwise Lisp isn't functional, and then "functional" isn't a very useful term. |
| 17:50 | <AryehGregor> | Sure it is, if you only care about Haskell. |
| 17:50 | <AryehGregor> | Anyone who cares about non-Haskell languages doesn't matter. |
| 17:50 | <TabAtkins> | Still, any definition of "functional" that excludes Lisp is a silly definition. |
| 17:51 | <Philip`> | It's a useful term for computations written in a subset of the language that don't do any mutation, since it means you can happily refactor things or do memoisation etc without worrying about changing the semantics of the program |
| 17:52 | <TabAtkins> | That's what the term "pure functional" is for. |
| 17:53 | <Philip`> | It doesn't seem a very useful term for referring to any syntax that happens to use functions as first-class objects, like forEach, since pretty much any language can do that |
| 17:54 | <TabAtkins> | Many languages still can't do so easily. Passing around function pointers doesn't really make functions "first-class objects". |
| 17:59 | <AryehGregor> | "One of the problems with block-break is that its exact semantics depend on the markup language being used and the nodeName of the editing host. For example, in HTML you want to disable the ability to insert p element nodes inside a h1 element node. For generic XML languages this is almost impossible with using a schema language of some sort." |
| 17:59 | <AryehGregor> | annevk, I can tell this is old. :) |