| 00:21 | <adiabatic> | Occasionally I have fairly mundane questions about how, say, <form> elements (ought to) work or whether <hgroup><h2>…</h2><h1>…</h1></hgroup> is OK. Which location of "the HTML5 spec" should I use? |
| 00:22 | <adiabatic> | AFAICT there's at least one WHATWG one and more than one on w3.org |
| 00:47 | <kennyluck> | adiabatic, for the latter question you usually look up the content model of each element definition. |
| 00:47 | <kennyluck> | For the former, it depends on what you are looking for, I guess. |
| 00:47 | <kennyluck> | s/content model/content model entry/ |
| 00:48 | <adiabatic> | sure, but on http://developers.whatwg.org/ or http://www.whatwg.org/specs/web-apps/current-work/multipage/ or http://www.w3.org/TR/html5/ or http://dev.w3.org/html5/spec/Overview.html or…? :D |
| 00:49 | <Philip`> | adiabatic: http://www.whatwg.org/specs/web-apps/current-work/multipage/ is the most complete and the most up-to-date |
| 00:50 | <kennyluck> | not the third one. But the others are pretty much similar in terms of content model, last I check. |
| 00:50 | <Philip`> | (Well, http://www.whatwg.org/specs/web-apps/current-work/ is more up-to-date but is too enormous) |
| 00:51 | <Philip`> | The developers one is intentionally incomplete and non-normative, but if you just want to know what is defined as valid syntax then it should suffice and is probably the easiest to read |
| 00:51 | <adiabatic> | I've never been a fan of it, myself. I know how to skim stuff that isn't for me. |
| 00:52 | <Philip`> | The ones on w3.org have various changes and omissions, listed in http://www.whatwg.org/specs/web-apps/current-work/multipage/introduction.html#how-do-the-whatwg-and-w3c-specifications-differ? |
| 00:53 | <Philip`> | Everything on w3.org/TR/ is generally hopelessly out of date and full of known bugs and has no value |
| 00:53 | <Philip`> | But the most important factor is what colour you prefer to read the spec in |
| 00:54 | <adiabatic> | Any huge spec bugs that you can name off the top of your head that I can use to dissuade others from using the w3.org one? |
| 00:54 | adiabatic | reads |
| 00:54 | <Philip`> | See also: http://wiki.whatwg.org/wiki/FAQ#What_are_the_various_versions_of_the_spec.3F |
| 00:54 | <Philip`> | The TR/ one, or the dev.w3.org one? |
| 00:55 | <adiabatic> | so: /TR/: old, dev.: less old? |
| 00:57 | <Philip`> | TR/html5 says it's 25 May 2011, which is ancient - there's been about a thousand edits since then (judging by http://html5.org/tools/web-apps-tracker) |
| 00:57 | <kennyluck> | dev.w3.org is not old I think. |
| 00:58 | <kennyluck> | At one time it was actually newer. That's was when the multipage version on whatwg.org was down. |
| 00:58 | <Philip`> | dev.w3.org is automatically updated after every commit, so it's about as up-to-date as the whatwg.org copies, when the build scripts aren't broken |
| 00:59 | <Philip`> | and when nobody has manually merged changes into the dev.w3.org copy because of HTML WG politics |
| 01:00 | <Philip`> | I think it's generally safe enough to use either the dev.w3.org or the whatwg.org copies, and doesn't make much difference for most people |
| 01:03 | <Philip`> | Oh, except that the dev.w3.org one omits stuff like the canvas 2D context and microdata and sticks them into separate documents, so it's harder to find features you're looking for |
| 01:04 | <Philip`> | You could choose to get overwhelmed by the complexity and just get everything from w3schools.com, I suppose |
| 01:04 | <adiabatic> | Funny man. |
| 03:57 | <heycam> | hsivonen, playing around with the the validator.nu live dom parser, I'm wondering what determines whether a given opening tag breaks out of SVG content |
| 03:58 | <heycam> | hsivonen, for example if I write <p><svg><canvas> that makes an svg:canvas element a child of the svg, but if I write <p><svg><span> then it creates an html:span as a child of the p |
| 04:02 | <MikeSmith> | heycam: http://hg.mozilla.org/projects/htmlparser/file/default/src/nu/validator/htmlparser/impl/TreeBuilder.java#l1555 |
| 04:03 | <MikeSmith> | ah wait |
| 04:03 | <MikeSmith> | that's for mathml |
| 04:03 | <heycam> | or svg maybe? |
| 04:03 | <heycam> | at the end of the big if condition |
| 04:04 | <MikeSmith> | ah yeah |
| 04:04 | <MikeSmith> | it's for both |
| 04:04 | <heycam> | do you know what in the spec defines these particular elements as breaking out? are they all particular classes of elements? |
| 04:06 | <MikeSmith> | http://dev.w3.org/html5/spec/tree-construction.html#parsing-main-inforeign |
| 04:07 | <heycam> | ok |
| 04:07 | <heycam> | thanks. though I wonder why that particular list. |
| 04:07 | <manu1> | hsivonen, MikeSmith: I've escalated your bug against HTML+RDFa to a Last Call comment for RDFa Core 1.1 and RDFa Lite 1.1 - https://www.w3.org/2010/02/rdfa/track/issues/130 |
| 04:07 | <MikeSmith> | manu1: hey |
| 04:08 | <MikeSmith> | manu1: thanks |
| 04:08 | <manu1> | np, just want to make sure it gets visibility in front of the entire WG (and some sort of sooner-than-later resolution) before we move forward. |
| 04:08 | <MikeSmith> | that's actually Henri's bug, I just +1ed it |
| 04:08 | <MikeSmith> | manu1: I appreciate it |
| 04:08 | manu1 | nods. |
| 04:09 | <manu1> | I think we can do what you want... making HTML+RDFa Lite the default mode for the validator (HTML+RDFa Lite didn't intend to allow @href and @rel and @rev everywhere) |
| 04:10 | <MikeSmith> | that would be great |
| 04:11 | <manu1> | so, I think we can achieve what you hoped for in HTML+RDFa Lite 1.1... I think the WG will have a bigger issue w/ not allowing @rel and @rev and @href to be used on any element... it's worked that way for a long time and there are just some types of markup that you cannot do unless you allow @rel and @rev everywhere. We may be able to remove the @href everywhere rule, but that would trigger... |
| 04:11 | <manu1> | ...all sorts of b/c issues that are not in our charter. |
| 04:11 | <MikeSmith> | I see |
| 04:11 | <manu1> | (note, this only applies to RDFa 1.1 "Full") |
| 04:11 | <MikeSmith> | yup |
| 04:12 | <manu1> | Henri did say that he will most likely file a formal objection if we take that route... so... we're between a rock and a hard place here... |
| 04:12 | <manu1> | we remove it, we create b/c issues... we don't remove it Henri files a FO |
| 04:13 | <manu1> | I was thinking that we could add text to say that, even in HTML+RDFa 1.1 Full, that validation /warnings/ could be spit out when you use @href or @rel or @rev in places where it's not traditionally allowed. |
| 04:14 | <MikeSmith> | That's worth considering |
| 04:14 | <manu1> | so, people may shy away from doing that unless absolutely necessary... but I don't think the WG will go for complete removal of @href/@rel/@rev everywhere (for the reasons stated previously) |
| 04:15 | <MikeSmith> | actually it's the same problem for src too |
| 04:15 | <MikeSmith> | I see now that Henri didn't mention that in the title of the bug |
| 04:15 | <manu1> | I don't think @src is allowed anywhere that it wasn't traditionally allowed (that was the intent anyway) |
| 04:15 | <MikeSmith> | but it is listed in the description |
| 04:15 | <MikeSmith> | really? |
| 04:15 | <MikeSmith> | if so, that's not clear in the spec |
| 04:16 | <manu1> | @src isn't in the same "allowed anywhere" category as @href, @rel and @rev ... that it's not clear in the spec is my bad... I'll try to clarify that further. |
| 04:16 | <MikeSmith> | OK |
| 04:16 | <manu1> | (or rather, in RDFa Core) |
| 04:16 | <MikeSmith> | that would help some |
| 04:16 | <MikeSmith> | I interpreted the current HTML+RDFa spec the same as Henri did |
| 04:17 | <MikeSmith> | "it's safe to guess that the above-quoted text tries to add attributes to all elements" |
| 04:17 | <MikeSmith> | and that's the way I implemented it in the validator schema |
| 04:17 | manu1 | raises another bug for this one. |
| 04:17 | <MikeSmith> | thanks :) |
| 04:19 | <MikeSmith> | manu1: I don't see that the b/c argument is a strong one |
| 04:19 | <MikeSmith> | iirc those were added to the spec relatively recently in its lifecycle |
| 04:20 | <MikeSmith> | they weren't in RDFa 1.0, right? |
| 04:21 | <manu1> | They were in RDFa 1.0: http://www.w3.org/TR/rdfa-syntax/#rdfa-attributes |
| 04:21 | <MikeSmith> | oh |
| 04:21 | <MikeSmith> | yeah, just found that now |
| 04:22 | <MikeSmith> | well I guess that make the b/c argument stronger |
| 04:22 | <manu1> | We could argue that HTML+RDFa was never defined, so there isn't a b/c argument there... |
| 04:23 | <manu1> | /however/ people have stuffed RDFa into HTML documents (non-XHTML) ... |
| 04:23 | <manu1> | the counter-argument to that is that there may not be that many of those documents out there... |
| 04:23 | <MikeSmith> | yeah |
| 04:24 | <manu1> | the counter-counter argument to that is: Yeah, but then you're talking about XHTML and HTML supporting a different subset of RDFa attributes... in XHTML you support @href/@rel/@rev everywhere, in HTML you don't. |
| 04:24 | <manu1> | and that may be even more confusing to people than being consistent. |
| 04:24 | <MikeSmith> | right, that would be odd |
| 04:24 | <MikeSmith> | so they should be removed from XHTML also :-) |
| 04:24 | <manu1> | and then we have the whole b/c argument again :) |
| 04:26 | <MikeSmith> | anyway, I think the first step is for you all to just do the normal thing of responding to Henri's comment with a WG resolution that says what the decision is about the comment and giving a rationale |
| 04:26 | <manu1> | I think the best that we can reasonably do (an address almost all of the concerns) is kick out validation warnings in HTML+RDFa when people use @rel/@rev and @href where they haven't traditionally been used. Something along the lines of: "Hey, you better really know what you're doing... if you don't... don't use @href/@rel/@rev here" |
| 04:26 | <manu1> | ok, well - we should have a response within the next two weeks. |
| 04:28 | <MikeSmith> | manu1: the warnings idea is worth discussing more |
| 04:28 | <manu1> | ok |
| 04:42 | <manu1> | hsivonen, MikeSmith: https://www.w3.org/2010/02/rdfa/track/issues/132 |
| 04:42 | MikeSmith | looks |
| 04:42 | <MikeSmith> | thanks |
| 04:59 | <MikeSmith> | heycam: about why that particular list, Henri would know. But I think he won't be on today until at least another hour or so from now |
| 04:59 | <MikeSmith> | Hixie would know too of course |
| 05:00 | <heycam> | MikeSmith, cool |
| 05:22 | <Hixie> | heycam: we did a deep crawl of the web and looked for what non-svg elements are found in html files after <svg> tags and before </svg> tags |
| 05:22 | <Hixie> | heycam: that's what made the list |
| 05:23 | <heycam> | Hixie, ah ok |
| 05:23 | <heycam> | thanks |
| 05:23 | MikeSmith | finds http://lists.w3.org/Archives/Public/public-svg-wg/2009JanMar/0150.html |
| 05:23 | <MikeSmith> | " this list was determined empirically by studying over 6,000,000,000 pages that were specifically not XML pages" |
| 05:24 | <heycam> | thanks for jogging my memory of that mail I wrote 3 years ago :) |
| 05:25 | <shepazu> | that seems kinda arbitrary… you won't find significant existing pages that don't work in any browser |
| 05:25 | <shepazu> | there may be weird experiments, but they won't necessarily represent what people want to do with compound HTML+SVG documents |
| 05:26 | <Hixie> | there were a quite a few pages that included random <svg> fragments |
| 05:26 | <Hixie> | the goal was to make them not break badly |
| 05:26 | <Hixie> | (i.e. not be any worse than an extra blank spot on the page) |
| 05:26 | <shepazu> | that doesn't really seem like a sensible goal |
| 05:26 | <Hixie> | to each their own :-) |
| 05:27 | <Hixie> | it's a core goal of the whatwg effort |
| 05:27 | <shepazu> | you mean, to each your own |
| 05:27 | <heycam> | to each his own? |
| 05:28 | <shepazu> | no, to everybody, the goal of some small set of people making arbitrary judgments |
| 05:28 | <MikeSmith> | http://html5.org/r/1418 is the original change, for the record |
| 07:40 | <zcorpan> | heycam|away: it's that particular list because Hixie researched legacy text/html content and those were the most common tags in <svg> or <math> that weren't intended to be svg or mathml |
| 07:56 | <hsivonen> | heycam|away: breaking out of svg should happen per spec. does it not? |
| 07:58 | <hsivonen> | manu1: thanks for opening those issues |
| 08:16 | <annevk> | MikeSmith: can you make a repo now? |
| 08:18 | <MikeSmith> | yeah |
| 08:19 | <annevk> | sweet |
| 08:28 | <MikeSmith> | annevk: you wanted a particular repo created? |
| 08:29 | <annevk> | xml-er or xmler |
| 08:29 | <MikeSmith> | ah yeah |
| 08:38 | <MikeSmith> | annevk: ready |
| 08:38 | <MikeSmith> | https://dvcs.w3.org/hg/xml-er |
| 08:45 | <annevk> | guess I better do some work on it later then :) |
| 08:46 | <annevk> | thanks |
| 09:16 | <hsivonen> | hmm. If this xml-er thing happens and SVG starts using it, I'll probably have to implement it |
| 09:16 | <hsivonen> | maybe I should join the CG |
| 09:22 | <hsivonen> | http://www.w3.org/community/blog/2012/02/20/call-for-participation-in-responsive-images-community-group/ is not going to end well without implementor participation |
| 09:23 | zcorpan | specced style="{ ... }" |
| 09:28 | <zcorpan> | hmm. |
| 09:28 | <zcorpan> | grep -iaPo "([a-z]+-)*(position|spacing|width|bottom|clip|size|height|left|right|top|bottom|margin|padding|indent|align|width|end|start|columns|border|shadow)\s*:\s*-?([1-9][0-9]*(\.[0-9]+)?|[0-9]?\.[0-9]+)\s+(px|em|ex|cm|mm|in|pt|pc)" web200904 |
| 09:28 | <zcorpan> | 6265 occurrences |
| 09:28 | <zcorpan> | (i.e. space before unit) |
| 09:28 | <zcorpan> | but opera and firefox don't support that quirk |
| 09:28 | <zcorpan> | although i thought opera did before |
| 09:43 | <zcorpan> | apparently we dropped it because supporting it broke some sites |
| 09:45 | <zcorpan> | if that quirk could be dropped, maybe style={ can also be dropped |
| 10:20 | <asmodai> | buddy of mine asking: Does anyone know if Firefox emits events if it unloads/loads an image for memory usage reasons? |
| 10:43 | <hsivonen> | "Dropping prefixes before CR (via legacy clause in the prefixing policy documented at /TR/CSS)" |
| 10:43 | <hsivonen> | http://www.w3.org/blog/CSS/2012/02/19/resolutions-24/ |
| 10:43 | <hsivonen> | does the CSS WG really need to lawyer a clause in their old policy to justify unprefixing? |
| 10:43 | <hsivonen> | why not just mint new policy as the situation requires? |
| 11:28 | <annevk> | jgraham: where do you store blueberries? |
| 11:51 | <annevk> | MikeSmith: aah, and one for progress events |
| 11:52 | <annevk> | so we can move http://dev.w3.org/2006/webapi/progress/ |
| 11:52 | <MikeSmith> | annevk: set that up already |
| 11:52 | <annevk> | "2 months ago" oops :) |
| 11:52 | <MikeSmith> | no problem :) |
| 12:03 | <annevk> | I like https://www.w3.org/Bugs/Public/show_bug.cgi?id=16026 |
| 12:04 | <annevk> | someone who's arguing on behalf of users/developers for who the level of indirection of CSS is too hard |
| 13:28 | <annevk> | MikeSmith: progress events has no bug component |
| 13:29 | <annevk> | maybe that's okay, but for consistency... |
| 13:33 | <zcorpan> | Hixie: i tried editing a status box. it said error 500 |
| 13:34 | <hsivonen> | "Where, then, is the multi-million dollar advertising campaign for Fennec?" http://infrequently.org/2012/02/misdirection/ |
| 13:35 | <annevk> | http://dvcs.w3.org/hg/progress/raw-file/tip/Overview.html |
| 13:35 | <hsivonen> | interesting point of view from someone who is working on a product that bootstrapped its success using Safari's vendor prefixes and UA string |
| 13:35 | <hsivonen> | as if Mozilla and Opera had the kind of advertising budgets Chrome seems to have |
| 13:36 | <annevk> | there was all kinds of wrong with that post |
| 13:36 | <hsivonen> | yes |
| 13:36 | <annevk> | but I've lost interest in arguing with people |
| 13:36 | <hsivonen> | vendor prefixes are full of 386 |
| 13:44 | <annevk> | okay Progress Events is fully moved now |
| 13:44 | <annevk> | thanks MikeSmith |
| 13:44 | <annevk> | if anyone notices bugs I can fix them again |
| 13:46 | <StoneCypher> | hsivonen: i can't disagree with him more about css and documents |
| 13:46 | <smaug____> | hsivonen: welcome back |
| 13:47 | <StoneCypher> | hsivonen: css is god's gift to documents, if-f you can force a high quality reader (eg through compile to pdf) |
| 13:58 | <hsivonen> | smaug____: thanks |
| 14:04 | <[tm]> | annevk: will add a bug component for progress events when i get back to my laptop |
| 14:06 | <annevk> | cheerios |
| 14:16 | <karlcow> | hsivonen: and sencha touch comment is going down the inception rabbit hole by taking the stance of a User experience monoculture, and then bashing the other platforms to not follow exactly the main one. |
| 14:17 | <StoneCypher> | i love how sencha touch thinks it isn't a flash in the pan |
| 14:20 | <hsivonen> | karlcow: the Web devs who say things along the lines of "I like vendor prefixes, because they let me target the engines I choose" aren't really making a persuasive argument against Mozilla/Opera/MS implementing -webkit- stuff |
| 14:20 | <hsivonen> | karlcow: but I bet many of them (not necessarily the sencha commenter) don't seem to realize this |
| 14:22 | <StoneCypher> | typical apple |
| 14:22 | <StoneCypher> | screech about the evil that microsoft does for ten years, then imitate it for ten more |
| 14:22 | <hsivonen> | StoneCypher: Apple has done things according to the CSS WG policy |
| 14:22 | <hsivonen> | StoneCypher: and then they've evangelized their product |
| 14:23 | <hsivonen> | StoneCypher: they submitted specs for their stuff, too |
| 14:23 | <StoneCypher> | yeah, there's more to apple than how they interact with whatwg |
| 14:23 | <hsivonen> | (except text-size-adjust, but that's a sidetrack) |
| 14:23 | <hsivonen> | the "Apple is evil" meme is missing the point |
| 14:23 | <StoneCypher> | 1) that's not what a meme is |
| 14:23 | <StoneCypher> | 2) i'm not using any stereotypes, despite your attempt to pigeonhole me into one |
| 14:23 | <hsivonen> | the vendor prefixing policy is fundamentally flawed, because it leads to this sort of thing |
| 14:23 | <StoneCypher> | 3) don't tell me that what i'm saying is missing your point; i wasn't speaking to your point |
| 14:24 | <StoneCypher> | i'm. |
| 14:24 | <StoneCypher> | not. |
| 14:24 | <StoneCypher> | talking. |
| 14:24 | <StoneCypher> | about. |
| 14:24 | <StoneCypher> | vendor. |
| 14:24 | <StoneCypher> | prefixing. |
| 14:25 | <StoneCypher> | nevermind. you're not interested in what other people are saying; you'll just keep telling me i'm missing the point as long as i'm not talking about what you're talking about. |
| 14:25 | <hsivonen> | StoneCypher: sorry. what were you referring to? |
| 14:26 | <StoneCypher> | do you remember when apple tried to have microsoft broken up by the department of justice? |
| 14:26 | <StoneCypher> | there were three big reasons |
| 14:26 | <StoneCypher> | all three now apply to apple's voluntary choices, even though they never applied to microsoft. |
| 14:26 | <StoneCypher> | i'm just pointing out that apple is the villain they've always pretended that microsoft is. |
| 14:27 | <StoneCypher> | 1) forcing applications to go through a vendor store at a vendor set price |
| 14:27 | <StoneCypher> | 2) controlling more than 10% of the hardware deployment |
| 14:27 | <hsivonen> | StoneCypher: actually I don't remember Apple trying to have Microsoft broken. Did they ask the DoJ to do that? |
| 14:27 | <StoneCypher> | about a dozen times. |
| 14:27 | <hsivonen> | I do remember Apple folks testifying |
| 14:27 | <StoneCypher> | this is why nobody understands apple |
| 14:27 | <StoneCypher> | they don't know a damn thing about it |
| 14:28 | <StoneCypher> | apple's got a litigious history that makes the RIAA look downright reasonable |
| 14:28 | <StoneCypher> | they're a bunch of monsters |
| 14:35 | <karlcow> | https://en.wikipedia.org/wiki/Apple_Computer,_Inc._v._Microsoft_Corporation |
| 14:36 | <hsivonen> | karlcow: that case didn't ask MS to be broken up, did it? |
| 14:37 | <karlcow> | hsivonen: nope, I'm searching for references. I didn't infer anything on the nature |
| 14:37 | <karlcow> | of the link |
| 14:38 | <hsivonen> | I'd be curious to see a reference for Apple asking the DoJ to break up MS. |
| 14:39 | <karlcow> | yup I was looking for it |
| 14:39 | <hsivonen> | (not suggesting that they didn't ask. just curious for [citation needed]) |
| 14:39 | <karlcow> | I don't see it here eithe rhttps://en.wikipedia.org/wiki/Apple_Inc._litigation |
| 14:41 | <karlcow> | https://en.wikipedia.org/wiki/United_States_v._Microsoft |
| 14:41 | <karlcow> | still no obvious references to Apple |
| 14:42 | <mk___> | hello all - I've done a quick search of the mailing list and I can't figure out what happened re: forms and URI templates |
| 14:42 | <mk___> | was that officially denied as a feature request or did the discussion just die out ? |
| 14:44 | <mk___> | .. I'm not looking to discuss it here I'm just trying to figure out what the status with it is :) |
| 14:44 | <zcorpan> | can you find it here? http://www.whatwg.org/issues/ |
| 14:45 | <mk___> | thanks, I'll have a look |
| 14:46 | zcorpan | can't find it using google on the static version |
| 14:46 | <zcorpan> | if you find it there, it means Hixie hasn't got to it yet |
| 14:47 | <MikeSmith> | http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-November/016985.html looks relevant |
| 14:48 | <zcorpan> | "url--awaiting-work-from-abarth--timeout-end-q3-2011" |
| 14:51 | <mk___> | which is the right mailing list to use these days? |
| 14:51 | <mk___> | or do you just cross-post to both ? |
| 14:52 | <hsivonen> | mk___: no crossposting |
| 14:52 | <zcorpan> | if you want to whine about the process, use public-html |
| 14:52 | <hsivonen> | mk___: the whatwg list for real work. the W3C list for raising ISSUES per the Decision Process |
| 14:52 | <zcorpan> | if you want to discuss technical matters, use whatwg :-) |
| 14:53 | <MikeSmith> | mk___: www-tag |
| 14:53 | <mk___> | public-html sounds wack yo! |
| 14:54 | <annevk> | http://dvcs.w3.org/hg/xml-er/raw-file/tip/Overview.html |
| 14:54 | <mk___> | fight the powa. |
| 14:55 | <zcorpan> | annevk: nice |
| 14:55 | <mk___> | MikeSmith: www-tag ? you mad bro ? |
| 14:55 | <hsivonen> | annevk: cool |
| 14:59 | <MikeSmith> | annevk: component for pgoress events added |
| 15:01 | <annevk> | thanks |
| 15:01 | <annevk> | added to the draft |
| 15:19 | <MikeSmith> | just made http://lists.w3.org/Archives/Public/public-webapps-bugzilla/ |
| 15:20 | <MikeSmith> | bugzilla firehose for webapps bugz |
| 15:20 | <annevk> | nifty |
| 15:20 | <MikeSmith> | gets search engine love now |
| 15:21 | <MikeSmith> | it had been set up to go to member-webapi-cvs⊙wo |
| 15:22 | <annevk> | ah yeah, forgot about that |
| 16:04 | <karlcow> | A monoculture life http://www.flickr.com/photos/alanahmontreal/6907109137/ |
| 16:19 | <hsivonen> | manu1: btw, the bugs I filed on HTML+RDFa can't cause backwards compat issues with processing existing content, because I didn't ask for processing model changes |
| 16:31 | <manu1> | b/c issues would relate to document conformance between XHTML1+RDFa and XHTML5+RDFa documents... |
| 16:32 | <kennyluck> | mk___, there's also a Bugzilal bug for this → https://www.w3.org/Bugs/Public/show_bug.cgi?id=11361 |
| 16:33 | <manu1> | so, you're right - there would be no b/c issues w/ the processing algorithm... but there would be b/c issues between XHTML1+RDFa and XHTML5+RDFa... (primarily because authors won't understand the nuanced difference between the two and would expect their XHTML1+RDFa documents to continue to "conform" under XHTML5+RDFa. |
| 16:34 | <manu1> | I think we could make a technical argument that XHTML1+RDFa can be different from XHTML5+RDFa (based on document conformance)... but that nuance will be lost on authors, I imagine. |
| 16:34 | <manu1> | The technical argument would go something like this: Since RDFa was never defined for XHTML5+RDFa, there are no backwards incompatible issues by not allowing @href on all elements. |
| 16:35 | <manu1> | (but then, as I said a few hours ago, conformance differences for @href/@rel/@rev between XHTML1+RDFa and HTML5+RDFa will confuse authors) |
| 16:37 | <manu1> | (leading me to the conclusion that we should not allow those attributes as conforming in RDFa Lite 1.1, and warn strongly against using @href/@rel/@rev on elements that traditionally didn't allow those attributes in RDFa 1.1 Full via validator warnings) |
| 16:38 | <manu1> | ... understanding, of course, that the solution isn't acceptable to you. :) |
| 17:08 | <Ms2ger> | AryehGregor, please ask webkit devs to email to www-dom instead of changing the spec when they complain in their bugzilla, we don't want to encourage that behaviour further |
| 17:09 | <AryehGregor> | Ms2ger, they CC'd Anne and me. |
| 17:09 | <AryehGregor> | I don't see any reason to require them to do more than contact the editors for tiny things like this. |
| 17:09 | <annevk> | what was this? |
| 17:09 | <AryehGregor> | They pointed out the spec was wrong, I'm not going to say I'm going to leave the spec wrong until they e-mail www-dom. |
| 17:09 | <AryehGregor> | annevk, https://bugs.webkit.org/show_bug.cgi?id=78887 |
| 17:10 | <AryehGregor> | If I thought it needed discussion, I'd have e-mailed www-dom myself, but I don't think it did -- the spec says the parameter defaults to true, IE and WebKit default to false, Gecko and Opera make it non-optional. |
| 17:11 | <annevk> | that was an intentional change from WebKit actually |
| 17:11 | <annevk> | because false is useless default |
| 17:11 | <annevk> | so yeah, prolly better to email the list first |
| 17:11 | <AryehGregor> | Is it really worth breaking compat with IE/WebKit, especially if WebKit doesn't seem willing to change? |
| 17:11 | <AryehGregor> | cloneNode(false) isn't useless. It depends what you're doing with it. |
| 17:11 | <annevk> | this is IE10... |
| 17:12 | <AryehGregor> | If you want me to revert it, I will. |
| 17:12 | AryehGregor | checks in compat modes |
| 17:12 | <annevk> | yeah I'd prefer that |
| 17:12 | <annevk> | at least until things are a bit more clear; I didn't realize IE had optional arguments |
| 17:12 | <AryehGregor> | Yay, my Windows 8 VM always freezes and bogs down. |
| 17:12 | <AryehGregor> | Great advertisement for the OS. |
| 17:13 | AryehGregor | will check what IE does in compat modes before reverting |
| 17:13 | <StoneCypher> | mine's fine |
| 17:14 | <AryehGregor> | Awesome. Some antimalware thing was using all its CPU. |
| 17:14 | <AryehGregor> | Very handy. |
| 17:14 | <AryehGregor> | Since it's a VM with nothing installed on it and no files I care about. |
| 17:15 | <StoneCypher> | huhu |
| 17:19 | <AryehGregor> | annevk, IE10 Developer Preview treats the argument as null defaulting to false even in IE7 browser mode, quirks document mode. |
| 17:19 | <AryehGregor> | So it looks like old behavior. |
| 17:19 | <AryehGregor> | It doesn't seem worth changing the default here from what IE/WebKit have apparently done for years, IMO. |
| 17:19 | AryehGregor | solicits Ms2ger's opinion too |
| 17:21 | <Ms2ger> | I'm not convinces that default-to-false is better than mandatory in this case |
| 17:22 | <AryehGregor> | Well, mandatory is okay by me too. |
| 17:22 | <AryehGregor> | I don't see the value in making up a totally new behavior. |
| 17:22 | <AryehGregor> | Because authors won't be able to rely on it for a long time, and we have no reason to think IE or WebKit will actually change. |
| 17:22 | <AryehGregor> | As a general rule, I'm against requiring stuff in specs that goes against all browsers unless the browsers actually want to change. |
| 17:23 | <annevk> | we made a similar change already |
| 17:23 | <annevk> | for where the false-ness was not liked either |
| 17:24 | <annevk> | importNode() |
| 17:24 | <annevk> | and importNode and cloneNode should do the same |
| 17:25 | <AryehGregor> | Yeah, that's definitely true, they should be consistent. |
| 17:26 | <annevk> | it's only optional in webkit because of some legacy stuff they had |
| 17:27 | <AryehGregor> | Ooh, Gecko/WebKit treat that as true by default and IE/Opera make it mandatory. |
| 17:27 | <AryehGregor> | The plot thickens. |
| 17:27 | <AryehGregor> | I'll revert. |
| 17:27 | Ms2ger | mumbles about the mess that is the DOM |
| 17:38 | <hsivonen> | manu1: XHTML 1.1 docs aren't conforming HTML5 docs anyway. and in any case, claiming that RDFa 1.1 needs to keep RDFa 1.0 conforming is a Stop Energy tactic that prevents any sort of fixing of design failures in RDFa 1.0 |
| 17:38 | <AryehGregor> | Why do mail archives not update immediately? Is it really such a hard problem? |
| 17:39 | <hsivonen> | manu1: https://lists.w3.org/Archives/Member/w3c-archive/2011Mar/0199.html |
| 17:40 | <StoneCypher> | AryehGregor: it was in the 70s when they were invented |
| 18:58 | <AryehGregor> | jgraham, . . . are you planning to accept my pull request at some point? |
| 18:59 | <AryehGregor> | Also: why am I not surprised that WebKit refuses to consider budging on cloneNode()? |
| 18:59 | <AryehGregor> | They seem to practically never be willing to change to match other browsers or the spec if there's any chance they can hold out with their current behavior . . . |
| 19:11 | <StoneCypher> | AryehGregor: because apple only cares about standards as a marketing ploy? |
| 19:11 | <AryehGregor> | StoneCypher, who said anything about Apple? Apple doesn't control WebKit. |
| 19:11 | StoneCypher | blinks. "isn't webkit apple's adaptation of khtml, like dolphin is nokia's?" |
| 19:12 | <AryehGregor> | It's an open-source project. |
| 19:12 | <AryehGregor> | Google has as much influence as Apple these days. |
| 19:12 | <AryehGregor> | Other companies do too, like Nokia, Adobe, . . . |
| 19:13 | <StoneCypher> | ah. |
| 19:13 | <AryehGregor> | Originally, yes, it was just Apple's. |
| 19:13 | <AryehGregor> | Not for several years now. |
| 19:16 | <gsnedders> | AFAIK Apple/Google practically have veto power over stuff, though |
| 19:17 | <AryehGregor> | Probably, but not just Apple. |
| 19:18 | <gsnedders> | AryehGregor: FWIW, most of the stop energy for mutli-VM bindings was from Apple |
| 19:18 | <AryehGregor> | Multi-VM bindings? |
| 19:18 | <gsnedders> | They can still stop stuff that Google wants in. |
| 19:18 | <AryehGregor> | Google does what in that case, moves the code it wants to Chromium? |
| 19:18 | <gsnedders> | AryehGregor: Add the possibilities to bind multiple VMs within the environment, so JS and Dart is what Google wanted. |
| 19:18 | <AryehGregor> | Ah. |
| 19:19 | <gsnedders> | AryehGregor: They tend to try and avoid divergence, though what exactly happens in such disputes normally I don't know |
| 19:19 | <gsnedders> | AFAIK normally they just discuss/comprimise. |
| 19:20 | <AryehGregor> | I've been told they have no formal decision-making or dispute-resolution process. |
| 19:21 | <AryehGregor> | Which seems a bit crazy. |
| 19:21 | <gsnedders> | That's my understanding too. |
| 19:46 | AryehGregor | wonders if his posts to www-style on prefixes are worth it |
| 19:47 | <AryehGregor> | gsnedders or someone: is there a list somewhere of what properties Opera will transition? |
| 19:49 | <Hixie> | a lot of people seem to be registering <meta> names that are specific to their tool and not intended for interoperation with other software |
| 19:49 | <Hixie> | i wonder if we should address that use separately |
| 19:49 | <AryehGregor> | Yay, it's not documented for IE. |
| 19:49 | <StoneCypher> | isn't that the purpose of meta? |
| 19:49 | <StoneCypher> | i thought it was basically #pragma |
| 19:50 | <Hixie> | well the purpose of registering values is to prevent different software packages from using the same name |
| 19:50 | <StoneCypher> | oh, i missed that you were talking about registration |
| 19:50 | <StoneCypher> | looking for ideas, or looking to nail down conflicting existing behaviors? |
| 19:50 | <Hixie> | but if the software packages are scoped to a particular domain, it doesn't make much sense to have to register the term to protect it against an identical term used by software for another domain |
| 19:51 | <StoneCypher> | big if |
| 19:51 | <StoneCypher> | wordpress violates that if |
| 19:51 | <StoneCypher> | runs on a bunch of domains, and on domains running other things |
| 19:52 | <Hixie> | by "domain" i mean more the term in the mathematical sense of "defined space" |
| 19:53 | <StoneCypher> | oh |
| 19:53 | <Hixie> | if wordpress and mediawiki both use a meta value for internal purposes, it doesn't matter if they clash |
| 19:53 | <Hixie> | so we shouldn't be requiring that they register the terms |
| 19:53 | <StoneCypher> | might. they share extensions. |
| 19:53 | <Hixie> | anyway |
| 19:53 | <Hixie> | just an observation |
| 19:53 | <StoneCypher> | so |
| 19:53 | <StoneCypher> | i am against registration, for the record |
| 19:53 | <Ms2ger> | |(HTMLElement? or long)| or |(HTMLElement or long)?|? |
| 19:53 | <StoneCypher> | on grounds that i don't find it to be practical |
| 19:53 | <StoneCypher> | but |
| 19:53 | <StoneCypher> | that doesn't mean registration can't be faked |
| 19:53 | <StoneCypher> | and as a mechanism it is useful |
| 19:54 | <StoneCypher> | and you get right back into the same old "give it a fake namespace with a prefix" mindset |
| 19:54 | <StoneCypher> | if that became the norm |
| 19:54 | <StoneCypher> | then you'd actually have a pretty reasonable setup |
| 19:54 | <Hixie> | the other problem with registration is it isn't stopping people who happen to use the same term as someone else with a different meaning from doing so |
| 19:54 | <StoneCypher> | allow me to play hypothetical for a moment |
| 19:55 | <StoneCypher> | we get in our time machine and set the social norm, if not the requirement, that these be in the form "packagename-key" |
| 19:55 | <StoneCypher> | so all that needs to happen is that people manage their package names (string fake namespaces) |
| 19:55 | <StoneCypher> | webkit uses webkit, wordpress uses wordpress, google tells you to use google-token for ads |
| 19:56 | <StoneCypher> | does that satisfy the kind of thing you want to think about? |
| 19:56 | <gsnedders> | AryehGregor: Doubt anybody in here will know. |
| 19:56 | <Hixie> | yeah we could do something like that, like we do for data-* attributes |
| 19:57 | <StoneCypher> | that also has the advantage of not colliding (much) with current practice |
| 19:57 | <AryehGregor> | It seems to not include marginLeft, and IE doesn't do textIndent or most other useful stuff, so I can't find a test-case that will work in all browsers for the issue I just found. |
| 20:03 | <Ms2ger> | Hrm, AllowAny |
| 20:05 | <Ms2ger> | annevk, yt? |
| 20:11 | <annevk> | Ms2ger: yeah |
| 20:11 | <Ms2ger> | annevk, xhr.send() |
| 20:12 | <Ms2ger> | There's an overload that takes DOMString?, but the string case doesn't seem to handle null |
| 20:14 | <annevk> | not handle null? |
| 20:14 | <annevk> | do you mean in prose or IDL? |
| 20:17 | <Ms2ger> | Prose |
| 20:17 | <annevk> | http://dvcs.w3.org/hg/xhr/raw-file/tip/Overview.html#the-send()-method |
| 20:17 | <annevk> | "If the data argument has been omitted or is null, do not include a request entity body and go to the next step." |
| 20:19 | <annevk> | maybe i'll make it send(optional (ArrayBuffer or Blob ...)? data) at some point |
| 20:19 | <annevk> | not sure if that's worth it though |
| 20:20 | <Ms2ger> | Er, oops |
| 20:20 | <Ms2ger> | annevk, probably is: https://www.w3.org/Bugs/Public/show_bug.cgi?id=15986 |
| 20:23 | <mk___> | thanks for pointing me to that kennyluck |
| 20:26 | <annevk> | Ms2ger: bug looks complex |
| 20:26 | <Ms2ger> | Yeah |
| 20:26 | <annevk> | Ms2ger: hopefully someone explains it at one point |
| 20:26 | <Ms2ger> | The conclusion seems to be that we can get rid of overloading |
| 20:27 | <Ms2ger> | And just have a map from the number of arguments to the right signature |
| 20:31 | <annevk> | so you would have to write test(X, A); test(X, B) as test(X, (A or B)) |
| 20:31 | <Ms2ger> | Yes |
| 20:31 | <annevk> | are there any cases outlawed? |
| 20:32 | <Ms2ger> | I dunno |
| 20:36 | <AryehGregor> | annevk, none that anyone's found in actual specs. In theory yes, e.g. foo(long a, boolean b) plus foo(Node a, float b) or something. |
| 20:36 | <AryehGregor> | In those cases you'd have to do foo((long or Node) a, (boolean or float) b) and enforce the extra restrictions in prose. |
| 20:36 | <AryehGregor> | In practice that seems not to happen. |
| 20:37 | <AryehGregor> | heycam|away compiled a list of all the overloading he could find in real specs, and it all works with this simplified overloading. |
| 20:44 | <annevk> | extra restrictions in prose is nasty |
| 20:45 | <AryehGregor> | It's not needed for any known example. |
| 20:45 | <annevk> | but yeah, that would seem like pretty poor API design |
| 20:45 | <AryehGregor> | Cases where it would be needed are probably -- right. |
| 20:45 | <annevk> | so maybe that should not be allowed anyway |
| 20:45 | <AryehGregor> | It would only happen if you had the type of one argument restrict the type of another argument. |
| 20:46 | <AryehGregor> | It's a significant WebIDL simplification, so if there are weird cases where we need an extra line of prose, it seems justified. |
| 20:47 | <AryehGregor> | The current situation requires arguments' types to be evaluated sometimes to determine which overloaded operation to use, and that's bad if evaluating the argument has side-effects. |
| 20:47 | <Ms2ger> | Oh |
| 20:47 | <annevk> | yeah sounds fair enough |
| 20:48 | <Ms2ger> | AryehGregor, did bz email you about testing left-to-right evaluation of arguments? |
| 20:48 | <AryehGregor> | Ms2ger, yes. |
| 20:48 | <AryehGregor> | That was what spawned that whole bug. |
| 20:48 | <Ms2ger> | Great |
| 21:20 | <matjas> | “Also, the author is some kind of hipster bastard? No one uses XHTML since 2010? are you kidding?” — http://www.reddit.com/r/programming/comments/px67c/using_css_without_html/c3t52vr |
| 21:21 | <StoneCypher> | 's been longer than that |
| 21:23 | matjas | takes pride in being called a hipster bastard |
| 21:23 | <Hixie> | hardly anyone has ever used xhtml... |
| 21:24 | matjas | has, and still feels bad for it |
| 21:25 | matjas | unkills kittens |
| 21:26 | Ms2ger | has been there |
| 21:28 | <Philip`> | Unfortunately the laws of thermodynamics state that every time you unkill a kitten, God kills a kitten |
| 21:29 | <StoneCypher> | Hixie: that essay of yours is a big part of why |
| 21:30 | <Hixie> | StoneCypher: hopefully |
| 21:35 | <Ms2ger> | Weren't the CSSWG chairs going to shut down useless threads? |
| 21:41 | <gwicke> | hello, I am wondering about the current state of multiple itemtype support in microdata. As far as I know only a single itemtype is currently reported using the DOM, and similarly indexed by search engines. Are there any plans to associate absolute-url itemprops with secondary itemtypes based on url prefixes? |
| 21:56 | <Hixie> | gwicke: to your question, the answer is not currently; what's your use case? |
| 21:57 | <gwicke> | one would be marking up template arguments in wikipedia |
| 21:57 | <gwicke> | I am currently working on a new wiki parser, and we are using HTML DOM as our internal data model |
| 21:58 | <gwicke> | there is also a visual editor in development, that is supposed to allow WYSIWYG editing |
| 21:58 | <gwicke> | the idea is to use microdata to mark up template expansions to allow inline editing |
| 21:58 | <Hixie> | why can't you do inline editing without microdata? |
| 21:58 | <gwicke> | at the same time templates are quite structured, and also semantically interesting |
| 21:59 | <Hixie> | i don't understand what microdata is giving you here |
| 22:00 | <gwicke> | many users are interested in getting at template parameters, and we figured we might as well use the same mechanism for both the editor and semantic information |
| 22:00 | <Hixie> | i don't really understand who your consumers are |
| 22:00 | <Hixie> | i mean, why bother marking this up at all? |
| 22:01 | <gwicke> | for the editor, we would like to edit arguments to some infobox right in the expanded infobox template |
| 22:02 | <gwicke> | infoboxes are these boxes that are often displayed for towns, plants etc |
| 22:02 | <gwicke> | they mostly contain data such as number of inhabitants etc |
| 22:02 | <gwicke> | which makes them interesting for data extraction |
| 22:02 | <AryehGregor> | Ooh, anti-Google attack post by MS on IEBlog. Fun stuff. Wonder what Google will respond. |
| 22:02 | <Hixie> | gwicke: ok but for the editor that's trivial. you just put a class name on the element that holds the value, and boom, that value is editable. |
| 22:03 | <Hixie> | gwicke: my question is what is the software doing the extraction? |
| 22:03 | <gwicke> | right now there are projects like http://mappings.dbpedia.org/index.php/How_to_edit_the_DBpedia_Ontology |
| 22:04 | <gwicke> | they need to parse the source to get at any template information |
| 22:04 | <bga> | is there :contains() selector. I know that is evil but i want it for usercss. For gecko only is accepted |
| 22:04 | <gwicke> | so the idea is to make it easier or them to get at parameters, and potentially also map some parameters to names in a known vocabulary |
| 22:05 | <gwicke> | ..which is where the second itemtype would come in |
| 22:05 | <Ms2ger> | bga, no |
| 22:05 | <heycam> | hsivonen, the breaking out of svg did happen. I had just forgotten the reason for certain tags breaking out and others not. |
| 22:05 | <Hixie> | gwicke: i don't understand why you'd need more than two properties, one to say "this is the name of the attribute" and one to say "this is the value" |
| 22:05 | <bga> | Ms2ger thanks |
| 22:05 | <Hixie> | gwicke: i suppose you could hard-code the accepted names, in which case you could have one property per value |
| 22:05 | <Hixie> | gwicke: and not mark up the names |
| 22:06 | <Hixie> | gwicke: but then why would you need more than one vocabulary? |
| 22:06 | <gwicke> | each template has a different set of named parameters |
| 22:06 | <Hixie> | gwicke: just put them all in the same vocabulary |
| 22:06 | <Hixie> | gwicke: same itemtype="" |
| 22:06 | <Hixie> | gwicke: since it doesn't seem you're getting any value out of the itemtype="" anyway |
| 22:07 | <gwicke> | that would not help to expose the semantics though |
| 22:07 | <Hixie> | gwicke: the semantics is the "attributes", no? |
| 22:08 | <gwicke> | the idea was that an infobox about an event for example could be mapped to the schema.org vocabulary for an event |
| 22:08 | <Hixie> | wait, why schema.org? you told me your consumer was a dbpedia tool |
| 22:09 | <gwicke> | the idea is to make it searchable to |
| 22:09 | <Hixie> | ok let's start over |
| 22:09 | <gwicke> | dbpedia is one project, but there are others |
| 22:09 | <Hixie> | what are all the use cases for what you're doing |
| 22:09 | <gwicke> | data mining and editing basically |
| 22:10 | <Hixie> | those aren't use cases, they're buzzwords :-) |
| 22:10 | <gwicke> | ok ;) |
| 22:10 | <Hixie> | i mean concretely, what is it you expect an actual user to do |
| 22:10 | <gwicke> | I think the editor portion is quite clear, and not critical for the microdata stuff |
| 22:11 | <gwicke> | but we'd like to expose the same information to search engines using a standard vocabulary where it makes sense |
| 22:11 | <gwicke> | which will likely be a subset of template parameters per itemtype |
| 22:11 | <Hixie> | sounds like "english" would be a suitable vocabulary for what you've described |
| 22:11 | <Hixie> | no need for microdata |
| 22:12 | <gwicke> | template arguments are things like years, number of inhabitants etc |
| 22:12 | <gwicke> | imo there is some benefit in getting at that information in an automated way |
| 22:13 | <Hixie> | i'm trying to work out what that benefit is... so far you've just said "search", but search engines seem to handle searching wikipedia fine |
| 22:13 | <Hixie> | so it's not clear to me what problem you're trying to solve |
| 22:14 | <gwicke> | most of the structured information is hard to use currently |
| 22:15 | <gwicke> | sure, search engines have heuristics, but you cannot directly extract structured data |
| 22:16 | <gwicke> | and we have to mark that stuff up for editing anyway- so why not expose it in a standard way |
| 22:16 | <Hixie> | english is a standard way :-) |
| 22:16 | <Hixie> | so your use case is e.g. to have Microsoft's Bing team extract data from Wikipedia pages and then... do what with it? |
| 22:17 | <gwicke> | whatever- build some ontology to improve search results,.. |
| 22:17 | <gwicke> | right now you can already do that, but it requires a lot of effort |
| 22:18 | <Hixie> | this seems like a very poorly-defined problem |
| 22:18 | <Hixie> | i'm not sure what to suggest |
| 22:18 | <gwicke> | so do you think we should not use microdata at all for some reason? |
| 22:18 | <StoneCypher> | my interpretation of what hixie said is "you haven't defined this problem well enough yet" |
| 22:18 | <StoneCypher> | not "this tool is wrong because" |
| 22:19 | <gwicke> | ok |
| 22:19 | <Hixie> | gwicke: without knowing exactly what you're trying to do, i don't know what would be a good answer |
| 22:19 | <Hixie> | gwicke: put it another way |
| 22:19 | <gwicke> | well- I can't define the data extraction uses more concretely as I don't know what it will be used for |
| 22:19 | <Hixie> | gwicke: how could you tell if you have succeeded in doing what you're trying to do? |
| 22:19 | <StoneCypher> | that's a problem if you want a computer to do things for you |
| 22:19 | <Hixie> | gwicke: how do you plan to evaluate your project's success? |
| 22:20 | <gwicke> | for the editor, we can either mark it up as data- attributes, or as microdata |
| 22:20 | <gwicke> | both have about the same amount of overhead |
| 22:20 | <gwicke> | so we don't care |
| 22:21 | <gwicke> | but external users could use microdata a bit easier than some weird data- attributes, so any use would be a success in my book |
| 22:22 | <Hixie> | external users wouldn't be technically allowed to use your data-* attributes |
| 22:22 | <Hixie> | the whole point of data-* attributes is that they're for internal use only |
| 22:22 | gwicke | nods |
| 22:22 | <gwicke> | but we want this stuff to be easily available |
| 22:22 | <Hixie> | it _is_ easily available |
| 22:23 | <gwicke> | except not for automated tools |
| 22:23 | <Hixie> | google is an automated tool, and as a user i find it does pretty well at finding the wikipedia page i want when i ask it for one |
| 22:23 | <Hixie> | i'm not saying your goal is a bad goal, just that it's underdefined |
| 22:24 | <Hixie> | my earlier question is serious -- how do you plan to evaluate your project's success? |
| 22:25 | <gwicke> | I think we are in agreement that stuffing this information in data- attributes is not such a good idea |
| 22:26 | <gwicke> | so for me it would be a success if we can expose this information to the public without incurring much overhead in markup or processing time |
| 22:26 | <StoneCypher> | that isn't really measurable. |
| 22:26 | <Hixie> | ok. done. you have exposed the information already. |
| 22:26 | <Hixie> | 100% success with zero additional effort! |
| 22:26 | <Hixie> | :-) |
| 22:27 | <gwicke> | well - we are constantly asked 'how do I get the arguments for this or that template?' |
| 22:27 | <Hixie> | aha |
| 22:27 | <gwicke> | there are some heuristics using css classes and so on, but that is all a hack |
| 22:27 | <gwicke> | others start to parse the source, see dbpedia |
| 22:28 | <Hixie> | ok well solving _that_ problem is easy |
| 22:28 | <Hixie> | just mint a new URL for each attribute |
| 22:28 | <Hixie> | and don't bother with itemtype="" at all |
| 22:29 | <Hixie> | you don't even need to use microdata for that |
| 22:29 | <Hixie> | just put the URLs you mint as class names on the elements you want to have machine-readable |
| 22:29 | <Hixie> | doesn't even have to be URLs, you can just document unique class names |
| 22:29 | <Hixie> | like org.wikipedia.countries.population |
| 22:30 | <gwicke> | we need the template name and the association of arguments with template transclusions for the editor |
| 22:30 | <gwicke> | so the item / microdata model fits that aspect quite well |
| 22:30 | <gwicke> | we also have a need for something like itemref |
| 22:31 | <gwicke> | as many templates don't expand to a single DOM subtree |
| 22:31 | <Hixie> | ok so then just have itemtype="http://wikipedia.org/template";, and then mint a new URL for each attributne |
| 22:32 | <gwicke> | we were thinking about using http://wikipedia.org/Template:Foo as the itemtype |
| 22:32 | <Hixie> | no need for unique item types as far as i can tell from what you've said |
| 22:32 | <Hixie> | why? |
| 22:32 | <Hixie> | what problem does it solve? |
| 22:33 | <gwicke> | the template determines the semantics of its parameters |
| 22:33 | <gwicke> | there is normally an informal description at that location, which could also be formalized in the future |
| 22:33 | <gwicke> | we would also like to display special widgets for some templates |
| 22:34 | <Hixie> | if you use unique strings for each attribute, then you'll never have any clashes, so you can just have the unique strings determine the semantics of the parameters |
| 22:34 | <gwicke> | and we could use type information for generic editor widgets |
| 22:34 | <Hixie> | microdata doesn't do anything with widgets |
| 22:35 | <Hixie> | oh you mean in the editor |
| 22:35 | <StoneCypher> | Hixie: you're on css councils, right? |
| 22:35 | <Hixie> | StoneCypher: never heard of it |
| 22:35 | <StoneCypher> | no i just mean councils having to do with css |
| 22:35 | <StoneCypher> | i don't know the proper name of the css standards committee |
| 22:35 | <Hixie> | oh the css working group? |
| 22:35 | <gwicke> | Hixie: yes, we could use parameter semantics to help the editor |
| 22:35 | <StoneCypher> | i suppose, yes |
| 22:36 | <Hixie> | StoneCypher: i think technically i'm a member but i haven't actually participated in years |
| 22:36 | <StoneCypher> | how come css doesn't have what other languages call inheritance yet? there have been like a dozen tools invented to deal with that, each more awful than the last. |
| 22:36 | <StoneCypher> | and yes, i know css uses taht word for something different |
| 22:37 | <Hixie> | gwicke: then yeah, i'd say use an absolute URL per template as the itemtype="" so that the editor knows what UI to use for that template, and use absolute URLs for each attribute, so you can reuse attributes across types and so that there's no need to rely on the type for them. |
| 22:37 | <annevk> | StoneCypher: http://dev.w3.org/csswg/css3-hierarchies/ |
| 22:37 | <Hixie> | StoneCypher: css also doesn't have what other languages call classes, so there's nothing to inherit to and from |
| 22:38 | <Hixie> | StoneCypher: but what annevk said |
| 22:38 | <StoneCypher> | Hixie: well that's not exactly difficult to solve |
| 22:38 | <StoneCypher> | annevk: ... orly. |
| 22:38 | <StoneCypher> | oh |
| 22:38 | <StoneCypher> | no, this is just LESS reified |
| 22:38 | <StoneCypher> | and not even very well :( |
| 22:39 | <StoneCypher> | it loses most of what makes LESS almost-work |
| 22:39 | <StoneCypher> | namely concrete specifiers, variables and calculations |
| 22:39 | <StoneCypher> | this enforces a heirarchy for inheritance which is neither useful nor desirable |
| 22:39 | <StoneCypher> | this is just syntactic sugar |
| 22:40 | <zcorpan> | http://dev.w3.org/csswg/css-variables/ |
| 22:40 | <zcorpan> | variables are also syntactic sugar though |
| 22:40 | <zcorpan> | calculations, is that like calc()? |
| 22:40 | <StoneCypher> | variables are useful |
| 22:40 | <StoneCypher> | it serves the same purpose as calc() but in a far less horrible way |
| 22:41 | <StoneCypher> | admittedly still horrible |
| 22:41 | <StoneCypher> | but less so |
| 22:41 | <annevk> | #read-text etc. does not mention anything about quirks mode |
| 22:41 | <zcorpan> | what's concrete specifiers? |
| 22:41 | <StoneCypher> | basically constants |
| 22:41 | <gwicke> | Hixie: if we go that route, then we can't add for example an additional schema.org itemtype to templates where most parameters correspond to a standard vocabulary |
| 22:41 | <StoneCypher> | i mean it's not exactly a constant because it's subject to selectors |
| 22:41 | <StoneCypher> | but |
| 22:41 | <annevk> | StoneCypher: you want http://lists.w3.org/Archives/Public/www-style/ |
| 22:41 | <StoneCypher> | annevk: no, i don't |
| 22:42 | <StoneCypher> | if i did i'd be there, thanks though |
| 22:42 | <annevk> | almost nobody here works on CSS |
| 22:42 | <gwicke> | so we have to choose between an internal itemtype or an external one |
| 22:42 | <StoneCypher> | and yet there's a discussion at hand. |
| 22:42 | <StoneCypher> | no need to purposefully derail it. |
| 22:42 | <zcorpan> | annevk: doesn't the parser set the mode? |
| 22:42 | <Hixie> | gwicke: i don't understand what you mean |
| 22:42 | <StoneCypher> | zcorpan: reading |
| 22:42 | <Hixie> | gwicke: first, why would you add schema.org? what problem does that solve? and second, why couldn't you use both? |
| 22:42 | <annevk> | zcorpan: not sure I want it to be quirks mode is what I mean I guess |
| 22:43 | <StoneCypher> | zcorpan: yeah, this is pretty similar to concrete specifiers. works differently but serves the same goal. |
| 22:43 | <zcorpan> | annevk: don't all browsers use quirks mode? |
| 22:43 | <gwicke> | Hixie: lets say a template displays an event and its parameters mostly map to some schema.org event vocabulary |
| 22:43 | <Ms2ger> | Gecko might not |
| 22:44 | <gwicke> | then it would be nice to make this information available using that schema.org itemtype |
| 22:44 | Ms2ger | is too tired to remember the details of the conversation he had about that |
| 22:44 | <gwicke> | afaik we can only specify a single itemtype in the current spec |
| 22:44 | <gwicke> | but can add absolute-url names for itemprops |
| 22:44 | <annevk> | zcorpan: yeah maybe |
| 22:44 | <StoneCypher> | zcorpan: is it too early to know whether this spec is likely to take hold? |
| 22:45 | <gwicke> | so we would have two names for most itemprops, and a single one where the property does not map to schema.org |
| 22:45 | <gwicke> | the 'secondary' itemtype would be the wikipedia one in that case |
| 22:45 | <Hixie> | gwicke: the spec says you can have multiple types in itemtype="" so long as they are all the same vocabulary |
| 22:46 | <Hixie> | gwicke: if you're using absolute URLs for all your itemprops, then it's easy to do that, since your vocabulary would technically be empty |
| 22:46 | <gwicke> | the names unfortunately differ |
| 22:46 | <Hixie> | gwicke: just say that the wikipedia itemtype=""s actually use the schema.org vocabulary |
| 22:46 | <Hixie> | gwicke: and then never use those values |
| 22:46 | <Hixie> | gwicke: but you didn't answer my main question, which is "what problem does that solve" |
| 22:47 | <zcorpan> | StoneCypher: i guess it could be not-implemented in browsers for another few years, but clearly it's something many authors want |
| 22:47 | <Hixie> | gwicke: if it's wikipedia we're talking about, you can just do your own vocabulary, i'm sure the browser vendors would support it |
| 22:47 | <Hixie> | gwicke: s/browser vendors/search engine vendors/ |
| 22:47 | <Hixie> | gwicke: at which point having schema.org stuff in there as well would just be confusing |
| 22:48 | <StoneCypher> | zcorpan: also my head keeps pretending you're a 3d printer |
| 22:48 | <gwicke> | search engines can always put the resources in to get at the information |
| 22:48 | <zcorpan> | StoneCypher: i've heard about that one |
| 22:48 | <gwicke> | but ideally it would be so easy that some researcher could get at it just as easy as google or some other organization |
| 22:48 | <zcorpan> | StoneCypher: fortunately i predated it by years, iirc :-) |
| 22:49 | <StoneCypher> | but you were going to fab things for me and put AN at the end |
| 22:49 | <gwicke> | so that is the problem we are trying to solve |
| 22:50 | <Hixie> | gwicke: "some researcher" can use your vocabulary though right? so why use schema.org? |
| 22:50 | <zcorpan> | hmm, turns out i didn't predate zcorp. at least not my nick. |
| 22:51 | <StoneCypher> | ten dollars says you change your name to ShapeWaysan |
| 22:51 | <gwicke> | Hixie: mainly to tie into a more general schema, that does not change with each template |
| 22:51 | <gwicke> | there are multiple templates that might map to the same schema.org type |
| 22:52 | <Hixie> | gwicke: i don't understand why you are caring about schema.org if not for search engines |
| 22:52 | <Hixie> | gwicke: why schema.org and not any of the other six gazillion vocabularies out there? |
| 22:52 | <gwicke> | I use schema.org mostly as an illustration |
| 22:53 | <Hixie> | ok let's please stick to concrete problems because if we're going to start fixing sample problems as well we'll be here all day :-) |
| 22:53 | <gwicke> | aye ;) |
| 22:55 | <gwicke> | in general, we would like to add one or more additional itemtypes to an item, where each might only include a subset of the itemprops in the main itemtype |
| 22:55 | <Hixie> | ok but why??? |
| 22:55 | <Hixie> | give me the concrete problem that this would solve that you are actually trying to solve that isn't an illustration |
| 22:56 | <gwicke> | if we define our own itemtype per template, then that makes sense for editing and complete parameter availability |
| 22:56 | <gwicke> | but it would not necessarily serve to identify the shared semantics between two otherwise similar templates |
| 22:56 | <Hixie> | i don't know what "complete parameter availability" means |
| 22:56 | <Hixie> | if you use the same absolute URL for each property that is in common between two itemtypes, then the shared semantic problem would be solved. |
| 22:59 | <gwicke> | that would certainly help to identify 'this is a date', so we could display the date widget in the editor |
| 22:59 | <zcorpan> | so what happened with htmlwg's heart beat? it stopped? |
| 23:00 | <zcorpan> | CPR anyone? |
| 23:01 | <gwicke> | at the same time there seems to be some value in being able to add a standard itemtype and have browsers or search engines use that information |
| 23:03 | <Hixie> | gwicke: "some value" isn't a concrete problem. |
| 23:04 | <Hixie> | gwicke: i see no value if there's no concrete problem being solved. |
| 23:04 | <Hixie> | gwicke: and as i said earlier, in any case, if wikipedia makes up a vocabulary, browser and search engine vendors will adapt to support it |
| 23:05 | <gwicke> | Hixie: each wiki has its own templates and vocabulary, so there would be no standard at all |
| 23:05 | <gwicke> | at least nothing that could be described in a few rules |
| 23:06 | <Hixie> | gwicke: wikipedia, or mediawiki? i thought we were talking about wikipedia. |
| 23:06 | <gwicke> | so we are looking for a way to identify the common things and relate them to more widely used vocabularies |
| 23:06 | <gwicke> | the software is mediawiki, so this system would be available in other wikis too |
| 23:07 | <gwicke> | and wikipedia is made up of a lot of different wikis as well |
| 23:07 | <gwicke> | each with a slightly different template system |
| 23:07 | <gwicke> | template names are often localized for example |
| 23:07 | <Hixie> | gwicke: i don't see how the problems you've described apply to other mediawiki instances (e.g. wiki.whatwg.org) |
| 23:08 | <Hixie> | gwicke: certainly you wouldn't want to localise attribte names per instance of _wikipedia_, that's where documentation comes into play. |
| 23:08 | <Hixie> | gwicke: for this purpose, i think it's reasonable to view all the localisations as one project |
| 23:08 | <gwicke> | the structure is different too |
| 23:09 | <Hixie> | structure of what? |
| 23:09 | <gwicke> | templates |
| 23:09 | <gwicke> | many only exist in some wikis |
| 23:09 | <gwicke> | some are copied around and adapted |
| 23:10 | <gwicke> | there are also presentational parameters, that are not semantically interesting at all |
| 23:11 | <Hixie> | those seem like non-issues from microdata's perspective |
| 23:12 | <gwicke> | except if you would like to expose a subset using a commonly used itemtype |
| 23:12 | <gwicke> | and all of them using an internal itemtype |
| 23:12 | <gwicke> | (and possibly a third, widely used itemtype for a different subset) |
| 23:13 | <Hixie> | good lord, no |
| 23:13 | <Hixie> | that sounds like massive complexity |
| 23:13 | <Hixie> | just have one itemtype for the editor to know what kind of UI to use |
| 23:13 | <Hixie> | and that's it |
| 23:13 | <Hixie> | and for the properties, always use absolute URLs |
| 23:13 | <Hixie> | picked from a common set defined for all localisations |
| 23:14 | <gwicke> | that works for the editor problem, yes |
| 23:15 | <Hixie> | works for all the concrete problems you have given so far |
| 23:15 | <Hixie> | the "researcher" thing, the "people keep asking us questions" thing |
| 23:15 | <Hixie> | and the dbpedia thing |
| 23:15 | <Hixie> | also the search engine and browser vendor things |
| 23:15 | <gwicke> | maybe not the 'browser pops up an offer to add the event to my calendar' use case |
| 23:16 | <Hixie> | why not? |
| 23:16 | <gwicke> | the schema would be specific to some wiki |
| 23:17 | <gwicke> | or would you use absolute urls from some commonly known vocabulary? |
| 23:17 | <zcorpan> | woah. "CfC: Publish ten heartbeat drafts as WDs" |
| 23:24 | <gwicke> | I wonder if itemprops named with an absolute url could be associated with an itemtype that matches its prefix |
| 23:24 | <gwicke> | (and if there are several matches, with the longest matching itemtype) |
| 23:27 | <Hixie> | gwicke: "wikipedia" is not "some wiki" |
| 23:27 | <gwicke> | it is many wikis |
| 23:27 | <Hixie> | gwicke: right, but they can all share a single set of itemprop urls |
| 23:28 | <gwicke> | they could, but there seems to be little value in recreating another vocabulary |
| 23:30 | <gwicke> | at least if external vocabularies already cover what is needed |
| 23:33 | <gwicke> | regarding the prefix idea: if all names for all itemprops used absolute urls, then that could enable mixing itemtypes without identical vocabularies in a single item |
| 23:33 | <Hixie> | you said earlier they didn't |
| 23:33 | <Hixie> | so... |
| 23:33 | <Hixie> | i have no idea what problem you're trying to solve with the prefix thing, so there's no way for me to evaluate it |
| 23:35 | <gwicke> | we have some per-template vocabulary, in which some names might be purely presentational; then we have a subset of those names which could be mapped to a widely used and known vocabulary |
| 23:35 | <gwicke> | absolute urls for itemprops seem to mainly solve the 'type' problem per property |
| 23:36 | <gwicke> | which is still valuable for an editor, but does not present the properties as a single event or the like that can be acted on |
| 23:37 | <gwicke> | in a browser for example |
| 23:38 | <gwicke> | 'add this person to your address book' for example |
| 23:39 | <Hixie> | i don't understand what you mean by "purely presentational". surely nothing "purely presentational" would be in HTML at all, let alone in microdata. |
| 23:39 | <Hixie> | i don't understand what "the 'type' problem" is |
| 23:40 | <Hixie> | what browser wants to add "add this person to your address book"? |
| 23:40 | <gwicke> | Text labels that are not data would fall into that category, singular/plural etc |
| 23:40 | <Hixie> | ok so that seems like something that would just not be in the microdata |
| 23:41 | <gwicke> | or only in an internal itemtype that is mainly used by edit tools |
| 23:42 | <Hixie> | so far i've not seen any use case for itemtype other than the editor UI thing |
| 23:43 | <Hixie> | i need to go soon. as a general comment i have to go back to what i said earlier: before one can figure out a solution to a problem, one needs to figure out what the problem is. |
| 23:43 | <Hixie> | i strongly recommend against trying to solve hypothetical problems that aren't well-defined |
| 23:43 | <gwicke> | ok, thanks for your comments! |
| 23:43 | <Hixie> | it's essentially impossible to come up with good solutions for problems that one doesn't understand |
| 23:44 | <gwicke> | it is hard to define all possible uses as use cases though ;) |
| 23:44 | <gwicke> | but picking some will sure help |
| 23:44 | <Hixie> | when someone wants to solve a problem you haven't yet solved, you can always go back and fix the problem then |
| 23:45 | <Hixie> | you'll do a much better job that way and will avoid wasting time earlier on something nobody ever uses :-) |
| 23:45 | AryehGregor | waves to gwicke |
| 23:46 | <gwicke> | Hixie: ok, will try to define those use cases more tightly |
| 23:46 | <gwicke> | ;) |
| 23:46 | <Hixie> | gwicke: it's perfectly ok to solve one problem one day and another another day, rather than solving all the problems at once :-) |
| 23:47 | <gwicke> | we still have to define our DOM embedding of the wiki stuff, and we would like to make choices that make other uses easy if possible |