| 00:00 | <vvv> | Lachy: graphics editors would need it |
| 00:00 | <TabAtkins> | I know that GIMP exposes alpha through an opacity control, which is separate from the color-picker. |
| 00:01 | <Lachy> | vvv, I'm not questioning the need for an alpha channel itself, just whether it needs to be integrated in the same control, rather than a separate control. |
| 00:02 | <Hixie> | Lachy: it's common for the colour control on Mac OS X to have an alpha slider |
| 00:05 | <Lachy> | Hixie, I don't appear to have any graphics apps on my mac to be able to check that. |
| 00:05 | <vvv> | Lachy: http://img252.imageshack.us/img252/9418/rgbacolorpicker.png - that's a GTK one |
| 00:06 | <Lachy> | ok |
| 00:06 | <Hixie> | Lachy: keynote and pages, e.g. |
| 00:07 | <Lachy> | ah, ok. I have those apps and have now seen it |
| 00:10 | <Lachy> | vvv, in the mean time, this should be a suitable substitue <input type=number min=0 max=1 step=0.01 name=alpha> |
| 00:11 | <Lachy> | or input type=range instead |
| 00:28 | <othermaciej> | Hixie: looks like Roy identified some specific things he thinks are lacking in the HTML5 definition, his latest message and my response to him |
| 00:28 | <Hixie> | yeah, already fixing the spec |
| 00:30 | <Rik`> | vvv: you can add a input type=range for ask the user to specify the alpha channel ? |
| 00:31 | <vvv> | Rik`: color pickers do it nicer usually |
| 00:43 | <Hixie> | wow, that was the first time roy said something that actually resulted in changes to the spec |
| 00:45 | <othermaciej> | I am hoping this experience will help him appreciate the merits of being specific |
| 00:46 | <othermaciej> | Hixie: you still don't have a requirement that two <a>s can't have the same name, afaict |
| 00:47 | <Hixie> | oops |
| 00:47 | <Hixie> | fixing |
| 00:52 | <othermaciej> | also would it kill you to change " In earlier versions of the language, this attribute served a similar role as the id attribute." to something like " In earlier versions of the language, this attribute served a similar role as the id attribute, including defining targets for fragment identifiers."? |
| 00:52 | <othermaciej> | Not that it's a hugely meaningful difference, but it might brighten Roy's day |
| 00:55 | <Dashiva> | Is that possible? |
| 00:56 | <othermaciej> | well, he deserves a prize for finding a material error in the spec (one I myself overlooked despite looking at the two definitions side by side just recently) |
| 00:57 | <othermaciej> | whether that would in fact brighten his day, I can't say |
| 00:57 | <heycam> | does <a name> not define a target for a fragid in html5? |
| 00:57 | <othermaciej> | it does |
| 00:57 | <heycam> | ok, then the "in earlier languages" sounds misleading |
| 00:57 | <othermaciej> | true |
| 00:57 | <heycam> | sounds like in this version that's not the case |
| 00:57 | <Hixie> | othermaciej: i have no opinion on that particular change, but i have to go afk for a while. if you want it, post on that thread. |
| 00:57 | <Hixie> | bbiab |
| 00:57 | <Dashiva> | Is Roy basically writing a multi-version validator? |
| 00:58 | KevinMarks | reads http://blog.foolip.org/2009/08/23/microformats-vs-rdfa-vs-microdata/ too, and has no idea what he is trying to represent - scope fail |
| 00:58 | <othermaciej> | Dashiva: I believe he has a tool that's not a validator per se, it just wants to check link targets |
| 00:59 | <othermaciej> | Dashiva: so for links with a fragid, it would want to check that the fragment target exists in the target file |
| 00:59 | <othermaciej> | heycam: any wordsmithing advice? |
| 00:59 | <othermaciej> | heycam: it would be nice to mention the purpose in establishing a fragid, without making it sound like it doesn't actually do that, but while still recommending id instead |
| 01:00 | <heycam> | othermaciej, yeah it might be good to have a section dedicated to that in fact |
| 01:00 | <heycam> | which says that id and name both establish such names |
| 01:00 | <othermaciej> | heycam: there is a section dedicated to the algorithm for the target of fragid |
| 01:01 | <heycam> | which already mentions name? |
| 01:01 | <othermaciej> | http://dev.w3.org/html5/spec/Overview.html#the-indicated-part-of-the-document |
| 01:02 | <heycam> | ok it does |
| 01:02 | <othermaciej> | is it worth mentioning this again in the description of "name" or no? |
| 01:02 | <heycam> | yes i think so |
| 01:02 | <heycam> | linking to that alg |
| 01:02 | <heycam> | otherwise it might not be easy to find |
| 01:03 | <heycam> | i think people may start by looking up the definition of the name attribute |
| 01:03 | <heycam> | and if they don't find the mention of the fragid stuff there then they might assume that that is it |
| 01:04 | <othermaciej> | heycam: the definition of the id attribute mentions the fragment use, so that's fair |
| 01:04 | <heycam> | sounds good then |
| 01:04 | <heycam> | is there a tendency in the spec not to define the meaning of obsolete features? |
| 01:05 | <heycam> | (and only to define the behavior of the UA for them?) |
| 01:05 | <othermaciej> | it depends on what you mean by meaning |
| 01:06 | <othermaciej> | in some cases, it's pretty vague about the former intended purpose of the obsolete feature, but it does give author conformance requirements and implementation conformance requirements |
| 01:06 | <heycam> | yeah |
| 01:06 | <othermaciej> | for obsolete but conforming, it should probably give the semantics in the same way as they are given for fully conforming, to the degree applicable |
| 01:06 | <heycam> | i was wondering if that was deliberate, to dissuade people from using them |
| 01:06 | <othermaciej> | because even though you SHOULD NOT use the feature, it ought to still be the case that you MUST use it in accordance with its semantics |
| 01:06 | <heycam> | right |
| 01:07 | <AryehGregor> | What's the point of obsolete but conforming? Isn't that like HTML 4 Strict, which HTML 5 wanted to avoid? |
| 01:07 | <heycam> | but if we're going down the road of "html 5 is replacing all previous versions and therefore must define all previously allowed features", then we might need them for obsolete and non-conforming too |
| 01:08 | <heycam> | unless we consider it acceptable to change previously conforming documents to be non-conforming, of course |
| 01:08 | <othermaciej> | it is considered acceptable to change previously conforming documents to be nonconforming |
| 01:09 | <othermaciej> | older versions of HTML have done that too |
| 01:09 | <heycam> | but it's a bit different with older versions of HTML |
| 01:09 | <heycam> | since you had version identifiers in the documents themselves |
| 01:10 | <heycam> | so you're just changing what is conforming for documents with the newer version identifier |
| 01:10 | <othermaciej> | heycam: I'm going to suggest adding a note like: |
| 01:10 | <othermaciej> | "An a element's name attribute can be used for a variety of purposes, most notably as a way to link to specific parts of a document using fragment identifiers." |
| 01:10 | <othermaciej> | or "An a element's name attribute can be as a way to link to specific parts of a document using fragment identifiers. The id attribute is recommended instead for this purpose." |
| 01:10 | <othermaciej> | heycam: does that sound sane? |
| 01:10 | <heycam> | prefer the second one |
| 01:10 | <heycam> | yep, sounds good |
| 01:10 | <othermaciej> | I'm including both suggestions |
| 01:11 | <heycam> | ok |
| 01:11 | heycam | should respond to the issue-37 thread at some point he supposes |
| 01:11 | <othermaciej> | heycam: that would be nice - sorry for giving you such a long-winded and multifaceted reply |
| 01:11 | <heycam> | no that's fine |
| 01:13 | <othermaciej> | ooh, I have a cut off sentence in what I wrote |
| 01:13 | <heycam> | the svg wg is having a f2f in late september, so i'm planning to discuss svg-in-text/html then, and get any remaining issues sent to the htmlwg by the end of that meeting |
| 01:14 | <othermaciej> | replied to self |
| 01:14 | heycam | wonders whether the planned LC is early or late october :) |
| 01:14 | <othermaciej> | heycam: "planned" is such a strong word |
| 01:14 | <heycam> | heh |
| 01:15 | <heycam> | desired then |
| 01:15 | <othermaciej> | looks like I had 5 open questions for you (in addition to filing 2 bugs based on the feedback) |
| 03:21 | <othermaciej> | howdy folks |
| 03:34 | <othermaciej> | Hixie: I like how you worded it |
| 03:37 | <Hixie> | assuming you mean the edit to the spec, cool |
| 03:37 | <Hixie> | i really have no idea what roy wants though |
| 03:37 | <Hixie> | how can we define a DOM-based language without reference to the DOM? |
| 03:37 | <Hixie> | i thought HTML4 had shown that idea was a complete failure |
| 03:41 | <Hixie> | wow, turns out onhashchange is actually synchronous in IE |
| 03:41 | <Hixie> | i thought we tested that and found it async |
| 04:02 | <dimich> | I have an XHR question. I'm reading the XHR spec, it has a sentence on failed TLS negotiation, but it'd be nice to get a clarification: in case XHR is over SSL and encounters bad certificate error, and user already accepted bad cert for the page that runs the script - should XHR fail or succeed? |
| 04:03 | <Hixie> | that's probably either a TLS spec question, or a UI question |
| 04:04 | <dimich> | Hixie: The XHR spec says do NETWORK_ERR silently. That's clear except the case where user already agreed with the bad cert... |
| 04:04 | <Hixie> | sounds like a UI issue to me -- depends on whether the UI says "accept this one time" or "accept forever" or "accept for this page and anything this page does" etc |
| 04:05 | <Hixie> | same answer as if you asked the same thing but with <img> pointing to a resource on that server |
| 04:05 | <dimich> | Hixie: so basically it's up to UA. I see. Do you think loading from Workers is any different? I woudl assume not since they are part of the page, sort of. |
| 04:06 | <Hixie> | i would say that if the user has said to temporarily accept a bogus cert, then it should be accepted until the session closes |
| 04:06 | <Hixie> | of course personally i would just treat bogus certs as the same as no cert and pretend that it was an http: connection |
| 04:07 | <Hixie> | and not show any (modal) UI |
| 04:07 | <Hixie> | (maybe have an infobar warning) |
| 04:08 | <dimich> | Hixie: thanks! |
| 04:24 | <AryehGregor> | Hixie, that means there's no protection against MITM unless you can rely on the user to realize something is wrong if the URL bar is the wrong color or such. |
| 04:24 | <AryehGregor> | Currently you only get to do that if the user initially tries an HTTP connection and only later switches to HTTPS, e.g., if they type "amazon.com" in the URL bar. |
| 04:25 | <AryehGregor> | On the other hand, the warning that browsers usually present these days is obviously ridiculously too scary, given that in probably >99.9% of cases it will just be innocuous misconfiguration. |
| 04:26 | <AryehGregor> | HTTPS is unreasonably easy to misconfigure in practice. |
| 04:27 | <Hixie> | AryehGregor: hence the infobar warning. |
| 04:27 | <Hixie> | AryehGregor: then again, that warning should probabl appear for all HTTP accesses too |
| 04:28 | <AryehGregor> | It's kind of a pain when there's a 99.9% chance that it's totally innocuous, and a <0.1% chance that someone is stealing your credit card numbers and will spend $5000 of your money on gambling or something. |
| 04:28 | <AryehGregor> | Not easy to make good UI for that. |
| 04:29 | <AryehGregor> | https://google.com at one point gave a mismatched cert, it was serving a cert for www.google.com. :/ |
| 04:29 | <Hixie> | the current practice of prompting the user and then, if the user hits the right sequence of buttons, just pretending that all is ok, is clearly not the answer |
| 04:29 | <AryehGregor> | They don't pretend it's okay, they color the address bar red and such, AFAIK. |
| 04:29 | <Hixie> | yeah, exactly |
| 04:29 | <Hixie> | they do it differently than port 80 |
| 04:29 | <Hixie> | which i think is worse |
| 04:29 | <Hixie> | people go "ok, there's a lock, and it's the special color, i must be ok" |
| 04:30 | <AryehGregor> | Do people even look at the URL bar color in practice? |
| 04:30 | <AryehGregor> | I mentioned it once to my mother, and she insisted she had never seen the URL bar turn different colors. |
| 04:30 | <AryehGregor> | Even though she uses Gmail continuously, over HTTPS. |
| 04:30 | <Hixie> | i saw research saying 25% of people only trust the content inside the rendering area |
| 04:30 | <Hixie> | and ignore UA UI |
| 04:30 | <Hixie> | so... |
| 04:30 | <AryehGregor> | That's horribly backwards. |
| 04:31 | <AryehGregor> | Too bad Tim Berners-Lee didn't think to make it all encrypted from day one. :/ |
| 04:32 | <AryehGregor> | DNSSEC will hopefully allow easier deployment of certificates, at least. It should theoretically remove most or all of the self-signing and mismatch problems we get today, if I understand correctly. |
| 04:32 | <AryehGregor> | I haven't looked at the details, though. I'd hope you could set up your DNS to just serve the same (uncertified) key for all your domains, and then just dump the same key on all your servers, and have it work. |
| 04:33 | <AryehGregor> | Right now you have headaches with the wrong key being served, and people not being willing to shell out for a certificate. |
| 04:33 | <Hixie> | yeah well we're not doing websockets all encrypted either :-) |
| 04:33 | <Hixie> | encryption has high overhead and makes debugging a pain in the ass |
| 04:34 | <AryehGregor> | I'd also hope you could add a DNS entry (with DNSSEC) saying "don't ever connect to this site unencrypted". |
| 04:35 | <AryehGregor> | High overhead, maybe. Hopefully the Moore's law fairy will solve that one soon. For debugging, do you often look at actual network packets using a packet sniffer? I've only done that rarely. |
| 04:40 | <Hixie> | the overhead will always be more than no encryption |
| 04:40 | <Hixie> | i do network sniffing all the time |
| 04:44 | <AryehGregor> | Well, just because it's more doesn't mean it's significantly more. Web servers usually aren't CPU-bound anyway (assuming "web server" is different from "application server"). I've also heard that the i7 works very well for efficient crypto. |
| 04:45 | <Hixie> | the issue isn't cpu usage, it's latency |
| 04:45 | <Hixie> | annevk2: yt? |
| 04:54 | <Hixie> | hey kevin |
| 04:54 | <Hixie> | nice appearance on twig :-) |
| 05:08 | <cardona507> | kevinmarks - is leos new room like a spaceship? |
| 08:26 | <erlehmann> | Hixie, why is using microdata for styling a bad idea? because it is prone to change? |
| 08:26 | <erlehmann> | after all, i use semantics in styling all the time |
| 09:24 | <hsivonen> | mantic.se is a great idea. I wish I had thought about it. |
| 10:23 | <MikeSmith> | hsivonen: I bet there's still mantics.se, and miotic.se/miotics.se |
| 10:23 | <MikeSmith> | gnifies.si |
| 10:24 | gsnedders|work | wants .rs to exist |
| 10:24 | <gsnedders|work> | Oh, it does, since 2006 |
| 10:25 | <gsnedders|work> | But you can only get third level domains |
| 10:25 | <jgraham> | eless.us |
| 10:25 | <MikeSmith> | heh |
| 10:43 | <beowulf> | oteric.es |
| 10:45 | <othermaciej> | tadata.me |
| 10:49 | <annevk2> | ml.sg |
| 10:49 | <annevk2> | but then apparently Singapore doesn't do top-level |
| 10:51 | <jgraham> | why not ml.ht? |
| 10:52 | <zcorpan> | btex.bi |
| 10:54 | <jgraham> | ard.vc |
| 10:55 | <zcorpan> | mon.si |
| 10:55 | <annevk2> | atwg.wh |
| 10:56 | <jacobolus> | Hixie: I like your Tetris playing thing |
| 11:00 | <erlehmann> | jacobolus, link? |
| 11:03 | <jacobolus> | erlehmann: http://tetrisapp.appspot.com/ |
| 11:04 | <jacobolus> | Hixie: maybe you're asleep; I'll try to catch you tomorrow :) |
| 11:04 | <erlehmann> | jacobolus, wait "ian.hickson" has the highscore |
| 11:04 | <erlehmann> | unfair ^^ |
| 11:04 | <jacobolus> | erlehmann: no, I don't think it's Hixie's site. he just has the high score |
| 11:05 | <jacobolus> | I was complementing his bot |
| 11:05 | <erlehmann> | his tetris bot? |
| 11:05 | <jacobolus> | erlehmann: click it and you can see the replay |
| 11:05 | <jacobolus> | erlehmann: right |
| 11:05 | <erlehmann> | jacobolus, so this is not a tetris game but a scripting game ? |
| 11:06 | <erlehmann> | wow, cool |
| 11:06 | <jacobolus> | erlehmann: I made a multiplayer iphone game w/ some friends, and I was going to ask Hixie if we released a bot API, and let people's bots compete, w/ games visible in real time using Web Sockets, if he'd port his bot to our API, etc. :) |
| 11:09 | <jacobolus> | erlehmann: "Mino" |
| 11:09 | <erlehmann> | mino? |
| 11:10 | <jacobolus> | erlehmann: did that other message all make it through? |
| 11:10 | <erlehmann> | <jacobolus> erlehmann: I made a multiplayer iphone game w/ some friends, and I was going to ask Hixie if we released a bot API, and let people's bots compete, w/ games visible in real time using Web Sockets, if he'd port his bot to our API, etc. :) |
| 11:10 | <erlehmann> | jacobolus, this? |
| 11:10 | <jacobolus> | erlehmann: right, so the multiplayer iphone game is called Mino :) |
| 11:10 | <erlehmann> | i see |
| 11:10 | <erlehmann> | iphones suck :p |
| 11:10 | <erlehmann> | <-- android user |
| 11:13 | <jacobolus> | erlehmann: well, I don't have a judgement, because I haven't used one. I just made the graphics for this game :) |
| 11:13 | <jacobolus> | erlehmann: but I find the ipod touch kind of neat |
| 11:14 | <jacobolus> | then again, it's the first mp3 player I've had, and the whole thing is a bit mind-bending :) |
| 11:15 | <erlehmann> | jacobolus, its just … as an app developer i dont want maintainers to take month |
| 11:15 | gsnedders|work | ought to get a new phone sometime, but can't decide what |
| 11:15 | <erlehmann> | and then reject my app. |
| 11:15 | <erlehmann> | so i would never develop for the iphone. |
| 11:25 | <jacobolus> | erlehmann: that's fair; we've been somewhat frustrated with the approval process, etc. |
| 11:25 | <jacobolus> | erlehmann: still, the game is pretty fun :) |
| 12:40 | <remysharp> | I'm reading the specs for offline, and trying to work out if there's a way to programatically expire the cache - is this possible? |
| 12:41 | <gsnedders|work> | The HTTP cache control headers? |
| 12:41 | <remysharp> | no - via the manifest |
| 12:41 | <remysharp> | or, sorry, are you saying you do it via the http cache control headers? |
| 12:42 | <gsnedders|work> | Oh, I don't know about manifest |
| 12:42 | <remysharp> | okay, cheers :) |
| 12:43 | <remysharp> | if anyone else has any idea, happy to hear - currently my browser won't give up it's cache of the manifest! |
| 12:44 | <annevk2> | remysharp, point the manifest attribute to a new file |
| 12:45 | <gsnedders|work> | Should the browser not obey the HTTP headers of the manifest cache file? |
| 12:46 | <gsnedders|work> | (But yeah, there's no way with HTTP to then invalidate a file's cache for all clients) |
| 12:47 | <remysharp> | cheers, that worked. Seems a bit of a shame I have to point it to a dead manifest to get it flip out, rather than just removing the manifest (which didn't seem to work) |
| 12:48 | <annevk2> | changing the manifest file should also work in theory |
| 12:48 | <annevk2> | having said that I haven't studied that stuff recently |
| 12:48 | <remysharp> | changing the manifest did work - so cheers :) |
| 14:33 | <miketaylr> | would someone mind looking at a test page, and tell me if i'm abusing <article> headings (nested in a <section>)? |
| 14:33 | <miketaylr> | test page is here: http://miketaylr.com/pres/html5/index.html |
| 14:33 | <miketaylr> | i'm interested in the 'Openings and Closings' section in the bottom right of the page... |
| 14:35 | <erlehmann> | miketaylr, looks nice. where are you unsure spec-wise? |
| 14:35 | <miketaylr> | erlehmann: i suppose i just feel a little wary of wrapping the whole message content in an <h2>, within each 'opening and closing' <article> |
| 14:35 | <gsnedders|work> | miketaylr: See http://gsnedders.html5.org/outliner/process.py?url=http%3A%2F%2Fmiketaylr.com%2Fpres%2Fhtml5%2Findex.html FWIW |
| 14:36 | <gsnedders|work> | If that looks sane, you're probably doing it right |
| 14:36 | <miketaylr> | gsnedders|work: yeah, thanks. i've got that open as well. ;) |
| 14:36 | <miketaylr> | thanks |
| 14:36 | <gsnedders|work> | (Honestly, there's more than vanity at pimpin' that link) |
| 14:36 | <miketaylr> | haha |
| 14:37 | <miketaylr> | the outline is super helpful |
| 14:38 | <zcorpan> | miketaylr: maybe it could be argued that it's more of a list than separate sections |
| 14:38 | <gsnedders|work> | (Like using up other people's CPU time and bandwidth, that's the real reason) |
| 14:38 | <miketaylr> | zcorpan: i see what you mean |
| 14:39 | <zcorpan> | miketaylr: if you were a user and picked a section from the outline, you'd be disappointed to find no further content in the section :) |
| 14:39 | <miketaylr> | zcorpan: yeah, that's a good point. i think that's why i feel unsure having the whole content appear as a section. |
| 14:40 | gsnedders|work | should add links to the outline |
| 14:41 | <miketaylr> | those 'openings and closings' are actually categorized by city (london, ny, sf). so perhaps it would make more sense for the city to appear in the outline, that leads to the actual restaurant blurb |
| 14:42 | <erlehmann> | gsnedders|work, your dom magic is superiour :D |
| 14:42 | <gsnedders|work> | erlehmann: How so? |
| 14:42 | <erlehmann> | superior to my judgement - it reveals that i am doing it wrong http://gsnedders.html5.org/outliner/process.py?url=http://blog.dieweltistgarnichtso.net |
| 14:43 | <erlehmann> | only the first five subheaders are articles, i forgot a section |
| 14:43 | <gsnedders|work> | Also the encoding is going wrong somewhere :P |
| 14:44 | <miketaylr> | heh |
| 14:44 | <TabAtkins> | Oooh, I'll be using that outliner in the future. |
| 14:44 | <gsnedders|work> | I'll probably rewrite it from something thrown together in around ten minutes :P |
| 14:45 | <TabAtkins> | I need to learn Python. And get it running on a server. |
| 14:45 | <TabAtkins> | Or maybe I already have it on my server...? |
| 14:45 | <erlehmann> | gsnedders|work, i only see an article where someone submitted a bad URI (wordpresses fault) |
| 14:45 | <erlehmann> | gsnedders|work, sure you are using unicode internally ? |
| 14:46 | <gsnedders|work> | erlehmann: I think I ignore content-type :P |
| 14:46 | <TabAtkins> | Ah, only Python 2.5.4 is available. No Python3 goodness for me. |
| 14:46 | <Rik|work> | gsnedders|work: http://gsnedders.html5.org/outliner/process.py?url=google.com |
| 14:46 | <gsnedders|work> | TabAtkins: You don't want Python 3 yet |
| 14:46 | <TabAtkins> | Ok. |
| 14:46 | <gsnedders|work> | Rik|work: Yeah, my code is awesome. |
| 14:47 | <Rik|work> | a little check on "http://" might help |
| 14:47 | <miketaylr> | the real outline is less interesting than the error:http://gsnedders.html5.org/outliner/process.py?url=http://www.google.com/ |
| 14:47 | <TabAtkins> | gsnedders|work, can you share code? I'd like something fun to learn from. |
| 14:47 | <miketaylr> | oops |
| 14:47 | <miketaylr> | http://gsnedders.html5.org/outliner/process.py?url=http://www.google.com/ |
| 14:47 | <erlehmann> | gsnedders|work, i am using perfectly save XHTML5. if i ever get around to it, i'll even make sure even bad input results in XHTML5 via re-serializing. also, you can use the unicode in python via the u"" thingy. |
| 14:48 | <gsnedders|work> | TabAtkins: Just take a look at http://hg.gsnedders.com/anolis/ — it the same outlining algorithm as there |
| 14:48 | <TabAtkins> | kk |
| 14:48 | <gsnedders|work> | (and the output is based upon the TOC module) |
| 14:49 | <gsnedders|work> | erlehmann: Yeah, I use Unicode fine, it's just detecting the charset is wrong :) |
| 14:49 | <jgraham> | http://hg.gsnedders.com/anolis/file/e75817a809b8/anolislib/processes/outliner.py <-- this is not code that you want to learn python from |
| 14:49 | <gsnedders|work> | Probably not. |
| 14:49 | <TabAtkins> | Man, remove the comments and it'd be readable. |
| 14:50 | <gsnedders|work> | TabAtkins: It'd take ten times longer whenever I wanted to check that it matched the spec |
| 14:50 | <erlehmann> | jgraham, jeah, but you can learn commenting from it :p |
| 14:50 | <TabAtkins> | I suppose this is true. |
| 14:51 | <gsnedders|work> | (It also blindly follows the spec and uses Hixie-goto all over the place) |
| 14:51 | <erlehmann> | i hate this whole microdata issue. i had a plugin ready for deployment, then suddenly the spec turns around :( |
| 14:51 | <jgraham> | erlehmann: It sucks to be an early implementor. |
| 14:51 | jgraham | sympathises |
| 14:52 | <erlehmann> | jgraham, well, if everything else fails, RDFa. its not urgent, but unfortunate nevertheless. |
| 14:52 | <jgraham> | erlehmann: It can't be that bad, surely? ;) What are you doing with microdata |
| 14:53 | <erlehmann> | creative commons markup :D |
| 14:53 | jgraham | has managed to put "Inner City Pressure" in his head simply by using the word "Sympathises" |
| 14:53 | <TabAtkins> | I really wish I could eliminate links from the internet. Two years later and I'm still dealing with horrifying urls showing in my 404 emails from when the Dev team decided to take a crack at web dev. |
| 14:54 | <erlehmann> | jgraham, this was an early version of it, http://daten.dieweltistgarnichtso.net/src/cc-license-markup/generator2.xhtml |
| 14:54 | <miketaylr> | heh, chromium just barfed on the outline page: http://skitch.com/miketaylr/bh22u/chromium |
| 14:54 | <jgraham> | erlehmann: Oh nice. I was just thinking this morning I could use microdata for marking up license bits |
| 14:54 | <gsnedders|work> | The only time IE creates non-tree DOMs is with misnested formatting elements, right? |
| 14:54 | <erlehmann> | jgraham, you are welcome to spawn more stylesheets. |
| 14:56 | <gsnedders|work> | Do browsers use HTMLDocument for XHTML? |
| 14:56 | <annevk2> | some |
| 14:58 | <hsivonen> | annevk2: which ones don't? |
| 14:58 | <hsivonen> | annevk2: apart from ancient Gecko versions |
| 15:00 | <annevk2> | hsivonen, I don't think Gecko does if the media type is text/xml |
| 15:00 | <hsivonen> | annevk2: ah, OK. |
| 15:01 | <hsivonen> | that's non-compliant with HTML5 |
| 15:01 | <hsivonen> | I wonder if we have a bug about it |
| 15:02 | <TabAtkins> | http://docs.jquery.com/UI/Datepicker#event-beforeShowDay <-- I use this event in several places in my apps, and would find it difficult to switch to <input type=date> without something like it. Anyone think it's got a chance (presumably in v2)? |
| 15:02 | <hsivonen> | hmm. looks like a bug is missing |
| 15:07 | <annevk2> | TabAtkins, yeah, things like that have already been raised |
| 15:07 | <TabAtkins> | K, cool. Couldn't remember seeing anything like that. |
| 15:07 | <TabAtkins> | Was just going through stuff yesterday and seeing how I would replace bits with HTML5. |
| 15:10 | <annevk2> | TabAtkins, might be 2004/2005 discussions |
| 15:11 | <TabAtkins> | Ah, yeah, I definitely wasn't around then. Had just graduated high-school the year before. ^_^ |
| 15:11 | <gsnedders|work> | TabAtkins: Peh! Some of us only graduated high-school in June! :P |
| 15:11 | <TabAtkins> | Whatev. |
| 15:12 | <gsnedders|work> | TabAtkins: You're old, man. |
| 15:12 | <jcranmer> | dang |
| 15:12 | <jcranmer> | I only graduated in 2008 |
| 15:13 | <TabAtkins> | Craps, I am old. I know Anne's a few months younger than me too. |
| 15:13 | <AryehGregor> | I'm the class of 2005 for high school. |
| 15:13 | <AryehGregor> | Whoa, I never realized how young everyone was. |
| 15:13 | <AryehGregor> | I thought I was young. |
| 15:13 | <AryehGregor> | Seems not. :) |
| 15:13 | <hsivonen> | Hixie: Is there a reason to believe that it's Web-compatible to make text/xml documents implement HTMLDocument and SVGDocument? |
| 15:13 | <jcranmer> | I think gsnedders|work wins for youth, though |
| 15:13 | <TabAtkins> | I would agree. |
| 15:14 | <TabAtkins> | othermaciej: Congrats are in order! ::pops the cork on some champagne:: |
| 15:16 | <jcranmer> | I have a feeling display: run-in was specced mostly with dl's in mind |
| 15:16 | <TabAtkins> | They are difficult to style without it sometimes. |
| 15:16 | <TabAtkins> | At least, without a <di> or ::di to hang things on. |
| 15:16 | <annevk2> | hsivonen, Opera does it |
| 15:16 | <annevk2> | hsivonen, iirc |
| 15:16 | <annevk2> | hsivonen, also, who is using text/xml anyway? |
| 15:17 | <jgraham> | You people make me feel so old :( |
| 15:17 | <jcranmer> | I hope bz gets it into FF sometime relatively soon |
| 15:17 | <TabAtkins> | You are old, oldie. |
| 15:17 | <jcranmer> | although the 1.9.2 branch has already been cut IIRC |
| 15:17 | <gsnedders|work> | jgraham: Yeah, well, serves you right for having a birthday cake. |
| 15:17 | <jgraham> | I don't think foregoing the cake would have allowed me to do the Dorian Grey thing |
| 15:18 | <TabAtkins> | Dont' knock it til you try it. |
| 15:18 | <gsnedders|work> | Well, maybe |
| 15:18 | <Creap> | what is the difference between code and samp and why should I use code for file names? in particular, file extensions |
| 15:18 | <AryehGregor> | samp is a silly tag that we only have because there's no active reason to get rid of it. |
| 15:18 | gsnedders|work | shakes his head at jgraham and his b'day cake with its "special ingredient" |
| 15:19 | <AryehGregor> | I just use code all the time, personally. |
| 15:19 | <gsnedders|work> | Creap: In general, don't. |
| 15:19 | <TabAtkins> | Crap, this whole time I've been working around javascript's stupid use of milliseconds for its timestamp. I could have just trimmed the last three digits off at the js level and never had to deal with it leaking into my php code. ;_; |
| 15:19 | <gsnedders|work> | Creap: (Unless you really care.) |
| 15:19 | <Creap> | I'd say a filename is more often output from a program than "input" or "computer code" |
| 15:19 | <Creap> | gsnedders|work: don't what? |
| 15:19 | <gsnedders|work> | Creap: Use either, and ignore it :P |
| 15:20 | <gsnedders|work> | Creap: It avoids the entire debate :) |
| 15:20 | <Creap> | heh.. |
| 15:20 | <Creap> | the specs say I should use code for filenames though |
| 15:20 | <gsnedders|work> | (The elements exist basically just for the people who really care about marking up such things semantically. Nobody in the real world does.) |
| 15:20 | <jgraham> | Creap: Just use <code>. Seriously. No one uses <samp> for anything useful anyway |
| 15:20 | <Creap> | or well, it says code CAN be a filename, but that example is nto included in samp |
| 15:20 | <TabAtkins> | Easy resolution, then: use <code> for filenames. ^_^ |
| 15:21 | <Creap> | ok |
| 15:21 | <Creap> | :P |
| 15:21 | <TabAtkins> | But really, just use <code> everywhere. That's a relic from the time when people thought that someone might actually care about the distinction. |
| 15:21 | <jcranmer> | just byte the bullet |
| 15:21 | <jcranmer> | use <tt> |
| 15:21 | <Creap> | hehe |
| 15:21 | TabAtkins | punkills jcranmer. |
| 15:21 | <jcranmer> | and screw over people who want everything to be semantic |
| 15:22 | <gsnedders|work> | w00t! microdata! |
| 15:22 | <Creap> | I think the distinction between kbd and code for instance can be useful, I could do something like <kbd title="aka Windows / Apple button bla bla">Super</kbd> and kbd[title] { border-bottom:.. |
| 15:23 | <jcranmer> | I think half of the semantic tags won't be used anyways |
| 15:23 | <takkaria> | how is that useful? ^_^ |
| 15:23 | <TabAtkins> | jcranmer: Nah, they'll be used, just for the wrong things. |
| 15:23 | <jcranmer> | since the distinction between several are a bit fine to easily put into WYSIWYG editors |
| 15:23 | <TabAtkins> | <nav><i> is an annoying fairy.</i></nav> |
| 15:24 | <jcranmer> | and people writing HTML by hand won't bother trying to edit each and every single attribute properly |
| 15:24 | <Creap> | takkaria: to add a hint? |
| 15:25 | <hsivonen> | annevk2: filed https://bugzilla.mozilla.org/show_bug.cgi?id=512688 |
| 15:25 | <jcranmer> | I'd rather spend my time worrying about what my content should actually be as opposed to the fiddly semantic meanings of all of these titles, code snippets, etc. |
| 15:26 | <Creap> | Ok, have fun with that and I'll have fun with doing it my way |
| 15:28 | <TabAtkins> | Ah, cool, setting window.search does force a refresh. |
| 15:28 | <annevk2> | hsivonen, hopefully someone fixes it :) |
| 15:59 | <zcorpan> | hsivonen: http://www.w3.org/Bugs/Public/show_bug.cgi?id=7434 is about what to expose for <h2> |
| 16:03 | <hsivonen> | zcorpan: oh ok |
| 16:11 | <gsnedders|work> | Random programming question time: why would perl -i.bak -npe 's/\n{2,}/\n/' foo.txt not work? |
| 16:12 | <jcranmer> | wrong phase of moon |
| 16:13 | <TabAtkins> | I think I'm a bad person for making an <input> look like a button just so I don't have to muck about with getting my datepicker to show/hide manually. |
| 16:13 | <TabAtkins> | To be fair, intranet app. |
| 16:15 | TabAtkins | feels his conscious gnawing at him. |
| 16:15 | TabAtkins | notes s/conscious/conscience/ |
| 16:25 | <webben> | gsnedders|work: I have a feeling that might be processing it line by line, and you wouldn't have two new lines on one line ... |
| 16:25 | <gsnedders|work> | webben: Ah |
| 16:32 | <TabAtkins> | Ah, I feel much better now. Now I'm styling the <label> as a button, and making the <input> invisible. That feels less disgusting. |
| 16:35 | <takkaria> | gsnedders|work: try tacking 'g' on the end? |
| 16:35 | <gsnedders|work> | takkaria: That doesn't fix it |
| 16:35 | <TabAtkins> | Nah, you need the multiline switch. |
| 16:35 | <TabAtkins> | I forget what it is. |
| 16:36 | <gsnedders|work> | No, multiline just makes ^ and $ match start and end of line |
| 16:36 | <TabAtkins> | I thought it did the opposite. |
| 16:36 | <Dashiva> | -i.bak? |
| 16:37 | <TabAtkins> | It's been a while since I've had to use regexps for anything serious. |
| 16:37 | <takkaria> | Dashiva: writes the original file out to $ORIGINAL_NAME.bak |
| 16:37 | <Dashiva> | Typical perl, everyone knows -i is for input |
| 16:39 | <Dashiva> | gsnedders|work: I'd think you need /g in any case. Does the file contain \r\n maybe? |
| 16:39 | <gsnedders|work> | Dashiva: No |
| 16:39 | <gsnedders|work> | Fuck it, I'll just use Brianfuck. That's simpler. |
| 16:39 | <Dashiva> | Why not use sed? :) |
| 16:40 | <gsnedders|work> | (to understand, that is) |
| 16:40 | <TabAtkins> | Sounds reasonable. |
| 16:40 | <gsnedders|work> | Dashiva: You can't read from one file then write back to it |
| 16:40 | <beowulf> | gsnedders|work: /s perhaps |
| 16:40 | <AryehGregor> | Newlines are magical. |
| 17:35 | <jacobolus> | some people may find this useful: http://pastie.textmate.org/595605 |
| 17:36 | <jacobolus> | most javascript implementations of utf-8 encoders/decoders are slow, and also can't incrementally parse, just throwing an error if they get a partial multi-byte character at the end |
| 17:37 | <jacobolus> | this one mostly relies on native functions |
| 17:37 | <jacobolus> | (the idea for which was taken from this awesome observation http://ecmanaut.blogspot.com/2006/07/encoding-decoding-utf8-in-javascript.html ) |
| 17:40 | <jacobolus> | oops, minor fix: http://pastie.textmate.org/595615 |
| 17:47 | <jacobolus> | oh, extra oops; I mixed up encode/decode, like apparently about 25% of the other implementations of this |
| 17:47 | <jacobolus> | better: http://pastie.textmate.org/595629 |
| 17:48 | <hallvors> | love that blogger's user name - ecmanaut :) |
| 18:07 | <webben> | jacobolus: Is the ; at the start to prevent borking when minified JS is concatenated? |
| 18:07 | <jacobolus> | webben: yeah, just being defensive |
| 18:08 | <jacobolus> | webben: I also religiously add semicolons to the end of each statement, even when it would end in a } |
| 18:10 | <jacobolus> | for comparison, here's the almost unspeakably bad piece of code that Orbited was using before to accomplish the same thing: http://pastie.textmate.org/595659 |
| 18:10 | webben | prefers jacobolus's approach ;) |
| 18:11 | <jacobolus> | I'm going to benchmark all the javascript implementations of this I can find in a google search, and write up a blog post |
| 19:05 | <othermaciej> | morning, folks |
| 19:06 | <Hixie> | morning, chair |
| 19:08 | <othermaciej> | *sigh* |
| 19:08 | <annevk3> | you were not planning on being co-chair? |
| 19:11 | <othermaciej> | well obviously they asked me first, so I was expecting it, but it's going to be a lot of work and probably not entirely fun |
| 19:19 | <tantek> | congrats othermaciej on your chairship! wishing you the best of luck. |
| 19:20 | <othermaciej> | tantek: thanks! |
| 19:20 | <Hixie> | i am amused that the html wg now has more chairs than most wgs have active members |
| 19:21 | <othermaciej> | we also have more active members than 10 WGs |
| 19:22 | <gsnedders> | So there are 64 WGs with more active members? :\ |
| 19:22 | Hixie | bops gsnedders on the head |
| 19:23 | gsnedders | falls down into his whole |
| 19:23 | <gsnedders> | *hole |
| 19:23 | <jcranmer> | whole hole? |
| 19:23 | <gsnedders> | jcranmer: I'm not wholly sure |
| 19:24 | <jcranmer> | is that a holy whole hole? |
| 19:24 | <jcranmer> | (mole!) |
| 19:24 | gsnedders | places the holy hand grenade of archigoch in the centre of the channel and walk away |
| 19:24 | jcranmer | leaves |
| 19:25 | <gsnedders> | So him? |
| 19:25 | <jcranmer|NOT_HER> | damn nick length on freenode |
| 19:25 | <jacobolus> | Hixie: oh, you're awake. did you see my comments from the middle of the night? :) |
| 19:26 | <jacobolus> | (vaguely off topic for this channel maybe... or maybe Tetris bots are always on topic) |
| 19:27 | <Hixie> | jacobolus: no, i had some problems with my irc client tonight. what's up? |
| 19:27 | <jacobolus> | Hixie: I like your bot at http://tetrisapp.appspot.com/ |
| 19:27 | <Hixie> | jacobolus: and don't worry, there's no "topic" for this irc channel :-) |
| 19:28 | <annevk3> | othermaciej, maybe you can get the HTML CG more open :) |
| 19:28 | <jacobolus> | I made the graphics for a multiplayer iphone game, & we've been thinking it might be fun to hook up a browser to our server & show games in real time, using some kind of web socket thinger |
| 19:28 | <jacobolus> | Hixie: and anyway, we thought it'd be fun to have a bot competition |
| 19:28 | <othermaciej> | annevk3: I don't even know what the HTML CG is, really |
| 19:28 | <jacobolus> | somewhat like that one, but with the bots competing against each other |
| 19:29 | <jacobolus> | and allowing anyone interested to watch the games in a browser |
| 19:29 | <jacobolus> | so the question is whether you'd potentially be interested in porting your bot if do such a thing, & send out the API to use, etc. |
| 19:29 | <jacobolus> | *if we do... |
| 19:30 | <Hixie> | jacobolus: i don't think i'll have the time to do anything like that anytime soon, to be honest |
| 19:30 | <jacobolus> | Hixie: the game is pretty fun. "Mino", & there's a free "lite" version; the idea would be that people could also watch the games via iPod/iPhone, even in the free version of the app |
| 19:31 | <jacobolus> | okay, no worries. |
| 19:31 | <jacobolus> | Hixie: it just looked like you have a better algo than our current bots |
| 19:31 | <jacobolus> | (which are, frankly, pretty stupid) |
| 19:32 | <jacobolus> | (we match people against bots after 60 seconds if not enough humans are playing) |
| 19:32 | <Hixie> | jacobolus: oh well you can have the code if you want |
| 19:32 | <jacobolus> | oh. that'd also be neat |
| 19:32 | <Hixie> | (it's GPLed, i think) |
| 19:32 | <jacobolus> | did you put it up somewhere? |
| 19:33 | <jacobolus> | how old is this tetrisapp thing? |
| 19:33 | <jacobolus> | I just saw it on news.ycombinator yesterday |
| 19:33 | <Hixie> | a few months, i think |
| 19:33 | <jacobolus> | aha |
| 19:33 | <Hixie> | my bots are timestamped dec 2008 |
| 19:35 | <jacobolus> | Hixie: well if you have a copy or a link or something, I'd be happy to pass them around our team, & see if anyone is inspired to make some better bots in the next couple of days, instead of in a couple weeks :) |
| 19:38 | <Hixie> | http://damowmow.com/playground/tetrisapp/tetrisapp.tar.gz |
| 19:38 | <Hixie> | is a tarball of all the files in that directory |
| 19:38 | <Hixie> | HTH |
| 19:38 | <Lachy> | I don't get the new channel topic. What happened to "Please leave your sense of logic at the door, thanks!"? |
| 19:38 | <jacobolus> | thanks! |
| 19:38 | <Hixie> | aaah, who changed the topic! |
| 19:38 | <Lachy> | annevk3, did apparently |
| 19:39 | <gsnedders> | See translationparty.com |
| 19:39 | <gsnedders> | And put the old topic in :) |
| 19:39 | <jacobolus> | ahahahaha |
| 19:39 | <gsnedders> | But now it doesn't get that any more :( |
| 19:41 | <jacobolus> | gsnedders: you sure you have the exact wording of the old topic the same? |
| 19:41 | <gsnedders> | jacobolus: Google Translate changed. See the footer of the party. |
| 19:41 | <jacobolus> | boo |
| 19:41 | <jacobolus> | did you try babelfish? |
| 19:41 | <jacobolus> | :) |
| 19:41 | <jacobolus> | babelfish korean has always given the most amusing results, in my experience |
| 19:41 | <Lachy> | jacobolus, yes, the topic was the same as that used for the tag line on http://blog.whatwg.org/ |
| 19:42 | <jacobolus> | that is, english -> korean -> english -> etc. |
| 19:46 | <jacobolus> | "Please leave your sense of logic at the door, thanks!" |
| 19:46 | <jacobolus> | "Logic and thanks will wind to the gate, to leave!" |
| 19:46 | <jacobolus> | "With logic as for thanks to the gate, in order to leave to relax!" |
| 19:46 | <jacobolus> | "To the gate regarding a thanks with logic, in order to relax in order to leave!" |
| 19:46 | <jacobolus> | "In order to leave about the thanks which had a logic to the gate, in order to relax!" |
| 19:46 | <jacobolus> | "In order to leave refers to the thanks which had a logic in the gate, in order to relax!" |
| 19:46 | <jacobolus> | "As for the Huaihe woman leaving to the thanks which had the logic which is in the gate, in order to relax refers! where" |
| 19:46 | <jacobolus> | "In order to relax to the thanks which had the logic which in the gate is leaves, or, like the thing and for refers Huaihe women! where To place" |
| 19:46 | <jacobolus> | "Or, having the logic which from the gate for is a leaf to thanks relaxing together refers to Huaihe women! where In order where" |
| 19:46 | <jacobolus> | "Or, rises to the thanks where the leaf relaxes together from the gate to Huaihe women and to be a logic refers! where To place as sequence to place" |
| 19:46 | <jacobolus> | and then it starts to get too long for the apple translation dashboard widget, I think (or at least it seems truncated) |
| 19:46 | <miketaylr> | ^C |
| 19:46 | <jacobolus> | :) |
| 19:46 | <miketaylr> | ;) |
| 19:46 | <jacobolus> | miketaylr: I figured this was amusing enough to be worth it ;) |
| 19:47 | <miketaylr> | jacobolus: i just want to know what a Huaihe woman is. |
| 19:47 | <jacobolus> | me too |
| 19:49 | <Hixie> | Lachy: feel free to change the topic back btw |
| 19:50 | <jacobolus> | since when has blog.whatwg.org had a theme? |
| 19:50 | <jacobolus> | that's much nicer. |
| 19:50 | <Hixie> | a while now |
| 19:50 | <jacobolus> | I guess I just see it in a feed reader |
| 19:54 | Lachy | changes topic to 'WHATWG (HTML5) -- http://www.whatwg.org/ -- Logs: http://krijnhoetmer.nl/irc-logs/ -- Vennligst legg igjen din følelse av logikken ved døren, takk!' |
| 19:55 | <gsnedders> | Oh dear, has Lachy tried writing a language that's not English again? |
| 19:56 | <Lachy> | gsnedders, ja, jeg skrev på norsk |
| 20:01 | <gsnedders> | Anyhow, I need to get to the cinema. |
| 20:05 | <mpilgrim> | i use <samp>, damn it |
| 20:07 | <annevk3> | Hixie, you could consider naming it "URL decomposition DOM attributes" I suppose |
| 20:09 | <annevk3> | what happened to <samp>? |
| 20:11 | <mpilgrim> | nothing |
| 20:11 | <mpilgrim> | just some people dissing it earlier (check the backscroll) |
| 20:21 | <TabAtkins> | I am unreasonably amused by the use of data urls for simple html/css/js examples. |
| 20:36 | <Hixie> | annevk3: yeah, maybe. |
| 20:44 | <annodomini> | Anyone have any quick comments on this idea before I try writing up a more complete and detailed proposal? http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-August/022329.html |
| 20:45 | <annevk3> | what if the inner item is not associated with the outer item? |
| 20:46 | <annodomini> | Don't do that, or associate it with something else using @about? Good question, though, I'll think about that. |
| 20:46 | <TabAtkins> | I like the overall idea, *especially* the simplified JSON parsed out of it. |
| 20:47 | <TabAtkins> | That is much closer to what I'd use to mark up the data in json |
| 20:48 | <annodomini> | Great, so I'm not off base there. The simplified JSON was a big motivation; I didn't like having random type information that seemed like it could conflict with the semantics of the named properties. |
| 20:49 | <TabAtkins> | So nested items are automatically associated with the nearest Microdata ancestor unless @about overrides, right? |
| 20:49 | <annodomini> | Right. |
| 20:50 | <TabAtkins> | The only appreciable difference I can see is that spec Microdata associates it with the nearest @item ancestor, rather than the nearest @itemprop. |
| 20:50 | <TabAtkins> | But yeah, that seems fine. |
| 20:50 | <TabAtkins> | It does make the DOM map intuitively to the data structure, even if you may need to occasionally use more @about than spec-Microdata would require. |
| 20:52 | <annodomini> | Yep. I think a more intuitive DOM map is important; if you're creating good, semantic HTML, that should give you the simplest map. |
| 20:52 | <annodomini> | And if you're doing something strange that doesn't match the HTML structure very well, then you should be explicit with @about |
| 20:53 | <TabAtkins> | Yeah, that just means you have to pepper things with @id, but meh. |
| 20:53 | <annevk3> | maybe you could allow about="" to unassociate it with the outer item |
| 20:53 | <TabAtkins> | And drop immediately to beina top-level item? |
| 20:54 | <annodomini> | annevk3: That could work. |
| 20:54 | <annevk3> | or something like item="standalone org.example.bar" |
| 20:54 | <TabAtkins> | If we were going to do *that*, I'd probably just use another attribute. |
| 20:54 | <TabAtkins> | @standalone |
| 20:54 | <TabAtkins> | @topitem |
| 20:54 | <TabAtkins> | @root? |
| 20:55 | <annevk3> | rootitem or topitem seems clearer |
| 20:55 | <annevk3> | anyway, more details would be good |
| 20:55 | <annodomini> | What details in particular should I concentrate on for my more complete proposal? API, more use case examples, something else? |
| 20:56 | <TabAtkins> | I'd probably take a few examples that appear in the spec, put them as-written into your proposal and contrast them with your structure and output. |
| 20:57 | <annodomini> | I should obviously address the un-associating question, though I think the @about="" or @rootitem ideas sound like pretty plausible solutions. |
| 20:57 | annodomini | nods |
| 20:59 | <TabAtkins> | The major objection I anticipate is the "only leaf nodes can have content directly" bit. |
| 20:59 | <annevk3> | yeah, more examples that demonstrate how your proposal compares to the spec |
| 20:59 | <TabAtkins> | I dunno if it'll be an issue. |
| 21:08 | <MikeSmith> | annodomini: fwiw, I think annevk3 advice about providing more examples would be the best use of time, and would get you more specific response |
| 21:08 | <MikeSmith> | *responses |
| 21:09 | <annodomini> | Er, have I been incorrectly referring to @subject as @about this entire time? Replace all of my uses of @about with @subject in the preceding to match the existing attribute. |
| 21:09 | <annodomini> | MikeSmith: Yeah, I'll write up some more examples and explain how it works. |
| 21:09 | <annevk3> | oh it was renamed? |
| 21:09 | <annodomini> | That does sound like the best use of my time. |
| 21:09 | annevk3 | is not really up to speed |
| 21:10 | <TabAtkins> | Eh, we knew what you meant, annodomini. |
| 21:12 | <annodomini> | TabAtkins: Yeah, everyone here seemed to understand, but I figured I'd clarify for posterity in the logs, if anyone cares. |
| 21:18 | <krijn> | -_- |
| 21:18 | <TabAtkins> | Aw, why is krijn sad? |
| 21:18 | <krijn> | Bit tired after 12 hours working |
| 21:18 | <TabAtkins> | I would imagine. |
| 21:23 | <krijn> | But, very pleased with the results, this HTML5 stuff is quite handy for building sites with :) |
| 21:23 | <TabAtkins> | Heh, cool. |
| 21:23 | <TabAtkins> | What're you having fun with? |
| 21:24 | <krijn> | Basically just the doctype ;) |
| 21:24 | <TabAtkins> | I'm pretty sure that's when I fell in love too. |
| 21:25 | <krijn> | Block level anchors, less silly attributes on script/link, that's about as far as I can go atm |
| 21:26 | <TabAtkins> | If you're willing to shim ie, you can use the new sectioning elements too. |
| 21:26 | <krijn> | I know, but I don't really see the advantage in that just yet |
| 21:26 | <TabAtkins> | They make my page a bit easier to read. |
| 21:26 | <krijn> | And then your code gets mangled by some J2EE backend |
| 21:27 | <krijn> | And out goes your readability :) |
| 21:27 | <TabAtkins> | Luckily don't have to do crap with that. ^_^ All hand-coded php around here. |
| 21:30 | <krijn> | Days like this make me like those other days better indeed, when I don't have to deal with XSLT and non-utf-8 issues |
| 21:30 | <krijn> | So, we're the only two authors here? |
| 21:32 | <MikeSmith> | TabAtkins: if you love HTML5 so much, maybe the two of you should get married |
| 21:32 | <MikeSmith> | or you should send a love note |
| 21:33 | <MikeSmith> | Dear HTML5, I like you. Do you like me? |
| 21:33 | <Dashiva> | TabAtkins: What uses HTML that isn't a user agent? |
| 21:33 | <TabAtkins> | Dashiva: Apparently link-checkers. |
| 21:34 | <TabAtkins> | MikeSmith: I'm already married, unfortunately. ;_; (Don't tell my wife.) |
| 21:35 | <krijn> | TabAtkins: she doesn't know you're already married? |
| 21:36 | <TabAtkins> | krijn: The circumstances were honestly confusing for all involved, and I'd rather not upset her. |
| 21:36 | <TabAtkins> | ^_^ |
| 21:36 | <krijn> | Heh |
| 21:36 | <Dashiva> | TabAtkins: I'd say a link checker is a user agent. Or is user agent just a euphemism for browser now? |
| 21:36 | <TabAtkins> | I'm pretty sure that's the distinction Roy is using. |
| 21:39 | <KevinMarks> | http://www.computerworld.com/s/article/9136919/Web_OS_Still_in_the_early_stages?taxonomyId=16&pageNumber=4 |
| 21:40 | <KevinMarks> | fairly sure I didn't say "On top of HTML5 are REST APIs, standards such as XML and JSON, and OAuth" |
| 21:40 | <othermaciej> | KevinMarks: aren't you now not at Google? |
| 21:40 | <KevinMarks> | yep, not been at google for 2 months |
| 21:40 | <KevinMarks> | this must be a very old conversation |
| 21:41 | <othermaciej> | KevinMarks: that wasn't a direct quote, so maybe instead of "on top of" they meant "in addition to" |
| 21:42 | <billyjackass> | Dashiva: a context-sensitive editing application |
| 21:44 | <KevinMarks> | right, I think I was explaining how these things are composable and work together |
| 21:44 | <KevinMarks> | and build on previous work |
| 21:45 | <KevinMarks> | or maybe he paraphrased it from this: http://epeus.blogspot.com/2008/12/cycling-to-new-layers-of-freedom.html |
| 21:50 | <Hixie> | annodomini: it's an interesting idea, though it basically means removing types altogether, which makes it much harder to scope identifiers |
| 21:50 | <Hixie> | annodomini: for example, say we define a vcard vocabulary, and someone wants to pull out all the vcards. There's no way to do it in your model, as far as I can tell. |
| 21:50 | <annodomini> | Hixie: The idea is that the names are the types. |
| 21:51 | <Hixie> | names and types are different things |
| 21:51 | <Hixie> | say you have an item that represents a book |
| 21:51 | <Hixie> | and the book has two editors and two authors |
| 21:51 | <annodomini> | If you want a vcard vocabulary, you use org.example.vcard or http://example.org/vcard as a type instead. |
| 21:51 | <Hixie> | editors and authors are both vcards |
| 21:51 | <Hixie> | so how would you distinguish the authors and the editors? |
| 21:52 | <annevk3> | <span item=authors> <vcard/> <vcard> </span> <span item=editors> ... </span> maybe? |
| 21:52 | <annodomini> | <div item="book"><div item="editor |
| 21:52 | <TabAtkins> | That's what I was about to suggest, too. |
| 21:53 | <annodomini> | Yeah, that's basically what I was in the middle of typing when I hit return too soon. |
| 21:53 | <Hixie> | in that example, "authors" and "editors" are both items whose type os "list of vcards" |
| 21:53 | <TabAtkins> | Yes...? |
| 21:53 | <Hixie> | so how would you find all the objects whose type is "list of vcards"? |
| 21:54 | <TabAtkins> | Are we reasoning about vocabs here, or can we assume that the tool explicitly knows the vocabs being used? |
| 21:54 | <annodomini> | Walk through the data structure and pull out all everything with item="vcard"? |
| 21:54 | <Hixie> | TabAtkins: we're assuming a tool that doesn't know any vocabs except the ones it wants |
| 21:54 | <TabAtkins> | Then it just walks and finds <vcard>s. |
| 21:55 | <Hixie> | <div item=book> <div item=editors> <div item=vcard> <div item=fn>A Person</div> </div> </div> </div> |
| 21:55 | <Hixie> | vs |
| 21:55 | <TabAtkins> | I don't see how saying the type is "list of vcards" is better than saying the type is "authors" and "editors". |
| 21:55 | <Hixie> | <div item=book> <div itemprop=editor item=vcard> <div itemprop=fn>A Person</div> </div> </div> |
| 21:55 | <TabAtkins> | Yeah, you win a bit on terseness. |
| 21:55 | <Hixie> | TabAtkins: "authors" and "editors" are names, not types |
| 21:56 | <Hixie> | it's like the difference between a variable name and a variabel type |
| 21:56 | <annodomini> | How about <div item=book><div item="editor vcard"><div itemprop=fn>Someone</div></div></div> |
| 21:56 | <TabAtkins> | Hmm, I don't agree with your distinction, Hixie. I'm seeing the element's @id as being more like the var name, with @item being the variable type. |
| 21:57 | <TabAtkins> | The book vocabulary has "authors" and "editors" values. These are types of values. |
| 21:57 | <Hixie> | TabAtkins: id="" doesn't take part in the model we're discussing as far as i'm aware |
| 21:57 | <annevk3> | annodomini, I don't think that's very clear |
| 21:57 | <TabAtkins> | Implicitly with @subject, Hixie. |
| 21:57 | <Hixie> | TabAtkins: yeah, subject="" is a whole other ball game |
| 21:58 | <annevk3> | with subject it's just a linking mechanism |
| 21:58 | <TabAtkins> | Yeah. |
| 21:58 | <TabAtkins> | So, my point is that I don't like the analogy. ^_^ |
| 21:58 | <Hixie> | i'm surprised that this name vs type distinction has caused so much confusion |
| 21:58 | <Hixie> | i really thought it was obvious |
| 21:58 | <Hixie> | but almost everyone who has commented on microdata has been confused about it |
| 21:58 | <TabAtkins> | I think it *is* obvious Hixie. But it can be obviouser. |
| 21:59 | <annevk3> | itemtype/itemprop maybe |
| 21:59 | <TabAtkins> | Well, hrm. Okay, here's the issue. @item has a type. But @itemprop only has a name. That seems arbitrary. |
| 21:59 | <Hixie> | TabAtkins: you disagree with me about what is a name and what is a type, so it's not _that_ obvious :-) (not saying which one of is right, of course) |
| 21:59 | <annodomini> | Hixie: I understand the name vs type distinction, but I think that its an extra layer of complexity that needs to be justified over just using names with types implied by whoever is consuming the data. |
| 21:59 | <Hixie> | annodomini: the need for types comes from the need to unambiguously specify what the property names are |
| 21:59 | <TabAtkins> | I want my properties to have types too. The notion that they can *only* have types when they're actually a chunk of some other vocab is weird. |
| 22:00 | <Hixie> | annodomini: so that a validator can validate vcards found within other vocabularies that it doesn't know about |
| 22:00 | <Hixie> | TabAtkins: in the spec, the types are optional, the names are required. |
| 22:01 | <TabAtkins> | Hixie, a new vocab can use vcard and make this obvious by having an element named whatever it wants, with a child that is a vcard. |
| 22:01 | <annevk3> | TabAtkins, what if you want a property that is named vcard? |
| 22:01 | <Hixie> | annodomini: in the proposals that collapse name and type together, you either lose the ability to have multiple distinct properties with values that have the same type (e.g. editors and authors both being types), or you lose the ability to detect types |
| 22:01 | <annevk3> | I think Hixie is right and that it doesn't really work well |
| 22:02 | <TabAtkins> | Then we have problems, annevk3. |
| 22:02 | <TabAtkins> | Are we scoping prefixes on @item? |
| 22:02 | <Hixie> | TabAtkins: that doesn't work because you have no way to know if an item is a type or a name |
| 22:02 | <TabAtkins> | At least, in a general sense? |
| 22:02 | <annevk3> | there are no prefixes |
| 22:02 | <TabAtkins> | Hixie, I'm not yet convinced that's a useful distinction. |
| 22:02 | <annodomini> | Actually, I would propose that we use URLs or reversed domains for our "top-level" names like vcard |
| 22:03 | <TabAtkins> | annevk3: Then how do you distinguish a vcard from anything else in the current proposal? |
| 22:03 | <Hixie> | TabAtkins: in which proposal? in the spec? |
| 22:03 | <TabAtkins> | Yeah. |
| 22:03 | <Hixie> | TabAtkins: in the spec, property names and item types use separate attributes with no overlap |
| 22:03 | <TabAtkins> | Yeah, so the type of the ancestor @item is implicitly prefixing the @itemprop, right? |
| 22:04 | <Hixie> | no? |
| 22:04 | <annodomini> | So, you would only ever use item="http://example.com/vcard";, and if you used item=vcard (or anything else), it would be assumed that this was defined relative to its ancestor. |
| 22:04 | <TabAtkins> | In a general sense of the word "prefixing". |
| 22:04 | <Hixie> | no more so than an <object> element is "prefixing |
| 22:04 | <Hixie> | " the <param> elements |
| 22:04 | <TabAtkins> | That's the sense I mean, I think. |
| 22:04 | <TabAtkins> | In that the <param> is implicitly assigned to the <object> parent. |
| 22:04 | <Hixie> | if you mean that itemprop="" names are scoped to their item="", then yes |
| 22:05 | <TabAtkins> | K, yes. |
| 22:05 | <TabAtkins> | Now what's wrong the problem with having @itemprop names scoped to their nearest ancestor @itemprop? |
| 22:05 | <annevk3> | but itemprop=foo stays foo and does not become bar.foo or something for an item bar |
| 22:05 | <hober> | but not by string-bashing their names together |
| 22:05 | <Hixie> | annodomini: unless we prevent names from using that syntax also, that doesn't solve the problem |
| 22:05 | <hober> | (what annevk3 said) |
| 22:06 | <Hixie> | TabAtkins: nothing is particularly wrong with that either |
| 22:06 | <annodomini> | Hixie: Can you expand? Unless we prevent what names from using what syntax? |
| 22:06 | <TabAtkins> | annevk3: Well, doesn't it? Multiple vocabs can use "foo" as a name, and it implicitly disambiguates between "foo" being a property of "bar" and "foo" being a property of "baz" by the nearest ancesteor @item, right? |
| 22:07 | <Hixie> | annodomini: <div item="org.example.book"> <div item="com.example.editor"> <div item="net.example.vcard"> </div> </div> </div> -- which are types and which are property names? |
| 22:07 | <TabAtkins> | They're all both? |
| 22:07 | <Hixie> | names and types aren't the same thing |
| 22:07 | <TabAtkins> | And a consumer knows what name/types to look for, and grabs its children too. |
| 22:07 | <annodomini> | Right. Those are all fully qualified names, with whatever types are implicit in the definition of those names. |
| 22:07 | <Hixie> | that's the microformats model |
| 22:07 | <Hixie> | that's exactly what we're trying to move away from here |
| 22:08 | <annodomini> | Hixie: Why are we trying to move away from that? |
| 22:08 | <TabAtkins> | I can't understand the difference. What problem is solved by having two different flavors of name? |
| 22:08 | <annevk3> | TabAtkins, no |
| 22:08 | <Hixie> | because the problem we're trying to solve here is the problem that to parse microformats, the parser needs to know the vocabularies |
| 22:08 | <annevk3> | TabAtkins, afaict that's wrong |
| 22:08 | <Hixie> | TabAtkins: see, i told you you were confused about types :-) |
| 22:09 | <TabAtkins> | Hixie: Bah, fine, you win that point. ^_^ |
| 22:09 | <Hixie> | i think i need to work out a new data model that doesn't use types at all |
| 22:09 | <TabAtkins> | annevk3: Seriously? So names have to be web-global? |
| 22:09 | <annevk3> | TabAtkins, rtfm ;) |
| 22:09 | <Hixie> | though i've no idea how to do that |
| 22:09 | <TabAtkins> | Bah, I can ask you instead. |
| 22:10 | <annevk3> | ok, yes |
| 22:10 | <annodomini> | OK, I suppose I should give some more detail on my proposal, and how I envisioned the parsing and processing to work. |
| 22:11 | <TabAtkins> | Hixie: What I'm seeing right now is that you have two different types of names. One is "name of vocab" and one is "name of property". Is this more-or-less right? |
| 22:11 | <annevk3> | you could I suppose have a thing where reversed DNS/URIs are the types and simple strings are the properties |
| 22:11 | <Hixie> | TabAtkins: yeah |
| 22:11 | <annevk3> | and predefined types would have the form of w3c.vcard or something |
| 22:11 | <Hixie> | TabAtkins: one is "here is what the relationship is between the parent item and this value (string, url, date/time, child item)" |
| 22:12 | <annevk3> | not sure it's very nice and not sure it would be shorter than Microdata |
| 22:12 | <Hixie> | TabAtkins: and the other is "here is what the relationships used in this item mean" |
| 22:12 | <TabAtkins> | Hixie: yeah, what I said. ^_^ |
| 22:13 | <Hixie> | TabAtkins: the key point being that if you don't know what the parent item's vocab is, then, unless you have the type names, you can't work out what the child's vocab is. |
| 22:13 | <Hixie> | maybe that's ok |
| 22:13 | <annodomini> | Right, I was thinking that you would use global, unambiguous names (reverse DNS or URI) at the top levels of new objects, and short names that were considered to be interpreted relative to their item below it. |
| 22:13 | <TabAtkins> | I see your complaint - if you merge the two concepts, then a consumer can find the root of data that it wants, but it can't distinguish between legitimate properties of that data and properties that are part of some other vocab. |
| 22:14 | <TabAtkins> | So compositing might be more difficult? |
| 22:14 | <TabAtkins> | But if you're compositing values, the consumer really has to know what the lower vocabs that appear in its children are anyway. |
| 22:14 | <Hixie> | if you merge the two concepts, a consumer can't find all vcards without knowing all the vocabularies that are in the chain from the top of the document to the vcard |
| 22:16 | <TabAtkins> | Nah, it just finds anything with the property-name "i.am.a.vcard" or whatever. |
| 22:16 | <annodomini> | So, you'd have <div item="org.w3.vcard"><div item="fn">my name</div></div>, and if you wanted to embed a vcard, you'd get: <div item="org.example.book"><div item=author><div item="org.w3.vcard">author name</div></div></div> |
| 22:16 | <annodomini> | Yes, it's an extra level of nesting, but it still provides everything that you need for that use case. |
| 22:16 | <TabAtkins> | The outer vocab has to double-wrap child vocabs, once in its own property and once in the child vocab's root property. |
| 22:16 | <Hixie> | no, that's just wrong |
| 22:17 | <Hixie> | you're again mixing the relationship with the parent with the definition of the relationships of the children |
| 22:17 | <TabAtkins> | Tell me how annodomini's example is ambiguous, then. |
| 22:17 | <Hixie> | either the value of item="" says what the relationship is to the parent, or it says what the children mean, or it always does both |
| 22:17 | <Hixie> | but it can't sometimes do one and sometimes do the other |
| 22:17 | <TabAtkins> | Or how a consumer would need to know about org.example.book to find the org.w3.vcard |
| 22:18 | <annevk3> | Hixie, it's overloading item |
| 22:18 | <Hixie> | exactly |
| 22:18 | <TabAtkins> | Exactly. |
| 22:18 | <annevk3> | Hixie, when it contains a . it's the type and otherwise it's a name |
| 22:18 | <Hixie> | what is the relationship between the item with item=author, and the item with item=org.w3.vcard? |
| 22:18 | <annevk3> | Hixie, certainly possible, not sure whether it's elegant |
| 22:18 | <Hixie> | it's Wrong |
| 22:18 | <Hixie> | capital W |
| 22:18 | <TabAtkins> | Hixie, that's up to the org.example.book vocab to define. |
| 22:19 | <Hixie> | it's worse than perl having variables prefixed by their type sigil |
| 22:19 | <hober> | TabAtkins: that's the problem |
| 22:19 | <Hixie> | what hober said |
| 22:19 | <annevk3> | Hixie, I think author would be the property and vcard it's type |
| 22:19 | <hober> | TabAtkins: you need to know org.example.book to parse in such a case |
| 22:19 | <Hixie> | annevk3: then we're not making things simpler |
| 22:19 | <Hixie> | annevk3: i don't think that's what they're proposing |
| 22:19 | <annodomini> | No, you don't need to know org.example.book to parse it. |
| 22:19 | <TabAtkins> | hober: if you want to parse the book vocab, yes. |
| 22:19 | <TabAtkins> | It's not necessary if you just want to find vcards. |
| 22:19 | <annodomini> | You only need that to figure out how the vcard relates to the book. |
| 22:20 | TabAtkins | nods at annodomini |
| 22:20 | <hober> | ... which is the problem |
| 22:20 | <annodomini> | No, that's not the problem. |
| 22:20 | <TabAtkins> | ...? |
| 22:20 | <annevk3> | Hixie, I think TabAtkins is confused and annodomini and I agree, but I could be wrong :) |
| 22:20 | <TabAtkins> | Why do you need to know *anything* about how the vcard relates to the book, *if you're not trying to parse the book*? |
| 22:20 | <annevk3> | Hixie, I'm not sure whether it's simpler |
| 22:20 | <Hixie> | TabAtkins: if you are trying to parse the book, what is the relationship? |
| 22:20 | <TabAtkins> | If you just care about the vcard, there you go. There's a vcard. Go get it. |
| 22:21 | <Hixie> | what if you're parsing the book? |
| 22:21 | <TabAtkins> | Hixie: if you're trying to parse the book, what's the relationship between "book" and "author"? |
| 22:21 | <hober> | the idea is to have a generic parser. this is the case where microdata and rdfa share an architectural principle and microformats don't |
| 22:21 | <TabAtkins> | That's up to the book vocab to define. |
| 22:21 | <annodomini> | hober: You can still have a generic parser. |
| 22:21 | <annodomini> | There |
| 22:21 | <TabAtkins> | The one failure is that you can't look at a page and say "these are the vocabs I've found". |
| 22:21 | <Hixie> | TabAtkins: the book vocab would define that "author" is the item that is the author of the book |
| 22:21 | <annodomini> | There's nothing non-generic about what I've proposed. |
| 22:22 | <annevk3> | TabAtkins, you can, you don't understand his proposal :/ |
| 22:22 | <TabAtkins> | And the book vocab can then define that the contents of "author" are the deteails about the author. |
| 22:22 | <Hixie> | TabAtkins: but the book vocab can't define what org.w3.vcard means, if you're saying that org.w3.vcard defines its own vocab |
| 22:22 | <TabAtkins> | Hixie: It doesn't need to define what org.w3.vcard means. All it cares is that it has a property, and that property is the author's details. |
| 22:22 | annevk3 | bows out of this discussion as it's way too confused to be useful |
| 22:22 | <Hixie> | (i'm looking into speccing this idea, and i've come across a much bigger problem, btw, which iirc was mentioned in the original e-mail on this -- to work out the value of a property, you have to examine all the descendants elements.) |
| 22:22 | <TabAtkins> | The fact that the author's details are encoded in a vcard are irrelevant to the book. |
| 22:23 | <Hixie> | TabAtkins: what is the relationship between the item with item=org.w3.vcard and the item with item=author? |
| 22:23 | <TabAtkins> | Implicit child in the data tree? |
| 22:24 | <Hixie> | which vocabulary defines that? book, or vcard? |
| 22:24 | <annodomini> | Book would define that. |
| 22:24 | <Hixie> | so book is defining the meaning of vcard's own identifier? |
| 22:24 | <TabAtkins> | Neither. Why does either need to? And how does the current spec resolve this? |
| 22:24 | <Hixie> | TabAtkins: the current spec never mixes types and names |
| 22:24 | <annodomini> | It would define how a vcard relates to the author. How to interpret a vcard as an author. |
| 22:25 | <TabAtkins> | There is a fundamental point that we're talking past each other on. >_< |
| 22:25 | <Hixie> | TabAtkins: so you have one attribute to specify the relationship, and another to define the type |
| 22:25 | <TabAtkins> | annodomini: I'm thinking more that book would say "the 'author' property is the author" and leave it at that. You can then encode it with vcard if you wish, or use another vocab or none at all. |
| 22:25 | <annodomini> | Hixie: But why do you need to define the type? Why can't the type be implicit in the name of the relationship, and specified in the definition of the format that you're talking about. |
| 22:26 | <TabAtkins> | If you're consuming a book and don't know about vcards, you'll just say that the value of author is the dom contents of that element. |
| 22:26 | <Hixie> | annodomini: it can, if we're willing to throw away the ability to validate the parts of unknown vocabularies that reuse known vocabularies |
| 22:26 | <TabAtkins> | But having the book vocab say "the 'author' property encodes the author's details in a 'vcard'". |
| 22:27 | <TabAtkins> | Hixie: Why do you lose that ability, though? |
| 22:27 | <Hixie> | i don't know how to explain this any better than i already have |
| 22:27 | <annodomini> | Well, if you use item="org.w3.vcard", then everything about that vcard can be validated. |
| 22:27 | <TabAtkins> | You see a property named org.w3.vcard. It's a vcard. this is a global name. |
| 22:27 | <TabAtkins> | Is the problem that "book" can define a property named "org.w3.vcard" as well, so you're never sure if you're looking at a vocab root or just some arbitrary unknown property? |
| 22:27 | <Hixie> | what you're suggesting is equivalent to having typed structures defined like this: |
| 22:28 | <annodomini> | The only part that can't be validated is that a org.example.book's author property should be a vcard, which if you don't know anything about org.example.book, you can't really validate anyhow. |
| 22:29 | <Hixie> | "person is a record. it has values "age" and "address". "age" has a value "integer". "integer" has a value 28. "address" has a value "vCard geo record". "vCard geo record" has a value "123 Any Street"." |
| 22:29 | <TabAtkins> | Is that last one supposed to be three different types at the same time? |
| 22:29 | <Hixie> | s/vcard geo record/address record/ |
| 22:30 | <Hixie> | or s/.../string/ |
| 22:30 | <TabAtkins> | kk. |
| 22:30 | <Hixie> | my point is that you're saying "age has a value integer, integer has a value 28" |
| 22:30 | <Hixie> | which is compeltely bogus |
| 22:30 | <TabAtkins> | Hrm? |
| 22:31 | <TabAtkins> | <div item="person"><span item="age><span item="integer">28</span></span>...</div>? |
| 22:31 | <Hixie> | right |
| 22:31 | <TabAtkins> | Why would I be defining a data model like that? |
| 22:31 | <Hixie> | it's what you're doing! |
| 22:31 | <TabAtkins> | Only if you need to know the type of arbitrary unknown vocab properties. |
| 22:31 | <Hixie> | except s/age/author/ and s/integer/vcard/ |
| 22:31 | <Hixie> | a vcard doesn't have a value |
| 22:31 | <TabAtkins> | In practice, "person" knows that "age" is an integer, so that gets omitted. Consumers of "person" also know this. |
| 22:31 | <Hixie> | an integer doesn't have a value |
| 22:31 | <Hixie> | a vcard IS a value |
| 22:31 | <Hixie> | an integer IS a value |
| 22:32 | <TabAtkins> | Oh, I see what you're saying. |
| 22:32 | <TabAtkins> | Dont' think it's necessary to maintain that sort of purity, though. |
| 22:33 | <Hixie> | anyway all this is academic |
| 22:33 | <annodomini> | So, how about this proposal then: only have item, with a value required to name it, and itemtype as an optional value, that is implicit if it is defined in terms of the ancestor item or type? |
| 22:33 | <Hixie> | the problem with having to look at all descendants is a much bigger issue |
| 22:33 | <TabAtkins> | You mean because you can't tell when someone's scoped a new vocab so you can stop looking for the current vocab's properties? |
| 22:34 | <annodomini> | Hixie: Is that a big issue? |
| 22:34 | <Hixie> | i mean because <div item=test> ... (23 mb of text) ... </div> should not require you to scan the entire DOM just to work out if you should be returning a string or an object |
| 22:34 | <annevk3> | Hixie, looking at itemprop the one thing that seems a bit dangerous is allowing it to use the same space as predefined items |
| 22:35 | <Hixie> | annevk3: yeah, i think that's a blocker, sadly |
| 22:35 | <Hixie> | annevk3: hm? |
| 22:35 | <annodomini> | Hixie: Hmm. Yeah, that is a bit of a problem. |
| 22:35 | <annevk3> | Hixie, oh sorry, predefined global property name |
| 22:36 | <Hixie> | annevk3: yeah, that's a danger |
| 22:36 | <annevk3> | Hixie, that won't scale very well |
| 22:36 | <Hixie> | annevk3: i don't know that we'll ever add any to that list, though (assuming we keep this model at all) |
| 22:36 | <TabAtkins> | Hixie: Ah, I see what you're talking about with that now. |
| 22:36 | <Hixie> | hm, this problem sucks |
| 22:36 | <TabAtkins> | When doing generic scanning, right? So you don't know if item="test" is supposed to have an object for children or not? |
| 22:37 | <Hixie> | TabAtkins: whether it's supposed to or not doesn't really matter |
| 22:37 | <Hixie> | it also means you can't model a property whose value is an item with no properties |
| 22:37 | <Hixie> | though that's not a biggie |
| 22:37 | <TabAtkins> | Not without double-wrapping, sure. |
| 22:38 | <Hixie> | double wrapping? |
| 22:38 | <Hixie> | you can't do it whatever you do as far as i can tell |
| 22:38 | <annodomini> | Hixie: Wh would you want an item with no properties? |
| 22:39 | <TabAtkins> | Or, hrm. If "org.example.book" says that "author" has to have a "org.w3.vcard" child, and that node has no properties... |
| 22:39 | <Hixie> | annodomini: you wouldn't want it, necessarily, but you might run into it e.g. while filling in an incomplete page |
| 22:39 | <annodomini> | Can't you represent the same thing by just not having the item in the first place? |
| 22:39 | <TabAtkins> | Blar, what I meant to say is that if the <div item="author"> *doesn't* have a <div item="org.w3.vcard"> child, then it would return a vcard with no properties. |
| 22:39 | <Hixie> | annodomini: or e.g. in automatically generated content |
| 22:40 | <Hixie> | annodomini: typically in a template generator you don't know if you have any data when you generate the outer part |
| 22:40 | <Hixie> | TabAtkins: no, it would return a string |
| 22:40 | <TabAtkins> | Hmm, yes, if processed generically with no knowledge of the org.example.book vocab. |
| 22:41 | <TabAtkins> | Is it wrong for a parser with knowledge of the book vocab to parse differently? |
| 22:41 | <Hixie> | yes |
| 22:41 | <TabAtkins> | Or, to move the problem to another level, for a consumer of generically-parsed data to know that a string is, in this case, an object with no properties? |
| 22:41 | <Hixie> | the whole point is that the result is unambiguous |
| 22:41 | <annodomini> | We generally want to be able to use the same parser no matter the vocab, and just leave the interpretation of the data to something that knows about the vocab. |
| 22:42 | <TabAtkins> | Yeah, so is it cool for a downstream tool to interpret a string as an object with no properties? |
| 22:42 | <annodomini> | This is actually a bigger problem for me than the issue of not having types or using names that have implicit types. |
| 22:42 | <annodomini> | You could do that, but that just feels wrong to me. |
| 22:43 | <Hixie> | it also makes the code to handle it much harder |
| 22:43 | <Hixie> | cos now instead of just saying "if it's not an item, fail", you have to explicitly look for it and handle it differently |
| 22:43 | <Hixie> | it also makes it much harder to detect actual errors |
| 22:44 | <Hixie> | and means that you can't easily have properties that take either a string or an item |
| 22:44 | <TabAtkins> | That is true - you'd have to have properties be one or the other. |
| 22:44 | <TabAtkins> | Unless you wanted to differentiate based on the contents of the string, which *is* horrifying. |
| 22:45 | <annodomini> | OK, thanks for the feedback, Hixie. |
| 22:45 | <Hixie> | thanks for your feedback too |
| 22:45 | annodomini | goes back to the drawing board |
| 22:45 | <Hixie> | i'm working on a third variant |
| 22:45 | <Hixie> | that uses some of your ideas |
| 22:46 | <annodomini> | Great! I like variants. I'm going to try and come up with another variant, too, but I'll need to work on it some more. |
| 22:46 | <annodomini> | But I'm going to withdraw my proposal in its current form; you're right that there are too many problems. |
| 22:47 | <annevk3> | Hixie, is the second alternative online already? |
| 22:47 | <Hixie> | http://www.whatwg.org/specs/web-apps/current-work/temp |
| 22:48 | <Hixie> | just examples so far |
| 22:52 | <Hixie> | ok my third variant just turned into my second as i fixed problems with it |
| 22:52 | <Hixie> | that's no good |
| 22:53 | <annevk3> | the first still seems the most attractive |
| 22:57 | <annevk3> | except for subject="" which should get a name that's more aligned with the rest or vice versa |
| 22:58 | <TabAtkins> | itemparent? |
| 22:58 | <TabAtkins> | Or, no, since it refers to itemprops. itempropsubject! Woo! |
| 22:58 | <hober> | masteritem="" |
| 22:59 | <Hixie> | itemfor="" |
| 22:59 | <TabAtkins> | ... |
| 22:59 | <TabAtkins> | That's the one I like. |
| 22:59 | <TabAtkins> | @itemfor 4 life. |
| 22:59 | <annevk3> | Hixie, ja :) |
| 23:00 | <Hixie> | what should it point back to, though? an id="", or the value of item=""? with item="" replacing itemprop=about? |
| 23:00 | <TabAtkins> | And that's why Hixie writes the specs. |
| 23:00 | <TabAtkins> | Surely it can't point back to the item type, can it? It's meant to associate things that aren't DOM children of the @item. |
| 23:00 | <TabAtkins> | And there may be many items of that type on the page. |
| 23:00 | <annevk3> | Hixie, id I think, not every item has an about |
| 23:01 | <Hixie> | sorry, i'm thinking out loud. In the variant I'm doing now, there's no type |
| 23:01 | <TabAtkins> | Ok. Well, my vote is cast for @id anyway, just for consistency with @for. |
| 23:02 | <Hixie> | i prefer id="" also |
| 23:02 | <Hixie> | but for these variants let's try something else |
| 23:02 | <Hixie> | that way we can see in the studies which is better |
| 23:02 | TabAtkins | wishes *so hard* that Template Layout was ready already. He can't bring himself to fake this into a table, and he hates rearranging data just to fit arcane display requirements. |
| 23:02 | <annevk3> | itemrel is also somewhat nicer than itemprop |
| 23:03 | <annevk3> | TabAtkins, feel free to solve all the issues with flexbox so we can implement it and Gecko/WebKit can fix their bugs :) |
| 23:04 | <TabAtkins> | annevk3, maybe I will. Point me to all the issues. ^^; |
| 23:04 | <annevk3> | TabAtkins, the idea is that you figure them out on your own by writing lots of tests etc. |
| 23:05 | <TabAtkins> | Hm, k. |
| 23:05 | <annevk3> | TabAtkins, then you edit the spec based on your experience and understanding of the rest of the CSS model |
| 23:05 | <annevk3> | that's how e.g. Hixie wrote the parser algorithm and how I edit the XHR spec |
| 23:05 | <Hixie> | it's a lot of work :-P |
| 23:05 | <TabAtkins> | So, start recoding pages using FF/Safari's implementations, finding where they break, and where the spec simply fails my needs? |
| 23:06 | <annevk3> | TabAtkins, for starters you could figure out the interaction with the box model :) |
| 23:06 | <TabAtkins> | Sounds like a project to start this weekend. |
| 23:07 | <annevk3> | TabAtkins, warning though, it's probably too complicated |
| 23:07 | <TabAtkins> | In general, or for me specifically? |
| 23:07 | <annevk3> | for most people, just like the CSS table model still isn't documented |
| 23:08 | <TabAtkins> | kk |
| 23:08 | <TabAtkins> | We'll just have to see if I can aspie something out of it. |
| 23:10 | <Hixie> | frankly for flexbox i would start with use cases and invent a new technology from scratch |
| 23:10 | <Hixie> | i don't think flexbox is powerful enough, and i think it's too complicated |
| 23:10 | <TabAtkins> | It would be best to get with someone who's done a good bit of XUL editting. |
| 23:11 | <annevk3> | Hixie, it does have two impl going for it, but I do not know enough about layout I suppose to really know |
| 23:12 | <Hixie> | http://www.whatwg.org/specs/web-apps/current-work/temp now has three variants |
| 23:12 | <TabAtkins> | I've had several cases where flexbox as written would have been very useful, but I won't put it out of possibility that a different design would have served equally well in those cases. |
| 23:12 | <TabAtkins> | Wait, though, how'd we get on flexbox anyway? I was talking sexy Template Layout. |
| 23:15 | <othermaciej> | flexbox seems powerful enough to do a lot of the kind of layout native apps like to do, but which is awkward in CSS |
| 23:15 | <othermaciej> | the interface to it is admittedly somewhat awkward |
| 23:15 | <annevk3> | Hixie, what about <x itemrel="foo bar" item> ? |
| 23:15 | <Hixie> | what about it? |
| 23:16 | <annevk3> | Hixie, oh, I guess that's the same as item="foo bar" |
| 23:16 | <othermaciej> | if Template Layout is still ASCII Art Layout, then I think it's kind of lame and not suitable for any application that would have to update the layout dynamically |
| 23:16 | <Hixie> | annevk3: hm? |
| 23:16 | <othermaciej> | (you can't expect apps to do that by making new ASCII art on the fly) |
| 23:16 | <TabAtkins> | othermaciej: Yeah, it's no good for dynamic layouts. But it's ridiculously good for pre-known layouts. |
| 23:16 | <annevk3> | Hixie, I thought item="" in 1 was restricted to a single token and that therefore in 3 a similar restriction would have to be placed on itemrel in case item was present... |
| 23:17 | <Hixie> | annevk3: oh, yeah, i should mention that explicitly |
| 23:18 | <othermaciej> | TabAtkins: it would be nice to have something clean for pre-known layouts that scales naturally to the dynamic case |
| 23:19 | <annevk3> | Hixie, but basically these are all the same idea, just a slightly different syntax |
| 23:19 | <annevk3> | I personally still like 1, but maybe with some naming inspired by 3 |
| 23:19 | <othermaciej> | TabAtkins, annevk3: one annoying problem with flexbox is that it requires you to do layout twice in some cases (hyatt understands the details better than me) |
| 23:19 | <TabAtkins> | othermaciej: Yeah, right now you have to make a known template, then nest a different layout mode inside the cell. Either another template, or a flexbox, or somthing else. |
| 23:19 | <TabAtkins> | Hmm, I'll ping Hyatt about that. |
| 23:19 | <annevk3> | othermaciej, and there's no 2d-flexbox |
| 23:20 | <TabAtkins> | Man, I have difficulty imagining how that would work. |
| 23:20 | <TabAtkins> | In terms of the current flexbox, at least. |
| 23:20 | <Hixie> | annevk3: more or less, yeah |
| 23:20 | <annevk3> | there was this idea for table-layout:flexbox |
| 23:20 | <annevk3> | but we'd actually have to define table layout first :-o |
| 23:21 | <othermaciej> | annevk3: you can do most things that app-style layouts need with nested horizontal and vertical flexboxes |
| 23:21 | <othermaciej> | (that's basically the main thing Gtk is based on, for instance) |
| 23:21 | <othermaciej> | Cocoa has the spring/strut model instead, which may be easier to understand but which I think is less powerful for adaptive flexible layouts |
| 23:22 | <othermaciej> | but yeah, hyatt has raised the idea of enhancing table layout for 2d grid type cases |
| 23:22 | <annevk3> | as I understand it Gecko has some grid internals as well |
| 23:22 | <othermaciej> | XUL has grid stuff of some kind |
| 23:22 | <TabAtkins> | Is that sort of like what I and other were talking about last time Template Layout was tossed around on the list? I think when the dude brought up Matrix Layout? |
| 23:23 | <TabAtkins> | Basically almost floating things to table cells? |
| 23:23 | <annevk3> | that discussion might have gone past me |
| 23:23 | <annevk3> | too much noise on www-style |
| 23:23 | <TabAtkins> | Sorry; I tend to generate a lot of noise when I get interested in a topic. |
| 23:24 | <TabAtkins> | And almost treat the list like a chat. |
| 23:25 | <annevk3> | for instance I have not read the gradient email apart from a few of the initial ones by dbaron and dhyatt |
| 23:30 | <gsnedders> | LOL @ "This Summer in HTML %" |
| 23:30 | <gsnedders> | *5 |
| 23:33 | <TabAtkins> | annevk3: You didn't miss a whole lot, unless you design with gradients a lot and find the exact syntax used for them to be of earth-shaking importance. |
| 23:45 | othermaciej | was surprised at how many people did find the gradient syntax to be of earth-shaking importance |
| 23:47 | <TabAtkins> | Hey, it's just complex and new enough to be interesting, and just simple enough to bikeshed the hell out of. |
| 23:50 | <Lachy_> | Hixie, I really dislike the webdatabase API! The arguments parameter in the executeSql() function is too easy to accidentially omit when you have no need for passing extra arguments, but still want to have success and error callbacks |
| 23:51 | <hober> | makes you pine for keyword arguments à la lisp or python |
| 23:52 | <TabAtkins> | jQuery usually handles that sort of thing by simply letting you omit it, when the argument types allow reliable disambiguation. |
| 23:52 | <Lachy> | in fact, I find the whole API to be overly complex and insane to use and wish we had thrown it out. But oh well, too late now I guess |
| 23:52 | <TabAtkins> | Or just folds them all into an object and names them. |
