| 00:12 | <othermaciej> | rubys: any thoughts on my suggested issue closures? |
| 00:17 | <Hixie> | othermaciej: he was only here about 60 seconds |
| 00:18 | <Hixie> | oh, no, rubys is still here |
| 00:18 | <Hixie> | rubys2 left |
| 00:18 | <othermaciej> | Hixie: yeah, he just changed nicks |
| 00:18 | <roc> | othermaciej: you might be interested in this: http://lists.w3.org/Archives/Public/www-font/2009JulSep/1238.html |
| 00:18 | <roc> | in fact, it would be good to get some feedback |
| 00:19 | <othermaciej> | roc: we discussed it briefly among web folks and font folks |
| 00:19 | <roc> | oh good |
| 00:19 | <roc> | http://www.jfkew.plus.com/webotf/webotf-test.html too |
| 00:19 | <othermaciej> | roc: we are not at all enthusiastic about implementing a new font format |
| 00:20 | <othermaciej> | roc: and grabbing only chunks of it at a time would be pretty hard to shoehorn into our font infrastructure |
| 00:20 | <roc> | you don't have to grab only chunks of it at a time |
| 00:20 | <othermaciej> | roc: if all other browsers want to push something, we won't block it, but I don't think we are going to actively endorse any new format |
| 00:21 | <roc> | ok |
| 00:21 | <roc> | thanks |
| 00:21 | <Hixie> | google's in pretty much the same position -- we are fine with TTF. |
| 00:21 | <Hixie> | if operating systems add support for WebOTF, we would probably follow suit |
| 00:21 | <Hixie> | but on its own, it doesn't really seem to solve any pressing problems |
| 00:22 | <othermaciej> | we are also fine with TTF/OTF, and would not consider WebOTF an improvement |
| 00:22 | <othermaciej> | but we are less opposed to it than EOT or anything EOT based, since it does not seem to have DRM-like characteristics |
| 00:22 | <rubys> | i'm back |
| 00:22 | <heycam> | Hixie, are you sure that "Sean Hogen" in the Acknowledgements section shouldn't be "Sean Hogan"? |
| 00:23 | <othermaciej> | hi! |
| 00:23 | <Hixie> | heycam: i am not |
| 00:23 | <heycam> | (i remember seeing someone with the latter name send mails, but not the former) |
| 00:23 | <rubys> | what's the question? |
| 00:23 | <rubys> | irc archives appear to be down |
| 00:23 | <othermaciej> | rubys: I wanted to get your thoughts on my suggested closures of old issues, but I decided to just make a proposal for how to proceed with them on public-html |
| 00:24 | <othermaciej> | rubys: that being said, your input is still welcome if you have any |
| 00:24 | <Hixie> | rubys: regarding your comment in the poll, the reason i removed that issue marker was that i was under the impression that the issue had been resolved as part of the compromise maciej set out -- removing the issue marker was one of the things jf and maciej agreed to as far as i understood it |
| 00:24 | <Hixie> | rubys: and i didn't see your e-mails about it (there was a lot of traffic at the time, i must have missed one) |
| 00:24 | <rubys> | othermaciej: where is the proposal? |
| 00:25 | <rubys> | hixie: we clearly have a different idea of what closed means, but that's OK |
| 00:25 | <othermaciej> | rubys: oh, I guess I didn't send it yet |
| 00:25 | <rubys> | I guess that would explain why I couldn't find it. |
| 00:26 | <rubys> | yes, I do have thoughts... |
| 00:26 | <othermaciej> | rubys: my suggestion was going to be, close ISSUE-5, ISSUE-6, ISSUE-9, ISSUE-10, ISSUE-11, ISSUE-12, ISSUE-13, ISSUE-16, ISSUE-17, ISSUE-20, ISSUE-26 and ISSUE-28 on Monday if there are no objections |
| 00:26 | <othermaciej> | and I was planning to ask the team contacts to give me issue tracker edit rights to do it |
| 00:26 | <rubys> | oh, I can give you that now. |
| 00:27 | <rubys> | but I wouldn't suggest any sudden closure. Weren't you complaining a short while back about a particular vote being rushed? :-) |
| 00:27 | <othermaciej> | (I sent emails justifying closing each of those issues and soliciting feedback.) |
| 00:27 | <rubys> | oh, I think you are aright on all counts except for the one that Julian owns. |
| 00:27 | <othermaciej> | if you would like to suggest a different process for closing them, then I'm fine with that |
| 00:27 | <rubys> | and if nobody steps forward and agrees to work an item, it should be closed. |
| 00:28 | <othermaciej> | I think some reasonable period to object to closing is an adequate process, I am willing to make the time period whatever you think is best, if it's not unreasonable long |
| 00:29 | <rubys> | it looks like I'm chairing again on thursday, my plan was to announce that the issues that you identified that have no owners will be closed by the next thursday unless somebody steps forward to owning it. |
| 00:29 | <othermaciej> | I'm willing to leave Julian's open if he insists on it, although I think an issue about an old feature proposal he had is not the right way to represent the fact that he'd like to review a related section of the spec and give some feedback |
| 00:29 | <rubys> | he seems to agree that there won't be any major change. |
| 00:30 | <othermaciej> | the issue is pretty explicitly about a particular kind of major change, so it doesn't seem to represent his intent |
| 00:30 | <othermaciej> | that being said, I am satisfied to keep it open for now |
| 00:31 | <othermaciej> | though at some point, Julian's intent to do some review can't block Last Call, if he continues not to do it |
| 00:31 | <rubys> | totally agreed on that last point |
| 00:32 | <othermaciej> | rubys: OK if I send email summarizing this discussion? ("Issues to be announced at Thursday's telecon, and closed next Thursday except for ones where someone objects and steps up to own it." basically) |
| 00:33 | svl | (n=me⊙idn) has left #whatwg |
| 00:33 | <rubys> | you can now edit issues. I love the work you have done, just make sure that you give people an opportunity. |
| 00:34 | <othermaciej> | I'm trying to be extremely conservative in issues that I propose to close, and I intend to give everyone adequate opportunity to object |
| 00:34 | <rubys> | as I said, I was going to include it on the announce I was sending out tomorrow, but if you feel you want to go ahead, that's fine. I feel that announce is low traffic and there is no excuses to miss an email (me glances towards hixie :-)) |
| 00:34 | <Dashiva> | What about those of us who only read public-html and not announces? :) |
| 00:34 | <rubys> | then you get to read it later (in the minutes :-)) |
| 00:35 | <othermaciej> | I think I'll send it separately and mention that you will also mention the details in the announcement, since I think there are people who will be interested, but habitually skip (or at best skim) the announcements |
| 00:35 | <Hixie> | rubys: oh you sent your comment in an agenda e-mail? i don't read those, they seem to never change. |
| 00:35 | <rubys> | http://lists.w3.org/Archives/Public/public-html/2009Aug/0315.html |
| 00:35 | <rubys> | http://lists.w3.org/Archives/Public/public-html/2009Aug/0330.html |
| 00:35 | <rubys> | no, my comment wasn't in those. Chris's agenda emails are formulaic, but I try to add more 'spice' to mine. |
| 00:38 | <Hixie> | oh i saw your e-mail of those two, but it didn't seem to be a question, so i decided it'd be better for everyone if i didn't add fuel to the fire |
| 00:39 | <rubys> | othermaciej: I totally agree about moving 12 and 20 from issues to bugzilla on testcases |
| 00:39 | <Hixie> | the first one was from laura, and i'm still waiting for her to explain how i wasn't cooperating before i reply to her e-mails |
| 00:39 | <Hixie> | as i'm tired of sending e-mails with questions, and never getting replies |
| 00:39 | <Hixie> | yet getting called on not replying to questions |
| 00:40 | <Hixie> | anyway, as i said, the reason i didn't include the issue marker was that was the agreement with jf and maciej |
| 00:40 | <rubys> | I made it clear then that I still view the issue as open. I tried to encourage you to add back the issue box, and later I tried to encourage manu not to proceed with the poll. Seem to be batting 000 these days. :-) |
| 00:40 | <Hixie> | considering the summary issue open is a huge mistake imho |
| 00:41 | <Hixie> | there's no direction from this point that doesn't make more people less happy |
| 00:41 | <Hixie> | so if we want to change the spec at this point, it pretty much has to be a vote |
| 00:41 | <othermaciej> | I don't think JF and I specifically said either to remove the marker or to keep it, and I personally don't care |
| 00:41 | <rubys> | considering it closed invites Formal Objection. Much better to give people rope and all that. And sometimes they surprise you. |
| 00:42 | <rubys> | http://lists.w3.org/Archives/Public/public-html/2009Aug/0017.html |
| 00:42 | <rubys> | JF clearly asked for the mark, and Ian clearly agreed. |
| 00:42 | <Hixie> | that was long before maciej's compromise |
| 00:42 | <othermaciej> | and indeed Ian added the marker at that point |
| 00:43 | <rubys> | which you accepted, but not everybody did. such a hasty process creates ill will |
| 00:43 | <othermaciej> | if only there were a way to avoid having a hasty process on technical issues right before WD |
| 00:44 | <rubys> | othermaciej: want me to dig up all the times recently where you were complaining about a vote being too fast? :-) |
| 00:44 | <Lachy> | rubys, I think pushing to have warnings in the spec about open issues for summary and, previously, longdesc, has set a silly precedent that has lead us to this time wasting effort to vote on the inclusion of transient warnings that won't last longer than one WD cycle, let alone help to resolve the actual issues at hand. |
| 00:45 | <rubys> | Lachy: have you looked at the poll lately? |
| 00:45 | <Lachy> | yeah, I know Hixie's draft is ahead |
| 00:45 | <rubys> | so why get upset and argue? |
| 00:46 | <Dashiva> | Precedent? |
| 00:46 | <othermaciej> | rubys: the meaning of my statement was supposed to be - I think there is indeed a way to avoid having a hasty process on technical issues right before WD, several ways, and we should do one of those |
| 00:46 | <Lachy> | because I'm annoyed with this whole heartbeat issue having taken 4 weeks of valuable time that could have been spent finding real solutions, rather than meaningless nonsense |
| 00:47 | <rubys> | there are only two issues that I'm really worried about. Issue-35 and Issue-74. |
| 00:47 | <Hixie> | rubys: btw do you still intend to do the review you said you'd do? |
| 00:47 | <rubys> | Lachy: so don't spend your valuable time on it. |
| 00:48 | <Hixie> | rubys: (just asking to know how to plan for the next few months) |
| 00:48 | <rubys> | I no longer see calling out sections as an effective way to proceed. |
| 00:48 | <Hixie> | k |
| 00:48 | <Hixie> | what's your new plan for establishing consensus? |
| 00:49 | <othermaciej> | it seems to me the blocker on issue-35 at the moment is not controversy on how to proceed, but rather blocking on a PFWG decision |
| 00:49 | <othermaciej> | we can (and should IMO) find ways to be more pro-active about unblocking progress |
| 00:49 | <rubys> | both 35 and 74 are blocked on PFWG |
| 00:50 | <othermaciej> | for 74, I believe good progress is being made on proposing a solution |
| 00:50 | <othermaciej> | and the solution may require little or no change to the spec besides editorial text giving examples |
| 00:50 | <Lachy> | Dashiva, yes, that's what I meant. I always spell that word wrong |
| 00:50 | <rubys> | http://www.w3.org/html/wg/tracker/actions/133 |
| 00:50 | <othermaciej> | at least, that is what I have heard from my sources involved closely in those discussions |
| 00:50 | <hober> | rubys: I'm surprised you're not really worried about issue 41 |
| 00:51 | <rubys> | 41 has no concrete proposal. |
| 00:51 | <Dashiva> | Lachy: I wasn't correcting you, I was semi-answering rubys |
| 00:51 | <othermaciej> | anyway, sorting out the chaff will make it easier for the group to have a shared view of which issues are important to worry about |
| 00:51 | <othermaciej> | which is why I am starting with the low-hanging fruit |
| 00:52 | <othermaciej> | I'm thinking like a project manager - must get bug trendline to point in the right direction |
| 00:52 | <rubys> | othermaciej: that's great, just make sure that everybody has a thursday-thursday period to notice the impending closure. |
| 00:52 | <rubys> | not everybody has the bandwidth to keep up with the emails. |
| 00:53 | <othermaciej> | rubys: I think thursday-thursday is a fine timeline and I'll stick to that |
| 00:53 | <othermaciej> | I think that way, both primarily-email and primarily-telecon participants get a fair chance to have their say |
| 00:53 | <rubys> | exactly |
| 00:54 | <rubys> | I have no interest in keeping open issues for which there are no owners. |
| 00:54 | <rubys> | And for issues with owners, I want dates. |
| 00:54 | <rubys> | 35 and 74 have dates in Nov and Dec, which is what concerns me. |
| 00:54 | Hixie | would rather see progress than dates :-P |
| 00:55 | <Hixie> | rubys: what's your new plan for establishing consensus? |
| 00:55 | <rubys> | close items with no owners, give issues with owners a chance, and then close the issues either when they complete or fail. |
| 00:56 | <Hixie> | so the issue tracker's list of issues in the state Open (not Raised, not Pending Review, and not Closed) is the list of issues that need to be resolved before LC? |
| 00:57 | <Hixie> | or do you mean the list of issues not marked Closed? |
| 00:57 | <othermaciej> | I think establishing committed owners and deadlines for the issues that remain after closing the low hanging fruit is a fine next step |
| 00:59 | <othermaciej> | that leaves the questions of what to do if the deadline is missed (can't let it slip indefinitely), and what to do if there are multiple competing concrete proposals |
| 00:59 | <rubys> | Hixie: after a bit of cleanup, I do see the issue tracker as being that. And othermaciej is doing a fine job at kicking off that discussion. |
| 00:59 | <Hixie> | rubys: which states are the ones i need to look at to see issues blocking LC? |
| 00:59 | <othermaciej> | I think Hixie is asking if issues marked as "Raised" or "Pending Review" are considered open in the sense of blocking LC |
| 00:59 | <othermaciej> | (it's not entirely clear to me what the distinctions are) |
| 01:00 | <rubys> | Raised means no owners. Destined to be closed due to lack of interest unless somebody steps up. |
| 01:00 | <rubys> | Pending Review means that the owner considers his or herself done. Also destined to be closed. |
| 01:01 | <othermaciej> | by what process will Destiny work its will? |
| 01:01 | <rubys> | Open are the key ones, and what is key is getting agreement. Telling people that it is closed only pisses them off. |
| 01:01 | <rubys> | othermaciej: taking your list and giving people until a week from thursday to volunteer is a great process. |
| 01:02 | <othermaciej> | rubys: all right, then in my next pass I will consider all Raised and Pending Review issues for the chopping block if they do not get caught in the first pass (where I am hoping to find issues where no real dissent remains) |
| 01:03 | <Hixie> | rubys: who owns issues with no action items? |
| 01:04 | <Hixie> | (i'm assuming the people with action items own the issues with them) |
| 01:04 | <Dashiva> | If hybi were to create a generic bidirectional tunneling protocol, wouldn't that immediately get blocked in firewalls for the same reason the firewalls block non-http in the first place? |
| 01:05 | <rubys> | hixie: tell me which ones, and I'll demote to raised or find an owner. I just demoted 60. |
| 01:05 | <Hixie> | rubys: http://www.w3.org/html/wg/tracker/issues/37 http://www.w3.org/html/wg/tracker/issues/59 |
| 01:05 | <Dashiva> | (Well, not immediately, but as soon as the firewalls change) |
| 01:05 | <othermaciej> | Hixie: it seems to me that based on what Sam said, issues with no action item should be given an opportunity to find an owner, who presumably thereby receives an action item |
| 01:06 | <othermaciej> | I will continue my review of open issues tonight |
| 01:06 | <rubys> | demoted 37. Will kick Mike again about 59. |
| 01:07 | <rubys> | s/presumably/definitely/ |
| 01:07 | <Hixie> | i can volunteer to own 59 if you like. And then immediately announce I've done it. :-) |
| 01:07 | <Hixie> | (the html5 spec has had an "author view" for a while now) |
| 01:07 | <Lachy> | Hixie, I like that idea |
| 01:07 | <othermaciej> | Hixie: is it possible to produce a copy of your spec that has the "author view" as the default stylesheet? |
| 01:08 | <othermaciej> | Hixie: I suspect people will be a tiny bit more satisfied if they can follow a link to the "author view", even if there is no material difference |
| 01:08 | <Hixie> | othermaciej: sure, that's technically trivial. |
| 01:09 | <Lachy> | Is it possible generate a copy which excludes all the implementer stuff from the file, rather than just hiding it with a stylesheet? |
| 01:10 | <Lachy> | That should make the file significantly smaller and at least partially resolve the issues people have with the monolithic spec |
| 01:10 | <rubys> | if nobody else volunteers for 59, it will get closed. I would must rather have a situation where somebody (in this case Mike) was given every opportunity and failed rather than telling them NO and have them be convinced that the only reason why they failed was that they weren't given a reasonable opportunity. |
| 01:10 | <othermaciej> | people might be slightly even more satisfied with that, even though there is even less material difference |
| 01:10 | <Hixie> | Lachy: technically yes, but someone would have to make the script to do it. |
| 01:10 | <Lachy> | ok |
| 01:11 | <Lachy> | I assume it would just take a small script to strip out any element with a class="impl" on it |
| 01:11 | <othermaciej> | we should give Mike the opportunity to weigh in on whether Hixie's author view (if it can be linked standalone) satisfies the goals he had for H:TML |
| 01:11 | <rubys> | Mike is traveling at the moment, but he does log on. He also plans to be on Thursday's call. |
| 01:11 | <Hixie> | Lachy: yes |
| 01:12 | <othermaciej> | Lachy: are you willing to volunteer to make that script |
| 01:12 | <Lachy> | I wouldn't mind having Mike's H:TML draft published non-normatively in addition to an author only copy |
| 01:12 | <othermaciej> | ? |
| 01:12 | <Lachy> | othermaciej, maybe. |
| 01:12 | <Lachy> | I might even be able to do it now, if I can base it one one of my existing scripts I use for generating the authoring guide |
| 01:12 | <othermaciej> | if someone actually makes the script, then we may be able to persuade Mike that the author view is a win-win solution |
| 01:13 | <othermaciej> | or if it does not meet some of his goals, we can ask him to articulate what those are |
| 01:13 | <Lachy> | Hixie, if it works like this: cat source | author-view > author-only-source, will that fit into your tool chain? |
| 01:20 | <Hixie> | Lachy: it has to be a web service for me to put it in my toolchain |
| 01:21 | <Hixie> | Lachy: (i can't be parsing the html5 spec a dozen times at once on the local machine) |
| 01:22 | <Lachy> | ok. Well, I will proceed under the assumption that such a simple system will be very easy to integrate into a web service |
| 01:22 | <Philip`> | So you prefer to rely on a dozen remote machines to each parse it? |
| 01:22 | <Hixie> | Philip`: yup |
| 01:22 | <Hixie> | Philip`: so long as it's not mine :-P |
| 01:23 | Philip` | doesn't understand why that system doesn't collapse constantly, since it has lots of potential points of failure |
| 01:23 | <Lachy> | it sucks that we don't have a nicely integrated system that allows the source to be parsed just once and processed such that it results in multiple output files |
| 01:24 | <Hixie> | Philip`: the only critical point of failure i don't control is pimpmyspec.net |
| 01:24 | Philip` | should probably move the multipage splitter onto a proper server, rather than on an old machine in his parents' house over an ADSL line |
| 01:24 | <Dashiva> | Where's the fun in that? |
| 01:24 | <Hixie> | Lachy: i have a number of preprocessing steps that happen before the source becomes valid HTML that can be parsed |
| 01:24 | <Hixie> | Lachy: e.g. merging source files from whatwg.org/demos, filtering the references, etc. |
| 01:26 | <rubys> | I seem to be able to go from Hixie-source to w3c split out spec in about 15 seconds on a rather midling AMD e-machine that I purchased for $199 earlier this year. |
| 01:26 | <rubys> | http://www.tigerdirect.com/applications/searchtools/item-details.asp?EdpNo=4616541 |
| 02:03 | <Hixie> | wow, a lot of these actions have been open a long time |
| 02:03 | <Hixie> | i wonder how to help people make progress on them |
| 04:03 | <roc> | this BWTP thread looks like a textbook case of feature creep |
| 04:05 | <othermaciej> | roc: gonna vote in the HTML WG poll? |
| 04:05 | <othermaciej> | http://www.w3.org/2002/09/wbs/40318/wd08/ |
| 04:06 | <othermaciej> | I encourage you to vote your conscience, despite the relative triviality of the issue at stake |
| 04:06 | <othermaciej> | roc: BWTP looks like feature creep to me too - I wonder if there is a middle ground that adds a few of the most useful features but otherwise is closer in simplicity to WebSocket Protocol |
| 04:11 | <roc> | othermaciej: your wish is my command |
| 04:15 | <roc> | hmm, and I missed the part about BWTP having "forgiving syntax" |
| 04:48 | <Hixie> | othermaciej: if there are features that actually make sense to add, and don't put onerous requirements on server-side implementations that don't need those features, i hope we can add them |
| 04:48 | <Hixie> | othermaciej: i haven't seen any such features yet |
| 04:48 | <othermaciej> | Hixie: I haven't had a chance to give it a close review |
| 04:49 | <othermaciej> | for now I am taking it on faith that being "like http" would make things easier for server-side implementations embedded in an existing Web server |
| 04:49 | <othermaciej> | but I don't have the context to evaluate the merit of this claim |
| 04:49 | <othermaciej> | and the corresponding claim as to the client side seems wrong |
| 04:49 | <Hixie> | it certainly wouldn't make it easier for standalone servers |
| 04:50 | <Hixie> | which i expect to be the common case |
| 04:50 | <Hixie> | on the other hand, i've written a websocket server in 99 lines of perl |
| 04:50 | <othermaciej> | I would love to hear from someone in charge of a big existing infrastructure which would be easier for them |
| 04:51 | <othermaciej> | (although I suppose that risks enterprise-itis) |
| 04:52 | <dave_levin> | othermaciej: Bidirection Web Transfer Protocol vs Web Sockets? |
| 04:52 | <othermaciej> | dave_levin: yes |
| 04:53 | <othermaciej> | I don't know if I should bother to argue with the crazy people who think that instead of a ws: URI scheme (or similar), the URIs should just be http://ws.specific-magic-hostname.org?the-actual-url-goes-here |
| 04:54 | <dave_levin> | othermaciej: I'll see if I can find someone on the Google Talk team to look them over if that would be helpful. They sit pretty close to me. |
| 04:58 | <Hixie> | dave_levin: it would be helpful if they could review websocket in general |
| 04:59 | <roc> | othermaciej: ask someone who's actually in charge of actual infrastructure what would be easier for them ... do not ask their Architect |
| 05:00 | <dave_levin> | Hixie: Honestly, they were a bit slow on all of that, but I think they are ready to focus more on these issues. I'll talk to them. I think Ukai has also been talking to someone on that team (since he has been working web sockets in WebKit). |
| 05:01 | <Hixie> | cool |
| 05:01 | <Hixie> | roc: i'm not sure we even have any of those :-) |
| 05:02 | <othermaciej> | roc: *shudder* |
| 07:05 | <hsivonen> | annevk42: the comment box on the poll seems like a good place to enumerate what's not factual about Manu's draft |
| 07:07 | <othermaciej> | I wonder if this poll will top our record for most total votes (which I believe is 88) |
| 07:09 | othermaciej | is surprised to find on review that neither anne nor james have voted yet |
| 07:51 | <Mrmil> | Looks like there is a boom in HTML 5 tutorials... |
| 07:54 | <othermaciej> | hsivonen: do you know what's up with this issue? is there still a conflict? http://www.w3.org/html/wg/tracker/issues/38 |
| 07:55 | <othermaciej> | looks fixed, nevermind |
| 08:03 | <othermaciej> | hsivonen: does ARIA still depend in any way on CURIEs? |
| 08:03 | <othermaciej> | (re http://www.w3.org/html/wg/tracker/issues/51 ) |
| 08:06 | <hsivonen> | othermaciej: AFAIK, no, but I'll check |
| 08:07 | <hsivonen> | othermaciej: can't find any mention of curie in the latest ARIA spec. |
| 08:07 | <othermaciej> | hsivonen: ok, thanks |
| 08:08 | othermaciej | wonders whether he has the stomach to review issues 46-60 |
| 08:08 | <othermaciej> | this is an incredibly boring task, which the chairs should have long ago done or delegated :-( |
| 08:08 | <hsivonen> | indeed |
| 08:09 | <hsivonen> | othermaciej: thank you for doing it anyway |
| 08:10 | <hsivonen> | Issue 53 seems to have draft text now |
| 08:10 | <hsivonen> | issue 54 has been addressed |
| 08:10 | <othermaciej> | I'm not sure what to suggest for issue 48 |
| 08:10 | <Lachy> | issue 54 is pending the registration of about: URI scheme |
| 08:11 | <othermaciej> | yeah |
| 08:11 | <Lachy> | I would close it, but some people wanted it kept open until that's done |
| 08:11 | <othermaciej> | I think I'll suggest raising a separate issue on registering the about: URI scheme, if registering the scheme needs to block Last Call |
| 08:11 | <Lachy> | good idea |
| 08:12 | <hsivonen> | othermaciej: about ARIA specifically: ARIA was fixed to acknowledge similarity of role to "XHTML Role Attribute Module" without actually importing the definition |
| 08:12 | <othermaciej> | or we can track it in bugzilla, if a scheme registration doesn't need to block Last Call |
| 08:13 | <othermaciej> | do media type registrations normally get updated before or after LC? |
| 08:13 | <hsivonen> | I hope the pont of issue 56 is to update AWWW if it turns out that real-world URL processing conflicts with Architecture |
| 08:13 | <hsivonen> | s/pont/point/ |
| 08:13 | <othermaciej> | I have no idea what issue-56 is about |
| 08:14 | <othermaciej> | but I believe the plan to defer to WEBADDRESS or IRIbis or whatever addresses it |
| 08:14 | <hsivonen> | if issue 56 needs to be an issue, it should be a TAG issue filed against Architecture |
| 08:15 | <othermaciej> | so the only ones I don't know what to do with are ISSUE-48 and ISSUE-53 out of this next batch |
| 08:15 | <Hixie> | othermaciej: if you mean mime types, we let the IESG know that we're going to register them when we hit LC, then we register them at CR. |
| 08:16 | <othermaciej> | Hixie: ok, so a task on MIME type registration doesn't need to block LC? |
| 08:16 | <othermaciej> | Hixie: or do we need draft registration text before LC, and if so do we have it? |
| 08:23 | <hsivonen> | BWTP seems like a lot of feature creep :-( |
| 08:27 | <Hixie> | othermaciej: the draft registrations for all the MIME types I'm aware that we need to register are all at http://www.whatwg.org/specs/web-apps/current-work/#iana-considerations |
| 08:28 | <othermaciej> | Hixie: ok, sounds like the issue on registrations can be closed, the |
| 08:29 | <hober> | I hope the ARIA folk handle their LC comments by either renaming @role to @aria-role or allowing the host language to use a more appropriate existing attr (in our case, @class) |
| 08:29 | <othermaciej> | hober: I don't think putting aria roles in @class is viable |
| 08:30 | <othermaciej> | too many existing pages would then appear to have an ARIA role accidentally |
| 08:30 | <hsivonen> | hober: renaming role isn't on the table |
| 08:30 | <hsivonen> | hober: hasn't been since Firefox 3.0 froze |
| 08:32 | jgraham | hasn't finished reading the scrollback but notes that he has a script that strips non author view stuff from the spec somewhere |
| 08:32 | <hsivonen> | hmm. my email isn't appearing on public-html |
| 08:33 | <othermaciej> | jgraham: do you think it would be feasible to integrate it with Hixie's toolchain? |
| 08:33 | <jgraham> | I also hacked together an anolis module to copy status annotations from the WHATWG data to a static spec |
| 08:33 | <hsivonen> | jgraham: awesome! |
| 08:33 | <jgraham> | I haven't checked it works very properly or anything |
| 08:34 | <jgraham> | I will continue to poke at it a bit |
| 08:34 | <jgraham> | othermaciej: pobably |
| 08:34 | <jgraham> | *probably |
| 08:34 | <othermaciej> | jgraham: it would be useful - so we can see if such a spec would satisfy those who want an author-only spec |
| 08:34 | <Lachy> | jgraham, great, that means I can take that off my todo list for today |
| 08:35 | <hsivonen> | anyway, the content of my email to list was that issue-30 isn't controversial anymore, because WAI-CG agreed to the obsoletion of longdesc if aria-describedby gets in |
| 08:35 | <othermaciej> | hsivonen: I saw your email |
| 08:35 | <othermaciej> | hsivonen: I even replied to it |
| 08:35 | <othermaciej> | I may have seen it not-via-the-list |
| 08:36 | <hsivonen> | othermaciej: ok. then SMTP at my end isn't horked |
| 08:38 | <jgraham> | biab |
| 08:38 | <othermaciej> | hsivonen: mails seem to be appearing in the archive out of order |
| 08:38 | otherarun | (n=arun⊙adpsn) has left #whatwg |
| 09:37 | <Hixie> | http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2009Aug/0070.html |
| 09:37 | <hsivonen> | http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2009Aug/0085.html |
| 09:38 | <Hixie> | yeah i couldn't tell if he was unintentionally proving our point about prefixes being confusing, or if he was being sarcastic. |
| 09:39 | <hsivonen> | I can't tell what his point is, either, but the email looks very confused. |
| 09:42 | <hsivonen> | http://www.w3.org/2009/07/30-rdfa-minutes : "We need to structure it so that it's easy for the W3C to accept the RDFa IG. RDFa isn't controversial, so shouldn't be an issue." |
| 09:44 | <Lachy> | what the? I've never known anyone to claim that <div xmlns:dc="..."> was invalid XML |
| 09:44 | hsivonen | fights the urge to reply to the anti-pattern thread and point out less than factual statements |
| 09:45 | <Lachy> | hsivonen, which anti-pattern thread? |
| 09:45 | <Lachy> | oh, on rdfa list |
| 09:45 | <hsivonen> | Lachy: on public-rdf-in-xhtml-tf |
| 09:50 | <jgraham> | http://hoppipolla.co.uk/410/spec-annotated.html first cut with no headers or stylesheet and with all the removed sections and so on left in |
| 09:52 | <annevk42> | the BWTP guys know that eventually the UTF-8 frame type won't be the only option available, right? |
| 09:52 | <annevk42> | they're so fixated on it... |
| 09:59 | <annevk42> | would it make sense to extend bogus comments to also include <% ? |
| 09:59 | <annevk42> | apparently WebKit/Trident already does that |
| 10:00 | <hsivonen> | annevk42: is it guys or guy? |
| 10:00 | <annevk42> | and e.g. http://www.lex24.ilsole24ore.com/Redazione/Riforma_cpc/Riforma.html would look better at the bottom |
| 10:00 | <annevk42> | hsivonen, there's more on the hybi list |
| 10:00 | <annevk42> | but fair enough |
| 10:01 | <gsnedders|work> | annevk42: Is that not quirks only, at least in WebKit? |
| 10:01 | <annevk42> | no |
| 10:02 | <Lachy> | jgraham, what have you added to that copy of the spec? |
| 10:02 | <annevk42> | also at the top of that page, not just the bottom |
| 10:02 | <Lachy> | ah, I see, a few sections have Status annotations |
| 10:04 | <jgraham> | Lachy: It should in theory be all sections that have status annotations in the WHATWG draft but I may have missed some |
| 10:04 | <hsivonen> | jgraham: let's ship it! |
| 10:05 | <jgraham> | s/I/my code/ |
| 10:06 | <Lachy> | jgraham, the one for the introduction is missing, which is the one I checked for first and didn't see |
| 10:06 | <annevk42> | hsivonen, how do you feel about having <% besides <? ? |
| 10:07 | <Lachy> | wait, that's weird. It is there |
| 10:07 | <jgraham> | Lachy: I don't have the introduction do I? |
| 10:07 | <jgraham> | It's in the header which I don't have |
| 10:07 | <Lachy> | yeah, you do. It says: |
| 10:07 | <Lachy> | Introduction |
| 10:07 | <Lachy> | Status: Working draft |
| 10:07 | <Lachy> | 1 Background |
| 10:07 | <Lachy> | ... |
| 10:08 | <Lachy> | the abstract is in the header |
| 10:09 | <jgraham> | Oh yeah |
| 10:11 | <hsivonen> | annevk42: assuming that WebKit/Trident already does it, I'm open to trying it. |
| 10:13 | <Lachy> | unless supporting it is really needed for compatibility reasons, I don't think we should |
| 10:14 | <Lachy> | have Mozilla received any bugs about supporting it? |
| 10:15 | <roc> | supportin gwhat? |
| 10:15 | <gsnedders|work> | <% as comments |
| 10:15 | <Lachy> | roc, webkit and trident apparently support it |
| 10:17 | <hsivonen> | Lachy: no bugs against the HTML5 parser at least |
| 10:18 | <Philip`> | http://brand.icxo.com/htmlnews/2007/07/11/919666_1.htm |
| 10:18 | <Philip`> | http://yuanyunfu.artron.net/exhibi_2.php?aid=A0000016&wrkid=BRT000000033876 |
| 10:18 | <Philip`> | http://www.51234.org/sy/3777.html |
| 10:19 | <Lachy> | Philip`, it depends on whether supporting that as a comment is really the best solution. If they're only testing it with browsers that do, then that would explain why they havne't noticed or fixed the error |
| 10:19 | <hsivonen> | the last one is a "reported attack page!" |
| 10:19 | <Lachy> | and presumably they have no intention of outputting JSP into the HTML |
| 10:20 | <hsivonen> | it's pretty clear that it's error recovery that makes the error less obvious to authors |
| 10:20 | <annevk42> | well, a) the cost is minor and b) it is far more likely they just tested in IE than anything else |
| 10:20 | <hsivonen> | the question is if Gecko and Opera are worse off by not doing it if Trident and WebKit do it |
| 10:21 | <hsivonen> | also, the implementation would be trivial |
| 10:21 | <hsivonen> | no new states. just another transition |
| 10:21 | <Philip`> | Most of the <%...s seem to be in attribute values rather than in text content |
| 10:21 | <hsivonen> | assuming we are OK with the % in the trailing %> ending up in comment data |
| 10:22 | <annevk42> | I don't think that matters one bit |
| 10:22 | <Lachy> | I think the question we should be asking is if Microsoft and Apple would be willing to drop support for it |
| 10:23 | <annevk42> | it's an error, but for the pages I've looked at so far not displaying <% is better |
| 10:24 | <Philip`> | http://blog.pewitt.org/CommentView,guid,56fbd9c0-6c0b-4773-abb7-dafb40fae8a7.aspx |
| 10:25 | <Philip`> | That one looks a bit like it intentionally wants to use <%...%> as a comment |
| 10:32 | <gsnedders|work> | Hixie: yt? |
| 10:37 | <jgraham> | Lachy: After discussion with gsnedders|work I will convert the author view generator to a anolis module that runs before things like the toc are generated |
| 10:41 | <gsnedders|work> | jgraham: http://74.125.77.132/search?q=cache:5iAdTkTth4EJ:krijnhoetmer.nl/irc-logs/whatwg/20090703+http://krijnhoetmer.nl/irc-logs/whatwg/20090703&hl=en&client=opera&strip=1#l-1126 |
| 10:41 | <Lachy> | jgraham, ok |
| 10:42 | <Lachy> | what's happened to krijn? |
| 10:44 | <annevk42> | he's in hiding |
| 10:47 | <svl> | The computer he logs things from isn't exactly the most stable. :/ |
| 10:48 | <annevk42> | given that nobody else seems to be willing to log, it's been pretty awesome for us :) |
| 10:48 | <annevk42> | I filed a bug on the <% crap btw |
| 11:02 | <gsnedders|work> | Wait! This means the evil cabal can say anything! |
| 11:05 | <remysharp> | Is Lachy around? |
| 11:05 | <Lachy> | remysharp, yes |
| 11:06 | <remysharp> | hi - I've got a link for you - discussion possible alternatives to the legend issue |
| 11:06 | <Lachy> | ok |
| 11:06 | <remysharp> | it's not for public consumption - I couldn't get a preview of the blog post - but here you go: |
| 11:06 | <remysharp> | http://remysharp.com/figure-legend.html |
| 11:07 | <Lachy> | Not for public consumption? By posting it here, you've made it public anyway |
| 11:07 | <remysharp> | brucel: I've added your example in too: http://www.brucelawson.co.uk/tests/html5-details-label.html |
| 11:07 | <remysharp> | sorry, not quite what I meant - as in it's a blog post |
| 11:08 | <Lachy> | ah |
| 11:08 | <remysharp> | it's not the "real" url, more that comments won't work! :) |
| 11:08 | <remysharp> | screw it I can publish it now anyway. |
| 11:10 | <Lachy> | remysharp, I'll take a look in a moment, just busy with some work stuff right now |
| 11:10 | <remysharp> | np |
| 11:11 | <remysharp> | This is the latest url anyway - with examples of alternatives to the legend in figure & details issue: http://remysharp.com/2009/08/12/saving-figure-detail/ |
| 11:16 | <Lachy> | remysharp, your claim about hgroup isn't quite correct |
| 11:16 | <gsnedders|work> | Should <iframe></iframe> fire an onload event? |
| 11:16 | <remysharp> | okay, so it *would* come up in the TOC? |
| 11:16 | <remysharp> | Lachy: enlighten me :-) |
| 11:17 | <Lachy> | basically, using <hgroup> means that all the headings inside it are grouped, such that they only the top level heading within it will appear in the TOC |
| 11:17 | <gsnedders|work> | remysharp: hgroup comes up in the TOC as the highest ranked heading within |
| 11:17 | <remysharp> | Right - so actually it's not a viable solution at all in my particular example - cheers. |
| 11:17 | <Lachy> | so, e.g. <hgroup><h2>Foo</h2><h3>Bar</h3></hgroup> should appear in the TOC as "Foo" |
| 11:17 | remysharp | updating post |
| 11:18 | <remy_> | whoops! |
| 11:19 | [remy_] | (n=remyshar⊙c3cvc): Remy Sharp |
| 11:19 | [remy_] | #jquery-ot #whatwg #jquery |
| 11:19 | [remy_] | irc.freenode.net :http://freenode.net/ |
| 11:19 | [remy_] | End of WHOIS list. |
| 11:20 | <Lachy> | remy_, I'm not a big fan of reusing <header> for this purpose. As I told brucel yesterday, it's not the right semantics. |
| 11:20 | <remy_> | Aye, he mentioned that too |
| 11:21 | <remy_> | I just want to get the alternatives up there. |
| 11:21 | <remy_> | My preference is label, but I want to see what screenreaders do when it's embedded in a form |
| 11:21 | <annevk42> | you people should just be patience |
| 11:21 | <Lachy> | yeah, it's good to have a discussion about the alternatives again to show that Hixie's stubbornness about using <legend> is not good |
| 11:21 | <annevk42> | with time <legend> will be fine |
| 11:21 | <brucel> | I think that we're open to almost any solution as legend won't fly |
| 11:21 | <remy_> | time? in that time authors won't use legend |
| 11:21 | <jgraham> | annevk42: I don't think that's a good answer |
| 11:22 | <remy_> | and there'll be a mess of solutions |
| 11:22 | <annevk42> | jgraham, I think it is |
| 11:22 | <Lachy> | annevk42, that's what Hixie said, but authors are going to push forward with whatever hacks they can to work around the problems today, and unless we come up with a real solution, the result with be a huge mess in the long run |
| 11:22 | <jgraham> | People think that they ought to be able to use it today since it is not having any effect in UAs and will become frustrated and discouraged when they find that they cannot |
| 11:22 | <remy_> | by the time all the current browsers have been weeded out it's going to be well beyond 2022!!! :) |
| 11:22 | <annevk42> | oh please |
| 11:22 | <annevk42> | stop the drama |
| 11:23 | <jgraham> | Especially given the long half life of legacy browsers |
| 11:23 | <brucel> | It will result in either no-one using the new elements (figure, details) or using header/ label anyway |
| 11:23 | <remy_> | The bottom line is that I want to give a caption to figure and details. I'll run with my own solution if the spec sticks with legend |
| 11:23 | <remy_> | and others with have their own solutions |
| 11:23 | <remy_> | and when it *is* supported properly, we *won't* use legend - |
| 11:24 | <remy_> | that particular part of the spec, is sadly, fiction. There's no point in it being there because we can't use it at all :( |
| 11:24 | <brucel> | wrt visuals, legend isn't a cowpath, it's more of a cowpat |
| 11:24 | <annevk42> | it's like complaining you cannot use <datalist> |
| 11:24 | <remy_> | not really, because we *can* use datalist |
| 11:24 | <remy_> | I've seen Dean Edwards demo using it and it works |
| 11:24 | <remy_> | it doesn't vomit all over the DOM like legend does. |
| 11:25 | <Hixie> | if we're not using <legend>, i'm dropping <figure> until we can. it's just not an important enough feature for us to worry about. |
| 11:25 | <jgraham> | annevk42: It makes a difference if, say, firefox implemets <legend> and couples it to AT in a sensible way but I can't use it because of legacy parsing issues in other browsers |
| 11:25 | <Hixie> | same with <details> |
| 11:25 | <jgraham> | So I am forced to use some other solution to get those AT hooks |
| 11:26 | <brucel> | that's daft, Hixie - they're far too useful to drop. Why would you not use label, if it proves to play nice with AT? |
| 11:26 | <jgraham> | Hixie: Totally disagree. If nothing else it is one of the cornerstones of the @summary situation |
| 11:26 | <jgraham> | s/situation/compromise/ |
| 11:27 | <jgraham> | Since they represent improved visible-data alternatives to @summary that, unlike <caption>, the a11y community seems to believe in |
| 11:27 | annevk42 | is with Hixie on this |
| 11:27 | <Hixie> | brucel: they're not so useful that we've not been able to live 19 years without them |
| 11:27 | <jgraham> | Hixie: That is a terrible argument |
| 11:27 | <Hixie> | jgraham: realistically, neither <figure> not <details> are necessary for including explanatory text about tables |
| 11:28 | <gsnedders|work> | Hixie: That's true of the whole HTML 5 spec. |
| 11:28 | <gsnedders|work> | Hixie: We can drop the whole parsing section. We've been able to live without them for 19 years. |
| 11:28 | <jgraham> | Since it applies to all x for x in html 5 where x is not in HTML 4 |
| 11:28 | <brucel> | When I ran a webteam we would have killed for figure and details |
| 11:29 | <jgraham> | Hixie: Neither are required but both are better than <caption> in certian situations |
| 11:29 | <remy_> | Aren't authors (i.e. me) going to end up using aside for figures then - that doesn't quite sit right. |
| 11:29 | <brucel> | particularly details, as we were not in a position to add jQuery/ scripts to simulate details |
| 11:29 | <Hixie> | gsnedders|work: no, e.g. <video> we haven't been able to live without (people ended up using proprietary technologies to get around it) |
| 11:29 | <Lachy> | Hixie, while we can probably live without <details> until UAs are ready to begin supporting it, which might not be a bad idea given that we don't know about potential implementation problems yet, but <figure> is really useful to avoid having to go with the more complicated aria stuff that authors won't readily use |
| 11:29 | <Hixie> | gsnedders|work: and the parsing section we've only lived without by having huge reverse-engineering efforts duplicated in all vendors |
| 11:30 | <beowulf> | wq |
| 11:30 | <gsnedders|work> | Hixie: And there's been a lot of duplicated work to make stuff appear like a legend by web authors. |
| 11:30 | <Hixie> | jgraham: i've never been convinced that either details or figure particularly help with table, to be honest |
| 11:30 | <jgraham> | Hixie: Other people have, however :) |
| 11:32 | <Hixie> | we'll just wait a bit more and see what happens with <legend> |
| 11:32 | <remy_> | Hixie: *nothing* is going to happen with <legend> |
| 11:32 | <remy_> | there may be a few new browsers that fix it |
| 11:32 | <Hixie> | that's not nothing then is it |
| 11:32 | <Lachy> | to avoid repeating the same arguments again, http://lists.w3.org/Archives/Public/public-html/2007Sep/0375.html |
| 11:32 | <brucel> | Hixie: if label plays nicely with AT, what's your aversion to using that? |
| 11:32 | <remy_> | but 100% of the browser landscape screws the render with it right now |
| 11:33 | <Hixie> | brucel: label is completely inappropriate. it does weird things with forms, it has weird APIs, etc. |
| 11:33 | <Lachy> | remy_, that email contains a nice little styling trick you might like to use |
| 11:33 | <Hixie> | remy_: and 10 years from now, it'll be near-0. |
| 11:34 | <remy_> | Hixie: you think? I don't think so. I think IE7 and 8 will still have a strong hold on the browser landscape |
| 11:34 | <gsnedders|work> | Hixie: People are using HTML 5 _today_. 10 years from now HTML 5 will be as relevant as HTML 4.01 is today. |
| 11:34 | <Lachy> | Hixie, authors don't work in the future, they have to deal with the problems now, so endlessly deferring issues until such time as they might theoretically be fixed is not a good solution |
| 11:34 | <brucel> | what kind of wierdness with forms/ APIs? Could legend doees terrible things with visuals |
| 11:35 | jgraham | is somewhat reminded of "The fact that xHTML2 won't be widely used before the end of the decade is not a problem." |
| 11:35 | <brucel> | could -> cause |
| 11:35 | <Hixie> | gsnedders|work: exactly |
| 11:36 | <gsnedders|work> | Hixie: huh? |
| 11:36 | <gsnedders|work> | Hixie: If people are using HTML 5 today, surely HTML 5 should be compatible with UAs today? |
| 11:36 | <Hixie> | Lachy: we're not "endlessly deferring", we're just waiting until browsers implement the parsing spec. it's already happening. If you want to make it happen sooner, speak to your eng team. |
| 11:37 | <remysharp> | Seriously though, there's legacy/existing browsers to deal with. The vast majority of the language of HTML 5 works right now |
| 11:37 | <Hixie> | gsnedders|work: in the soundbite world, maybe; in the real world, specs and implementations co-evolve over many years. |
| 11:37 | <Hixie> | remysharp: the vast majority of the HTML5 language doesn't work right now. |
| 11:37 | <remysharp> | this is the exception and <figure> is an element we, as authors, want to use |
| 11:38 | <gsnedders|work> | Hixie: The vast majority of HTML 5 can be made to work quite easily |
| 11:39 | <remysharp> | gsnedders|work: spot on. |
| 11:39 | <Lachy> | Hixie, the point is that <legend> fails to meet the graceful degredation principle |
| 11:39 | <Hixie> | gsnedders|work: show me an implementation of pushState(). of <audio>. of UndoManager. of <script async>. of <iframe sandbox>. |
| 11:40 | <Hixie> | remysharp: if you want to use it, the most effective thing you can do is ask browser vendors to fix their parsers. |
| 11:40 | <remysharp> | sorry, by language I'm talking about the elements (a small part of HTML 5 admittedly) |
| 11:40 | <Hixie> | just elements? or attributes also? |
| 11:40 | <remysharp> | Sure but the starting point for authors is the elements, no? |
| 11:41 | <Hixie> | i don't think there really is a meaningful concept of "starting point" that applies here |
| 11:41 | <remysharp> | speaking to other authors, that's what they're focusing on right now. I love the JS stuff, I think it's awesome, but right now, the interest is being able to use better semantics in the docs |
| 11:41 | <Hixie> | right now the interest is in being able to use what works |
| 11:41 | <remysharp> | Absolutely |
| 11:42 | <Hixie> | well that doesn't include <figure> |
| 11:42 | <Hixie> | so stop using it :-) |
| 11:42 | <remysharp> | that's right - |
| 11:42 | <remysharp> | but we're sooo close to be able to use it :) |
| 11:42 | <brucel> | only because of the insistence on legend does it not work |
| 11:42 | <jgraham> | Hixie: From the point of view of vendors changing the whole parser has a high risk since it consumes a great deal of resources and may lead to compat regressions. On the other hand the reward for vendors of being able to say "we support the <figure> element" is much smaller than being able to say "we support <video>" or whatever |
| 11:42 | <Hixie> | jgraham: why is it so much smaller? |
| 11:42 | <jgraham> | You are placing the onus in the wrong place compared to the benefits |
| 11:43 | tantekc | tends to agree with brucel and remysharp - <label> is preferable to <legend>, and both <figure> and <details> seem quite practically useful. |
| 11:43 | <jgraham> | Hixie: Because <video> is an end-user visible feature that reduces the dependence on, often unstable, plugins |
| 11:43 | <hsivonen> | I think we should consider both <label> and <legend> tainted as far as use in <figure> or <details> goes |
| 11:44 | <Hixie> | <label>'s a non-starter. |
| 11:44 | <hsivonen> | although I can't quite remember what the problem with <label> was |
| 11:44 | <jgraham> | <figure> is mainly useful for authors and AT |
| 11:44 | <remysharp> | are there any tests that show label is problematic? |
| 11:44 | <Hixie> | e.g. it would prevent you from having form controls in captions or <details>'s legend. |
| 11:44 | <gsnedders|work> | uh, what's the use-case for that? |
| 11:45 | <Lachy> | I'm not thrilled about the idea of reusing label, as discussed in that email I linked to above, but I prefer it over legend |
| 11:45 | <jgraham> | gsnedders|work: Form controls in <details> should be obvious |
| 11:45 | <remysharp> | gsnedders|work: possibly an advanced section search...maybe |
| 11:45 | <hsivonen> | the spec feedback box makes "find on page" less useful in Firefox |
| 11:45 | <Hixie> | gsnedders|work: a fill-in wysiwyg form on Flickr that allows you to type in the title of the photo and the photo credit, say. |
| 11:46 | <remysharp> | so exactly what is the issue if there's a form inside a <detail> with labels? I don't know what the browser would do /justasking |
| 11:46 | <Hixie> | anyway. the only browser that doesn't get rapid uptake is IE, and in IE you can pretty easily work around the parsing of legend. |
| 11:46 | <Hixie> | so it's not a big deal. |
| 11:46 | <tantekc> | Hixie - isn't the Flickr editable scenario actually just contentEditable? |
| 11:46 | <gsnedders|work> | remysharp: <label> would imply a closing </label> |
| 11:47 | <Hixie> | tantekc: i don't see why it would be |
| 11:47 | <Lachy> | my preferred solution is introducing a new element if we can find a suitable name (maybe <c>?), or possibly redefining <header> as remysharp suggested |
| 11:47 | <hsivonen> | remysharp: <label><input></label> makes the label become the label for for the input |
| 11:47 | <karlcow> | "When a LABEL element receives focus, it passes the focus on to its associated control." - http://www.w3.org/TR/html401/interact/forms.html#h-17.9 |
| 11:48 | <hsivonen> | Do iframe, noembed or noframes really need the <!-- ... --> escape functionality? |
| 11:48 | <remysharp> | aye, but if there's no associated input element, what happens, I thought nothing (assuming the input element isn't embedded inside the <label>)? |
| 11:48 | remysharp | just mocking a test |
| 11:48 | <hsivonen> | hmm. I imagine they might if there are "comments" in the fallback markup |
| 11:54 | <hsivonen> | whee! MediaWiki doesn't allow me to say <!-- or --> |
| 11:54 | <remysharp> | Lachy: there's something funky (as in not great) with the email you gave me: http://jsbin.com/uraco (2nd form, styles the label for input el as the caption for the <detail>) |
| 11:55 | <remysharp> | Lachy: hmm - in fact, looking at FF3.5 there's a rendering bug, if I trigger a redraw, it correctly puts the label in the table caption, but on load it doesn't work. |
| 11:58 | <hsivonen> | Did I miss any requirements: http://wiki.whatwg.org/wiki/CDATA_Escapes#Requirements ? |
| 11:59 | <Lachy> | remysharp, brucel, as a workaround, I'd recommend instead of misusing other new elements, you could just use <span class="legend"> for now, and then when legend finally is supported, it's easy to switch to <legend> |
| 11:59 | <hsivonen> | in particular, is the ability to use "</style>" in CSS string literals inside inline CSS a Web compat requirement? |
| 11:59 | <Lachy> | and since no UA actually does anything with <figure> or <legend> now anyway, you don't lose much by sticking with <span> for the short term |
| 12:00 | <remysharp> | Lachy: I guess that's my problem, if we use something like span, we'll end up either sticking with it (and not switching in years to come) or there'll be all kinds of inconsistent solutions out there - as there is now. |
| 12:01 | <Hixie> | ok i'm going to bed now |
| 12:01 | <remysharp> | If the spec remains, then yeah, I'll be using my own way to solve this, but it just feels like it's close to being right |
| 12:01 | <Hixie> | nn |
| 12:03 | <hsivonen> | Lachy: if you can stick to span now, why bother with <legend> later? |
| 12:04 | <hsivonen> | remysharp: <caption> is even more tainted than <label> and <legend> |
| 12:05 | <Lachy> | hsivonen, because the benefit of using <figure>/<legend> is that you get the prober association, which helps with accessibility. Using span will never provide that, but it's a quick and easy workaround that won't cause irreperable harm later |
| 12:05 | <remysharp> | hsivonen: oh, absolutely, it's completely screwed in the browser outside of a <table> element |
| 12:06 | <brucel> | I'm not seeing any ill-effects using label inside details ina form when I don't associate label using for="id" (because it's inside the details element so doesn't need explicitly associating) |
| 12:06 | <hsivonen> | <header> sucks, because it pairs nicely with "footer", and having it for two radically different purposes would be bad |
| 12:06 | <brucel> | Have asked some friends with screenreaders to see what happens for them |
| 12:06 | <brucel> | http://www.brucelawson.co.uk/tests/html5-details-label.html |
| 12:07 | <Lachy> | hsivonen, the point is, blatently misusing elements like <header> now is going to potentially create more problems later when UAs try to make sense out of the element in the future, beyond the normal problems created by the inevitable unintentional misuse |
| 12:08 | <hsivonen> | I'd prefer to have a completely novel element name for the purpose that the spec now uses <legend> for in <details> and <figure> |
| 12:08 | <brucel> | would like to know more about the label wierdness that Hixie alluded to |
| 12:08 | <hsivonen> | I can't think of a good English word |
| 12:08 | <jmb> | <description> ? |
| 12:08 | <remysharp> | Lachy: if that's the case, then I'd like to find out what screenreaders do with label |
| 12:08 | <jmb> | even if it is overly verbose |
| 12:08 | <hsivonen> | jmb: could work! |
| 12:08 | jgraham | could live with <description> |
| 12:08 | <remysharp> | jmb: that just feels like we're repeating <caption> <heading> <label>, etc doesn't it? |
| 12:08 | <brucel> | hsivonen, I'm agnostic about the actual element we do use - just not legend as we can;t use that now or forseeable future |
| 12:09 | <Lachy> | <desc> would be better |
| 12:09 | remysharp | agrees with brucel too though |
| 12:09 | <hsivonen> | Lachy: overlaps with SVG, we don't want more SVG overlap |
| 12:09 | <brucel> | what about longdesc?? (heh) |
| 12:09 | <jmb> | remysharp: I don't deny that |
| 12:09 | <Lachy> | oh, damn |
| 12:09 | <annevk42> | can't you guys just put your effort into getting browsers fixed? |
| 12:09 | <Lachy> | <summary> :-) |
| 12:09 | <jgraham> | annevk42: What more would you like me to do to get browsers fixed? |
| 12:09 | <annevk42> | Gecko is getting fixed, WebKit shouldn't be too hard to fix either, and I'm sure a few here can try to get Opera inline |
| 12:10 | <brucel> | sure, I'll get on the phone to Redmond straight after lunch, annevk42 |
| 12:10 | <remysharp> | annevk42: because we still have to work with existing browsers |
| 12:10 | <annevk42> | there's a workaround for IE, no? |
| 12:10 | <jgraham> | Lachy: <summary> has the wrong english meaning |
| 12:10 | <brucel> | why have workarounds when there's a chance to spec a work-straight? |
| 12:10 | <remysharp> | annevk42: IE completely shitcans the legend element |
| 12:10 | <remysharp> | annevk42: http://remysharp.com/wp-content/uploads/2009/07/ies-details-element-treatment.jpg |
| 12:11 | <Lachy> | actually, if we use <figure><summary> and <details><summary>, then we could make people happy and allow them to use it for table too in some way and finally ditch summary="" |
| 12:11 | <annevk42> | remysharp, also with createElement? |
| 12:12 | <annevk42> | oh well, I don't really care until 3 years from now :) |
| 12:12 | <remysharp> | annevk42: do you mean on the detail element? |
| 12:12 | <jgraham> | Lachy: Still has the wrong english meaning |
| 12:12 | <remysharp> | annevk42: if so, yeah, that's on there. |
| 12:13 | <Lachy> | jgraham, it's not completely inaccurate. |
| 12:13 | <hsivonen> | Lachy: worse than <description> |
| 12:14 | <hsivonen> | what about <fc> for "figure caption"? |
| 12:14 | <remysharp> | hsivonen: but then we'll have <dc>, which seems daft if it's the same thing, no? |
| 12:14 | <brucel> | while I like description, could live with summary, could live with label, c, fc and dc (for details caption), Hixie said he'll take his toys home if he can't have legend |
| 12:14 | <Lachy> | Since caption is defined as "A title, short explanation, or description accompanying an illustration or a photograph." (answers.com) and a summary is like a short explanation |
| 12:15 | <Lachy> | but <description> is acceptable |
| 12:15 | <hsivonen> | remysharp: daft, but better than <legend> |
| 12:15 | <remysharp> | hsivonen: dude, *anything* is better than <legend> right now! :) |
| 12:15 | <hsivonen> | oh, and <c> would work, too |
| 12:16 | <remysharp> | isn't <c> an attempted replacement for <caption> then? |
| 12:16 | <Lachy> | brucel, I wouldn't worry about Hixie. He can usually be convinced with reasonable arguments |
| 12:16 | <Lachy> | yes, <c> is good if we accept new single letter element names |
| 12:16 | <hsivonen> | how do I create a <dt> element it mediawiki? |
| 12:16 | <Lachy> | our previous attempts at doing so have all been replaced with longer names |
| 12:17 | <remysharp> | Lachy: that's a slippery slope isn't it? |
| 12:17 | <remysharp> | I mean, I'm all for it if we need a new element though. |
| 12:17 | <Lachy> | what slippery slope? |
| 12:17 | <brucel> | so where do we go from here wrt to <c>, description, <rubric>, etc? |
| 12:17 | <remysharp> | using single letter elements |
| 12:17 | <Lachy> | I don't see how that's a slippery slope |
| 12:18 | <remysharp> | Lachy: that's cool then :) |
| 12:18 | <Lachy> | we have <a>, <b>, <i> and they haven't caused any problems |
| 12:19 | <hsivonen> | brucel: I suggest filing a bug against the spec in the W3C Bugzilla explaining why <legend> sucks and why alternatives suck less |
| 12:19 | <brucel> | like I said, am agnostic about name of new element (if we can't reuse label/ caption for reasons I don't understand so be it: I'm all for pragmatism). But figure and details are highly useful but not if unstylable. (I know of one accessibility-focussed agency that already regularly use <hx> rather than legend because of the visual horrors that it entails) |
| 12:20 | <hsivonen> | brucel: please mention that in the bug |
| 12:21 | <Lachy> | brucel, yeah, and if you can, be specific about which organisation, as it could give a little more weight to the argument, especially if they're of any real significance |
| 12:22 | <brucel> | will ask them if they'd go "on record" (tho they're talking unstylability of html4 form legends, not html5 extended legends) |
| 12:23 | <brucel> | Is the process of filing a w3c bugzilla bug documented anywhere (as it's almost cetainly elaborate)? |
| 12:23 | <Lachy> | yeah, well, I've heard of a few people thinking that the old fashion design of fieldset/legend makes them unappealing to use |
| 12:24 | <Lachy> | brucel, yes, one sec... |
| 12:25 | <brucel> | I guess a mail to the list would be useful too - maybe accessibility-focussed readers would know more about how AT reacts to labels in figure and details |
| 12:26 | <Lachy> | brucel, http://www.w3.org/Bugs/Public/enter_bug.cgi?product=HTML%20WG&component=HTML5+spec+bugs |
| 12:26 | <Lachy> | just write a summary and comment, and then submit |
| 12:28 | <Lachy> | http://www.neowin.net/news/main/09/08/12/judge-orders-microsoft-to-stop-selling-word |
| 12:30 | <Lachy> | I wonder how much that will impact organisations in the US that depend on MS Word |
| 12:30 | <hsivonen> | Lachy: not good. (the MS patent thing) |
| 12:31 | <hsivonen> | the only silver lining is that it demonstrates the evilness of software idea patents |
| 12:32 | <brucel> | cheers Lachy. Bye y'all. |
| 12:32 | <Lachy> | yeah, but there have been plenty of patent infringment cases that demonstrate the same thing, and yet still they persist |
| 12:37 | brucel | (n=brucel⊙9212) has left #whatwg |
| 12:55 | <krijnh> | Testin' |
| 12:55 | <Philip`> | Passin' |
| 12:55 | <krijnh> | Tee hee |
| 13:02 | <Philip`> | Looks like it probably shouldn't be too unreasonable for Microsoft to change OOXML to remove the feature that infringes the patent |
| 13:03 | <Philip`> | (like, it wouldn't involve redesigning the entire file format) |
| 13:03 | <gsnedders|work> | Or moving away from XML, or anything big. |
| 13:05 | jgraham | doesn't understand the patent at all since it uses lots of words like "metacodes" that he doens't understand |
| 13:06 | <jgraham> | Although it seems to be about associating external metadata with a document, which, if I have not misunderstood, is an insane thing to have a patent on |
| 13:06 | <jmb> | jgraham: sounds like most patents |
| 13:07 | <jmb> | jgraham: i.e. completely incomprehensible |
| 13:07 | <Philip`> | jgraham: It gives some clear examples later on |
| 13:13 | <jgraham> | Philip`: Yeah I just read enough to grasp that |
| 13:13 | <jgraham> | That is incredibly silly |
| 13:13 | <jgraham> | I mean it might work but it is a really obvious idea |
| 13:20 | <Philip`> | http://philip.html5.org/misc/cdata.png |
| 13:21 | <Philip`> | Not sure it's a lot easier to read than hsivonen's text version, but maybe it is |
| 13:23 | <jgraham> | hsivonen: Do you know whether actual minifiers do escape </script>? |
| 13:25 | <hsivonen> | Philip`: thanks. linked from wiki |
| 13:25 | <hsivonen> | jgraham: I don't |
| 13:26 | <jgraham> | hsivonen: That seems important to find out |
| 13:26 | <hsivonen> | jgraham: yes |
| 13:29 | <hsivonen> | sigh. Crockford's minifier has a field of use restriction that makes it non-Free |
| 13:29 | <jgraham> | I would expect them not to since escaping adds bytes and is not needed for HTML compat |
| 13:30 | <hsivonen> | jgraham: that's a reasonable expectation |
| 13:30 | <Philip`> | www.cheapextinguishers.com/index.php?cPath=18&osCsid=ab35aa82681ce6a1c114d53f70a3f56c </title></a><script>var o=document.links[3];if(o)o.innerHTML=o.innerHTML.replace(/\n([^"]+)/g,'');</script> |
| 13:30 | <hsivonen> | more reasonable than my expectation |
| 13:31 | <hsivonen> | Philip`: ouch |
| 13:31 | <hsivonen> | I fail |
| 13:31 | <Philip`> | www.zelluloid.de/person/index.php3?id=79678 <script type="text/javascript">var szu=encodeURIComponent(location.href); var szt=encodeURIComponent(document.title).replace(/\'/g,'`'); var szjsh=(window.location.protocol == 'https:'?'https://ssl.seitzeichen.de/':'http://w3.seitzeichen.de/';); document.write(unescape("%3Cscript src='" + szjsh + "w/86/3c/widget_863ce3df0b6bac66bf9259e95ee3a1bf.js' type='text/javascript'%3E%3C/script%3E"));</scri |
| 13:32 | <Philip`> | pt> |
| 13:32 | <jgraham> | So we either need to implement the RegExpLiteral production from ECMAScript or do something different |
| 13:32 | <Philip`> | Lots of pages seem to have that pattern |
| 13:32 | <Philip`> | and if I'm counting the quotes correctly, it'll break |
| 13:37 | <hsivonen> | IS there any way to tell apart regexps and divisions without a full JS parser? |
| 13:38 | <Philip`> | <script>g=1; x=2 |
| 13:38 | <Philip`> | /3/g; |
| 13:38 | <Philip`> | /4/g; |
| 13:38 | <Philip`> | </script> |
| 13:38 | <Philip`> | Doesn't look fun |
| 13:46 | <Philip`> | Even ignoring the regexp stuff, it'll break when someone writes something like <script language=vbscript>document.write("hello world") ' comment</script> |
| 13:46 | <Philip`> | (though I don't have any examples of that in practice) |
| 13:46 | <hsivonen> | oh crap. |
| 13:46 | <Philip`> | (but it seems like a legitimate thing to write (at least to the extent VBScript is legitimate)) |
| 13:47 | <Philip`> | (If you don't like VBScript, imagine it's <script language=python>print("hello world") # that's an excellent greeting</script>) |
| 13:48 | Philip` | doesn't like the idea of making non-JS languages so fragile, even if JS could be handled perfectly |
| 13:49 | <hsivonen> | non-JS languages are extensibility and extensibility is bad :-) |
| 13:49 | <Philip`> | Extensibility is only bad when other people extend it in ways we don't like |
| 13:49 | <Philip`> | and we like Python so that's good |
| 13:49 | <jgraham> | hsivonen: I'm pretty sure you need a full parser |
| 13:50 | <Philip`> | Even just with JS, there's <script type=text/javascript;e4x=1><x><!-- this example's great --></x></script> |
| 13:51 | <hsivonen> | e4x in inline script is just looking for trouble |
| 13:51 | <jgraham> | mmmm e4x |
| 13:52 | <Philip`> | It's lucky that web authors are always so careful to stay out of trouble, then |
| 13:52 | <hsivonen> | I wish <script> had a sane parsing model to begin with... |
| 13:53 | <Philip`> | Has anyone demonstrated a practical attack based on script reparsing? |
| 13:54 | <hsivonen> | I don't know |
| 13:54 | <jgraham> | What is the theoretical attack? |
| 13:54 | <hsivonen> | the next interesting thing is whether <!-- can be made not take effect if there's non-whitespace on the line before it |
| 13:57 | jgraham | worries about minifiers again |
| 13:59 | <hsivonen> | jgraham: are there instances of <!-- in the wild where it's meant to be an escape but it's not at the start of a line? |
| 13:59 | <jgraham> | hsivonen: Dunno, ask Philip` |
| 13:59 | <Philip`> | jgraham: Server returns a page with <script>var x="$escaped_user_input"</script> (safely escaping any '"' and '</script>'), attacker inputs "<img onload=alert('oops')>......", attacker somehow causes the output to stop before it prints the </script>, their own script gets executed, I guess |
| 14:01 | <Philip`> | (Maybe their input includes U+0000 or some invalid bytes or something, so the server dies with an error message after printing half the output) |
| 14:02 | <Philip`> | Is this the theoretical attack that people are thinking of? |
| 14:03 | <hsivonen> | I guess the careful server needs to escape < as \u003C |
| 14:04 | <hsivonen> | Philip`: your attack works in WebKit: http://software.hixie.ch/utilities/js/live-dom-viewer/saved/205 |
| 14:10 | <Philip`> | hsivonen: I can't think of any easy way of searching for cases where <!-- is used for escaping |
| 14:12 | <jgraham> | Is is possible to do reparsing whilst mitigating that attack? |
| 14:12 | <jgraham> | What does gecko do? |
| 14:13 | <hsivonen> | jgraham: Philip`'s attack works is Gecko, too (with the old parser) |
| 14:13 | <Philip`> | It runs the script in hsivonen's example too |
| 14:13 | <Philip`> | (in Firefox 3.0 at least) |
| 14:14 | <jgraham> | Oh right, I forgot I was using the new parser. Oops |
| 14:23 | <hsivonen> | http://wiki.whatwg.org/wiki/CDATA_Escapes#Proposal_.232 |
| 14:23 | <hsivonen> | how about Proposal #2? |
| 14:25 | <hsivonen> | does it suck, too? |
| 14:28 | <hsivonen> | when was maxlength put back on textarea? |
| 14:28 | <annevk42> | is 2b easy to implement? |
| 14:29 | <hsivonen> | annevk42: should be easy enough |
| 14:32 | <hsivonen> | having to escape < as \u003C in inline JS pretty much defeats to point of having it parse as CDATA to begin with... |
| 14:34 | <Philip`> | You probably only really need to escape user input like that, not your own trusted code |
| 14:34 | <jgraham> | annevk42: I assume you just need a couple of extra states indicating that you are at the start of a line with only whitespace and so on |
| 14:34 | <nessy> | resolutions... |
| 14:34 | <nessy> | ups - wrong window |
| 14:45 | Philip` | continues to be unable to think of a good way to detect escaped </script>s |
| 15:22 | <hsivonen> | can someone remind me of a host-native object whose constructor is exposed on window and the constructor takes an optional argument? |
| 15:24 | <remysharp> | is there an svg version of the whatwg logo about (I found a reference on an old email but I couldn't get the attachment)? ta |
| 15:24 | <jgraham> | hsivonen: What do you mean by host-native? |
| 15:24 | <hsivonen> | remysharp: you could extract the logo from Sam Ruby's blog assuming he is OK with it |
| 15:24 | <hsivonen> | jgraham: backed by C++ |
| 15:26 | <hsivonen> | hmm. Worker |
| 15:27 | <hsivonen> | Now I'm confused |
| 15:27 | <Philip`> | Image? |
| 15:27 | <Philip`> | (Optional width and height) |
| 15:28 | <jgraham> | Aren't all arguments in js effectively optional |
| 15:28 | <jgraham> | Since they are just replaced by undefined |
| 15:28 | <hsivonen> | Image is different, because the interface name and the contructor name differ |
| 15:28 | <Philip`> | Ah |
| 15:30 | <hsivonen> | apparently Gecko's IDL doesn't support WebIDL constructors automagically |
| 15:30 | <hsivonen> | sigh. |
| 15:31 | <hsivonen> | I'm in a maze of indirection |
| 15:54 | <hsivonen> | is there some kind of convention for JS constructors to ignore extra arguments if there's a larger number of args than what spec allows? |
| 15:55 | <jgraham> | hsivonen: That happens in js in general |
| 15:55 | <hsivonen> | ok |
| 16:49 | <rubys> | Sam is OK with people using my SVG logos. |
| 16:50 | <annevk5> | that makes it sound like you're two persons :) |
| 16:51 | <rubys> | Yeah, I could have phrased that better. |
| 16:52 | <jgraham> | It would explain a lot |
| 17:54 | <beowulf> | i wonder if the net effect of publishing a spec draft with warnings will be that people are disinclined to submit feedback on the items marked controversial |
| 17:58 | <annevk5> | it's likely we'll publish that draft then? |
| 17:59 | <beowulf> | i think the poll shows without-warnings 10 ahead, and publishing one only as a majority |
| 18:02 | <Dashiva> | It's only 6 ahead, and shrinking :) |
| 18:05 | <rubys> | My only hope was that it ends up with one side being a clear winner. Looks like I'm not likely to get that. |
| 18:05 | <Dashiva> | Well, 'one draft' is a solid winner |
| 18:09 | <Philip`> | We should start a grassroots get-out-the-vote campaign |
| 18:10 | <Dashiva> | Philip`: Ask Ericsson |
| 18:11 | <Lachy> | the with warnings draft still has over 50% voting no, though it is close |
| 18:13 | <Philip`> | Manu says: "Clearly /something/ caused the WAI/PFWG to object, en masse, to the way things were being handled re: @summary in HTML5: http://lists.w3.org/Archives/Public/public-html/2009Jul/0556.html"; |
| 18:13 | <Philip`> | Maybe someone should point him to http://lists.w3.org/Archives/Public/public-html/2009Jul/0583.html - "Of course it is not from WAI" |
| 18:14 | Dashiva | goes to check up on that "microdata makes sense" email, to see if there's any response |
| 18:15 | <Philip`> | I think the only discussion on that list has been with someone who seems to not understand XML Namespaces |
| 18:16 | <Dashiva> | 0 replies, how surprising |
| 18:18 | <Lachy> | Philip`, feel free to do so. |
| 18:18 | <annevk5> | 'The "real" reason why xmlns should "not" be used' is a nice thread |
| 18:18 | <Philip`> | Lachy: No thanks |
| 18:19 | <Philip`> | I'll just mention it on IRC and maybe he'll read the logs |
| 18:20 | <Dashiva> | Philip`: Or maybe he'll accidentally skip over your line |
| 18:20 | <Philip`> | Quite possibly |
| 18:21 | <Philip`> | Anyway it doesn't seem a point worth wasting tens of man-minutes on by posting to the list |
| 18:21 | <Dashiva> | That's what www-archive is for :P |
| 18:22 | <Philip`> | It doesn't seem a point worth wasting man-minutes on by posting to www-archive |
| 18:22 | <Lachy> | yeah, that's why I'm not doing it myself. The claim about all the objections coming from WAI has been debunked several times before. Once more probably won't help |
| 18:23 | <Lachy> | just like so many other debunked claims people keep repeating |
| 18:23 | <Dashiva> | Philip`: Anyone reading www-archive has accepted waste up-front |
| 18:28 | <Lachy> | spending a few seconds deciding to ignore waste on www-archive is outweighed by the good stuff that often gets posted there |
| 18:33 | <rubys> | I've got Richard Schwerdtfeger to agree to discuss the current state of the answers to Ian's questions on ARIA on tomorrow's call, and it is my opinion that these answers will be enough to unblock Ian. Now the question is: what does it take to get Hixie to join this *one* call? |
| 18:34 | <annevk5> | why can't Richard just say it over email? |
| 18:34 | <annevk5> | will give us a clearer log of the state too... |
| 18:35 | <rubys> | why is the sky blue? |
| 18:35 | <annevk5> | I'm not a physicist |
| 18:35 | <Dashiva> | It's not just Ian who doesn't attend the calls |
| 18:36 | <Dashiva> | Don't the rest of the non-callers deserve to hear the answers too? |
| 18:36 | <rubys> | I am not a psychologist. |
| 18:36 | <rubys> | the answers will be minuted. |
| 18:37 | <annevk5> | well, that's all I had |
| 18:37 | <rubys> | I believe a dialog is necessary. And what has been going on the mailing list is not exactly a dialog. |
| 18:37 | <annevk5> | I assumed that since you were able to talk directly with Richard that much would be clear |
| 18:38 | <rubys> | I think I've been pretty clear: http://intertwingly.net/blog/2009/08/12/Mountain-Mohammed-Mohammed-Mountain-Please-Talk |
| 18:38 | <rubys> | Looks like I |
| 18:38 | <rubys> | 've pissed of Matt May. |
| 18:39 | <annevk5> | that blog entry was not clear on whether answers to ARIA LC comments would be discussed on the call |
| 18:39 | Lachy | notes that the sky is blue due to refraction of light |
| 18:39 | <annevk5> | in any case, it seems absurd that they can be discussed there, but that we cannot get a reply to our emails for another couple of months |
| 18:40 | <Dashiva> | Well, as long as PF's ASAP is as fast as it is, it doesn't seem like dialog can happen any faster than it currently is |
| 18:43 | <rubys> | FWIW, Richard and I not only work for the same company (so I can catch him via internal IM), we are in the same department. |
| 18:52 | <rubys> | In case is still isn't clear: Ian's ARIA LC comments will be discussed on tomorrow's call. |
| 19:00 | <rubys> | http://intertwingly.net/blog/2009/08/12/Mountain-Mohammed-Mohammed-Mountain-Please-Talk#c1250100182 |
| 19:06 | <othermaciej> | rubys: if the PFWG folks are willing to give a sneak preview of their answers on the phone, I can tell them to high degree of certainty if Hixie will find their answer acceptable |
| 19:06 | <rubys> | excellent. |
| 19:07 | <othermaciej> | rubys: I can also help clarify Hixie's request if needed, because based on things I've heard, I believe they may be confused between implementation requirements and authoring conformance requirements |
| 19:07 | <othermaciej> | "they" meaning the people trying to come up with an answer |
| 19:07 | <rubys> | A summary of what I understand to be the answer to the key issue: "Other than the role attribute, the host language takes precedence". |
| 19:08 | <othermaciej> | whose key issue is that? |
| 19:08 | <rubys> | based on your answer, it is clear that I don't understand Ian's issue. |
| 19:09 | <othermaciej> | Hixie's key issue is simply that he'd like to make "nonsensical" combinations of native markup and ARIA nonconforming |
| 19:09 | <othermaciej> | it's fine to let ARIA take precedence in behavior if someone actually does it |
| 19:09 | <othermaciej> | but ARIA apparently doesn't let host languages make any ARIA markup nonconforming |
| 19:10 | <othermaciej> | the idea being that if you tell ARIA that your radio button is a checkbox, you probably did something wrong |
| 19:10 | <rubys> | my understanding is that in the case on nonsensical combinations, non comforming is not only OK, it is preferred; furthermore, the host language takes precedence in everything but role. |
| 19:11 | <othermaciej> | maybe I should talk to Hixie and make sure *I* understand his issues |
| 19:12 | <othermaciej> | wait, are you stating what you think Hixie's position is, or what you think ARIA currently says? |
| 19:12 | <rubys> | even better, convince him to attend this one meeting. I'm willing to clear the calendar of other items if that is what it takes. |
| 19:12 | <rubys> | I am stating what I believe the next draft of ARIA will state. |
| 19:13 | <othermaciej> | I think convincing Hixie to attend a telecon is beyond my powers |
| 19:14 | <rubys> | See my latest comment on my latest blog post. |
| 19:15 | <rubys> | It is a damn shame when principles stand in the way of progress. |
| 19:25 | <Lachy> | rubys, am I correct in understanding that it would be inappropriate for Shelly to formatlly object to canvas being in HTML5 due to our previous vote on the issue in which the group formally decided to include it? |
| 19:25 | <Lachy> | or is it possible for such a formal objection to actually hold up progress? |
| 19:26 | <rubys> | Did you see Dan's response? (by the way Cynthia Shelly isn't talking about an objection, Shell***E***y Powers is) |
| 19:27 | <rubys> | I do believe that the course of action that Shelley described would be treated as out-of-order |
| 19:27 | <Lachy> | rubys, I know. I didn't mention Cynthia |
| 19:28 | <rubys> | no, but you misspelled shelley |
| 19:28 | <Lachy> | oh |
| 19:28 | <Lachy> | sorry. I didn't realise you'd associated my typo with Cynthia's last name |
| 19:29 | <rubys> | oh, joy, matt responded again to my post |
| 19:30 | <Lachy> | I'm not sure which response from Dan you're talking about though. He hasn't responded to this http://lists.w3.org/Archives/Public/public-html/2009Aug/0604.html (nor the one before that in that thread) |
| 19:51 | <rubys> | Lachy: I was talking about DanC's response before that point. I do believe that objecting to canvas is out of order, and I do believe that the last call date is in jeopardy -- the latter mostly because the right people aren't volunteering to help. |
| 19:52 | <rubys> | Does anybody know of a javascript implementation of the HTML5 progress element that can be used on legacy browsers? |
| 19:54 | Philip` | doesn't remember having heard of one |
| 20:00 | <annevk5> | rubys, what parts need helping with in your opinion? |
| 20:03 | <rubys> | Whatever parts won't be ready until December. :-) |
| 20:03 | <rubys> | I don't have insight into a more granular breakdown of the tasks. |
| 20:03 | <rubys> | I take it that DaveSinger and RichardS do. |
| 20:04 | <annevk5> | so given those names you think the issues are primarily with accessibility and maybe video codecs? |
| 20:05 | <annevk5> | given your statement "the latter mostly because the right people aren't volunteering to help" I was asking the above question, fwiw |
| 20:15 | <rubys> | just to make sure that we are talking about the same issue, two links: http://www.w3.org/html/wg/tracker/actions/133 and http://lists.w3.org/Archives/Public/public-html/2009Aug/0611.html and I should have said RichardS and Maciej |
| 20:58 | <othermaciej> | Lachy: I believe it would be out of order to reopen the decision, but it's not out of order to make a Formal Objection to a decision before her time |
| 20:58 | <Lachy> | I'm surprised that this wordpress exploit is even possible http://lists.grok.org.uk/pipermail/full-disclosure/2009-August/070137.html |
| 20:59 | <Lachy> | I just upgraded the whatwg blog and my own blog to the new patched version. |
| 21:13 | <othermaciej> | rubys: I don't know of a JS progress implementation, but studying the element it looks like it is probably doable with script to a rough approximation |
| 22:56 | <jgraham> | rubys: a2 |
| 22:57 | <jgraham> | er, ignore me |
| 22:57 | <jgraham> | I pressed a sequence of incorrect keys... |
| 23:25 | <SamerZ> | what wig |
