/irc-logs / w3c / #html-wg / 2007-09-26 / end

Options:

# Session Start: Wed Sep 26 00:00:00 2007
# Session Ident: #html-wg
# [00:01] * Quits: timbl_ (timbl@128.30.7.41) (Ping timeout)
# [00:21] <anne> hmm same-origin... bah
# [00:21] <Hixie> agreed
# [00:21] <Hixie> html5 has some stuff on it but it needs more
# [00:25] * Joins: mjs (mjs@17.203.14.225)
# [00:26] <anne> i don't like the dependency on HTML5 from XMLHttpRequest but I guess it's unavoidable
# [00:26] <anne> doesn't really matter I suppose
# [00:26] <Hixie> xbl2 has it too
# [00:26] <anne> prolly goes for most relevant specs :p
# [00:26] <Hixie> :-)
# [00:32] * Joins: MikeSmith (MikeSmith@mcclure.w3.org)
# [00:45] * Quits: hasather (hasather@90.227.221.48) (Quit: Lost terminal)
# [00:47] * Quits: heycam (cam@203.214.33.166) (Ping timeout)
# [00:58] * Quits: tH (Rob@87.102.114.133) (Quit: ChatZilla 0.9.78.1-rdmsoft [XULRunner 1.8.0.9/2006120508])
# [01:07] * Joins: karl (karlcow@128.30.52.30)
# [01:12] * Joins: sbuluf (up@200.49.140.162)
# [01:17] * Quits: sbuluf (up@200.49.140.162) (Ping timeout)
# [01:18] * Joins: mjs_ (mjs@17.255.111.173)
# [01:19] * Joins: heycam (cam@130.194.72.84)
# [01:20] * Quits: mjs (mjs@17.203.14.225) (Ping timeout)
# [01:20] * Joins: olivier (ot@128.30.52.30)
# [01:21] * Quits: billmason (billmason@69.30.57.156) (Connection reset by peer)
# [01:24] * Joins: sbuluf (ojeqnpe@200.49.140.198)
# [01:26] * Joins: zcorpan_ (zcorpan@83.227.34.9)
# [01:44] * Quits: zcorpan_ (zcorpan@83.227.34.9) (Ping timeout)
# [02:04] * Quits: sbuluf (ojeqnpe@200.49.140.198) (Ping timeout)
# [02:14] * Joins: timbl_ (timbl@146.115.66.146)
# [03:19] * Quits: anne (annevk@81.68.67.12) (Ping timeout)
# [03:20] * Quits: icaaq (icaaaq@85.228.55.82) (Ping timeout)
# [03:21] * Joins: DougJ (djones4@74.76.28.112)
# [03:37] * Quits: timbl_ (timbl@146.115.66.146) (Ping timeout)
# [03:40] * Quits: dbaron (dbaron@63.245.220.241) (Quit: 8403864 bytes have been tenured, next gc will be global.)
# [03:45] * Quits: karl (karlcow@128.30.52.30) (Quit: Where dwelt Ymir, or wherein did he find sustenance?)
# [03:52] * Joins: aaronlev (chatzilla@209.6.168.245)
# [03:57] * Quits: kingryan (rking3@208.66.64.47) (Quit: kingryan)
# [04:10] * Quits: jane (j@76.170.65.146) (Connection reset by peer)
# [04:12] * Quits: DougJ (djones4@74.76.28.112) (Quit: DougJ)
# [04:13] * Joins: jane (j@76.170.65.146)
# [04:27] * Quits: MikeSmith (MikeSmith@mcclure.w3.org) (Quit: Less talk, more pimp walk.)
# [04:48] * Quits: jane (j@76.170.65.146) (No route to host)
# [04:55] * Joins: jane (j@76.170.65.146)
# [05:01] * Quits: mjs_ (mjs@17.255.111.173) (Quit: mjs_)
# [05:06] * Joins: Lionheart (robin@66.57.69.65)
# [05:19] * Joins: karl (karlcow@128.30.52.30)
# [05:39] * Joins: schepers (schepers@128.30.52.30)
# [05:42] * Joins: hyatt (hyatt@209.173.92.142)
# [05:50] * Joins: aaron (chatzilla@209.6.168.245)
# [05:52] * Joins: mjs (mjs@64.81.48.145)
# [05:52] * Quits: aaronlev (chatzilla@209.6.168.245) (Ping timeout)
# [05:52] * aaron is now known as aaronlev
# [05:57] * Quits: aaronlev (chatzilla@209.6.168.245) (Ping timeout)
# [06:06] * Quits: hyatt (hyatt@209.173.92.142) (Client exited)
# [06:06] * Joins: hyatt (hyatt@209.173.92.142)
# [06:08] * Quits: schepers (schepers@128.30.52.30) (Ping timeout)
# [06:09] * Joins: schepers (schepers@128.30.52.30)
# [06:11] * Joins: MikeSmith (MikeSmith@mcclure.w3.org)
# [06:29] * Quits: MikeSmith (MikeSmith@mcclure.w3.org) (Quit: Less talk, more pimp walk.)
# [07:19] * Joins: MikeSmith (MikeSmith@mcclure.w3.org)
# [07:53] * Quits: MikeSmith (MikeSmith@mcclure.w3.org) (Quit: Less talk, more pimp walk.)
# [08:16] * Parts: hyatt (hyatt@209.173.92.142)
# [08:18] * Quits: schepers (schepers@128.30.52.30) (Client exited)
# [08:22] * Joins: anne (annevk@81.68.67.12)
# [09:06] * Joins: schepers (schepers@128.30.52.30)
# [09:12] * Quits: Lionheart (robin@66.57.69.65) (Ping timeout)
# [10:03] * Quits: heycam (cam@130.194.72.84) (Quit: bye)
# [10:25] * Joins: heycam (cam@203.214.33.166)
# [10:28] * Joins: ROBOd (robod@89.123.60.111)
# [10:48] * Joins: zcorpan_ (zcorpan@88.131.66.80)
# [11:18] * Quits: schepers (schepers@128.30.52.30) (Client exited)
# [11:19] * Quits: jmb (jmb@152.78.71.152) (Ping timeout)
# [11:19] * Quits: hsivonen (hsivonen@130.233.41.50) (Ping timeout)
# [11:19] * Joins: jmb (jmb@152.78.71.152)
# [11:19] * Joins: hsivonen (hsivonen@130.233.41.50)
# [11:19] * Quits: Hixie (ianh@129.241.93.37) (Ping timeout)
# [11:19] * Joins: Hixie (ianh@129.241.93.37)
# [11:19] * Quits: bogi (bogi@153.19.120.250) (Ping timeout)
# [11:19] * Joins: bogi (bogi@153.19.120.250)
# [11:43] * Joins: Lachy_ (chatzilla@203.214.146.132)
# [11:45] * Quits: Lachy (chatzilla@203.214.146.132) (Ping timeout)
# [11:45] * Lachy_ is now known as Lachy
# [12:12] * Joins: Steve_ (chatzilla@82.44.69.8)
# [12:20] <Steve_> lurking here too
# [12:20] <karl> :)
# [12:20] * Joins: schepers (schepers@128.30.52.30)
# [12:20] <karl> time to drop off. 7:19pm
# [12:21] * Quits: karl (karlcow@128.30.52.30) (Quit: Where dwelt Ymir, or wherein did he find sustenance?)
# [12:21] <anne> Steve_ is steven f?
# [12:21] <anne> and hi
# [12:22] <Steve_> yes
# [12:25] <anne> mjs, any idea on how to proceed with the form TF?
# [12:26] <mjs> anne: I think we need to just start
# [12:26] <mjs> anne: I can think of a couple of possibilities: (1) suggest people email their thoughts on what should be in the charter (2) kick off with a telecon (3) kick off with an IRC discussion or similar
# [12:26] <anne> at some point in time some of the forms wg and you guys agreed on a set of ideas
# [12:27] <anne> based on that hixie and hyatt then drafted <datatemplate>
# [12:27] <anne> maybe we can use that as input for the charter?
# [12:27] <mjs> I was thinking something like that list of the ideas should be the output of the task force, not the charter
# [12:27] * Quits: Lachy (chatzilla@203.214.146.132) (Quit: ChatZilla 0.9.78.1 [Firefox 2.0.0.6/2007072518])
# [12:28] <mjs> the main thing we need to decide for the charter is whether our output is a technical specification or a meta-level document that should influence design of HTML and XForms
# [12:28] <mjs> (IMO anyway)
# [12:29] <mjs> I think if the output of the task force is required to be a language specification then it is likely the task force will fail, given the low level of activity so far
# [12:29] * Joins: Lachy (chatzilla@203.214.146.132)
# [12:29] <mjs> so I think that's a nonstarter
# [12:29] <mjs> but it has been suggested before
# [12:30] <anne> it seems that that's what the Forms WG charter suggests, but the HTML WG charter suggests it should be meta-level requirements
# [12:30] <anne> on forms for the web
# [12:31] <mjs> I think that is the issue that the Forms TF charter needs to resolve (and I guess it is also traditional for charters to estimate some sort of timeline)
# [12:32] <anne> yeah, when you expect to be finished and when you finish your first doc etc.
# [12:34] <Lachy> I think you should request that the forms wg appoint a new TF member to replace the one who has failed to participate and just proceed without him
# [12:35] * anne looks at www-archive...
# [12:36] <anne> Lachy, I suppose that's possible, but that doesn't help moving forward
# [12:38] <Lachy> how doesn't it help? It gives you a way to get started instead of waiting
# [12:38] <anne> to me it's more about how to start, then whether or not we have all participants ready
# [12:39] <anne> although it might be good to inform the forms WG of the guy who's absent
# [12:40] <Lachy> I think you could start with everyone stating what they want and don't want the group to achieve in the end, and using that as a basis for the charter.
# [12:46] <Hixie> the htmlwg charter requires the task force to get "architectural consistency" between html5 and xforms _transitional_, iirc
# [12:46] <Hixie> which isn't xforms at all
# [12:46] <Hixie> and can be far easier
# [12:46] <Hixie> since there are basically no requirements on xforms transitional that prevent it from being identical to wf2 as far as i can tell
# [12:47] <anne> it's all a bit icky
# [12:48] <anne> if we make it a literal reading of the HTML charter they might get upset
# [12:48] * anne remembers John Boyer pointing out the vision document and getting all upset at some point in the past
# [12:49] <Hixie> luckily for us, the w3c's vision, that the document nominally based on it, are not binding.
# [12:55] <Lachy> the meaning of architectural consistency isn't really clear in this context.
# [13:01] <mjs> I remember that DanC and John Boyer misquoted the vision document by accidentally citing an unpublished version, but I think that was most likely an honest mistake
# [13:02] <mjs> (still, that mistake did propagate to the message kicking off the TF)
# [13:04] <anne> k, so 1) write a draft charter and 2) ask forms wg about absent participant?
# [13:05] <mjs> proposing a draft is certainly a way to get the ball rolling
# [13:07] <Hixie> i recommend letting the xforms people deal with their own reps
# [13:10] * Joins: myakura (myakura@122.26.229.211)
# [13:11] <anne> the distributed extensibility thread is amusing
# [13:16] <Hixie> it's a tough problem
# [13:17] <Hixie> i do find it amusing that microformats is touted as an example of why it's a good idea when it basically goes against the whole point of microformats
# [13:17] <mjs> in general there seems to be more genuine demand for access to specific well-known vocabularies than to custom vocabularies
# [13:18] <Hixie> what's not really clear to me is why class="" and other html extension mechanisms aren't enough
# [13:18] <mjs> (under the category of well-known vocabularies I include both microformats and XML languages like SVG or MathML)
# [13:18] <Hixie> yeah
# [13:18] <Hixie> anyway
# [13:18] <Hixie> it's on the list of things to look at
# [13:19] <Hixie> though it's not near the top
# [13:19] * Hixie will try to finish the offline stuff tomorrow
# [13:19] <Hixie> assuming i get up in time to actually have a tomorrow
# [13:39] * Quits: Steve_ (chatzilla@82.44.69.8) (Connection reset by peer)
# [13:40] * Joins: Steve_ (chatzilla@82.44.69.8)
# [14:20] * Joins: hasather (hasather@90.227.221.48)
# [14:21] * Quits: hasather (hasather@90.227.221.48) (Quit: Lost terminal)
# [14:22] * Joins: aaron (chatzilla@209.6.168.245)
# [14:22] * aaron is now known as aaronlev
# [14:22] * Quits: aaronlev (chatzilla@209.6.168.245) (Quit: ChatZilla 0.9.78.1 [Firefox 2.0.0.7/2007091417])
# [14:22] * Joins: aaronlev (chatzilla@209.6.168.245)
# [14:23] * Joins: hasather (hasather@90.227.221.48)
# [14:40] * Joins: Lionheart (robin@66.57.69.65)
# [14:47] * Quits: schepers (schepers@128.30.52.30) (Ping timeout)
# [14:50] * Joins: schepers (schepers@128.30.52.30)
# [15:20] * Quits: aaronlev (chatzilla@209.6.168.245) (Ping timeout)
# [15:22] * Quits: Lionheart (robin@66.57.69.65) (Connection reset by peer)
# [15:27] * Joins: matt (matt@128.30.52.30)
# [15:39] * Joins: aaronlev (chatzilla@66.31.86.217)
# [15:44] * Joins: tH_ (Rob@87.102.114.133)
# [15:44] * tH_ is now known as tH
# [15:49] <aaronlev> hi zcorpan_
# [15:49] <aaronlev> zcorpan_: should we set up a 3 way chat with you, myself and rich?
# [15:49] <aaronlev> the email back and forth is not that useful
# [15:51] <anne> please publicly log the discussion somehow
# [15:51] * anne would like to follow it
# [15:52] <aaronlev> anne: why don't you join it
# [15:52] <aaronlev> anne: what if we want to discuss something political that we don't want to log :P
# [15:52] <anne> I suppose that works too, depending on when and where
# [15:53] <anne> sounds corperate :p
# [15:54] <aaronlev> nah
# [15:54] <aaronlev> not exactly
# [15:54] <aaronlev> it's just the same old same old
# [15:55] <anne> ah
# [16:00] * Quits: olivier (ot@128.30.52.30) (Quit: Leaving)
# [16:33] * Joins: billmason (billmason@69.30.57.156)
# [16:33] <zcorpan_> aaronlev: hi
# [16:34] <zcorpan_> aaronlev: chatting here wfm
# [16:34] <zcorpan_> although i need to do some other things today, actually
# [16:35] <zcorpan_> i changed the spec to allow multiple roles
# [16:35] <aaronlev> zcorpan_: ok
# [16:35] <aaronlev> so is the remaining unresolved issue that rich has related to requiring the prefix in the role value?
# [16:36] <zcorpan_> i don't understand his concern actually
# [16:36] <aaronlev> that's why i think a chat would be good
# [16:36] <anne> multiple roles, what's the use case?
# [16:37] <aaronlev> anne: i don't know
# [16:37] <zcorpan_> he says that we need to go through the xhtml2 wg, which is fine by me; we can put the proposal on their table
# [16:37] <aaronlev> firefox just uses the first one
# [16:37] <anne> right, I'd assume we're going to follow that
# [16:37] <zcorpan_> aaronlev: yeah, the spec still requires UAs to ignore all but the first
# [16:37] <aaronlev> zcorpan_: fine with me too, but i don't know how long it will take to get an answer, and i'm short on time
# [16:37] <anne> I'm not sure if it makes sense to allow multiple roles if they're not going be used...
# [16:37] <aaronlev> maybe we can split it into the parts we need their approval on and part we don't
# [16:37] <anne> seems very confusing
# [16:37] <aaronlev> anne: i'm confused by it, i voted against it
# [16:39] <zcorpan_> aaronlev: we can implement the spec and propose it at the same time. it's not incompatible with the existing specs or firefox 2 in any way, really
# [16:40] <anne> I think the XHTML2 namespace should not be considered in the namespaced role= algorithm
# [16:40] <aaronlev> not requiring a prefix for role values is different from firefox 2
# [16:40] <aaronlev> for wai roles
# [16:41] <aaronlev> rich says, that would make the wai roles part of the xhtml role module roles
# [16:41] <aaronlev> and that is part of the xhtml2 wg's spec
# [16:41] <zcorpan_> right
# [16:41] <aaronlev> i mean, the own the role module
# [16:41] <anne> maybe he should view it differently
# [16:41] <aaronlev> but the role module is farther along, it's in CR I think
# [16:41] <aaronlev> whereas the wai roles are still being worked on
# [16:41] <anne> role applies to elements in the (X)HTML5 namespace and can be put in the (X)HTML5 namespace
# [16:42] <aaronlev> so i suggested it just say, that the wai roles are included in the list, and use indirection
# [16:42] <anne> seems logical that the XHTML2 can't really do much about that
# [16:42] <aaronlev> anne: the proposal say that the prefix is not needed for wai roles, even when used outside of html/xhtml
# [16:42] <anne> aaronlev, the role module is a simple WD, not even Last Call
# [16:43] <anne> see http://www.w3.org/TR/xhtml-role/
# [16:43] <aaronlev> ok
# [16:43] <aaronlev> currently that wg owns the spec which says which roles don't require a prefix
# [16:44] <anne> i'm not really sure whether that matter much, zcorpan just put up a spec that says otherwise
# [16:44] <zcorpan_> if the spec is not different from the existing specs, then there is nothing to propose... :)
# [16:44] <zcorpan_> i thought the point was to make the syntax simpler
# [16:45] <zcorpan_> which means that is has to be different
# [16:45] <aaronlev> i'm just trying to help you understand rich's concern so you can address it
# [16:46] <aaronlev> we need to ask a group that loves the extensibility of namespaces to remove the need for them
# [16:46] <aaronlev> but maybe i just don't understand who really can do what
# [16:46] <aaronlev> since there are 2 xhtml groups
# [16:46] <anne> no, we simply need to encorperate the zcorpan proposal into HTML5 or into some separate draft the HTML WG publishes...
# [16:47] <anne> there's 1 XHTML group, there's also one XHTML2 group
# [16:47] <anne> (the XHTML group also happens to do HTML (or vice versa))
# [16:47] <aaronlev> and who decides how the xhtml2 role attribute or the role module's role attribute is used?
# [16:48] <anne> does it matter?
# [16:48] <aaronlev> it might to the people who wrote the original spec
# [16:48] <aaronlev> just politics
# [16:48] <aaronlev> if it's used in xhtml/1999 i say that the html wg decides
# [16:48] <anne> for instance, XHTML2 people want to change the namespace of XHTML2 back to the XHTML namespace creating all kinds of issues
# [16:48] <anne> we're not getting really upset about that, as we simply don't implement it
# [16:49] <aaronlev> ok
# [16:49] <anne> i'd suggest a similar strategy for equivalent proposals, such as the XHTML role module...
# [16:49] <zcorpan_> i guess i can send the spec to www-archive to get a permalink to a dated version of the draft, and then send an email to the html wg and the xhtml2 wg asking for feedback. is that a good idea?
# [16:50] <aaronlev> zcorpan_: yes, better that way i think
# [16:50] <aaronlev> btw i like your proposal
# [16:50] <zcorpan_> :)
# [16:50] <aaronlev> rich has been in w3c for a long time
# [16:50] <aaronlev> he's probably just anticipating some annoying politics and trying to avoid themn
# [16:51] <zcorpan_> i can list the goals/constraints we had when writing the proposal in the email
# [16:52] <aaronlev> ok
# [16:53] <anne> fwiw, I don't like that the conformance critera for authors are totally different from the implementation requirements
# [16:54] <zcorpan_> anne: ok
# [17:00] * Joins: Rich (schwer@72.183.111.208)
# [17:00] <aaronlev> hi Rich
# [17:00] <Rich> hi
# [17:00] <aaronlev> zcorpan_ is Simon Pieters
# [17:00] <Rich> thanks
# [17:01] <zcorpan_> hi Rich
# [17:01] <Rich> Hi Simon
# [17:02] <Rich> what topic are we on?
# [17:02] <Rich> namespaces? ...
# [17:02] <zcorpan_> Rich: i've sent the proposal to www-archive; i'm about the send an email to html wg and xhtml2 wg listing the goals and constraints for the proposal and asking for feedback
# [17:02] <Rich> prefix?
# [17:02] <Rich> cool
# [17:02] <anne> http://lists.w3.org/Archives/Public/www-archive/2007Sep/att-0106/aria-proposal.html
# [17:03] <zcorpan_> Rich: you can read the log if you want (link in /topic)
# [17:03] <anne> (hi Rich, btw!)
# [17:03] <Rich> Hi anne!
# [17:03] <Rich> Nice work by Simon pulling this all together
# [17:03] <zcorpan_> thanks :)
# [17:05] <aaronlev> yeah simon, really thanks
# [17:05] <Rich> reading the latest draft now
# [17:06] <aaronlev> zcorpan_: some of my xhtml exmples on mozilla.org don't use wairole, that breaks with this spec
# [17:06] <aaronlev> "No namespace lookup of the attribute value is performed in this version of this specification."
# [17:07] <aaronlev> I don't understand why you remove that, it's only a couple of lines of code, to ensure that a non "wairole" prefix is in fact pointing to the guiroletaxonomy
# [17:07] <Philip_> ("Note: What "unordered set of space-separated tokens" means is defined in HTML5." - doesn't that need to be a normative reference, rather than a note?)
# [17:07] <zcorpan_> aaronlev: perhaps those examples could be updated?
# [17:08] <zcorpan_> aaronlev: we can add namespace lookup in a future version of the spec when it is needed
# [17:09] <Rich> The PF working group agreed to replace the aaa prefix with aria so it is aria:hidden ( per the document)
# [17:09] <Rich> missed this one before
# [17:09] <zcorpan_> Philip_: i guess, i more pretended that the spec was part of the html5 spec :)
# [17:09] <zcorpan_> Rich: the proposal allows any prefix for those
# [17:10] <aaronlev> zcorpan_: yeah i told him but the latest spec zcorpan_ can read doesn't have that afaict
# [17:10] <aaronlev> s/zcorpan_/rich
# [17:10] <aaronlev> Rich: can't we get him a recent spec to review, the one up there is old
# [17:10] <zcorpan_> i can read the Member-only draft
# [17:10] <zcorpan_> if that's what you're referring to
# [17:11] <zcorpan_> http://www.w3.org/WAI/PF/Group/adaptable/
# [17:11] <aaronlev> ok good
# [17:12] <Rich> Simon, Did you mean to have aria-hidden in xhtml? I remember that for html 4 and 5 but not xhtml
# [17:12] <aaronlev> Rich: the proposal assums xhtml and html should work basically the same
# [17:12] <aaronlev> otherwise it causes migration issues
# [17:12] <zcorpan_> what aaronlev says
# [17:12] <aaronlev> and is just extra code
# [17:13] <Rich> It is fine with me - just that aria-hidden is not in the xhtml namespace
# [17:13] <aaronlev> zcorpan_: but why not allow the namespace lookup now? like i said it's tiny code
# [17:13] <aaronlev> i mean, namespaces should work like namespaces
# [17:14] <aaronlev> when they are used they should work consistently
# [17:14] <anne> role= should not have qnames!
# [17:14] <anne> and with that remark I'm off as I've to get food :)
# [17:14] <Rich> yes - I understand the position of the html working group for html
# [17:15] <aaronlev> right, what Rich says
# [17:15] <Rich> However let me explain why they are important going forward for xhtml based markup
# [17:15] <Rich> We have a lot of work to do on SVG.
# [17:15] <Rich> We need to deal with diagrams, charts, etc. and these will be there own taxonomies
# [17:16] <Rich> what we want to avoid is having a name duplicated and having different meanings.
# [17:16] <Rich> so,
# [17:16] <Rich> we could have the following namespaces (actually these are taxonomies).
# [17:16] <Rich> flowchart:
# [17:17] <Rich> diagram:
# [17:17] <Rich> geomap:
# [17:17] <Rich> Each taxonomy will has its own roles and set of properties belonging to those roles
# [17:18] <Rich> a decision in flowchart may mean something entirely different in another taxonomy and we don't want a name collision
# [17:18] <Rich> ARIA is pretty well vetted at this point in that the roles we have are targeted at web 2.0 style applications so the risk of name collision can be minimized
# [17:19] <Rich> In terms of accessibility we, as an industry, need to spend time on markup like svg and removing the namespace capability for xhtml would be a serious hindrance going forward
# [17:20] <Rich> Also important: although these are "namespaces" they are really taxonomies. I wish we had taken this approach when we created accessibility APIs in the past
# [17:21] <Rich> We could have clearly deliniated a role and it's designated properties and we probably would have been able to avoid the bad accessibility implementations we have today
# [17:21] * Quits: myakura (myakura@122.26.229.211) (Ping timeout)
# [17:21] * Joins: myakura (myakura@122.26.229.211)
# [17:21] <Rich> using the taxonomy approach was extremely helpful to the PF workin ggroup
# [17:21] <Rich> s/workin/working/
# [17:21] <zcorpan_> Rich: any new values will be meaningless to firefox 3 and opera 9.5; regardless of whether they look up namespaces or not. the namespace lookup can be specced later when it is needed. the current draft doesn't make new values conflict
# [17:21] <Rich> I hope this clears things up. For us a namespace is much more than a namespace
# [17:22] <zcorpan_> i understand the vision, but it is not needed at this point, and the proposal is compatible to make it in that way later on
# [17:22] <Rich> Actually, that is not entirely true. If we were to take the name, say flowchart:decision, we could pass it off to the AT through the accessibility api
# [17:23] <zcorpan_> Rich: indeed, that's what the proposal says
# [17:23] <Rich> I was addressing anne's comments about allowing namespaces
# [17:24] <Rich> flowchart:decision could be passed directly to the AT through the role value in msaa as a string. It would not break your impelmentation
# [17:24] <zcorpan_> indeed
# [17:24] <Rich> ok
# [17:25] <Rich> so, back to the states topic
# [17:25] <Rich> you want to have aria-state, etc. added to the xhtml namespace ... correct?
# [17:26] <anne> nope
# [17:26] <anne> attributes are not in a namespace generally
# [17:26] <Rich> ok
# [17:26] <anne> aria-* would be in no namespace on elements in the XHTML namespace
# [17:27] <anne> (which covers both HTML and XHTML documents; XML documents are covered by aaa:* with aaa bound to some namespace)
# [17:27] <Rich> ok aaa should be aria: not aaa:
# [17:28] <anne> hmm, if you're using namespaces prefixes shouldn't matter
# [17:28] <aaronlev> Rich: for consistency with where our WD is going right?
# [17:28] <aaronlev> anne: just for consistency with the other docs, less confusing i guess
# [17:28] <anne> if prefixes matter you're not using namespaces correctly
# [17:28] <zcorpan_> Rich: it is inappropriate to fix a namespace prefix when the lookup is done by the XML processor
# [17:28] <Rich> yes, namespaces prefixes do not matter but PF decided on this standard prefix
# [17:28] <aaronlev> Rich: but it's non normative right?
# [17:29] <aaronlev> just for the docs we say "aria:"
# [17:29] <Rich> correct
# [17:29] <aaronlev> but you can use anything
# [17:29] <Rich> correct
# [17:29] <aaronlev> so you just think it's clearer
# [17:29] <Rich> yes
# [17:29] <aaronlev> a nit, as they say
# [17:29] <Rich> it is a branding thing if you will. yep a nit
# [17:29] <Rich> a nit of a nit
# [17:31] <anne> hmm, seems better to use "foo" as to not confuse people that "aria" is somehow relevant here
# [17:31] <anne> or "example"
# [17:32] <anne> (bit more than a nit ;) )
# [17:34] <Rich> well aria indicates that the states are part of the aria states and properties specification
# [17:34] <Rich> but yes it is important that the prefix is not normative
# [17:34] <aaronlev> zcorpan_: i still disagree about not processing the prefix, because processing it now means ff3 is compatible with future content if that future content makes use of extensibility and multiple role namespaces
# [17:35] <aaronlev> it's about compatibility with future content when we have that, and it doesn't cost much
# [17:36] <anne> it's still not clear to me why qnames are the right solution to this, why not solve this problem when it actually comes up?
# [17:36] <anne> it's unclear how the prefix is resolved, this doesn't work in HTML, it doesn't allow you to write scripts or CSS that are agnostic of how the qname in the attribute is written (and depend use the namespace instead)
# [17:37] <zcorpan_> aaronlev: when you find an unknown role, do you pass along the qname or the namespace,role pair?
# [17:37] <anne> there's a lot to say against qnames in content and at this point there's not much in favor
# [17:37] <Rich> what is an alternative for specifying a taxonomy for say flowcharts
# [17:37] <Rich> ?
# [17:38] <aaronlev> zcorpan_: we pass on the actual namespace role pair
# [17:38] <anne> just specifying it?
# [17:38] <zcorpan_> Rich: we could have fixed strings "flowchart:foo" without namespaces, for instance
# [17:38] <anne> similarly to how we propose to extend HTML now
# [17:38] <zcorpan_> aaronlev: ok
# [17:39] <anne> there's so far not much evidence that suggests namespacing for web formats is really necessary
# [17:39] <aaronlev> zcorpan_: what if say, yahoo or facebook want to develop their own taxonomy, then they have to go through w3c?
# [17:39] <anne> especially given that virtually all content is in html
# [17:40] <zcorpan_> aaronlev: custom prefixes could with allowed by having them start with an underscore or something
# [17:40] <Rich> Yes, they won't want to clear these through the w3c
# [17:40] <zcorpan_> cf custom properties in css
# [17:40] <anne> do we want all kinds of people to invent their own formats and expose them on the web?
# [17:40] <aaronlev> zcorpan_: now we're getting like perl, not good
# [17:40] <anne> and expect them to work in clients for some reason?
# [17:40] <aaronlev> how about `@ ?
# [17:40] <Rich> we want to at least allow for other taxonomies
# [17:40] <anne> seems like very good reasons to avoid this...
# [17:40] <zcorpan_> aaronlev: any character will do for me
# [17:40] <anne> if everyone invents their own format and sends it over the wire the web won't become more accessible
# [17:41] <aaronlev> zcorpan_: but it's so cheap to process the prefix, so i don't understand the resistance
# [17:41] <anne> you'll just get less interop than you have now
# [17:41] <anne> aaronlev, see arguments above
# [17:41] <anne> aaronlev, about qnames
# [17:41] <aaronlev> so everyone should go through w3c when they want to do something news/
# [17:41] <aaronlev> new?
# [17:42] <zcorpan_> what do you do if you want a custom attribute in html? or a custom property in css?
# [17:42] <anne> not necessarily, but I wonder how often the scenario you describe happens
# [17:43] <aaronlev> anne: i don't know, but how expensive is it to process that?
# [17:43] <anne> afaict, only AT vendors can realistically introduce new values that are meaningfull for people
# [17:43] <anne> aaronlev, adding qnames is expensive, see above for how it complicates CSS and script authoring
# [17:43] <aaronlev> anne: no, the taxonomy describes the inheritance and localization for new properties
# [17:43] <anne> which taxonomy?
# [17:43] <aaronlev> anne: you already have support for qnames in opera
# [17:43] <zcorpan_> oh?
# [17:43] <anne> qnames in content
# [17:43] <anne> I'm not talking about <foo:bar>
# [17:44] <aaronlev> ok, all i do is grab the thing before the colon
# [17:44] <aaronlev> and use an interface to find out if that prefix matches the guiroletaxonomy
# [17:44] <aaronlev> i'm sure you have a n interface to match a namespace uri with a prefix
# [17:44] <anne> I've two documents containing <x role="foo:bar"> and <x role="baz:bar">
# [17:44] <anne> foo and baz are bound to the same namespace
# [17:44] <anne> they are thus equivalent documents
# [17:45] <anne> how do I style them?
# [17:45] <Rich> people are creating all sorts of taxonomies with html today - model-based authoring tools, etc. They are all widgets created with divs, spans, styling, and script. There is no way to convey what they are
# [17:45] <anne> how do I script against them?
# [17:45] <Rich> we need a vehicle
# [17:45] <Rich> for the author to convey what they are
# [17:45] <anne> they don't even work in HTML
# [17:45] <anne> so for the coming 10 years people won't be able to extend ARIA at all
# [17:46] <anne> because namespaces just don't work
# [17:46] <anne> and they will need to resort to other hacks
# [17:46] <anne> like requiring the prefix to be a certain string
# [17:46] <Rich> exactly if we lock the role into a single name that is true
# [17:46] <anne> no
# [17:46] <anne> huh
# [17:46] <anne> I'm not sure I understand that remark
# [17:47] <anne> (also, no implementation supports multiple roles, that's just a weird artifact of the role spec afaict)
# [17:47] <Rich> asl long as the prefix resolves to a url we will be ok. but the group does not want thes in html
# [17:47] <anne> HTML doesn't have prefixes, namespaces, etc.
# [17:47] <zcorpan_> Rich: why is an url+role better than prefix+role?
# [17:47] <Rich> anne: that is not true. middleware uses multiple roles to process information
# [17:47] <anne> HTML is what's being used by authors
# [17:48] <Rich> anne: we understand this
# [17:48] <anne> if we want authors to use it we thus need to cater for HTML
# [17:48] <anne> Rich, how is role="checkbox navigation" supposed to work?
# [17:49] <Rich> anne: Ok so on the server, navigation may be used to restructure the document placing the navigation section first, last, etc. checkbox could be replaced by another role which would fit on the client. I personally would not mix navigation and checkbox in the same instance but you gave that as an example
# [17:50] <Rich> role is being used for more than accessibility
# [17:50] <anne> no, what do I implement in Opera if I encounter stuff like that?
# [17:50] <anne> it's not really about authoring or servers here, I think
# [17:50] * Quits: billmason (billmason@69.30.57.156) (Quit: .)
# [17:50] <anne> authors will eventually code against software, and it's likely they'll do silly things such as the example I gave above
# [17:51] <Rich> understand: the landmark you can use for keyboard navigation and the widget you map to the accessibility api
# [17:51] <anne> (my evidence being that 95% of the web is syntactically incorrect and prolly 99.9% is non-conforming)
# [17:51] <anne> Rich, ok role="checkbox grid"
# [17:52] <Rich> if you have 2 widgets take the first. We are directing authors to use one role as only one role is handled by ATs today
# [17:52] <anne> role="password checkbox"
# [17:52] <anne> hmm
# [17:52] <Rich> we will have this in our best practices
# [17:52] <anne> see, this already makes it more complicated
# [17:52] <anne> because now you have to check whether it's a widget or not
# [17:52] <anne> which also defeats extensibility, because you don't know whether a new value represents a widget or not...
# [17:52] <Rich> btw: I agree with not supporting multiple roles - I was shot down in the xhtml working group as there are good arguments on both sides
# [17:53] <anne> and therefore you don't know which one to pass on to AT clients
# [17:53] <Rich> I am arguing against myself :-)
# [17:53] <Rich> so, it is in for consistency and to support non-accessibility related issues
# [17:54] <anne> hmm, but I just pointed out that it doesn't work?
# [17:54] * Joins: Sander (svl@86.87.68.167)
# [17:54] <anne> I'm not sure it makes sense to specify something that has obvious flaws
# [17:54] <anne> It's fine that some WG thinks it would be theoretically pure that it can have multiple values, but if implementation experience suggests otherwise, it might be wise to revisit that
# [17:54] <Rich> if you limited role to accessibility -which will never fly in the xhtml 2 working group - then that would be true
# [17:55] <anne> as far as I'm concerned role= is for accessibility and nothing else...
# [17:55] <Rich> well the xhtml2 working role is using roles for non-accessibility solutions - take RDF/A, etc.
# [17:55] <Rich> that would be incorrect
# [17:55] <anne> all real world uses are for accessibility
# [17:55] <Rich> It would be nice if that were true
# [17:56] <Rich> I think you need to talk to the RDF/A people
# [17:56] <Rich> but thank you for endorsing our work :-)
# [17:56] * anne isn't sure he's endorsing it
# [17:57] * anne talked to the RDF/A people, but believes more in simpler stuff
# [17:58] <Rich> Unfortunately I need to go to another call folks
# [17:58] <Rich> this is a good discussion - and thank you Simon for the great work
# [17:58] * Quits: schepers (schepers@128.30.52.30) (Quit: Trillian (http://www.ceruleanstudios.com)
# [17:59] <zcorpan_> Rich: ok, cya later
# [18:00] <aaronlev> zcorpan_: presumeably role+uri is better because no central authority is required for uniqueness
# [18:01] <aaronlev> zcorpan_: using just prefixes is like file extensions
# [18:01] <anne> not really
# [18:01] <anne> file extensions don't have prefixes
# [18:01] <anne> it's not ms-doc
# [18:01] <aaronlev> iow, they are both a small string
# [18:01] <anne> it's simply doc
# [18:01] <aaronlev> the prefix is not guaranteed to be unique
# [18:01] <anne> there's quite a difference
# [18:01] <aaronlev> whereas the url is
# [18:02] <anne> not really
# [18:02] * Quits: Rich (schwer@72.183.111.208) (Quit: Rich)
# [18:02] <anne> XHTML2 for instance proposes an <input> element that's radically different from HTML5 <input> yet is in the same namespace
# [18:02] <anne> (per the latest rumors)
# [18:03] <zcorpan_> aaronlev: uniqueness could be ensured in the same way as it is in css
# [18:03] <aaronlev> anne: btw i don't like xhtml2
# [18:03] <anne> CSS for instance has been using prefixes for years and never had issues with clashes
# [18:03] <anne> one of the reasons they never had clashes is that extensions mostly come from vendors, which is exactly the same here
# [18:03] <aaronlev> anne: so you mean like -moz-user-focus
# [18:04] <zcorpan_> right
# [18:04] <anne> yeah, role=-moz-tristatecheckbox
# [18:04] <anne> or without the - at the start
# [18:04] <aaronlev> we've killed tristatecheckbox btw
# [18:04] <zcorpan_> even when there are namespaces, most likely everyone will use the same prefix to declare it (see rss 1.0, everyone uses <rdf:RDF>)
# [18:04] <aaronlev> but anyway
# [18:04] <aaronlev> -moz-slider
# [18:04] <anne> having a weird prefix like moz-, o-, at- seems good enough
# [18:04] <aaronlev> whatever
# [18:05] <anne> (that's why I used -moz-tristatecheckbox :) )
# [18:05] <aaronlev> ok. how should the vendor define what that inherits from, what properties it has, and what the localization strings are
# [18:05] <aaronlev> ok
# [18:05] <anne> i'm not really familiar with "inherits from"
# [18:06] <anne> properties seems like simply passing the aria-* attributes to the AT client?
# [18:06] * Quits: Steve_ (chatzilla@82.44.69.8) (Quit: ChatZilla 0.9.78.1 [Firefox 2.0.0.7/2007091417])
# [18:06] <aaronlev> right, but what's the localization for the priperty, in case it changes
# [18:06] <anne> maybe the UA should have an API for all that stuff so AT clients can implement that themselves
# [18:06] <aaronlev> take for example aol-buddylist
# [18:06] <anne> seems easier
# [18:07] <aaronlev> role="aol-buddylist"
# [18:07] <aaronlev> and role="aol-buddy"
# [18:07] <aaronlev> they inherit from listbox and oiption
# [18:07] <aaronlev> or tree or something
# [18:07] <aaronlev> aol-buddy has some new properties, like away, which is a boolean
# [18:07] <aaronlev> and idle, which is a time string
# [18:07] <anne> I think the AT should have that knowledge
# [18:07] <anne> it will support the control after all...
# [18:07] <aaronlev> anne: you can't do that, small at vendors cannot keep up
# [18:08] <anne> if there's no support for a widget there's no point in using it
# [18:08] <aaronlev> when a user goes away and the property changes, we'll fire an event
# [18:08] <aaronlev> the boolean changes
# [18:08] <anne> (how is that handled by the other proposal btw?!)
# [18:09] <aaronlev> anne: it's not fleshed out completely, but basically the xmlns:aolwidgets would point to a URI
# [18:09] <aaronlev> role="aol:buddy"
# [18:09] <anne> oh help
# [18:09] <aaronlev> becomes something like "http://www.aol.com/widgets#buddy"
# [18:09] <aaronlev> which says buddy is really a list item
# [18:09] <aaronlev> so you're not wrong if you treat it as a list item
# [18:10] <aaronlev> anne: i'm actually in favor of xbl btw
# [18:10] <anne> seems like there's not much advantage in using buddy then...
# [18:10] <aaronlev> so don't hate me for explaing this
# [18:10] <anne> no
# [18:10] <anne> i won't
# [18:10] <aaronlev> anne: if either 1) an AT want to put in special code to deal with buddy in a future version they can
# [18:10] <anne> it just seems a really painfull solution
# [18:10] <anne> for no real problem
# [18:10] <aaronlev> and 2) they can read the localizations definied for the role and properties and changes
# [18:10] <zcorpan_> the url is just an opaque string; there's no reason the same processing model can't be applied to the prefix directly
# [18:10] <anne> you'd expect all those browsers to hit that namespace URI all the time?
# [18:11] <aaronlev> anne: i'd cache the info
# [18:11] <aaronlev> zcorpan_: how do i map the prefix to a URL?
# [18:11] <aaronlev> to fetch the definition?
# [18:11] <zcorpan_> aaronlev: you don't, you just use the prefix
# [18:12] <zcorpan_> aaronlev: oh? what do you do with the definition?
# [18:12] <zcorpan_> aaronlev: following the URI for namespaces is not how namespaces in xml work
# [18:12] * anne thinks this particular solution is _way_ too overengineered
# [18:12] <aaronlev> zcorpan_: you fetch the inheritance, the properties and the localization for the role and properties, as well as any special rules for calculating the name
# [18:12] <anne> why all these theoretical issues about extensibility and inheritence etc.?
# [18:13] <aaronlev> inheritancenot theoretical, for example xbl uses it
# [18:13] <anne> well yes, but XBL is not a stopgap solution
# [18:13] <aaronlev> i agree it's too complicated, and that xbl would be great
# [18:13] <aaronlev> but xbl isn't going to happen, i don't believe
# [18:13] <aaronlev> there's no market pressure to make it happen
# [18:14] <aaronlev> it needs to be everywhere to succeed
# [18:14] <aaronlev> in all browsers
# [18:14] <anne> dunno, fetching URIs and invoking an RDF parser...
# [18:14] <aaronlev> i didn't say i liked that, the pf is open to other ideas, so i'm asking for yours
# [18:14] <anne> i'm saying you don't need it
# [18:14] <aaronlev> the problem is that content is always genrations ahead of where AT tools exist, and being to define how to treat new kinds of objects is a very good idea
# [18:15] <anne> i'm saying their won't be many successful extensions unless AT vendors push hard for it
# [18:15] <anne> extensions would come from AT vendors, not the other way around
# [18:15] <aaronlev> i don't know
# [18:15] <anne> increasing pageload on pages seems not something that's really acceptable
# [18:15] <aaronlev> honestly i think xbl is the only technically good solution
# [18:15] <aaronlev> but that it won't happen
# [18:15] <aaronlev> so i feel we're stuck on this one
# [18:16] <zcorpan_> we could be implementing xbl instead of doing this ;)
# [18:16] * zcorpan_ hides
# [18:16] * anne expects it will be implemented in due course
# [18:16] <anne> just not by me
# [18:16] <aaronlev> in opera, yeah
# [18:17] <aaronlev> look, i told everyone this was overengineered and too complicated
# [18:18] <aaronlev> but i do like the idea of being able to describe inheritance and semantics of a widget
# [18:18] <aaronlev> e.g. when this property changes, do this
# [18:18] <aaronlev> because at vendors are tiny and can't keep up with the web
# [18:18] <aaronlev> and the problem will only get worse
# [18:19] <aaronlev> i don't think you can say that a predefined set of roles and states has served a11y very well up until now
# [18:19] <anne> why would new roles be used that don't work in ATs but do work after additional pageloads?
# [18:19] <anne> that seems silly
# [18:19] <aaronlev> why would additional page loads be required?
# [18:19] <anne> to fetch info about the roles that are not supported
# [18:20] <aaronlev> if a11y is active the accessible page load finished event would wait until the info is feteched
# [18:20] <anne> it seems better for me as an author to simply use the one that is supported
# [18:20] <aaronlev> sometimes the shoehorning works, sometimes it is too much of a stetech
# [18:20] <aaronlev> rich and i have been doing a11y for about 20 years each
# [18:21] <aaronlev> it's always been a problem
# [18:21] <aaronlev> to limit developers to shoehorning in these situations
# [18:21] <anne> yes, interop too
# [18:21] <aaronlev> looking ahead something better should be invented
# [18:21] <anne> for the 5 years I've been involved (if it's not a year more or so)
# [18:21] <aaronlev> and defining a taxonomy is logical
# [18:21] <anne> long term this is not going to work
# [18:21] <anne> i think
# [18:22] <aaronlev> why, inheritance and taxonomies are used all over the place in computing
# [18:22] <anne> just like longdesc, alt, headers, etc. don't work
# [18:22] <aaronlev> it's not magic
# [18:22] <anne> afterthought accessibility has mostly failed, betting on it doesn't seem smart
# [18:22] <aaronlev> anne: i didn't disagree that it was too complicated
# [18:22] <aaronlev> i disagreed that some solution is not needed
# [18:23] <aaronlev> and that shoehorning was the best way
# [18:23] <aaronlev> i think other ideas should be considered
# [18:23] <aaronlev> and we should try to advance things
# [18:23] <anne> i think the simple idea should be tried out first
# [18:23] <aaronlev> we are
# [18:23] <anne> and then we can revisit the whole thing in a year or so after we've examined some actual content that works in Opera / Firefox
# [18:23] <aaronlev> we are starting simple
# [18:24] <aaronlev> all i suggested was that a few lines of code are worth it for checking a non "wairole:" prefix to see if it's for one of the standard WAI roles
# [18:25] <aaronlev> so that we can have forward compat with future content
# [18:25] <aaronlev> if we go that way
# [18:25] <anne> all I pointed out was a lot of problems with qnames in content
# [18:25] <anne> which were not addressed
# [18:26] <aaronlev> anne: so you think they will go away completely?
# [18:26] <anne> I'm not sure what you mean
# [18:26] <zcorpan_> aaronlev: future content can use the "wairole:" prefix, and unknown values will be ignored either way. so we won't really be more future proff by looking up namespaces
# [18:27] <aaronlev> zcorpan_: it just seemed weird to me to half support an xml feature in xhtml
# [18:27] <aaronlev> it's there and cheap to impl
# [18:27] <aaronlev> anyway we've talked about it too much
# [18:27] <zcorpan_> aaronlev: it's not an xml feature, actually
# [18:27] <anne> qnames in content are a made up feature
# [18:28] <aaronlev> zcorpan_: would you consider putting a not in there saying it's not checked, and may be in the future if needed
# [18:28] <anne> and not really defined either in terms of dynamic changes to content etc.
# [18:28] * Quits: myakura (myakura@122.26.229.211) (Quit: Leaving...)
# [18:28] <zcorpan_> anne: isn't there such a note already?
# [18:28] <anne> but that's besides the points I raised earlier, as these are addressable
# [18:28] <anne> zcorpan_, does it deal with inserting xmlns attributes and such?
# [18:29] <zcorpan_> anne: i don't understand the q
# [18:29] <anne> <role="x:x"> with some xmlns:x declared
# [18:29] <anne> I can remove that xmlns:x
# [18:29] <anne> I can put a new xmlns:x closer to the role attribute with another value
# [18:29] <anne> I can change the value of xmlns:x
# [18:29] <anne> etc.
# [18:30] <zcorpan_> authors are required to declare prefixes
# [18:30] <anne> that doesn't solve any implementation issue mentioned above :)
# [18:30] <zcorpan_> indeed
# [18:30] <anne> (anyway, the real problems are with writing agnostic CSS and DOM script)
# [18:31] <anne> (for eqvuivalent documents that happen to use different prefixes)
# [18:31] <zcorpan_> right. the practical solution to that (for authors) is to treat prefixes as fixed and ignore the namespaces
# [18:31] <aaronlev> zcorpan_: i see the note, i think that's new,thanks
# [18:32] <zcorpan_> aaronlev: ok
# [18:32] <aaronlev> zcorpan_: where did you post it?
# [18:32] <zcorpan_> aaronlev: to www-archive
# [18:32] <zcorpan_> i will send an email to public-html and public-xhtml2
# [18:33] <anne> zcorpan_, the actual solution is not to introduce something as horrid as qnames into HTML
# [18:33] <anne> "qnames in content"
# [18:33] <zcorpan_> anne: agree
# [18:33] <aaronlev> zcorpan_: xtech?
# [18:33] <zcorpan_> aaronlev: ?
# [18:33] <aaronlev> zcorpan_: wai-xtech, it's the mailing list where people discuss aria
# [18:34] <anne> hmm, what about http://lists.w3.org/Archives/Public/public-pfwg-comments/2007JulSep/0000.html btw?
# [18:34] <anne> seems that the PFWG ignores comments
# [18:34] <zcorpan_> aaronlev: i can cc wai-xtech if you want
# [18:35] <aaronlev> thanks
# [18:35] <aaronlev> yes
# [18:36] * Quits: Shunsuke (Shunsuke@123.176.107.50) (Ping timeout)
# [18:37] * Joins: schepers (schepers@128.30.52.30)
# [18:39] <zcorpan_> wai-xtech is the PFWG, right?
# [18:39] <aaronlev> right, i can get you info for it, 1 sec
# [18:39] <aaronlev> http://lists.w3.org/Archives/Public/wai-xtech/
# [18:40] <aaronlev> http://www.w3.org/WAI/PF/participation.html
# [18:40] <zcorpan_> thanks
# [18:42] <aaronlev> zcorpan_: still missing an abstract
# [18:43] <zcorpan_> http://tinyurl.com/23ur7s
# [18:43] <zcorpan_> aaronlev: yeah
# [18:43] <aaronlev> how about "Details of proper usage of ARIA markup for authors and ARIA markup processing for user agents"
# [18:45] <aaronlev> "There should be as few different ways as possible to use role/ARIA."
# [18:45] <aaronlev> Maybe, The number of different possible ways to use ARIA should be minimized, and include only variations that are necessary
# [18:45] <aaronlev> emphasizing that we are simplifying not restricting unnecessarily
# [18:46] <zcorpan_> yep, sounds better
# [18:46] <zcorpan_> added an abstract
# [18:47] <aaronlev> I would remove " The proposal should not be unnecesarily incompatible with the existing specs." unless you want to defend against people who read every single letter like it's the law
# [18:47] <aaronlev> because there are some practical things we did that people might argue needlessly about
# [18:47] <zcorpan_> ok, removed
# [18:48] <aaronlev> zcorpan_: the proposal you point to there doesn't have the abstract but the old URL does
# [18:48] <zcorpan_> aaronlev: right, the point of sending it to www-archive was to get a dated version of the draft :)
# [18:49] <zcorpan_> i can also point to the simon.html5.org version in the email
# [18:49] <aaronlev> zcorpan_: yeah so if you update it based on comments new people comment on that
# [18:49] <aaronlev> can you remind me why we don't allow xhtml2:role in svg?
# [18:50] <aaronlev> but we allow xhtml:role?
# [18:50] <aaronlev> i guess that's fine
# [18:50] <zcorpan_> because "The number of different possible ways to use ARIA should be minimized, and include only variations that are necessary" :)
# [18:50] <aaronlev> yeah
# [18:50] <aaronlev> should we note that specifically?
# [18:51] <aaronlev> well, i'm ok with how it is
# [18:51] <zcorpan_> xhtml2:role is just something that was implemented and is not defined anywhere
# [18:51] <aaronlev> we'll see what people say anyway
# [18:51] <aaronlev> alright, ship it :)
# [18:51] <zcorpan_> ok
# [18:52] <aaronlev> oops, one thing
# [18:52] <aaronlev> you say for html that people can't say <role="wairole:checkbox">
# [18:52] <aaronlev> i still allow that "wairole:" as a predefined prefix
# [18:52] <aaronlev> i thought you wanted html and xhtml to work the same way as much as possible
# [18:53] <zcorpan_> aaronlev: that's just authoring conformance reqs
# [18:53] <zcorpan_> aaronlev: doesn't affect UAs
# [18:53] <aaronlev> ah
# [18:53] <aaronlev> true
# [18:53] <aaronlev> i think a couple of headings showing where the authoring conformance section is
# [18:54] <aaronlev> vs. the user agent processing section
# [18:54] <aaronlev> would make it clearer
# [18:54] <zcorpan_> ok
# [18:57] <zcorpan_> email sent
# [18:59] <zcorpan_> added headings
# [19:05] * Quits: mjs (mjs@64.81.48.145) (Quit: mjs)
# [19:06] <aaronlev> zcorpan_: maybe the title of the doc should be "Proposal: proper usage and processing of ARIA markup"
# [19:06] <aaronlev> because ARIA Proposal is too generic
# [19:07] <aaronlev> anyway, that's a nit, great work
# [19:11] <zcorpan_> that sounds more like an abstract than a title... :)
# [19:11] <zcorpan_> it should be convenient to refer to the thing using the title, imho
# [19:13] * Joins: Lionheart (robin@66.57.69.65)
# [19:14] <anne> yeah
# [19:14] <anne> at some point it will hopefully define all relevant aspects, too
# [19:14] <anne> not just the string details it handles now
# [19:14] <zcorpan_> right
# [19:20] * Parts: Lionheart (robin@66.57.69.65)
# [19:20] * Joins: Roger (roger@213.64.74.230)
# [19:24] * Joins: Shunsuke (Shunsuke@123.176.107.50)
# [19:45] * Quits: Lachy (chatzilla@203.214.146.132) (Ping timeout)
# [19:46] * Joins: Lachy (chatzilla@124.171.0.33)
# [19:59] * Joins: hyatt (hyatt@209.173.92.142)
# [20:02] * Quits: matt (matt@128.30.52.30) (Quit: matt)
# [20:04] * Joins: mjs (mjs@17.255.111.173)
# [20:17] * Joins: matt (matt@128.30.52.30)
# [20:24] * Joins: kingryan (rking3@208.66.64.47)
# [20:35] * Quits: aaronlev (chatzilla@66.31.86.217) (Ping timeout)
# [20:44] * Joins: MikeSmith (MikeSmith@mcclure.w3.org)
# [20:48] * Quits: MikeSmith (MikeSmith@mcclure.w3.org) (Quit: Less talk, more pimp walk.)
# [21:09] * Quits: zcorpan_ (zcorpan@88.131.66.80) (Ping timeout)
# [21:33] * Quits: hyatt (hyatt@209.173.92.142) (Quit: hyatt)
# [21:35] * Quits: Roger (roger@213.64.74.230) (Quit: Roger)
# [21:40] * Joins: hyatt (hyatt@209.173.92.142)
# [21:40] * Quits: hyatt (hyatt@209.173.92.142) (Client exited)
# [21:41] * Joins: hyatt (hyatt@209.173.92.142)
# [21:47] * Quits: matt (matt@128.30.52.30) (Quit: matt)
# [22:19] <anne> Hixie, this offline stuff integrates with the HTML parser, what about XML?
# [22:20] <anne> (I suppose this is something you considered yourself as well, I'm just curious.)
# [22:22] <anne> maybe it matters less in XML...
# [22:25] <Hixie> it doesn't integrate well with xml
# [22:25] <Hixie> in particular PIs screw up
# [22:25] <Hixie> but see the navigation section for my current attempt
# [22:28] <anne> in "Page load processing model for XML files" it mentions "Step 10" which points to Step 11...
# [22:28] <anne> oh, "step 10" (lowercase s)
# [22:35] * Quits: ROBOd (robod@89.123.60.111) (Quit: http://www.robodesign.ro )
# [22:59] <DanC> mjs, are you done with your editing pass over the design principles? hmm... no mjs... anne, do you know if he's done?
# [22:59] <mjs> DanC: no - it got slightly delayed by work distractions but I'll have time to make more progress this evening
# [23:00] <mjs> DanC: at some point I'd suggest to ship it instead of waiting more
# [23:01] <DanC> oh... you're here after all. (I'll learn to use this IRC client one day...)
# [23:01] <DanC> I'm ready to (propose to) ship when you are.
# [23:10] * Quits: gavin (gavin@63.245.208.169) (Ping timeout)
# [23:13] * Joins: gavin (gavin@63.245.208.169)
# [23:26] * Quits: hyatt (hyatt@209.173.92.142) (Quit: hyatt)
# [23:31] <anne> whoa, http://html4all.org/pipermail/list_html4all.org/2007-September/000428.html ...
# [23:34] <Dashiva> I second that ellipsis
# [23:35] * Quits: mjs (mjs@17.255.111.173) (Quit: mjs)
# [23:39] <kingryan> since the HTML WG is so openly hostile, he's decided to become more hostile and more open about his hostility?
# [23:40] <anne> i've no idea
# [23:41] <anne> i wonder what Opera did wrong
# [23:42] <anne> or the other browser vendors for that matter
# [23:42] <hsivonen> hmm. just about every jibe about html4all on IRC has been based on the irony of "IRC cabal" and actually having a secret mailing list
# [23:43] <anne> yeah, nothing is really based on any technical issues afaict
# [23:44] <anne> they can call us the "IRC cabal" but laughing about their private mailing list is not allowed... oh well, don't think it's my problem
# [23:44] <Philip_> There have been occasions where I thought it'd be good to comment on technical issues they've mentioned on their list, but it's hard to do that when you can't post to it
# [23:45] <hsivonen> Philip_: I subscribed successfully and am allowed to post
# [23:45] <Philip_> hsivonen: Oh, I hadn't realised they'd changed it now
# [23:46] * Philip_ is now known as Philip
# [23:48] <Dashiva> anne: I think the formal complaint over a few jokes in #whatwg set the bar pretty high already
# [23:51] <Hixie> i wonder which "closed small group" he's referring to
# [23:51] <anne> follow-up from DanC: http://html4all.org/pipermail/list_html4all.org/2007-September/000429.html
# [23:52] <anne> Hixie, I'd suspect the people chatting in #whatwg mostly
# [23:52] <Hixie> clearly not the whatwg (800+ people and open), nor the #whatwg (the pinacle of openness, with self-hosted archives)
# [23:52] <Hixie> unless he has a new definition of "closed" that i am not aware of
# [23:52] <Philip> It can be socially closed even if it's technically open
# [23:53] <anne> (which was forwarded, not sure where DanC e-mailed it initially...)
# [23:53] <Dashiva> Philip: Can't be any more closed than a private mailing list
# [23:54] <kingryan> anne: it seems that followup is bound to be misinterpretted
# [23:55] <kingryan> it seems that DanC just wants *more* editors, not to replace the existing ones
# [23:55] <Hixie> Philip: i haven't seen any sign that we are socially closed either, i mean, we actively invited Steven F to the IRC channel yesterday and spoke with him, I didn't see anyone being hostile there.
# [23:57] <Hixie> anyway, as far as i can tell this is just john playing us
# [23:57] <beowulf> when did html4all appear?
# [23:57] <Hixie> he did publically say that he would engage in a mission of divide and conquer
# [23:57] <Hixie> beowulf: early august
# [23:59] <hsivonen> though it didn't become known until late August. I found out only when I returned from Romania at the start of September
# Session Close: Thu Sep 27 00:00:00 2007

The end :)