| 00:12 | <Hixie> | ok, i mailed about toolbars and menus |
| 00:40 | <Hixie> | MikeSmith: yt? |
| 00:41 | <Hixie> | nevermind |
| 00:42 | <MikeSmith> | Hixie: yeah here now |
| 00:43 | <Hixie> | was just going to ask if it's still tim who decides the FOs on a transition call or if he's handed that potato to someone else |
| 00:44 | <MikeSmith> | it depends on which transition call it is I think |
| 00:45 | <MikeSmith> | some get delegated |
| 00:45 | <Hixie> | ah. whom to? |
| 00:46 | <MikeSmith> | "Those assigned by the Director to manage transitions" |
| 00:47 | <MikeSmith> | "The Director should be invited to attend the meeting if the transition involves contentious issues such as IPR, technical or other concerns" |
| 00:48 | <Hixie> | so, like, plh? |
| 00:48 | <Hixie> | i'm just curious if it is someone i've heard of or not, in practice :-) |
| 00:48 | <Hixie> | (trying to count the number of decision makers in the htmlwg, for an e-mail with jeff) |
| 00:48 | <MikeSmith> | http://w3.org/brief/MzAx |
| 00:49 | <MikeSmith> | Hixie: yeah in every case it's someone you've heard of for sure |
| 00:49 | <Hixie> | k |
| 00:49 | <MikeSmith> | plh would probably be a pretty good guess |
| 01:00 | <Hixie> | GPHemsley: yt? |
| 01:00 | <Hixie> | GPHemsley: i think the message on the wiki is encouraging people who don't need an account to try to get one. |
| 01:00 | <Hixie> | GPHemsley: can we either limit it to pages they might want to edit, or to the login page, or rewrite it to be clearer about only being relevant to people who need to edit the page? |
| 02:42 | <TabAtkins> | Hixie: Sent an email instead (about <ruby>). |
| 02:48 | <Hixie> | TabAtkins: k |
| 03:44 | <MikeSmith> | TabAtkins: about http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Nov/0370.html and "either mark up the ruby correctly ... or incorrectly group the entire thing as one ruby text over one ruby base" |
| 03:45 | <MikeSmith> | I'm not at all sure it's "incorrect" to group the entire thing as one ruby text over one ruby base |
| 03:46 | <MikeSmith> | I don't know who makes the rules that would say that's incorrect, or what conventions there might be outside of the Web |
| 03:47 | <MikeSmith> | but the thing is, those characters have those particular readings when they are used in combination with one another |
| 03:47 | <MikeSmith> | and they can have other readings in other combinations or alone |
| 03:48 | <MikeSmith> | in the example you have 東: in other contexts, the character 東 can be read as ひがし |
| 03:49 | <MikeSmith> | and the character 京 can be read as けい |
| 03:50 | <MikeSmith> | for example, there's a train line between Tokyo and Yokohama and it's called the 京急 line |
| 03:50 | <MikeSmith> | which is read as けいきゅう |
| 03:51 | <Hixie> | side note, japanese seems to be as wacked as english |
| 03:51 | <MikeSmith> | instead of as きょうきゅう |
| 03:51 | <MikeSmith> | heh |
| 03:52 | <MikeSmith> | anyway, given that, somebody might assert that it's actually more "correct" to group the entire thing as one ruby text over one ruby base |
| 03:52 | <MikeSmith> | purely from a markup perspective |
| 03:53 | <MikeSmith> | from a pure markup perspective, it's at least as correct as marking them up separately |
| 03:54 | <MikeSmith> | but of course nobody marks up a document with ruby just for the sake of marking it up with ruby |
| 03:54 | <MikeSmith> | but instead for the effect that it has |
| 03:55 | <MikeSmith> | and the effect for most cases of those two different ways of marking it up is exactly the same |
| 03:56 | <MikeSmith> | anyway, I realize the information is coming from fantasai, the as currently written, the "Inlining ruby" part of your message does not describe any use case |
| 03:57 | <MikeSmith> | it just asserts that one of those ways is more correct than the other, without saying what criteria are use to evaluate how correct either is |
| 03:57 | <MikeSmith> | but the point anyway is not how correct either of them is |
| 03:58 | <MikeSmith> | the point should be whether there's ever any difference in effect between the two |
| 03:58 | <MikeSmith> | and if either of them produces some undesirable effect in some cases |
| 04:15 | <MikeSmith> | the only case I can remember being put forward where the markup difference would produce an undesirable effect is the one described at http://www.w3.org/TR/2009/NOTE-jlreq-20090604/#fig2_30-en |
| 04:18 | <MikeSmith> | the "if the kanji break across multiple lines, the a ruby group can end up getting broken" |
| 04:19 | <MikeSmith> | but I think that case actually argues for grouping the entire thing as one ruby text over one ruby base |
| 04:21 | <MikeSmith> | at least I don't see how having an <rb> element would help in any way for that case |
| 04:36 | <MikeSmith> | ok I guess that "Inlining ruby" TabAtkins message is really just that same as what's already described in http://www.w3.org/TR/ruby-use-cases/#usecaseb |
| 04:37 | <MikeSmith> | "Fallback for multiple bases in one set of parentheses" |
| 04:37 | <MikeSmith> | but that again does not really provide a use case |
| 04:39 | <MikeSmith> | what it says instead essentially is that *if* you choose to not group the entire thing as one ruby text over one ruby base, then in browsers that don't support ruby, you end up with 東(とう)京(きょう) instead of 東京(とうきょう) |
| 04:39 | <MikeSmith> | but the solution to that is just, don't mark them up separately but instead as one ruby text over one ruby base, and you won't have that problem |
| 04:40 | <heycam> | fg |
| 04:40 | <heycam> | fg |
| 04:40 | <MikeSmith> | http://www.w3.org/TR/ruby-use-cases/#usecaseb asserts "Each base character should be annotated individually" but it never explains why |
| 04:40 | heycam | (oops) |
| 04:40 | <MikeSmith> | heh |
| 04:43 | <MikeSmith> | anyway IMHO, continuing discussion about "Inlining ruby" aka "Fallback for multiple bases in one set of parentheses" case is a distraction |
| 04:45 | <MikeSmith> | the real use case and rationale behind that has never been well explained by anybody, even after all the time spent discussing it |
| 04:45 | <MikeSmith> | the only case that really matters is the case where lack for rb has undesirable effects for double-sided ruby |
| 04:46 | <MikeSmith> | and last that I remember most everybody agreed that's an actual problem |
| 04:47 | <MikeSmith> | but just that it's not at all clear how common the problem occurs |
| 04:47 | <MikeSmith> | and so whether the benefits of trying to solve that problem outweigh the costs of adding more complexity to the spec really just to address that one use case |
| 04:52 | <MikeSmith> | actually I think we have agreement that the general double-sided use case is already covered |
| 04:52 | <MikeSmith> | http://www.w3.org/TR/ruby-use-cases/#approachd2 |
| 04:52 | <MikeSmith> | using nested ruby |
| 04:53 | <MikeSmith> | or actually not really the general use case but pretty much every case of double-sided ruby |
| 04:55 | <MikeSmith> | the main argument that's been put forward against authors needing to use nested ruby to solve that problem is, "Having to learn and use two different markup patterns for two nearly identical use-cases is sub-optimal for authors. It would be best if they could just learn one model that works for both." |
| 04:55 | <MikeSmith> | which is not a super-compelling argument |
| 04:56 | <MikeSmith> | and I'm not even sure I agree with that claim at all |
| 04:57 | <MikeSmith> | I don't think that nested ruby is conceptually a different model from non-nested ruby |
| 04:58 | <MikeSmith> | "As you can see, the only difference is that the <rtc> contains a single (implicit) <rt>, rather than two <rt>s. It seems plainly obviously that this is simpler for authors." |
| 04:58 | <MikeSmith> | it's actually not plain to me that it's simpler for authors |
| 07:54 | hsivonen | makes a mental note for future use that WebKit devs can cite Brendan as webkit-dev consensus |
| 09:09 | <zcorpan_> | hmm. pushing to dvcs.w3.org/hg/html now fails for me. auth failed. |
| 09:10 | <zcorpan_> | MikeSmith: ^ any idea? |
| 09:10 | <MikeSmith> | zcorpan_: which repo? |
| 09:10 | <MikeSmith> | oh |
| 09:10 | <MikeSmith> | html |
| 09:10 | <MikeSmith> | lemme check |
| 09:11 | <jgraham> | nessy: What I actually expect to happen with <main> is that W3C HTML will adopt it, probably for the .next version; UAs will implement it (indeed, aiui already are), and the WHATWG will lose epsilon of credibility with authors for not including it. |
| 09:15 | <annevk> | whoa, Hixie logged into twitter |
| 09:19 | <MikeSmith> | zcorpan_: OK auth failing for me to |
| 09:19 | <MikeSmith> | so that's good |
| 09:19 | <MikeSmith> | we're interoperable |
| 09:19 | <jgraham> | scare quotes implied? |
| 09:19 | <MikeSmith> | hah |
| 09:19 | <MikeSmith> | yeah |
| 09:21 | <MikeSmith> | ah I think the reason might be that they're doing DB maintenance |
| 09:21 | <MikeSmith> | oh no |
| 09:21 | <MikeSmith> | that's supposed to be done |
| 09:21 | <MikeSmith> | https://twitter.com/w3c_systeam/status/273392564474900480 |
| 09:22 | <MikeSmith> | "Our database procedure seems to have gone surprisingly smoothly; everything should be all clear now," |
| 09:22 | <MikeSmith> | maybe not so clear |
| 09:22 | <MikeSmith> | darobin: we can't push to the dvcs.w3.org html testsuite repo |
| 09:23 | <MikeSmith> | I suspect it's probably the same for all other repos |
| 09:23 | <jgraham> | Ah, nice delegation there |
| 09:23 | <MikeSmith> | hah |
| 09:23 | <MikeSmith> | I don't delegate to darobin. He allows me to bring things to his attention. |
| 09:26 | <jgraham> | That sounds like a nice scheme you have going there. "I'm not delegating to you, but wouldn't it be sad if all these things were broken?" |
| 09:26 | <MikeSmith> | exactly! |
| 09:26 | <MikeSmith> | ok same for all repos |
| 09:26 | <MikeSmith> | can't push |
| 09:27 | <MikeSmith> | I suspect it's just that it can't reach the ldap directory |
| 09:29 | <MikeSmith> | yeah |
| 09:29 | <MikeSmith> | problem with ldap server |
| 09:34 | <annevk> | http://dom.spec.whatwg.org/#interface-domtokenlist so many subtle differences from Set :/ |
| 09:45 | <darobin> | lol |
| 09:45 | <darobin> | MikeSmith: I also can't connect to the W3C IRC server |
| 09:45 | <darobin> | so I suspect there's a broader system failure |
| 09:45 | <MikeSmith> | blame ldap |
| 09:45 | <darobin> | "Access denied: Bad password?" yup |
| 09:46 | <darobin> | well, who needs dvcs anyway? |
| 09:46 | <darobin> | as soon as we get the CR out, I'll be moving the TS to GitHub (and moving the tests to the scheme that jgraham described) |
| 09:46 | <jgraham> | Well if you just used github you wouldn't have these problems</tobie> |
| 09:46 | <jgraham> | Heh |
| 09:47 | <darobin> | you channel tobie remarkably well |
| 09:47 | <MikeSmith> | I would love to see dvcs.w3.org retire |
| 09:48 | <darobin> | eventually it probably will |
| 09:48 | <MikeSmith> | or at least would love to retire from it |
| 09:48 | <darobin> | thankfully there's nowhere near as much depending on it as CVS |
| 09:48 | <darobin> | we will probably never manage to leave CVS |
| 09:48 | <darobin> | that is, unless the WHAT WG acquires W3C and then we'll be stuck with SVN :) |
| 09:49 | <MikeSmith> | Hixie still depends on CVS for the WebVTT spec |
| 09:49 | <karlcow> | :D |
| 09:49 | <darobin> | man, when you look at all those old SDOs using obsolete software... we should just start a new one |
| 09:50 | <darobin> | ah, LDAP seems fixed |
| 09:50 | <karlcow> | darobin: no software! Dance and poetry under the moon around the fire. That's the way to do it. |
| 09:50 | <MikeSmith> | darobin: yeah, working for me |
| 09:50 | <darobin> | yay! |
| 09:51 | <darobin> | karlcow: and we make all decision in best-of-three air hockey games |
| 09:51 | <karlcow> | :D |
| 09:51 | <darobin> | frankly, I'm not sure that anyone would notice the difference |
| 09:52 | <jgraham> | I thought that *was* the HTMLWG officiasl decision making process? |
| 09:53 | <darobin> | nah |
| 09:53 | <jgraham> | rubys vs othermaciej vs paulc in bar sports |
| 09:53 | <othermaciej> | what what what? |
| 09:54 | <darobin> | the official decision policy is we just keep moving bugs to a never-attained-but-perfect .next and do whatever we want in the meantime :) |
| 09:54 | <othermaciej> | I would support decision by air hockey |
| 09:54 | <othermaciej> | I think that is better than what the majority of standards orgs use |
| 09:54 | <othermaciej> | though I would prefer a game I am good at |
| 09:56 | darobin | didn't pick that one at random :) |
| 09:57 | <darobin> | we could also do snooker |
| 10:01 | <MikeSmith> | I think the game should be that people just keep repeating the same arguments, over many years, and getting defensive when people disagree with them, and also impugning other people's motives a lot |
| 10:01 | <MikeSmith> | that'd be a fun game |
| 10:01 | <MikeSmith> | if we played it, say, for like 5 1/2 years or whatever |
| 10:01 | <karlcow> | … ^_o |
| 10:02 | <MikeSmith> | hey, and then we could also have a lot of jackasses trolling about it twitter a lot |
| 10:02 | <MikeSmith> | that'd be a cool feature |
| 10:02 | <karlcow> | what is twitter? :p |
| 10:03 | <karlcow> | if at least I could get drunk without being sick. Maybe I could cope with that game MikeSmith |
| 10:04 | <MikeSmith> | hey I wish I could feel normal without being drunk |
| 10:04 | <MikeSmith> | speaking in character that is |
| 10:05 | <MikeSmith> | as the character I play |
| 10:06 | <MikeSmith> | anyway, I think the winners of this hypothetical game would be the people who say fuck it and go off to become the owner of a nightclub instead, or a bicycle shop |
| 10:07 | <karlcow> | I take the "planting rice" option |
| 10:09 | <karlcow> | or maybe cheese shop in Hayama… thinking more about it. |
| 10:13 | jgraham | thinks planting rice probably isn't much fun |
| 10:14 | <jgraham> | I could certainly give selling cheese a go though |
| 10:14 | <jgraham> | If I got to have a really *nice* cheese shop |
| 10:19 | <MikeSmith> | I've always dreamed of living alone in tiny apartment in, say, Tokyo or somewhere, and could go to late-night Denny's to eat and work if they had 90MBps wifi and I'd reached the 7GB-per-month download limit on the Android smartphone I'd normally be using for tethering |
| 10:19 | <MikeSmith> | that'd be the life |
| 10:20 | <MikeSmith> | also if I wanted to build Webkit and Chromium for sources to test stuff |
| 10:21 | <annevk> | jgraham: is http://darobin.github.com/test-harness-tutorial/docs/using-testharness.html the best documentation? |
| 10:21 | <jgraham> | annevk: On which axis of quality? |
| 10:21 | <annevk> | someone asking how to write tests |
| 10:21 | <jgraham> | Yes |
| 10:22 | <annevk> | i will cc you for remaining questions :) |
| 10:22 | <MikeSmith> | is that the side-by-side one? |
| 10:22 | MikeSmith | looks |
| 10:26 | <annevk> | MikeSmith: message is on member-i18n-core |
| 10:26 | <annevk> | MikeSmith: and I was cc'd because otherwise I would not have known :-) |
| 10:30 | <nessy> | jgraham - just saw your earlier message - the <main> discussion has just become so ridiculous - it's not worth explaining things any more |
| 10:30 | <nessy> | jgraham: there are more important things to discuss :-) |
| 10:31 | <annevk> | yeah, like longdesc |
| 10:31 | <jgraham> | nessy: Indeed. I think the course is now set and I can't see much changing by further argument |
| 10:31 | <nessy> | annevk: lol |
| 10:32 | <nessy> | annevk: but seriously - @longdesc is borked because different browsers do different things with it - it's not borked by design |
| 10:32 | <nessy> | annevk: but going down that path is just a rathole |
| 10:32 | <nessy> | it's actually quite funny - any discussion about a11y features can not be turned into the ridiculous by just mentioning @longdesc |
| 10:33 | <jgraham> | I think I disagree about longdesc. But I have seen this ratehole before and I am going to slowly back away from the entrance |
| 10:33 | <jgraham> | *rathole |
| 10:33 | <nessy> | lol |
| 10:35 | <annevk> | nessy: I'm happy to mostly be working on non-HTML specs and when I touch HTML it's usually API or architecture land and not semantics |
| 10:36 | <MikeSmith> | höllenloch |
| 10:37 | <nessy> | annevk: I'm impressed with the URI stuff you're doing |
| 10:38 | <zcorpan_> | MikeSmith: darobin: thanks |
| 10:39 | <darobin> | zcorpan_: not sure what I'm being thanked for, but you're welcome at any rate :) |
| 10:39 | <nessy> | (eh I think you prefer s/URI/URL/ - sorry - old habits don't die easily) |
| 10:39 | <darobin> | shouldn't it be renamed to IRI? |
| 10:39 | darobin | vanishes in case anyone bites |
| 10:39 | <annevk> | nessy: heh, thanks, it's getting there, but the IDN stuff is annoying |
| 10:40 | <zcorpan_> | darobin: in case you did something that helped fixing the ldap issue. if you didn't, then please disregard the thanks! :-P |
| 10:40 | <darobin> | zcorpan_: oh man, I'm sorry to say that neither MikeSmith nor I had anything to do with that |
| 10:40 | <darobin> | W3C has a kick arse systems team |
| 10:40 | <nessy> | annevk: have you thought about specifying query params? |
| 10:40 | <MikeSmith> | zcorpan_: what darobin said |
| 10:40 | <zcorpan_> | bringing it to their attention counts as helping |
| 10:41 | <zcorpan_> | but maybe they knew about it already |
| 10:41 | <annevk> | nessy: only in API form |
| 10:41 | <annevk> | nessy: probably matching the application/x-www-form-urlencoded syntax |
| 10:41 | <darobin> | zcorpan_: given the level of monitoring they have, I wouldn't be surprised if they knew before anyone noticed there was a problem |
| 10:41 | <MikeSmith> | yeah |
| 10:41 | <MikeSmith> | the watchdogs are watching |
| 10:42 | <darobin> | most of the time when I go to report a problem they're already talking about the fixes |
| 10:42 | <nessy> | annevk: that's what I was hoping for |
| 10:44 | <annevk> | nessy: I don't think I'll ever include it directly in the URL parser because it isn't used in that way by many URL schemes, but for the API it makes sense as that's mostly used for http/https/file |
| 10:44 | <annevk> | biab |
| 10:52 | <MikeSmith> | JS question: what's the best-practice alternative for doing the equivalent of jquery $.data() ? |
| 10:53 | <MikeSmith> | I have some code I want to use that relies on JQuery methods but having JQuery for this code in this case is just overkill |
| 10:54 | <MikeSmith> | it is bad practice to just add a custom properties to the element and store the data there? |
| 10:55 | <MikeSmith> | or are there any gotchas or doing that? |
| 10:55 | <MikeSmith> | is that the way people normally do it without using some library? |
| 10:55 | <jgraham> | Well if you use a data-* attribute name that is fine |
| 10:56 | <jgraham> | (one could argue that there are problems with putting your data directly in the DOM in general, but if your application is too small for jQuery it is certainly too small for that) |
| 10:56 | <annevk> | MikeSmith: use element.dataset? y u no HTML5?!!1! |
| 10:56 | <MikeSmith> | heh |
| 10:56 | <MikeSmith> | but I can only use strings for that right? |
| 10:57 | <jgraham> | You can only store strings in attributes in general? |
| 10:57 | <jgraham> | Unless jQuery is setting IDL attributes I guess |
| 10:58 | <annevk> | MikeSmith: yeah, setting expandos is somewhat dangerous as you might clash with future extensions to the DOM and such |
| 10:58 | <annevk> | MikeSmith: maybe we should have a dataany thingie that holds anything and recommend people to use that, dunno |
| 10:59 | <MikeSmith> | jgraham: yeah I meant directly setting IDL attributes |
| 10:59 | <annevk> | hmm |
| 10:59 | <annevk> | I'm starting to get to the point where I need to update fetch |
| 11:00 | <annevk> | maybe I should use a wiki for now to define the about and javascript schemes? |
| 11:00 | <MikeSmith> | annevk: I don't care much about clashing with future extensions to the DOM. I can just rewrite the code if I get to a case like that |
| 11:00 | <annevk> | MikeSmith: then just do element.whatever = whatever I guess |
| 11:00 | <MikeSmith> | ok |
| 11:01 | <annevk> | MikeSmith: maybe with a prefix so if people copy your code there's less of a chance |
| 11:01 | <MikeSmith> | annevk: rather than wiki, maybe a github repo that people can make pull requests for, and then you set up a GH pages branch to auto-publish from it |
| 11:01 | <MikeSmith> | annevk: yeah, OK |
| 11:02 | <MikeSmith> | I think I'll choose the prefix "vnu-" for this case |
| 11:02 | <annevk> | MikeSmith: well yeah, I can do the whole GitHub thing, but the point is that these need to be in whatwg/fetch |
| 11:02 | <annevk> | but I don't want to take all of fetch on right now |
| 11:02 | <MikeSmith> | ah |
| 11:03 | <annevk> | actually, javascript might need to be in HTML in the end, as subsection of navigate |
| 11:03 | <MikeSmith> | why? |
| 11:03 | <annevk> | because it will only function within that context |
| 11:04 | <annevk> | <img src=javascript> would just be a network error |
| 11:04 | <annevk> | (javascript URLs would never reach fetch is the plan) |
| 11:04 | <annevk> | http://wiki.whatwg.org/wiki/URL#Schemes has a rough outline of my thinking at this point for the distribution |
| 11:14 | MikeSmith | reads |
| 11:16 | <MikeSmith> | a mailto scheme is not necessarily external |
| 11:16 | <MikeSmith> | doesn't necessarily need to launch an external application |
| 11:16 | <MikeSmith> | if the app the link is in is itself a handler for mailto |
| 11:16 | <MikeSmith> | same goes for skype |
| 11:18 | <MikeSmith> | othermaciej: can I get editbugs for WebKit bugzilla or is that only for committers and reviewers? |
| 11:18 | <othermaciej> | MikeSmith: yes, you can |
| 11:19 | <MikeSmith> | ok |
| 11:19 | <MikeSmith> | who should I ping? |
| 11:19 | <othermaciej> | MikeSmith: can you see if anyone on #webkit can hook you up? |
| 11:19 | <MikeSmith> | yup |
| 11:19 | <MikeSmith> | thanks |
| 11:19 | <othermaciej> | I have the power to do it but I really need to sleep |
| 11:19 | <MikeSmith> | ok |
| 11:19 | <MikeSmith> | np |
| 11:22 | <darobin> | MikeSmith: I think that in the rPH case you should still consider it "external" |
| 11:22 | <darobin> | even if external is yourself reloaded |
| 11:23 | <MikeSmith> | ok |
| 11:25 | <annevk> | MikeSmith: it's a broad kind of "external"; maybe I should rename it to "execute" or some such |
| 11:26 | <annevk> | ah yeah, and the registerProtocolHandler() case is handled before that, by navigating to some http/https thingie instead |
| 12:05 | <MikeSmith> | "Shopping a patch to implementors, to get something into a standard spec by asserting de-facto status based on the patch(es) landing, is bad form." |
| 12:06 | <MikeSmith> | but it's good form to say that on the dev list of a browser project other than your own, and impugn somebody else's motives who's making a code contribution and providing tests for it |
| 12:06 | <MikeSmith> | classy |
| 12:08 | <annevk> | He has a point though, I also think it's bad if the spec, the implementation, and the tests are all written by the same person |
| 12:08 | <MikeSmith> | even if nobody else stepped forward to write them? |
| 12:09 | <MikeSmith> | the guy cares enough about this to take the time to do all that |
| 12:09 | <MikeSmith> | and he's not a guy who's sitting around with a lot of time on his hands |
| 12:10 | <MikeSmith> | de-moralizing people who are trying in good faith to contribute something is not helpful |
| 12:11 | <MikeSmith> | normally I don't give a shit |
| 12:12 | <MikeSmith> | but I don't like to see people get bullied |
| 12:12 | <MikeSmith> | r |
| 12:13 | <annevk> | You must see that <main> is not exactly set in stone and that there's clearly some people not liking it and some people liking it? |
| 12:13 | <tobie> | that's orthogonal to MikeSmith's point, though. |
| 12:13 | <annevk> | Maybe a bad analogy, but the people behind XForms also wrote patches for Gecko and did a bunch of work, only to see it rejected down the line. |
| 12:14 | <tobie> | I think MikeSmith smith was commenting on the form of the rejection, rather than the rejection itself. |
| 12:14 | <annevk> | Well if you take Brendan's email as rejection for the WebKit project I think you're being silly. He obviously has no power whatsoever there. |
| 12:16 | <MikeSmith> | annevk: of course I know it's not set in stone |
| 12:16 | <tobie> | s/rejection/comment/ |
| 12:17 | <tobie> | :) |
| 12:17 | <MikeSmith> | and obviously there's some disagreement about it and I frankly don't personally care much how it works out either way |
| 12:17 | <MikeSmith> | I would be happy if none of the HTML5 structural elements ever existed |
| 12:18 | <MikeSmith> | but there was not intent here to "get something into a standard spec by asserting de-facto status based on the patch(es) landing" as far as I can tell |
| 12:18 | <annevk> | Oh, that was certainly my impression |
| 12:21 | <tobie> | I'm increasingly convinced `main` is just a honey pot. Not yet sure who the master mind behind it is. |
| 12:22 | <tobie> | ;) |
| 12:24 | <smaug____> | annevk: why does getElementsByTagName in DOM(4) work differently from the same method in DOM 3 ? |
| 12:27 | <MikeSmith> | it's not my impression |
| 12:27 | <MikeSmith> | maybe I'm wrong |
| 12:28 | <MikeSmith> | but he's not in a position to unilaterally get something implemented |
| 12:29 | <MikeSmith> | if there's fault there, it's a fault of naiveté about how it would be perceived and received |
| 12:30 | <MikeSmith> | also, regarding "the high bar required to add a new element to HTML", yeah I remember that high bar from the time when the <menuitem> landed |
| 12:31 | <MikeSmith> | I remember the extensive public discussion we all had about that before the code went in |
| 12:42 | <annevk> | smaug____: what is different? |
| 12:44 | <annevk> | MikeSmith: that it landed does not make it a done deal; Microsoft landed VML years ago, now it's like it never happened |
| 12:45 | <annevk> | MikeSmith: but sure, there's a lot of hypocrisy :-) |
| 12:45 | <smaug____> | annevk: DOM3 works on tagNames, like the method name says, DOM uses localName |
| 12:45 | <annevk> | smaug____: I think that's because hsivonen asked for that |
| 12:46 | smaug____ | kicks hsivonen :) |
| 12:47 | <annevk> | smaug____: I don't remember the fine details right now, but I suspect it was because of HTML and XHTML integration |
| 12:47 | <smaug____> | yeah |
| 12:47 | <smaug____> | https://bugzilla.mozilla.org/show_bug.cgi?id=816012 |
| 12:48 | <smaug____> | it just feel very risky to change the behavior |
| 12:49 | <annevk> | I also think different browsers did different things already |
| 12:49 | <smaug____> | very likely |
| 12:55 | <MikeSmith> | I guess in contrast the hypocrisy around the spec republishing is an unsurprising hypocrisy |
| 12:55 | <MikeSmith> | it's part of a hypocrisy bundle |
| 12:56 | <MikeSmith> | hypocrisy coming from somebody you actually respect is a different kind of thing |
| 12:57 | <MikeSmith> | anyway I guess I should just stay out of it |
| 13:06 | <annevk> | MikeSmith: I often wish I had :-) |
| 13:06 | <annevk> | btw http://wiki.whatwg.org/wiki/URL_schemes |
| 13:07 | annevk | fixes the mistakes |
| 13:07 | <smaug____> | about:invalid ? |
| 13:08 | <MikeSmith> | wow i didn't even know about http://www.iana.org/assignments/about-uri-tokens/about-uri-tokens.xml .. when you obsolete something that's totally obscure is it still called "obsoleting"?... |
| 13:09 | <annevk> | smaug____: some CSS thing apparently |
| 13:09 | <annevk> | I guess I should add links |
| 13:09 | <smaug____> | I wonder why CSS needs about:invalid |
| 13:10 | <annevk> | it was explained to me at some point and then I promptly forgot, but I remember the reasoning was sound |
| 13:11 | <MikeSmith> | http://www.ietf.org/mail-archive/web/uri-review/current/msg01606.html |
| 13:11 | <MikeSmith> | it seems |
| 13:12 | <MikeSmith> | "when a URI is necessary, but the default value shouldn't be resolveable as any type of document." |
| 13:12 | <MikeSmith> | http://www.w3.org/TR/css3-values/#about-invalid |
| 13:24 | <Ms2ger> | smaug____, forgot you already reviewed my patch for getElementsByTagName? :) |
| 13:25 | <smaug____> | Ms2ger: but we didn't change the behavior |
| 13:26 | <smaug____> | Ms2ger: you didn't land the patch ? |
| 13:26 | <Ms2ger> | No, because you r-'d |
| 13:26 | <smaug____> | ahaa |
| 13:26 | <smaug____> | good! :) |
| 13:26 | <smaug____> | I can't remember what all I remember |
| 13:26 | <smaug____> | er |
| 13:26 | <smaug____> | oops |
| 13:27 | <smaug____> | I can't remember what all I review |
| 13:27 | <smaug____> | silly me |
| 13:28 | <Ms2ger> | Well dammit |
| 13:28 | <Ms2ger> | jgraham, timeout() still doesn't work :/ |
| 13:28 | <jgraham> | Ms2ger: Oh. Well that seems like a bug then |
| 13:29 | <jgraham> | wilhelm_: Interesting, thanks |
| 13:30 | <Ms2ger> | jgraham, (I guess that's the server we use for mobile testing) |
| 13:30 | <annevk> | SimonSapin: yo, you could add data URLs here for now if you want: http://wiki.whatwg.org/wiki/URL_schemes |
| 13:39 | <MikeSmith> | http://lists.w3.org/Archives/Public/public-html-comments/2012Nov/0008.html "I've not heard compelling arguments for why Microdata doesn't deserve to be a CR, rather I've only heard protectionism." |
| 13:39 | <MikeSmith> | bravo |
| 13:39 | <MikeSmith> | good application of the word "protectionism" |
| 13:39 | <MikeSmith> | apt |
| 13:42 | <marcosc> | STRAWMAN!!!! |
| 13:42 | <marcosc> | :) |
| 13:43 | <Ms2ger> | Who cares? |
| 13:44 | <SimonSapin> | annevk: you mean adding what? Start collecting spec ambiguities? |
| 13:44 | <annevk> | SimonSapin: and defining the new spec :) |
| 13:44 | <marcosc> | Ms2ger: agreed |
| 13:45 | <annevk> | If the W3C blocks Microdata, it's 2004 all over again. |
| 13:45 | <SimonSapin> | annevk: I wanted to start with tests, so that would need some JS to run |
| 13:45 | <marcosc> | annevk: that's what I told them too |
| 13:45 | <annevk> | I'm on the fence whether I would find that enjoyable or simply bad |
| 13:46 | <annevk> | SimonSapin: fair enough |
| 13:47 | <MikeSmith> | Microdata is not going to be blocked |
| 13:48 | <MikeSmith> | the story on this was already written a long time ago |
| 13:48 | <Ms2ger> | Let's block ALL THE THINGS |
| 13:48 | <MikeSmith> | on the assumption that everybody was acting in good faith |
| 13:49 | Ms2ger | tries really hard to avoid a cynical response |
| 13:49 | <MikeSmith> | there's no support anywhere for coming around after to attempt to re-write the story |
| 13:49 | <kennyluck> | annevk, how is that the same? In 2004, you care about HTML. Do you care about Microdata now? |
| 13:50 | <annevk> | kennyluck: it's not really about me, it's just about the situation |
| 13:50 | <kennyluck> | Isn't it true that Microdata doesn't have a driving force like HTML used to have? |
| 13:51 | <jgraham> | This is the kind of "anywhere" that exlcudes the people who are trying to rewrite the story, right? |
| 13:51 | <marcosc> | kennyluck: agree with annevk. It's an attempt by one group to abuse the w3c process to block something else. |
| 13:51 | <annevk> | kennyluck: sounds false to me, unless you diccount schema.org somehow... |
| 13:51 | <darobin> | a small group, too |
| 13:51 | <darobin> | since that's not even the position of the RDFa group |
| 13:51 | <marcosc> | darobin: it's also the position of the chair of RDF, it seems |
| 13:52 | <marcosc> | at least that's what I understood from a public-html-comment email |
| 13:52 | <darobin> | marcosc: which one? |
| 13:52 | <annevk> | and of timbl, via a Twitter RT |
| 13:53 | <marcosc> | darobin: http://lists.w3.org/Archives/Public/public-html-comments/2012Nov/0003.html |
| 13:53 | <kennyluck> | annevk, I don't see many people sending feedback about the spec on the WHATWG list. |
| 13:53 | <darobin> | I think that timbl will recuse himself from that decision |
| 13:53 | <darobin> | marcosc: *shrug*, it's just his position as an individual, he's not speaking for the RDF WG |
| 13:53 | Ms2ger | yawns |
| 13:53 | <annevk> | kennyluck: it's not as big as saying no to the entire platform we're building, is that the point you're making? |
| 13:53 | darobin | joins Ms2ger |
| 13:54 | <annevk> | naptime? |
| 13:54 | <marcosc> | darobin: I knows :) I'm also going to go hang out with Ms2ger now. |
| 13:54 | <Ms2ger> | annevk, useful work time ;) |
| 13:54 | <darobin> | we've now reached the point at which this microdata non-event has been discussed here more than on public-html |
| 13:54 | <annevk> | Ms2ger: I'm weeks ahead of schedule |
| 13:54 | <darobin> | talk about signal-to-noise ratio problems! |
| 13:54 | <annevk> | for once |
| 13:55 | <annevk> | maybe because I'm not employed |
| 13:55 | <annevk> | darobin: yeah, I'm out of things to do so I figured I could waste some time discussing non-issues :-) |
| 13:55 | <marcosc> | annevk: Barbara tells me I work more now that I'm also unemployed. Isn't that strange :) |
| 13:56 | <darobin> | annevk: go fix HTTP or something |
| 13:56 | <annevk> | marcosc: clearly someone should pay us for not being employed |
| 13:57 | <marcosc> | annevk: agreed! |
| 13:57 | <jgraham> | annevk: Organise some meetings. That should kill your productivity. |
| 13:57 | <annevk> | wanna get together to discuss Microdata? |
| 13:58 | <jgraham> | I ahve a job and therefore meetings already |
| 13:58 | <jgraham> | Go discuss it with marcosc |
| 13:58 | <annevk> | next thing on my list is URLQuery |
| 14:00 | <kennyluck> | annevk, the point I am making is that the person who designed the spec doesn't actually work with the use cases. If the schema.org people (or other people who care about the use cases) were the ones who wrote the spec and still either actively maintain it or send feedback, I probably have different opinion. |
| 14:01 | <annevk> | kennyluck: not sure what that means |
| 14:02 | <annevk> | kennyluck: and Hixie does actively maintain Microdata and makes adjustments to it based on feedback, it's not dead |
| 14:03 | <kennyluck> | annevk, that I don't agree (the "actively" part), and I never have an idea why schema.org people don't show up on the mailing list. |
| 14:04 | <marcosc> | kennyluck: that's quite irrelevant to the discussion, IMO. |
| 14:05 | <annevk> | kennyluck: what's actively then? last change was a couple of days ago |
| 14:06 | <annevk> | kennyluck: and it seems kind of irrelevant, we're hardly discussing <head> these days, if somebody came along and said <head> should not proceed because, well <head2> is cooler, what then? |
| 14:07 | <annevk> | Ms2ger: btw, I'm gonna add initCustomEvent back |
| 14:07 | <Ms2ger> | wfm |
| 14:08 | <kennyluck> | annevk, http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Jun/0096 takes three months for a feedback. Would you really consider that "actively maintained"? |
| 14:08 | <kennyluck> | annevk, no body would send a <head2> proposal anyway. But Microdata is different. |
| 14:09 | <Ms2ger> | 3 months? That's pretty good |
| 14:10 | <annevk> | kennyluck: dunno, the DOM has outstanding feedback from well over a year |
| 14:10 | <annevk> | kennyluck: I consider it actively maintained |
| 14:10 | <darobin> | actually a <head2> proposal could be a great way of adding new header stuff without Henri coming to your door with a silencer gun |
| 14:12 | <marcosc> | kennyluck: I have to agree. 3 months is generally considered ok. We don't want to give the impression that standards can move quickly. |
| 14:13 | <kennyluck> | *shrug* |
| 14:15 | <kennyluck> | I don't care about that notion of standards. ;) |
| 14:15 | <marcosc> | kennyluck: the point is, don't sit around and wait for stuff. Just work around the problem and get it (whatever that may be) done... except by abusing the W3C process with stupid formal objections. |
| 14:17 | <marcosc> | kennyluck: if the goal of the semantic web folks is to get structured data into HTML5 - and HTML5 gives you a mechanism that, as RDFa folks claim, is identical to RFDa, then you've already won. |
| 14:18 | <Ms2ger> | marcosc, it's identical, but it sucks |
| 14:20 | <annevk> | marcosc: except when it's called srcset right? |
| 14:20 | <marcosc> | annevk: exactly! |
| 14:21 | <kennyluck> | marcosc, as Hixie often says. The process is irrelevant. Play with it when you have time. |
| 14:21 | <marcosc> | rdf:srcset |
| 14:22 | <marcosc> | speaking of srcset ... about to file bugs on that https://gist.github.com/4161268 |
| 14:37 | <annevk> | Ms2ger: so I'm looking at http://w3c-test.org/webapps/DOMCore/tests/submissions/Ms2ger/Node-replaceChild.html |
| 14:37 | <annevk> | Ms2ger: and https://www.w3.org/Bugs/Public/show_bug.cgi?id=17318 |
| 14:38 | <annevk> | Ms2ger: and the results for the test seem different from what you say they are |
| 14:38 | <Ms2ger> | Seems possible |
| 14:38 | <Ms2ger> | Maybe stuff changed |
| 14:39 | <Ms2ger> | brb phone |
| 14:40 | <annevk> | Ms2ger: Chrome never seems to throw NotFoundError (or you missed a case) |
| 14:40 | <annevk> | Ms2ger: Opera and Firefox have when they throw NotFoundError reversed |
| 14:41 | karlcow | is trying to replace the "benefits of the doubt" by the "benefits of the FUD" in my vocabulary |
| 14:43 | <annevk> | Ms2ger: I think doing HierarchyRequestError all the time might be simplest |
| 14:45 | <Ms2ger> | I dunno, I guess |
| 14:45 | <annevk> | Ms2ger: the other option is adding an extra step |
| 14:46 | <annevk> | Ms2ger: or have an implementation per node type (which I think some implementations have) |
| 14:46 | <Ms2ger> | Yeah, WebKit does that |
| 14:46 | <annevk> | Ms2ger: funnily enough they also do the thing with HierarchyRequestError all the time |
| 14:48 | <annevk> | Ms2ger: ooh fuck |
| 14:49 | <annevk> | Ms2ger: so maybe it should just align with pre-insert? |
| 14:49 | <Ms2ger> | Sounds good |
| 14:49 | <annevk> | Ms2ger: because pre-insert does what the old DOM spec said |
| 14:49 | <annevk> | it has more checks, but I guess that's acceptable |
| 14:50 | <annevk> | did I mention I don't like these algorithms? |
| 14:50 | <Ms2ger> | Maybe once or twice :) |
| 14:53 | <annevk> | Ms2ger: should I leave the bug open for you to fix the tests? |
| 14:53 | <Ms2ger> | Wait, weren't you going to match the test? :) |
| 14:54 | <annevk> | the test matches the spec |
| 14:54 | <annevk> | the new spec matches Gecko |
| 14:54 | <annevk> | and if the test is fixed, Gecko would have no failures |
| 14:55 | <annevk> | (also matches DOM3 per some reading of DOM3) |
| 14:55 | <Ms2ger> | Er, you're right |
| 14:55 | <Ms2ger> | Lemme fix the test now |
| 15:02 | <annevk> | Looking at https://www.w3.org/Bugs/Public/show_bug.cgi?id=18581 now |
| 15:02 | <annevk> | I guess we can move some of those checks up |
| 15:05 | <annevk> | smaug____: should we put getElementsByTagName() and friends on DocumentFragment too? |
| 15:05 | <annevk> | smaug____: i.e. put it on rootnode |
| 15:06 | <smaug____> | yes, makes sense |
| 15:07 | <manu1> | marcosc: The reason I keep calling staw man on your arguments is that you continue to mis-represent the point I'm attempting to make as if there is some conspiracy going on. The Microdata objection isn't the position of the RDFa WG, it's not my position as chair of the RDFa WG, it's my opinion as a member of the HTML WG. You can call it protectionism if you want to, but I don't see it that... |
| 15:07 | <manu1> | ...way at all. I'm expressing an opinion and trying to see what others in the group think. |
| 15:07 | <Ms2ger> | Dammit |
| 15:07 | <Ms2ger> | Not again |
| 15:08 | <manu1> | I'm sure it's easy to paint it in the light that you have done as it removes all of the nuance in the argument and makes it seem as if I am taking a far more extreme position as I am taking. I specifically avoided raising a formal objection at this point to try and ease into the discussion, but there really is no easy way of saying: "I don't agree with what we're doing and I think it needs... |
| 15:08 | <manu1> | ...to change." |
| 15:10 | <manu1> | Don't worry, Ms2ger, just clearing up the broad-brush statements that marcosc keeps asserting as my position (which is clearly not my position). |
| 15:10 | <manu1> | I'm done. |
| 15:11 | <annevk> | manu1: marcosc is trying the "Mad Max" approach |
| 15:12 | <manu1> | decisions always seem easier when you make it about "all or nothing" or "good vs. evil" or "Group A vs. Group B" |
| 15:13 | <manu1> | just pointing out that I'm specifically trying to suggest that we DO NOT do it that way. |
| 15:15 | <annevk> | manu1: you mean http://manu.sporny.org/2012/microdata-cr/ was not written by you? |
| 15:16 | <manu1> | annevk: Be direct, don't beat around the point you're trying to make. What's your point? |
| 15:16 | <annevk> | manu1: my point is that you are advocating a vs b; and you've chosen a |
| 15:17 | <annevk> | manu1: threatening with the near-meaningless "W3C Formal Objection" and such |
| 15:17 | <annevk> | manu1: calling people to arms |
| 15:17 | <annevk> | manu1: anyway, I got some DOM bugs to fix |
| 15:17 | <manu1> | That's a bit melodramatic, don't you think? |
| 15:18 | <annevk> | I think you are, yes :-) |
| 15:19 | <manu1> | All I'm saying is this: RDFa is already a REC, that's done. RDFa Lite basically does what Microdata does, so why do we have Microdata? Microdata goes to a W3C Note. W3C gets clarity on publishing specs that heavily overlap. People can still choose. |
| 15:20 | <annevk> | You make it sound like a REC means anything. HTML4/DOM2/CSS1/etc. are all evidence to the contrary. |
| 15:21 | <manu1> | if REC doesn't mean anything to you, then why is this such a big deal, then? |
| 15:22 | <annevk> | Because I'd like the W3C to work, but if it keeps repeating its mistakes of the past it obviously won't. |
| 15:22 | <manu1> | I'd like the W3C to work as well, and I think publishing two specs that accomplish basically the same thing in basically the same way shows breakage. |
| 15:34 | <annevk> | Bit late for that. XDM vs DOM, XPath vs Selectors, XSL-FO vs CSS, XSLT vs XQuery, XQuery vs XQueryX, RDF/XML vs Turtle, XForms vs Web Forms 2.0, XHTML 1.0 vs HTML 4.01, XML 1.0 4th Edition vs XML 1.0 5th Edition, XML 1.0 vs XML 1.1, etc. |
| 15:36 | <darobin> | heh |
| 15:36 | <darobin> | not all of those are fair |
| 15:36 | <darobin> | but I guess that's not the point :) |
| 15:37 | <jgraham> | FWIW I think blocking specs for political reasons shows breakage |
| 15:40 | <GPHemsley> | Hixie: Hopefully addressed the wiki issue, independent of your message. |
| 15:41 | <GPHemsley> | Hixie: All writing systems are gonna be wacky in some cases. |
| 15:41 | <GPHemsley> | wacked, too |
| 15:41 | <manu1> | jgraham: You're assuming to know what I'm thinking - that I'm doing this for political reasons. I have stated why I'm doing this - It's not for political reasons. I'm doing this because I think publishing both of these specs as RECs is a bad idea (and I've outlined why I think it's a bad idea). |
| 15:42 | <manu1> | I want the community to have a discussion about this. |
| 15:44 | <manu1> | If you take what I'm saying and choose to brush it aside and replace it with your own opinion of what I'm trying to do, then that's your prerogative. Just know that your opinion of what I'm doing is not aligned with what I'm actually trying to do. |
| 15:47 | <manu1> | annevk: Again - my point isn't about preventing competing technologies from both going to REC at W3C... it's about preventing competing technologies where you can search/replace keywords and translate between the two going to REC at W3C. There is a sliding scale here, it's not an all-or-nothing situation. To put it another way: When you can use a regex to switch from RDFa Lite to Microdata... |
| 15:47 | <manu1> | ...and back, that seems like a good signal that syntaxes have effectively converged. |
| 15:48 | <jgraham> | I am happier letting the entire community evaluate with their actions rather than a small subset with their words |
| 15:48 | <manu1> | and the question I'm raising is: If two solutions are almost technically indistinguishable - should both of those technologies go to REC. I'm asserting that they shouldn't - others disagree. |
| 15:49 | <manu1> | jgraham: There is nothing to prevent that from happening if Microdata is published as a W3C Note. |
| 15:51 | <jgraham> | manu1: It is very hard to take you seriously when you are on one hand pushing very hard for something to be taken off the Rec. track and on the other saying that whether it is on the Rec. track doesn't matter |
| 15:52 | <manu1> | jgraham: Why do you feel that those two things are contradictory? |
| 15:52 | <manu1> | Looking at it from a W3C perspective, I think W3C should standardize on one thing when the technical solutions are so similar. |
| 15:53 | <gavinc> | Serious question, does anyone NOT think that Microdata and RDFa 1.1 Lite are technically equivalent? |
| 15:53 | <gavinc> | not NOT |
| 15:53 | <gavinc> | argh |
| 15:54 | gavinc | tries again too damn early in the morning |
| 15:54 | <manu1> | Looking at it from a WHATWG perspective, I think that if people choose Microdata in the market as the winner, it won't be because it was a W3C REC, it will be for other reasons. |
| 15:54 | <manu1> | I think both positions are perfectly reasonable ones to take simultaneously. |
| 15:54 | <gavinc> | Does anyone think that Microdata and RDFa 1.1 Lite have large technical differences? |
| 15:54 | darobin | wishes we rescinded more RECs, the stylesheet is pretty |
| 15:57 | GPHemsley | wishes he didn't spend all this time reading the backlog of this discussion. |
| 15:58 | <GPHemsley> | annevk: What is this obsession with about:unicorn? And why isn't about:mozilla in the list, then? |
| 16:00 | <darobin> | can we have about:dahut as well? |
| 16:01 | marcosc | sorry, back |
| 16:02 | <annevk> | GPHemsley: obsession? |
| 16:02 | <GPHemsley> | annevk: Well, you do talk about unicorn.svg a lot |
| 16:02 | <annevk> | GPHemsley: about:mozilla isn't cross-browser |
| 16:02 | <GPHemsley> | and about:unicorn is? |
| 16:02 | <annevk> | one day |
| 16:03 | <GPHemsley> | I mean, if we're gonna talk about about: easter eggs, about:mozilla is the granddaddy of them all |
| 16:03 | <GPHemsley> | http://en.wikipedia.org/wiki/The_Book_of_Mozilla |
| 16:06 | <marcosc> | manu1: what browsers implement RDFa? |
| 16:07 | <marcosc> | (what is the recommendation of RDFa based on? I don't know, just wondering) |
| 16:07 | <gavinc> | What is the need for browsers to implement RDFa? |
| 16:07 | <marcosc> | gavinc: I'm just wondering how it met its criteria to go to Rec? |
| 16:07 | <marcosc> | I don't know much (ok, anything) about RDFa |
| 16:07 | <marcosc> | so I'm wondering how it got to Rec |
| 16:08 | <annevk> | there's many ways to get to REC marcosc, the XHTML/RDF camp usually does so in a way that does not involve browsers |
| 16:08 | <marcosc> | annevk: I know, but I'm wondering what those ways are |
| 16:08 | <gavinc> | Hang on. |
| 16:09 | <manu1> | marcosc: RDFa got to REC how most other W3C specs get to REC - there was a spec, there was a test suite, and there were 7+ fully conforming and interoperable implementations of an RDFa processor. |
| 16:09 | <marcosc> | manu1: sure, do you have a pointer to those? |
| 16:09 | <annevk> | marcosc: saying it's a framework for other specs, providing a couple of script libraries, etc. |
| 16:10 | <annevk> | marcosc: that their usage of xmlns + : violates DOM consistency was apparently not a concern |
| 16:10 | <manu1> | marcosc: Here's the test suite for RDFa 1.0 and 1.1 in HTML4, HTML5, XHTML1, XHTML5, XML and SVG: http://rdfa.info/test-suite/ |
| 16:10 | <gavinc> | http://www.w3.org/2010/02/rdfa/drafts/2012/CR-implementation-report-20120503/ |
| 16:11 | <marcosc> | thanks gavinc, that's what I was looking for |
| 16:11 | <manu1> | annevk: xmlns: - deprecated in RDFa 1.1 (and is allowed to be reported as an error) |
| 16:11 | <gavinc> | marcosc: not sure if there is a more recent one |
| 16:11 | <marcosc> | that's ok, it gives me an idea of the class of products |
| 16:12 | <gavinc> | annevk: RDF 1.1 doesn't require or recomended using xmlns |
| 16:13 | <gavinc> | marcosc: The Google crawler also consumes RDFa |
| 16:13 | <marcosc> | gavinc: sure, but they are not part of the CR report |
| 16:13 | <marcosc> | so we don't know if they conform or not |
| 16:13 | <gavinc> | True. |
| 16:15 | <marcosc> | so, if RDFa is supposed to be used by Web browsers also, it would be nice to at least have one web browser supporting it, no? |
| 16:15 | <gavinc> | Still, this is still very political. I haven't seen anyone explain why Microdata today and RDFa 1.1 Lite are technically different. |
| 16:15 | <gavinc> | "supposed to be used" |
| 16:15 | <marcosc> | gavinc: did you read my email? |
| 16:15 | <gavinc> | ... clearly missed one? |
| 16:16 | <marcosc> | gavinc: the point I was making that having technically similar tech don't actually matter. As annevk pointed out above |
| 16:16 | <annevk> | time to make Range.detach() a no-op, seems AryehGregor's experiment succeeded |
| 16:17 | <marcosc> | gavinc: I'm confused about RDFa, when I add it to my page, how to I then use it in the browser? Is there some kind of API? |
| 16:18 | <JibberJim> | I guess the point is marcosc - are browsers the only audience of your page? If you believe they are, then there's no value in RDFa, because the human using the browser will have the information anyway. |
| 16:18 | <gavinc> | heck there isn't any clear value for microdata |
| 16:18 | <linclark> | there are still some technical differences between microdata and rdfa 1.1 lite. |
| 16:19 | <marcosc> | JibberJim: they are the main target of my apps |
| 16:19 | <gavinc> | the major use case that we see today is from search engines and aggregation |
| 16:19 | <manu1> | marcosc: RDFa API implementation if you want to consume your own content in the browser: http://code.google.com/p/green-turtle/ |
| 16:19 | <marcosc> | JibberJim: sometimes I add metadata for things like Facebook, etc |
| 16:19 | <gavinc> | marcosc: Ah! You used RDFa ;) Well done. |
| 16:21 | <marcosc> | gavinc: well, there ya go :) You learn something new everyday |
| 16:21 | <marcosc> | manu1: I don't want to be importing external libs |
| 16:22 | <marcosc> | manu1: seems like something that should be in the browser by default |
| 16:22 | <gavinc> | the obvious reason for a lack of an RDFa API in the browser and the lack of USE of the microdata API in the browser is that as far as I know no one has come up with a compelling reason to care about RDFa or microdata in the browser |
| 16:22 | <JibberJim> | So a standard for adding metadata for non-human visitors using a browser is probably a good thing. But I don't see the benefit of it being in the browser - the information is already there on the page for the user? |
| 16:22 | <gavinc> | those that have (metadata in side a book) have used a library |
| 16:23 | <linclark> | gavinc: a microdata is also a lot easier to code |
| 16:23 | <linclark> | a microdata parser, rather |
| 16:23 | <gavinc> | err |
| 16:23 | <gavinc> | How did you come up with that? |
| 16:24 | <linclark> | I've written a microdata parser and have hacked on RDFa parsers such as ARC2's |
| 16:24 | <JibberJim> | Having metadata against a picture of a "Man with a giant cock" - is useful to a non human visitor to establish that it's http://1.bp.blogspot.com/-c-cvrFDnBvY/TavlbrwNzmI/AAAAAAAAAik/CERjuQ6TTwg/s1600/big_cock.jpg and not something else - but the human using the browser will know. |
| 16:25 | <gavinc> | ARC2's (from memory) is mostly insane as it has to deal with an insane XML/HTML parser |
| 16:25 | <gavinc> | If your starting from a modern HTML parser I can't see a huge difference between them |
| 16:26 | <linclark> | gavinc: that's true, but look at rdfQuery vs MicrodataJS |
| 16:26 | <linclark> | http://code.google.com/p/rdfquery/source/browse/trunk/jquery.rdfa.js |
| 16:26 | <manu1> | gavinc: No, Microdata parsers are much easier to write than RDFa... |
| 16:26 | <linclark> | https://gitorious.org/microdatajs/microdatajs/blobs/master/jquery.microdata.js |
| 16:26 | <manu1> | some of that is because of the legacy RDFa 1.0 -> RDFa 1.1 upgrade, most of it is because of more advanced features of RDFa. |
| 16:27 | <manu1> | but, the pain of the few (implementers) is sacrificed for the gain of the many (authors)... aaaaand, que RDFa is more difficult to author than Microdata perma-thread. |
| 16:27 | <linclark> | ha |
| 16:31 | gavinc | and this is still more useful then talking about blank nodes again... sigh |
| 16:35 | <dglazkov> | good morning, Whatwg! |
| 16:50 | <annevk> | SimonSapin: https://www.w3.org/Bugs/Public/show_bug.cgi?id=19494 (data URLs) |
| 16:51 | <SimonSapin> | annevk: looking |
| 16:58 | <hsivonen> | huh. neither a w3cmeme nor a webkitmeme about <main> |
| 17:00 | <annevk> | jreschke: why not just hang out here if you read the logs anyway? :) |
| 17:01 | <annevk> | hsivonen: kinda disappointing |
| 17:04 | <GPHemsley> | ugh, Safari downloads |
| 17:05 | GPHemsley | doesn't understand why anyone would ever use Safari |
| 17:09 | <dglazkov> | hsivonen: the battles are so fierce because the stakes are so low. |
| 17:10 | <annevk> | https://github.com/joyent/node/pull/1580 is a good example of that dglazkov |
| 17:10 | <annevk> | (if you like memes, read it to the end) |
| 17:15 | <dglazkov> | annevk: fire all of these people |
| 17:18 | <marcosc> | I'm deeply shocked that no one W3C-meme'ed the microdata vs RDFa thing. |
| 17:19 | <GPHemsley> | annevk: Darn it, Anne, you almost made me read that whole thing again. |
| 17:21 | <marcosc> | hehe |
| 17:21 | <marcosc> | my fab is the scumbag : |
| 17:34 | tantek | scrolls up to read all the microdata vs rdfa kerfluffle. |
| 17:36 | <tantek> | I don't really understand efforts to block specs from progressing. a) it's hard enough to progress specs as it is, b) whether something is a "REC" has not mattered to web authors/publishers/developers for a while as far as whether they use it. |
| 17:37 | <tantek> | And if the argument is to avoid W3C specifying duplicate mechanisms, then might as well drop both microdata and RDFa, since you satisfy all the use cases with HTML 'class' attribute (e.f. microformats2), and frankly that's what developers tend to use a lot more than md or rdfa. |
| 17:37 | <tantek> | md has had some uptake recently, only because of a few folks at google advocating via schema. |
| 17:38 | <tantek> | (insert SEO folks obediently doing whatever anyone at google publicly suggests) |
| 17:38 | <scor> | tantek: have you seen any mf2 adoption? do you have examples? |
| 17:39 | <gavinc> | http://schema.org/docs/datamodel.html That page is staggeringly unhelpful if your trying to provide advice on "What should I use to encode meta data on my page?" |
| 17:39 | <tantek> | scor - have seen *some* mf2 adoption. the parsing spec and parsing implementations have been stable for only a couple of months or so. |
| 17:39 | <gavinc> | Why we have microdata and RDFa at the same time is still totally beyond me |
| 17:40 | <tantek> | so yes, it may be too new to tell with mf2, however the rate at how quickly people have been able to developer parsers (PHP, Node, clientside JS) is encouraging. |
| 17:40 | <tantek> | gavinc, we have microdata because it's less ugly and less typing than RDFa. |
| 17:40 | <gavinc> | "Our use of Microdata maps easily into RDFa Lite. In fact, all of Schema.org can be used with the RDFa Lite syntax as is. The RDFa Lite version of the markup looks almost isomorphic to the Microdata version" |
| 17:40 | <gavinc> | really? ;) |
| 17:40 | <tantek> | though both are horrendous (from a web author / hand coding perspective) compared to #microformats. |
| 17:41 | <tantek> | gavinc, yeah, the RDFa Lite 1.1 or RDFa 1.1 Lite was essentially squeezed into becoming md compat. |
| 17:41 | <gavinc> | Exactly! The spec took feedback |
| 17:41 | <gavinc> | isn't that what's supposed to happen? |
| 17:42 | <tantek> | md was (is?) easier to read/write than rdfa 1.0, that presented the market pressure that resulted in rda 1.1 lite |
| 17:42 | <tantek> | if it wasn't for md, rdfa 1.1 lite wouldn't exist. |
| 17:43 | <Hixie> | jgraham: if the vendors implement it, the spec will include it pretty much instantly. but i'm not convinced it'll be implemented. it doesn't serve its stated purpose. |
| 17:43 | <tantek> | and from a microformats perspective, the market feedback of *both* of those coming into existence provided substantial real world experience/pressure for the development of microformats2. |
| 17:43 | <Hixie> | as far as microdata goes, personally I think all RECs are pointless, so I'd be quite happy to see both HTML and Microdata not make it to REC :-) |
| 17:43 | <tantek> | lol |
| 17:44 | <marcosc> | gavinc: question: in the RDFa code I'm using, how does anything know what "og:" means? (i.e., in <meta property="og:site_name" content="my site">?) |
| 17:44 | <tantek> | I tend to agree re: md. I don't see much point in putting energy behind pushing it to a REC, but nor do I see any point in putting energy in *blocking* it going to REC. |
| 17:45 | <tantek> | marcosc, "og:" is a prefix squatted by FB/OGP. |
| 17:45 | <scor> | tantek: is the adoption / progress on mf2 documented anywhere? I'd like to follow it |
| 17:45 | <gavinc> | http://www.w3.org/2011/rdfa-context/rdfa-1.1.html |
| 17:45 | <tantek> | scor: for now, right on the wiki page for it: http://microformats.org/wiki/microformats2 |
| 17:46 | <tantek> | adoption in particular: |
| 17:46 | <Hixie> | tantek: i do think there's something to learn from the way that you and i have never tried to stop the rdf nonsense (only sent feedback when asked to), but they keep trying to block microdata (and sometimes even mf?) |
| 17:46 | <tantek> | publishing examples (hopelessly undercomplete, just a sample) http://microformats.org/wiki/microformats2#Examples_in_the_wild |
| 17:46 | <tantek> | parsing / consuming code: http://microformats.org/wiki/microformats2#Implementations |
| 17:46 | <scor> | tantek: thanks, that's helpful |
| 17:47 | <tantek> | Hixie, no need to put energy into stopping something which has been an uphill battle all on its own. |
| 17:47 | gavinc | doesn' |
| 17:47 | <Hixie> | tantek: stopping anything just doesn't work, it'll just go elsewhere if it's good, and will die anyway if it's bad |
| 17:47 | <tantek> | there's attempts to block md and mf only because they've actually seen a more rapid adoption per unit time than any flavor of rdf |
| 17:48 | <tantek> | hixie, I tend to agree with that |
| 17:48 | <tantek> | there were pre-whatwg examples of that too |
| 17:48 | <gavinc> | err |
| 17:48 | <tantek> | e.g. all the W3C -> OASIS "going elsewhere" |
| 17:48 | <gavinc> | I'm unaware of anyone trying block microformats? |
| 17:49 | <gavinc> | did I miss a memo? Was I supposed to as an "RDF Person" go and do that? |
| 17:49 | <tantek> | gavinc - it's hard to block something which is public domain on a public wiki |
| 17:49 | <gavinc> | yes |
| 17:49 | <gavinc> | and why would any of the "RDF People" |
| 17:49 | <manu-db> | tantek, Hixie - actually, no - the reasons don't have to do w/ rapid adoption - the reasons have to do with three ways to do the same thing that are not really all that different from each other (at the core) and leading to confusion among web developers. |
| 17:49 | <tantek> | there's been blog posts saying it shouldn't exist etc. because rdf already exists |
| 17:49 | <tantek> | but they're a minority |
| 17:49 | <manu-db> | and there is no such thing as "RDF people". |
| 17:49 | <marcosc> | oh, I've seen them! RDF people are real! |
| 17:50 | <marcosc> | they are an angry lot, too |
| 17:50 | <gavinc> | foaf:Person? ;) |
| 17:50 | <tantek> | manu-db - if they're all the same to you, why not support the syntax easiest for authors? |
| 17:50 | <manu-db> | please take a picture next time you see one of them, marcosc - I'd love to see what one actually looks like in the wild. |
| 17:50 | <tantek> | gavinc: LOL |
| 17:51 | <manu-db> | tantek - I don't think it's useful to take a minority that says crazy things and project it onto what's happening right now. |
| 17:51 | <marcosc> | manu-db: http://philarcher.org/diary/2012/fearofrdf/ |
| 17:52 | <marcosc> | That's what I got once for asking a question |
| 17:52 | <marcosc> | about RDF |
| 17:52 | <gavinc> | tantek: ... what is the easiest syntax? At the time that microdata came into being the drafts of RDFa were better and easier to use then it was, and microdata was totally fragmented. |
| 17:52 | <tantek> | gavinc - initial md was *much* easier than rdfa at the time due to the property vs. rel problem |
| 17:52 | <tantek> | and prefixes |
| 17:53 | <gavinc> | rel/rev sucked. |
| 17:53 | <gavinc> | Yes. |
| 17:53 | <tantek> | right |
| 17:53 | <tantek> | so rdfa 1.1 lite learned from md (and via market/political (read: Google/Schema) pressure) |
| 17:53 | <gavinc> | I admit to still not buying the prefix thing |
| 17:53 | <tantek> | and dropped dependency on rel/rev |
| 17:53 | <gavinc> | Yeah, rel/rev was BAD. |
| 17:53 | <tantek> | gavinc, prefixes are well documented failures |
| 17:54 | GPHemsley | continues to wonder why this discussion is happening here. |
| 17:54 | <tantek> | here, in case you haven't seen this: http://microformats.org/wiki/namespaces-considered-harmful |
| 17:54 | <gavinc> | No, XML namespaces are a well documented failure :D |
| 17:54 | <tantek> | GPHemsley - because someone brought it? ;) |
| 17:54 | <manu-db> | +1 to gavinc |
| 17:55 | <manu-db> | tantek: We haven't seen widespread misuse of prefixes in RDFa... in fact, most people use them correctly... and for those that don't, there is the RDFa initial context. |
| 17:55 | <gavinc> | tantek: my opinion from 3 years ago hasn't really been changed, http://gavin.carothers.name/2009/09/22/prefixes-not-that-complicated/ |
| 17:55 | <tantek> | gavinc, in particular: prefixes fail due to: "in practice people write scrapers that look for namespace prefixes as if they are part of the element name, or perform literal string matches on common namespace prefix uses (e.g. 1), not as mere shorthands for namespace URIs. " |
| 17:56 | <manu-db> | tantek: Data to back up that practice w/ RDFa ? |
| 17:56 | <Hixie> | RDFa has existed for years, if it was going to go anywhere it'd be there already |
| 17:56 | <Hixie> | same with RDF |
| 17:56 | <Hixie> | it's just tiresome to have these discussions over and over and over |
| 17:56 | gavinc | notes that it did go some where |
| 17:57 | <tantek> | manu-db: the way "og:" means Facebook OGP and nothing else. |
| 17:57 | <manu-db> | Hixie - RDFa going somewhere (along w/ Microdata + schema.org): http://webdatacommons.org/vocabulary-usage-analysis/index.html |
| 17:57 | gavinc | isn't from the 2004 crowd and neither is manu |
| 17:57 | <manu-db> | tantek: no, who is scraping data in the way that you're asserting that they scrape data. |
| 17:57 | <tantek> | as such, either RDFa prefixes/namespaces are a giant failure (per adoption of hardcoded "og:"), or Facebook OGP isn't really RDFa (please update all your adoption graphs/charts accordingly) |
| 17:58 | <tantek> | both Facebook at Twitter scrape "og:" |
| 17:58 | <manu-db> | tantek: There is a difference between everyone using 'og' to mean Open Graph (just because that's common practice) and parser writers just scraping data assuming certain prefixes. |
| 17:58 | <tantek> | and vast majority of "og:" markup lacks any namespace URI declaration |
| 17:58 | <gavinc> | Facebook works fine if you define another prefix to match the URI |
| 17:58 | <manu-db> | tantek: So what - the RDFa initial context pre-defines it. |
| 17:58 | <gavinc> | or if you just use the full URI |
| 17:59 | <manu-db> | also, what Gavin said - Facebook has implemented correctly. |
| 17:59 | <gavinc> | can't say that I've tested twitter |
| 17:59 | manu-db | has no idea what Twitter does, but I'd expect the data they're getting back to work just fine in most cases. |
| 17:59 | <tantek> | gavinc - test case to back up your claim? all evidence I've seen shows fb treating "og:" as OGP always. |
| 17:59 | <gavinc> | Ah, that's not what I said. |
| 17:59 | <gavinc> | That may be true |
| 17:59 | <tantek> | right, they just scrape it |
| 18:00 | <gavinc> | but if you define something else to be the same URI |
| 18:00 | <gavinc> | it works |
| 18:00 | <gavinc> | eg, they don't require you to use og: |
| 18:00 | <gavinc> | you can use facebook: |
| 18:00 | <manu-db> | test case to prove your assertion, tantek? |
| 18:00 | <gavinc> | or the full URI |
| 18:00 | <tantek> | gavinc - doesn't affect my argument |
| 18:00 | <gavinc> | mmm |
| 18:00 | <tantek> | manu-db, search for any publishing of "og:" on the web :) |
| 18:00 | <gavinc> | I don't KNOW if what your saying is true. |
| 18:00 | <tantek> | they're everywhere |
| 18:00 | <manu-db> | of course it does - you're saying that they blindly scrape 'og' and just 'og' - and they don't. |
| 18:01 | <tantek> | any use of namespaces that gains adoption deteriorates into scraping prefixes |
| 18:01 | <gavinc> | I can't think of a case where someone is using og: to mean something else... |
| 18:01 | <gavinc> | mmm |
| 18:01 | <tantek> | s/namespaces/namespace prefixes |
| 18:01 | <manu-db> | again, data to back up your assertion, tantek? |
| 18:01 | <gavinc> | but the reverse is true |
| 18:01 | <tantek> | manu-db, you're a fan of google searches, look it up ;) |
| 18:02 | <tantek> | essentially, "og:" might as well have been "og_" |
| 18:02 | <Hixie> | manu-db: i can't find baseline numbers on that page, but looking at http://events.linkeddata.org/ldow2012/papers/ldow2012-inv-paper-1.pdf which they link to, the highest amount they find is 5.5% penetration per eTLD, for microformats in general. That's pretty low. |
| 18:02 | <gavinc> | so the question would be concretely does defining another URI to the og: prefix correctly NOT get parsed by facebook? |
| 18:02 | <tantek> | and using meta name="og_foobar" rather than meta property="og:foobar" |
| 18:02 | <manu-db> | tantek: http://yourlogicalfallacyis.com/burden-of-proof :) |
| 18:02 | <tantek> | in practice og is just metatags using "property" instead of "name" |
| 18:04 | <Hixie> | manu-db: and as far as i can tell, it's for a _very_ small number of vocabularies, which calls into doubt the whole point of having this hugely extensible system. |
| 18:05 | <tantek> | Hixie, but microdata is a hugely extensible-system ;) |
| 18:05 | <manu-db> | Hixie: Yes, but compared to what? HTML? Anything compared to HTML is going to be pretty dismal. I all depends on where your bar for a "successful Web technology" lies. |
| 18:05 | <Hixie> | yeah, i'm not a fan of microdata either |
| 18:05 | <gavinc> | THEN WHY DID YOU CREATE IT?! |
| 18:05 | <tantek> | (as is microformats2, due to apparently sufficient market demand to create two such other systems) |
| 18:05 | <Hixie> | gavinc: to solve use cases, same as everything else in HTML |
| 18:05 | <tantek> | gavinc - see less ugly point above |
| 18:06 | <manu-db> | Hixie: Over 700 vocabularies currently being worked on - http://prefix.cc/popular/all |
| 18:06 | <manu-db> | (granted, I don't think vocabulary explosion is a good thing either) |
| 18:06 | <tantek> | manu-db - how many of them are divergent forks of various people/foaf/vcard vocabs because the people working on vocabs have no idea what they're doing? |
| 18:06 | <tantek> | exactly |
| 18:06 | <Hixie> | manu-db: "worked on" is irrelevant, what matters is what is used. If you just have a private vocab that is used on five pages, you don't need rdfa or microdata or mf, you can just use proprietary markup. |
| 18:06 | <manu-db> | tantek: Some yes, some no. |
| 18:06 | <gavinc> | Hixie: but those use cases were and are being served by RDFa, why not just make it better like it has gotten better... it is better, it did get better! |
| 18:07 | <tantek> | gavinc, see above, it only got better due to microdata/schema/google pressure |
| 18:07 | <Hixie> | gavinc: the use cases were not handled well or at all by rdfa, and still aren't. |
| 18:07 | <tantek> | rdfa would have stubbornly stuck/sucked with rel/rev confusion otherwise |
| 18:07 | <Hixie> | gavinc: e.g. a way to drag a blob of metadata across to another page using the drag and drop API |
| 18:07 | <manu-db> | tantek: So, it did get better (in your eyes), right? |
| 18:07 | <Hixie> | gavinc: plus, RDFa is just a terrible language in general |
| 18:07 | <MacTed> | the question is why that pressure wasn't brought into the RDFa work, rather than by creating an entirely different markup |
| 18:07 | <tantek> | manu-db, yes of course, I thought we had discussed that before. |
| 18:07 | <Hixie> | gavinc: poorly designed, hard to use, etc |
| 18:07 | <TabAtkins> | MikeSmith: What do you mean "the 'Inlining Ruby' part of [my] message does not describe any use case"? I explained right there in the bug that there is a correct normal rendering (per-character) and a correct inline rendering (per-word), but it's currently impossible to do both in HTML ruby.\ |
| 18:08 | <MacTed> | NIH. gotta love it. or something. |
| 18:08 | <Hixie> | but none of this is new, we've had this conversation before |
| 18:08 | <manu-db> | yep |
| 18:08 | <tantek> | MacTed, because sometimes you have to use the market to prove a point that a majority in a W3C WG won't accept. |
| 18:09 | <Hixie> | TabAtkins: hey sorry for moving that e-mail to bugs, btw, but my mail client really can't handle non-ASCII in a useful way and I figured you probably wouldn't mind |
| 18:09 | <gavinc> | The RDFa WG DID accept it! |
| 18:09 | <Hixie> | gavinc: it still uses RDF, so, no :-) |
| 18:09 | <tantek> | gavinc - only after MD adoption |
| 18:09 | <manu-db> | ha |
| 18:09 | <gavinc> | No. |
| 18:09 | <gavinc> | Not even close. |
| 18:09 | <MacTed> | so the point was "don't use RDF"? |
| 18:09 | <tantek> | rel/rev didn't get dropped til after schema/microdata |
| 18:09 | <linclark> | truth |
| 18:10 | <MikeSmith> | TabAtkins: that's only because they are marked up differently to begin with. It doesn't make it clear why anybody would want to mark them up separately that way to begin with instead of grouping them |
| 18:10 | <MikeSmith> | TabAtkins: it just asserts that marking them up individually is more "correct" |
| 18:10 | manu-db | grins at http://www.w3.org/TR/2012/WD-microdata-rdf-20120112/ |
| 18:10 | <TabAtkins> | ...I said why. When you're *not* inlining the ruby, you may want mono-ruby display, which is per-character. |
| 18:11 | <TabAtkins> | And whether to inline or not is a valid stylistic choice, not just a fallback behavior. |
| 18:11 | <MikeSmith> | TabAtkins: it's not for that example |
| 18:11 | <Hixie> | MacTed: if you want to read the history, these are the original e-mails that led to microdata: http://lists.w3.org/Archives/Public/public-html/2009May/0207.html |
| 18:11 | <MikeSmith> | you would never want to do it that way for 東京 |
| 18:11 | <gavinc> | schema.org: "The data model used is very generic and derived from RDF Schema" |
| 18:11 | <tantek> | hey manu-db, we got one of those too: http://microformats.org/wiki/microformats2-parsing-rdf |
| 18:11 | <tantek> | ;) |
| 18:11 | <manu-db> | tantek - I hate RDF |
| 18:12 | <TabAtkins> | MikeSmith: (note that I know nothing about Japanese. I understand the technical side of this argument, and trust the "right way" side to be what I was told.) |
| 18:12 | <manu-db> | :P |
| 18:12 | <tantek> | manu-db, you have a strange way of expressing it ;) |
| 18:12 | <TabAtkins> | MikeSmith: I assume that there are indeed some mono-ruby cases where you *would* want to inline multiple bases together. |
| 18:12 | <MikeSmith> | TabAtkins: well, like I said anyway I think that case is distraction, and continuing to include it in discussions along with the double-sided ruby case doesn't help the double-sided ruby case |
| 18:12 | <gavinc> | I don't know, not that strange. I've heard Norm claim to hate XML reasonably often |
| 18:13 | <MikeSmith> | TabAtkins: yeah I've yet to see anybody actually describe any such concrete cases well |
| 18:13 | <TabAtkins> | MikeSmith: I don't care about crossing the streams. I think the arguments are separable. |
| 18:13 | <MikeSmith> | so I think it's a mistake to assume it |
| 18:13 | <gavinc> | Heck, I'm pretty sure I've heard Hixie hate HTML :P |
| 18:13 | <Hixie> | HTML is wacked, but it's the best we have |
| 18:13 | <MikeSmith> | TabAtkins: ok |
| 18:13 | <manu-db> | I'm like an onion - complex, stinky, many layers... hate RDF, but haven't found anything better yet. gavinc can tell you about my constant attempts to down-play RDF in JSON-LD because of the knee-jerk effect it has on people. |
| 18:13 | <Hixie> | can't say the same about RDFa. :-P |
| 18:14 | <manu-db> | Hixie - booo! :P |
| 18:15 | <manu-db> | In the very worst case, people will decide what they like the most - we've given them options... that helps me sleep at night. Just trying to reduce the amount of pain (and economic waste) Web developers are going to have to go through to get there. |
| 18:15 | <tantek> | in that case, it does seem illogical to continue pushing an inferior syntax, but hey, it's your time ;) |
| 18:15 | <TabAtkins> | MikeSmith: I described what I was told. I'm told that there are reasonable instances where, displayed normally, you want mono-ruby display, but displayed inline, you want them grouped. If I take that as given, then switching to a mixed row/column markup model makes sense. |
| 18:15 | <manu-db> | I don't doubt that all of us have the best intentions... we're just each wrong for different reasons. |
| 18:15 | <MikeSmith> | TabAtkins: fair enough |
| 18:15 | <manu-db> | tantek - exactly, you don't get to tell me how to waste my time and the time of others. :P |
| 18:16 | <tantek> | we've all got our hobbies ;) |
| 18:16 | gavinc | goes back to figuring out escaping Turtle in HTML to screw with you all ;) |
| 18:17 | manu-db | goes back to the thing that puts food on the table. |
| 18:17 | <tantek> | gavinc - since you're into extensible data markup and all, would appreciate any feedback on microformats2 (feel free to do so in #microformats to reduce the noise here ;) ) |
| 18:17 | <TabAtkins> | MikeSmith: The double-ruby case is easier, actually - having two different markup models for nearly the exact same thing makes sense only in the "column only" ruby model that the spec currently uses, as it has no way of associating a run across multiple bases. If you do switch to a row-based model, then it gets really simple, and you can just collapse the two markup patterns into one, which is better. |
| 18:17 | <Hixie> | manu-db: stopping microdata from getting to REC isn't going to change anything, fwiw. It's already a standard. |
| 18:18 | tantek | isn't sure how stopping microdata from getting to REC puts food on the table. |
| 18:18 | <manu-db> | Hixie: Then nobody should have a problem with making it a W3C Note. :) |
| 18:18 | manu-db | tantek - it doesn't, but I'm concerned for the Web and felt like I needed to say something about it. |
| 18:19 | <MikeSmith> | TabAtkins: I'm not convinced it's actually easier for authors or that authors will actually take time to use it instead of you made it available |
| 18:19 | <Hixie> | manu-db: i don't have a problem with just dropping it and HTML entirely :-) |
| 18:19 | <manu-db> | I'd have a problem w/ dropping HTML5 - I like it. |
| 18:19 | <manu-db> | (warts and all) |
| 18:19 | <Hixie> | HTML is already a standard, the same standard, as microdata |
| 18:19 | <Hixie> | http://whatwg.org/html |
| 18:19 | <TabAtkins> | MikeSmith: I find it kinda self-evident that two models is worse than a single model of equivalent complexity to one of the other models. |
| 18:20 | <MikeSmith> | TabAtkins: I'm not convinced there are even enough cases of need to do double-sided ruby on the web that justify spending much time trying to address it all |
| 18:20 | <manu-db> | Hixie - this again? I don't disagree with you on that as much as you might think I do. |
| 18:21 | <TabAtkins> | MikeSmith: Shrug. Apparently Japanese publishers want to use it, and they're willing to suck it up and use the current model if they have to (even though it's worse for authors and for CSS). |
| 18:21 | manu-db | isn't a dyed-in-the-wool RDFer, nor W3Cer... just wants to help the Web suck less. |
| 18:21 | <MikeSmith> | Japanese publishers claim the want to do all kinds of crazy things |
| 18:22 | <TabAtkins> | Granted. |
| 18:22 | <manu-db> | I don't really care where HTML work is done, as long as things keep improving, and people have a say in what goes in the spec... but W3C is important to some and I don't think that's bad either. |
| 18:22 | <MikeSmith> | and have a very hard time giving feedback about which things are more important than others |
| 18:22 | <tantek> | HIxie, if you dislike microdata, why not drop it from whatwg.org/html ? |
| 18:23 | <Hixie> | manu-db: "this again"? you're in #whatwg, it kinda comes with the territory |
| 18:23 | <tantek> | or does it fall into the category of experimental stuff to try for a while and see how it goes? |
| 18:23 | <Hixie> | tantek: my like or dislike for things has no bearing on what goes in the spec |
| 18:23 | <tantek> | (which seems reasonable) |
| 18:23 | <manu-db> | Hixie - No, I mean... I get it, you don't have to keep saying it... I get it. |
| 18:23 | <Hixie> | tantek: if it did, the spec would be radically different (and not even slightly backwards-compatible, for example) |
| 18:24 | <MikeSmith> | TabAtkins: anway, the fact is really that most Japanese text in the vast majority of cases even off the Web has no ruby at all, and no use for it in the context of the meeting the needs of the people intended to read it |
| 18:24 | <TabAtkins> | Sure. |
| 18:25 | <Hixie> | tantek: it's in there because it solves use cases some people care about, and does so better than other solutions, and, at this point, has some adoption (though not much, see citations above). |
| 18:25 | <MikeSmith> | so even simple ruby is need only for a relatively small amount of cases to begin with |
| 18:25 | <TabAtkins> | Yup, no argument here. If we had *nothing* but mono ruby, it wouldn't be a terrible problem. |
| 18:26 | <MikeSmith> | also fwiw I'm not trying to kneejerk dis the effort you're making here |
| 18:26 | <MikeSmith> | just trying to give feedback that I hope helps to clarify the arguments |
| 18:27 | <TabAtkins> | No problem, even though a decent bit of your feedback feels like "let's ignore your arguments, and then claim you're not making any arguments". ^_^ |
| 18:27 | <tantek> | Hixie, seems reasonable. I wonder what else would fit given that criteria/bar. |
| 18:27 | <MikeSmith> | and as somebody who does actually need ruby in cases where native readers don't, I would love to see it made as easy as possible for authors to mark up text with and use it |
| 18:28 | <Hixie> | tantek: hopefully, the exact set of features in the spec plus those i will add minus those i will remove :-D |
| 18:28 | <tantek> | :) |
| 18:28 | <MikeSmith> | TabAtkins: I think you have articulated the technical points well, but there are assumptions behind those that you have not questioned |
| 18:29 | <MikeSmith> | and if we don't have evidence to support those assumptions the technical points become moot |
| 18:31 | <TabAtkins> | Sure. I think the double-ruby one is pretty much purely technical, as I've argued. For the inlining, can you think of better examples? I'm just using the one that fantasai had in her blog post. |
| 18:34 | <MikeSmith> | TabAtkins: I will look back at some of the examples in earlier discussions |
| 18:34 | <TabAtkins> | cool, thanks. |
| 18:34 | <MikeSmith> | I think some of those might be a bit more compelling |
| 18:35 | <MikeSmith> | and real-world |
| 19:02 | <Hixie> | manu-db: http://www.w3.org/mid/CACho_Au7FCdduJN1gwZOS3stEpe4dJ+qH8vkuFVALHepURBhZg⊙mgc seems to repeat exactly the kind of stuff i've been saying about RDFa since forever. |
| 19:02 | <Hixie> | including why Lite doesn't solve the problem |
| 19:04 | <Hixie> | in other news the other day i mailed a bunch of browser vendors (apple, opera, microsoft, mozilla, google) asking them (a) to comment on something, and (b) to tell me how to ask them to comment on things like it |
| 19:04 | <Hixie> | everyone has since replied, some in some detail, except microsoft. |
| 19:04 | <Hixie> | not a peep from them. |
| 19:05 | <TabAtkins> | Apparently that's not the right way to ask them to comment on things like that. |
| 19:07 | <Hixie> | i guess so |
| 19:07 | <SimonSapin> | what would be the right way? |
| 19:08 | <TabAtkins> | Fly to Redmond and pop out of a cake delivered to the IE team. |
| 19:09 | <Hixie> | actually i lied, the three microsoft people didn't reply, but there were also three other people who didn't reply |
| 19:09 | Hixie | glares at jgraham, for one :-P |
| 19:09 | <Hixie> | and eric_carlson :-P |
| 19:09 | <SimonSapin> | what? Three who didn’t, and three who didn’t? |
| 19:10 | <Hixie> | three other people from other organisations |
| 19:10 | <eric_carlson> | Hixie: oops, I have been a bit overwhelmed with email lately - what did I not respond to? |
| 19:11 | <Hixie> | e-mail subject was "Quick question re feedback on HTML spec bugs" |
| 19:11 | <eric_carlson> | Hixie: I will dig it out |
| 19:11 | <Hixie> | but basically, i was asking for feedback on https://www.w3.org/Bugs/Public/show_bug.cgi?id=17687 and for instructions on how to contact you for feedback on bugs |
| 19:12 | <Hixie> | the third person was michealn, but he doesn't seem to be online so he's probably on vacation or something |
| 19:12 | <annevk> | Hixie: are you okay with the about URI RFC not defining things like text/html and utf-8 or did you miss it omitted that? |
| 19:13 | <Hixie> | annevk: for about:blank? |
| 19:13 | <annevk> | Hixie: yeah |
| 19:13 | <Hixie> | annevk: i define all the processing for about:blank natively in the HTML spec |
| 19:13 | <Hixie> | annevk: so doesn't matter what the RFC says :-) |
| 19:14 | <eric_carlson> | Hixie: hmm, I don’t see anything with that title, or even anything from you directly to me for a while |
| 19:14 | <eric_carlson> | Hixie: can you please send it again? |
| 19:14 | <Hixie> | eric_carlson: maybe you're a different eric. Are you eric⊙wo? |
| 19:15 | <annevk> | Hixie: fair enough |
| 19:16 | <eric_carlson> | Hixie: that explains it - that is Eric Seidel |
| 19:16 | <eric_carlson> | Hixie: unless maybe you were trying to reach him? |
| 19:17 | <eric_carlson> | Hixie: which might make sense because I haven’t done much with app cache |
| 19:17 | <Hixie> | aha! |
| 19:17 | <Hixie> | yeah that makes sense |
| 19:17 | <Hixie> | who at apple should i contact about that, do you know? |
| 19:18 | <Hixie> | oh i e-mailed ap, he responded |
| 19:18 | <Hixie> | he's apple, right |
| 19:18 | <eric_carlson> | yes |
| 19:18 | <Hixie> | cool |
| 19:18 | <Hixie> | my deepest apologies for slandering you :-) |
| 19:18 | eric_carlson | was maligned! |
| 19:18 | <eric_carlson> | :-) |
| 19:20 | <Hixie> | in that case, what i learn is that google and microsoft don't reply to my e-mails |
| 19:20 | <Hixie> | that seems like pretty solid evidence that i'm not biased towards google and against microsoft |
| 19:21 | <Hixie> | it's also sad. :-P |
| 19:26 | <annevk> | Hixie: so the only problem with the current definition of about:blank, including the HTML spec, is that it's not very clear on whether percent encoding, case-sensitivity and URL's query and fragment components matter |
| 19:26 | <annevk> | Hixie: http://wiki.whatwg.org/wiki/URL_schemes is an attempt to define those things; also for javascript: |
| 19:26 | <annevk> | Hixie: my plan is to eventually define about: and javascript: in Fetch, but I think I still need to wait 4 years before starting on that, so it's wiki pages for now |
| 19:27 | <Hixie> | i think, though i'm not sure, that as specced i only care about about:blank, not about:blank with other features |
| 19:27 | <Hixie> | so i guess for the other urls the rfc does matter |
| 19:27 | <Hixie> | and should define everything |
| 19:35 | <annevk> | hmm |
| 19:51 | <jgraham> | Hixie: zcorpan replied |
| 19:51 | <jgraham> | I didn't think I had anything extra to say |
| 19:51 | <jgraham> | But if you want me to reply with the message "Filler text" I guess I could do that |
| 19:54 | <jgraham> | Hixie: But if it wasn't clear, I am often on IRC and respond there :p |
| 19:57 | <annevk> | http://cdn.memegenerator.net/instances/400x/30956693.jpg |
| 19:59 | <manu-db> | Hixie: Thanks for the heads-up, hadn't seen linclark's comment yet, I'll notify the implementers and add that test to the RDFa test suite. (and yes, the RDFa processing algorithm is far more complex than the Microdata one - due to all the reasons that I've outlined previously - more features, more public input, legacy support, some features I don't like at all, etc.) |
| 20:10 | <Hixie> | jgraham: oh didn't realise he'd cc'ed you, nevermind then :-) |
| 20:22 | <annevk> | smaug____: it would help if you were a bit more elaborate in your reply |
| 20:23 | <smaug____> | annevk: what is unclear |
| 20:24 | <annevk> | smaug____: the "why" is unclear |
| 20:24 | <smaug____> | MutationObserver don't share any mutation records |
| 20:24 | <annevk> | yes you mentioned that |
| 20:24 | <smaug____> | because they are different objects observing mutations the way the API on them has been used |
| 20:25 | <smaug____> | s/different/separate/ |
| 20:25 | <smaug____> | or how to say |
| 20:26 | <annevk> | I don't really see the problem I think |
| 20:27 | <annevk> | I mean sure, the MutationObserver objects are unique, but why do the MutationRecord objects delivered to them have to be? |
| 20:27 | <smaug____> | annevk: script library A observers something, and B something else |
| 20:28 | <smaug____> | they sure should be able to get their own records |
| 20:28 | <smaug____> | they could add expandos and what not |
| 20:28 | <annevk> | on the MutationRecord? |
| 20:28 | <smaug____> | annevk: also, why not create record per observer |
| 20:28 | <smaug____> | annevk: yes |
| 20:28 | <annevk> | it would be extra work to create a new record |
| 20:29 | <smaug____> | it would be extra work to figure out when to share record and when not |
| 20:29 | <annevk> | that would suggest the spec is still bogus somehow |
| 20:30 | <smaug____> | I thought it was clear that each mutation observer is truly unique thing and gets its own records. apparently no |
| 20:31 | <annevk> | indeed no |
| 20:32 | <annevk> | smaug____: http://dom.spec.whatwg.org/#queue-a-mutation-record creates one record and shares that with whoever listens to it |
| 20:32 | <annevk> | smaug____: if as you suggest it's extra work to figure things out, that algorithm is wrong... |
| 20:32 | <annevk> | smaug____: but Chrome seems to share as well |
| 20:33 | <smaug____> | Chrome doesn't seem to share it always |
| 20:33 | <smaug____> | per the bug report |
| 20:34 | <smaug____> | annevk: so all that pseudo-algorithm should be inside something like "for each interested observer" |
| 20:34 | <smaug____> | hmm |
| 20:35 | <smaug____> | so, first figure out the interested observers |
| 20:35 | <smaug____> | then for each of them create record |
| 20:36 | <annevk> | that's equivalent to doing what travis suggested |
| 20:36 | <annevk> | just cloning the record in 7.0 |
| 20:36 | <annevk> | which comes down to more work |
| 20:36 | <smaug____> | yup, but without cloning |
| 20:36 | <annevk> | and more copies |
| 20:37 | <annevk> | smaug____: why no cloning? |
| 20:37 | <smaug____> | the idea is to first figure out if something is interested in the mutation |
| 20:37 | <smaug____> | and then for each interested observer create record |
| 20:37 | <smaug____> | no extra work |
| 20:37 | <annevk> | sure there is |
| 20:37 | <annevk> | you create a record for each observer, rather than once |
| 20:38 | <smaug____> | well, that is a bug to fix |
| 20:38 | <smaug____> | IMHO |
| 20:38 | <annevk> | I wonder if people using that abbreviation really know what it stands for |
| 20:38 | <annevk> | it never feels very humble to me |
| 20:39 | <TabAtkins> | I expand it as "honest". |
| 20:39 | <TabAtkins> | Which is very different from "humble", often. |
| 20:39 | <annevk> | in any event, doing what you want is possible; seems a bit like a waste, but I don't care strongly |
| 20:39 | <smaug____> | I do care pretty strongly about this |
| 20:40 | <smaug____> | it would be odd API to share records |
| 20:41 | <annevk> | TabAtkins: normally the opinion people give is dishonest? that makes stuff even weirder, imo |
| 20:41 | <TabAtkins> | Nah, it means just, like, not sugar-coated. Real Talk. |
| 20:42 | <hober> | Hixie: bradee-oh is another good apple contact re: appcache |
| 20:45 | <annevk> | smaug____: I guess I'll let you sort it out with Adam for now; his point about Events seems valid |
| 20:47 | <smaug____> | annevk: totally invalid |
| 20:47 | <smaug____> | mutationobserver has nothing to do with events :) |
| 20:48 | <annevk> | sure it does, both are part of the platform |
| 20:48 | <smaug____> | different APIs |
| 20:50 | <annevk> | yeah sure, but it's the same thing, lots of observers getting the same object |
| 20:54 | <annevk> | smaug____: you're right btw it could be as simple as we have it now |
| 20:54 | <annevk> | smaug____: moving step 1-3 to 7.0 |
| 20:54 | <annevk> | smaug____: that would do what you want |
| 20:54 | <Hixie> | hober: thanks |
| 20:56 | <TabAtkins> | Who's in charge of the WHATWG forums? "Alexiswen" is a spammer account. |
| 20:58 | <annevk> | zcorpan |
| 20:58 | <annevk> | and some other people I think |
| 21:00 | <tantek> | anyone here play with famo.us? http://gigaom.com/2012/11/25/famous/ |
| 21:29 | <GPHemsley> | w00t w00t... all wiki admins are invited to: "The All Star Showcase |
| 21:29 | <GPHemsley> | Madhouse Comedy Club |
| 21:29 | <GPHemsley> | Tuesday, December 4" |
| 21:29 | <GPHemsley> | how exciting! |
| 21:30 | <annevk> | it's a boring job, but it has its perks |
| 21:30 | <GPHemsley> | annevk: How many free tickets do we want? |
| 21:31 | GPHemsley | counts 210 people here. |
| 21:31 | annevk | was gonna say the same |
| 21:31 | <GPHemsley> | Consensus! Yay! |
| 21:31 | <Ms2ger> | FO! |
| 21:39 | <gsnedders> | Ms2ger: You're violating the SHOULD requirement to give technical justification! |
| 21:39 | <Ms2ger> | gsnedders, FO to that requirement! |
| 21:40 | <gsnedders> | :) |
| 21:40 | <dglazkov> | Hixie, annevk: https://www.w3.org/Bugs/Public/show_bug.cgi?id=20050. It's tricky, because even though neither selectstart nor document.all are spec'd, I want implementers to do the right thing and leave no room for interpretation |
| 21:40 | <dglazkov> | Hixie, annevk: what do you usually do in such cases? |
| 21:40 | <Ms2ger> | doc.all is specced |
| 21:41 | <dglazkov> | Ms2ger: oh? |
| 21:41 | <Ms2ger> | In the Obsolete things / Requirements for implementers section |
| 21:41 | <dglazkov> | great, then selectstart |
| 21:41 | <dglazkov> | Ms2ger: ooh, that's a cool idea |
| 21:41 | <annevk> | dglazkov: if selectstart is expected to be implemented by everyone, it should be covered |
| 21:42 | <dglazkov> | annevk: IE + WebKit only |
| 21:42 | <annevk> | dglazkov: if it's expected to be removed from the platform, bugs should be filed on vendors |
| 21:42 | <Ms2ger> | dglazkov, does that list apply to synthetic events? :) |
| 21:42 | <annevk> | we don't really do middle ground, either it's in or out :) |
| 21:42 | <dglazkov> | Ms2ger: it does, but I need to make it more explicit |
| 21:43 | <dglazkov> | Ms2ger: related bug https://www.w3.org/Bugs/Public/show_bug.cgi?id=20017 |
| 21:43 | <Ms2ger> | Well, then it doesn't matter if the browser ever fires the event ;) |
| 21:43 | <Ms2ger> | Ugh, document.createEvent |
| 21:44 | <dglazkov> | Ms2ger: good point |
| 21:45 | <annevk> | dglazkov: fwiw, if you're going to change what happens to event dispatch in any way, I strongly suggest you make sure DOM gets updated appropriately |
| 21:45 | <annevk> | dglazkov: so it's clear from the core dispatch algorithm and not some monkey patching |
| 21:45 | <annevk> | dglazkov: that probably goes for a lot of the shadow DOM, at some point I should take a look I suppose and see what the DOM should handle |
| 21:46 | <Ms2ger> | dglazkov, and let annevk do it, I don't care for the shadow DOM :) |
| 21:47 | <annevk> | Ms2ger: not like there's been much activity from you on the standards front other than a couple of objections :p |
| 21:48 | <Ms2ger> | annevk, make that any front ;) |
| 21:48 | <annevk> | Ms2ger: aaaah, uni right? |
| 21:49 | <Ms2ger> | Still |
| 21:49 | Ms2ger | will be glad to be done, so he can spend all his time on this mess |
| 21:50 | <annevk> | Ms2ger: it is indeed a great mess |
| 21:51 | <jgraham> | I think to think of the "shadow" DOM as the "sinister" DOM |
| 21:51 | <Ms2ger> | The left-handed DOM? |
| 21:51 | <hober> | damn, Ms2ger beat me to it |
| 21:52 | Ms2ger | gives hober a sinister high five |
| 21:57 | <dglazkov> | Ms2ger: you don't care for shadow DOM?! |
| 21:57 | <Ms2ger> | dglazkov, I think that's what I said :) |
| 21:57 | <dglazkov> | whyyy |
| 22:00 | <smaug____> | someone should review what dglazkov is doing :p |
| 22:01 | smaug____ | has been way too busy with other stuff |
| 22:02 | <dglazkov> | annevk: that's a great idea. There's even a bug file for that: https://www.w3.org/Bugs/Public/show_bug.cgi?id=16904 |
| 22:02 | <smaug____> | I feel like Shadow DOM is going a bit wrong direction (by making things public by default etc), but I could be wrong, since I haven't checked the latest spec |
| 22:02 | <annevk> | dglazkov: teehee consistent me |
| 22:04 | <dglazkov> | annevk: it will be interesting to see how the shadow DOM machinery is split up/folded into relevant spec |
| 22:04 | <annevk> | dglazkov: is a shadow boundary between different shadow trees or between the document tree and the shadow tree? |
| 22:05 | <dglazkov> | all of the above |
| 22:05 | <annevk> | dglazkov: might want to clarify "The encapsulation boundaries between shadow trees are called shadow boundaries." then |
| 22:06 | <dglazkov> | annevk: yeah, makes sense |
| 22:07 | <annevk> | dglazkov: conformance criteria wise that start is also somewhat messy; e.g. in http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/shadow/index.html#shadow-trees it's established as fact that only elements can be shadow host, and then later on that's suddenly required |
| 22:07 | <annevk> | dglazkov: that MUST requirement does not make much sense |
| 22:10 | <annevk> | dglazkov: the same goes with http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/shadow/index.html#upper-boundary-encapsulation everything stated there should be non-normative; if that doesn't follow from the definitions of the various features mentioned, there's a big problem |
| 22:10 | <dglazkov> | annevk: http://dvcs.w3.org/hg/webcomponents/rev/314ccb4ffefd |
| 22:12 | <dglazkov> | annevk: on that last bit, what would be a better way to specify this? |
| 22:13 | <annevk> | dglazkov: hmm so an element can have one or more associated shadow trees |
| 22:14 | <annevk> | dglazkov: since these are standalone trees, obviously methods that operate on element's tree are not getting into it |
| 22:14 | <annevk> | dglazkov: so there's nothing to specify |
| 22:14 | <annevk> | dglazkov: likewise, since shadow root is the root of this tree, it will have a null parentElement/parentNode |
| 22:15 | <dglazkov> | annevk: so basically, the scoping constraint list is just a list of effects (which could be non-normative) |
| 22:15 | <annevk> | dglazkov: it should be non-normative |
| 22:15 | <dglazkov> | okay |
| 22:16 | <dglazkov> | that's great! |
| 22:16 | <annevk> | dglazkov: it's fine to explain implications, it's not fine to require them, because then you require things twice which generally leads to confusion |
| 22:16 | <annevk> | dglazkov: (e.g. here it was not clear to me whether I needed to change the DOM or not; apparently not for this case) |
| 22:16 | <dglazkov> | nope |
| 22:17 | <dglazkov> | I mean yep |
| 22:17 | <dglazkov> | :) |
| 22:18 | <annevk> | dglazkov: same goes for "If an insertion point is not in a shadow tree, it must have the same rendering behavior as the HTMLUnknownElement." |
| 22:18 | <annevk> | dglazkov: is "insertion point" some kind of element node btw? |
| 22:18 | Ms2ger | once argued that xmp should be an HTMLPreElement by such a comment |
| 22:19 | <dglazkov> | annevk: yes |
| 22:19 | <annevk> | dglazkov: also, are we actually talking about the layout tree here? |
| 22:19 | <annevk> | dglazkov: because afaict the document and shadow tree remain intact |
| 22:19 | <dglazkov> | annevk: yes |
| 22:19 | <annevk> | dglazkov: so it's really more how document+shadow affect layout than anything else? |
| 22:20 | <dglazkov> | annevk: yes! |
| 22:20 | <annevk> | dglazkov: I think it would be good to call that out explicitly |
| 22:20 | <dglazkov> | annevk: I thought it was? |
| 22:20 | <dglazkov> | oh you mean in introduction/background? |
| 22:21 | <dglazkov> | annevk: http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/shadow/index.html#rendering-shadow-trees |
| 22:21 | <annevk> | dglazkov: section 4.2 does not mention layout once |
| 22:23 | <dglazkov> | annevk: it's in 4 |
| 22:24 | <annevk> | I think it would be clearer if you had a section explaining the shadow tree (API, changes to the event model) and then a section explaining changes to the layout tree |
| 22:25 | <annevk> | maybe the problem is that shadow tree is used for a lot of things |
| 22:26 | <annevk> | "shadow tree" is the template, but it's still called "shadow tree" when rendered and intertwined with the document tree |
| 22:26 | <dglazkov> | "shadow tree" is not template? where do you get that? |
| 22:27 | <annevk> | sorry, it's a thing with insertion points, that kind of makes it look like a template to me |
| 22:28 | <annevk> | the confusion I have is that 4.1 talks about the DOM and then 4.2 suddenly talks about layout |
| 22:28 | <dglazkov> | the way I think of this is that insertion points and the fact that they have some nodes distributed into them is one thing, and the layout tree is just an effect of that |
| 22:28 | <dglazkov> | annevk: I don't think it does? |
| 22:29 | <annevk> | distribution is only observable from layout |
| 22:29 | <dglazkov> | annevk: no, you can totally see it from DOM |
| 22:29 | <dglazkov> | annevk: see HTMLContentElement.getDistributedNodes() |
| 22:30 | <dglazkov> | annevk: layout is a nice observable effect of the distribution though, that's definitely true |
| 22:30 | <annevk> | okay |
| 22:31 | <annevk> | so when do all these algorithms happen? |
| 22:31 | <annevk> | is it all instant? |
| 22:33 | <TabAtkins> | Hixie: Ugh, I forgot to trim the cc list on my reply to the menu thread. Mind unwedging it? |
| 22:34 | <dglazkov> | annevk: they happen as required. For example, when we need to render the shadow tree, it invokes distribution algorithm: http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/shadow/index.html#dfn-rendering |
| 22:34 | <Hixie> | TabAtkins: hah :-P |
| 22:34 | <Hixie> | TabAtkins: on it |
| 22:34 | <dglazkov> | annevk: via the composition algorithm |
| 22:35 | <annevk> | dglazkov: what if the shadow tree is under a display:none node and inside the shadow tree you call getDistrubutedNodes()? |
| 22:35 | <dglazkov> | annevk: one thing I really need to do is make sure I invoke this right for each API getter |
| 22:35 | <dglazkov> | right |
| 22:36 | <dglazkov> | getDistributedNodes should ask for distribution |
| 22:36 | <annevk> | dglazkov: I see |
| 22:36 | <TabAtkins> | annevk: distribution happens before box construction. display:none shouldn't have any effect. |
| 22:36 | <dglazkov> | there's probably more places where I need to put that in place |
| 22:36 | <dglazkov> | filing bug |
| 22:36 | <TabAtkins> | distribution affects the "document tree" that CSS sees, in other words. |
| 22:36 | <annevk> | dglazkov: could you maybe also align the style sheet of the spec with other specs? e.g. use bold for <dfn> and such |
| 22:36 | <dglazkov> | annevk: no! |
| 22:37 | <dglazkov> | annevk: okay |
| 22:37 | <annevk> | dglazkov: what would also be great to have is if you could click on the <dfn> like you can in dom.spec.whatwg.org |
| 22:37 | <dglazkov> | I really like my dfn style though |
| 22:37 | <dglazkov> | annevk: yes, I need to do that |
| 22:37 | <annevk> | dglazkov: I'm sorry for your dfn style, maybe keep it as a local style sheet for yourself? :) |
| 22:38 | <dglazkov> | annevk: no! |
| 22:38 | <dglazkov> | annevk: okay |
| 22:40 | <dglazkov> | Ms2ger: you can't just poop on my plate and disappear. Come read the spec and file bugs! :P |
| 22:40 | <Ms2ger> | Oh, I can't? :) |
| 22:40 | <dglazkov> | Ms2ger: no! |
| 22:41 | <dglazkov> | annevk: thanks for doing a quick review. Can I just hire you to do this more thoroughly or something? :) |
| 22:49 | <TabAtkins> | Do all elements have a directionality, or only those with an explicit dir attribute? I think the former, right? They inherit directionality from their parent, and the root is set based on user preference? |
| 22:50 | <Hixie> | all |
| 22:50 | <Hixie> | it's in the html spec at http://www.whatwg.org/specs/web-apps/current-work/#the-directionality |
| 22:50 | <rniwa> | Hixie, annevk: maybe you guys bring back DOM UI events stuff back to life and spec selectstart... |
| 22:51 | <rniwa> | alternatively, AryehGregor_ can spec it in the editing API spec. |
| 22:51 | <Hixie> | rniwa: i'm still hoping one day someone will spec "click" |
| 22:51 | <Hixie> | or "mousedown" |
| 22:51 | Ms2ger | thinks rniwa just volunteered |
| 22:51 | <rniwa> | we've been getting a lot of superflous bug reports because it's not spec'ed anywhere. |
| 22:51 | <annevk> | rniwa: speccing that involves the layout tree and I stepped away from the layout tree |
| 22:52 | <annevk> | rniwa: Hixie did too |
| 22:52 | <rniwa> | Hixie: well... those are at least somewhat specified in DOM3 |
| 22:52 | <annevk> | rniwa: so maybe ask www-style? |
| 22:52 | <rniwa> | annevk: oh, you think it's in the realm of CSS WG? |
| 22:52 | <TabAtkins> | It *might* be reasonable in terms of CSSOM. But probably better in DOM. |
| 22:52 | <annevk> | rniwa: yeah, mouse events involve hit testing -> CSS, selection does too -> CSS |
| 22:52 | <annevk> | no, not at all DOM |
| 22:52 | <rniwa> | annevk: I see, :( |
| 22:52 | <Hixie> | rniwa: not to the level of detail i'm talking about |
| 22:53 | <rniwa> | Hixie: sure. |
| 22:53 | <annevk> | layout tree -> DOM is a CSS affair |
| 22:54 | <rniwa> | annevk, Hixie: i don't mind it to be vaguely spec'ed for starters. |
| 22:54 | <rniwa> | annevk, Hixie: since a lot of things about selection is platform specific anyway. |
| 22:55 | <Hixie> | i'd love it to be specced |
| 22:55 | <annevk> | rniwa: vaguely speccing only works if I don't know what I'm doing, too late for UI events |
| 22:55 | <Hixie> | but i have too many fish on my plate already |
| 22:56 | <rniwa> | Hixie, annevk: okay. |
| 22:56 | <TabAtkins> | Hah, abusing operator overloading in C++ to allow "named operators", so you can write things like "v1 %dot% v2": http://forums.xkcd.com/viewtopic.php?f=11&t=14661&view=unread#p3210272 |
| 22:56 | <Hixie> | hah |
| 22:57 | <annevk> | rniwa: add it to http://wiki.whatwg.org/wiki/Specs_todo under APIs |
| 23:03 | <rniwa> | annevk: noted. |
| 23:04 | <Hixie> | jesus, i'm having trouble even treading water today |
| 23:04 | <Hixie> | why did everyone suddenly becme so prolific |
| 23:08 | <nessy1> | Hixie: you almost sound like you want me to convince you! |
| 23:10 | <Hixie> | i always want people to convince me |
| 23:10 | <Hixie> | that's the whole point of debate |
| 23:10 | <Hixie> | if i didn't want you to convince me, why would i bother debating? i don't care if you're convinced or not, it doesn't affect what i put in the spec :-) |
| 23:11 | <annevk> | heh, that's exactly right |
| 23:12 | <annevk> | I usually go out of my way to get convinced, e.g. listening to all of the IRI meeting the other week, while most of them didn't appear to have read my input |
| 23:17 | Hixie | tries to add crossorigin="" to <script> and gets tangled up in the already stupidly-complicated script loading alorithm |
| 23:17 | <annevk> | rniwa: added |
| 23:18 | <rniwa> | annevk: oh, thanks. |
| 23:18 | <annevk> | rniwa: other suggestions for that page welcome btw, it's good to have an overview of what needs to be done |
| 23:18 | <Hixie> | wow, i didn't realise the script fetch is started synchronously |
| 23:18 | <Hixie> | that makes life easier |
| 23:18 | <annevk> | Hixie: script loading + fetch + CORS, fun! |
| 23:18 | <Hixie> | srsly |
| 23:19 | <annevk> | so looking forward to untangling all that in couple of years |
| 23:19 | <Hixie> | i'm so not :-P |
| 23:20 | <rniwa> | Hixie: script loading indeed is insanely complicated :( |
| 23:26 | <Hixie> | hm, interesting |
| 23:26 | <Hixie> | per spec today, <script> sends Origin headers already |
| 23:26 | <Hixie> | any browsers do that? |
| 23:26 | <Hixie> | abarth? |
| 23:26 | <Hixie> | do you know, perchance? |
| 23:30 | <abarth> | Hixie: hi |
| 23:30 | <abarth> | Hixie: nope |
| 23:30 | <abarth> | Hixie: or at least not without the crossorigin attribute |
| 23:31 | <abarth> | I think WebKit and Firefox implement the crossorigin attribute for script |
| 23:31 | <pablof> | the origin is added when the crossorigin attribute is set in webkit, yeah |
| 23:32 | <Hixie> | ok good |
| 23:32 | <Hixie> | that's what i'm speccing |
| 23:32 | <Hixie> | that's muchly |
| 23:43 | <Hixie> | do any other specs invoke "report an error" or can i change its interface? |
| 23:51 | <nessy1> | Hixie: at this stage I'm happy to agree to disagree ;-) |
| 23:53 | <nessy1> | Hixie: I want to get back to captions ;-) |
