From rob at robburns.com Thu Jun 5 04:28:50 2008 From: rob at robburns.com (Robert J Burns) Date: Thu, 5 Jun 2008 13:28:50 +0200 Subject: [html4all] closed issue-tracker issues Message-ID: Does anyone following the teleconferences closely know why these two issues have been closed: ? no summary attribute for tables[1] ? distributed extensibility (i.e., namespaces)[2] I saw these in the issue-tracker system when I was preparing the latest list of issues, but I didn't realize they were 'closed' status. Take care, Rob [1]: [2]: From laura.lee.carlson at gmail.com Thu Jun 5 06:09:29 2008 From: laura.lee.carlson at gmail.com (Laura Carlson) Date: Thu, 5 Jun 2008 08:09:29 -0500 Subject: [html4all] closed issue-tracker issues In-Reply-To: References: Message-ID: <1c8dbcaa0806050609p4a6db89dnc16bc627ddfe0079@mail.gmail.com> Hi Rob, > ? no summary attribute for tables Some References: http://lists.w3.org/Archives/Public/public-html/2008Feb/0122.html http://lists.w3.org/Archives/Public/public-html/2008Mar/0215.html http://lists.w3.org/Archives/Public/www-archive/2008Apr/0002.html http://lists.w3.org/Archives/Public/www-archive/2008Apr/0004.html Best Regards, Laura -- Laura L. Carlson From rob at robburns.com Thu Jun 5 07:17:42 2008 From: rob at robburns.com (Robert J Burns) Date: Thu, 5 Jun 2008 16:17:42 +0200 Subject: [html4all] closed issue-tracker issues In-Reply-To: <1c8dbcaa0806050609p4a6db89dnc16bc627ddfe0079@mail.gmail.com> References: <1c8dbcaa0806050609p4a6db89dnc16bc627ddfe0079@mail.gmail.com> Message-ID: Hi Laura, On Jun 5, 2008, at 3:09 PM, Laura Carlson wrote: > Hi Rob, > >> ? no summary attribute for tables > > Some References: > > http://lists.w3.org/Archives/Public/public-html/2008Feb/0122.html > http://lists.w3.org/Archives/Public/public-html/2008Mar/0215.html > http://lists.w3.org/Archives/Public/www-archive/2008Apr/0002.html > http://lists.w3.org/Archives/Public/www-archive/2008Apr/0004.html Wow, so just like alt it was closed inappropriately. Reading through Ian?s message on this, it is a clear example of what I'm talking about with Ian. The need for a summary attribute is clear to anyone who takes the time to investigate the issue. If Ian doesn't understand it, he should try engaging in discussions with those of us who do understand it. I'm sure that after a few back and for email exchanges, Ian will start to get it. However, Ian is so afraid of saying I don't understand something meaning there's something to be understood that he doesn't understand). Instead he simply says I don't understand something meaning there's nothing to that something. It would only be embarrassing to watch if he also wasn't placed in a position of authority where he's enabled to undermine the accessibility of web content and daily life for the users who need these facilities. Take care, Rob From rob at robburns.com Fri Jun 6 04:12:58 2008 From: rob at robburns.com (Robert J Burns) Date: Fri, 6 Jun 2008 13:12:58 +0200 Subject: [html4all] Issue-tracker Issues and XHTML2 Message-ID: Hi Gregory, I've been working on cleaning up the wiki pages for the issues you added to the issue tracker for me (and the others I still have in the queue). It occurred to me that many of these issues could be applied to XHTML2 as well. I have others not yet on the wiki that only apply to HTML5 (on parsing for instance), but these ones already on the wiki certainly relate to XHTML2 also. I've included the original list at the end of this email. A few of them might involve too much implementation detail that, in contrast to XHTML2, HTML5 welcomes (e.g., DOM specifications and client-side redirects). But all in all I think they might be of interest to the XHTML2 WG too. Its also likely that some of these issues would belong in their own separate WGs if it wasn't for the HTML5 monolithic approach to standards specification. In any event, if you want to pass on these issues to that WG for review, I'd love to hear feedback from a more scholarly WG. Take care, Rob Below are the proposed issue-tracker Issues (with endnotes referencing the relevant wiki page): ? Add a document authoring requirement to designate role for embedded content. To ease the burden on authoring tools and authors, and to provide further information for UAs and users unable to consume non- text media provide an attribute and HTML specified attribute NCNames for designating the role of non-text media.[1] ? For Q (quotation) and BLOCKQUOTE a 'marks' content markup attribute. Permits authors greater control over the separation of concerns of styling quotations and specifying the semantics of quotations within a document. Also allows authors to work around the current state of interoperability across popular UAs.[2] ? Enhanced client-side Image Maps. Provide more complete specification of client-side image maps to improve accessibility and general usability and also entirely eliminate the need for server-side image map processing.[3] ? Markup support for bookmark and clipping support of documents. Provides a way to markup specific points within a document or contiguous sections of a document that may not be hierarchically well- formed (such as the pages of an archival document that may contain portions of a paragraph).[4] ? Pronunciation attributes for abbreviations, variables, proper nouns and terms. Adds phonetic and related pronunciation attributes for DFN, ABBR, VAR and proper names. Adds a phonetic attribute to several elements as well as type and expressedas attributes to the ABBR element.[5] ? Cross-referencing and subtext. To provide semantic features in HTML5 supporting proposed styling features in CSS3 and because authors have an independent need to markup notes and cross references regardless of presentation.[6] ? Markup improvements and UA norms to associate attributions, citations, quotations and references. Adds some attributes for pages, annotations and ordered and unordered reference lists and UA norms to retrieve and display attribution, citation and quotation, references to users (including auto-generation of source reference lists)[7] ? Definitions and Abbreviations cross-referencing. Provide a more complete and compact markup syntax for associating definitions, terms, variables, proper names and abbreviated forms. Also promote greater user enhancements within UA implementations for such semantics by automatically generating document subject and name indexes, glossaries and interactive UI for these semantics.[8] ? Support for eliminating authoring distinctions between block and non- block semantics (particularly within the HTML5 DOM and XML serialization, but perhaps also in text/html serialization) Proposal would allow authors to use only Q element and not need to worry about Q and BLOCKQUOTE distinctions (also could apply to CODE and BLOCKCODE if HTML5 adopted these semantics).[9] ? Add a new IDENT data type for the id attribute and clearly specify the CSS selector and DOM method processing for xml:id of type ID and id of type IDENT (helps facilitate compound documents and current authoring practice).[10] ? CSS and DOM support and new UA norms for associating data cells and header cells in tables.[11] ? Meta and HTTP redirect UA norm to improve accessibility and general usability.[12] ? Add MediaElement, VIDEO and AUDIO related features to the OBJECT element.[13] ? UAs should provide rich UI to access document data (title, href, cite, longdesc, aria-describedby, alt, ).[14] ? Support for a new cascading keyboard key binding mechanism.[15] ? Menu commands in the menu bar providing author access for arranging ordered menu bar menus (for better web application support).[16] ? Mechanism for expressing the semantics of styling (e.g., "[red letters] indicate [the words of Jesus]").[17] ? New attributes for handling and downloading linked and embedded resources.[18] ? ALT element or alternate list and other new mechanisms for delivering alternate content to users (in addition to content negotiation and rel='alternate' on the LINK and A elements).[19] ? UA language content-negotiation norms (presenting users with choices for multilingual users and whenever appropriate).[20] ? UA norm for DOM API to return the element containing the script and a re-implementation of document.write using this method.[21] ? UA norm to expose the metadata properties of non-text media.[22] Links: [1]: [2]: [3]: [4]: [5]: [6]: [7]: [8]: [9]: [10]: [11]: [12]: [13]: [14]: [15]: [16]: [17]: [18]: [19]: [20]: [21]: [22]: From rob at robburns.com Fri Jun 6 04:14:52 2008 From: rob at robburns.com (Robert J Burns) Date: Fri, 6 Jun 2008 13:14:52 +0200 Subject: [html4all] Issue-tracker Issues and XHTML2 Message-ID: <704CE078-2B6F-424C-B1E2-9A372D6159B0@robburns.com> Sorry that last message was meant to go only to Gregory. From rob at robburns.com Sat Jun 7 03:37:50 2008 From: rob at robburns.com (Robert J Burns) Date: Sat, 7 Jun 2008 12:37:50 +0200 Subject: [html4all] forms task force Message-ID: <916BA439-930E-46AF-B27C-8BC752104C09@robburns.com> Hello 4all (and especially Gregory), I was just looking over the activity (inactivity?) of the forms task force. Has anyone laid out the precise issues surrounding XForms or WebForms 2.0 regarding backwards compatibility with legacy UAs. They both seem to have problems, but XForms woul be a much more ideal state to achieve than WebForms from an authoring and user standpoint. For XForms, I can see that the INPUT element has problems since its defined as canonically empty in HTML and as containing labels in XForms. I imagine there are other issues, but it would be nice to see them laid out on the wiki or somewhere else so that the task force members (and the two WGs? members) were all on the same page. It also looks to me that this could be easily addressed by again including a namespace mechanism in the text/html serialization (possibly with a default namespace declaration prefix for ?xmlns:xforms?). Take care, Rob From rob at robburns.com Sat Jun 7 03:39:50 2008 From: rob at robburns.com (Robert J Burns) Date: Sat, 7 Jun 2008 12:39:50 +0200 Subject: [html4all] forms task force In-Reply-To: <916BA439-930E-46AF-B27C-8BC752104C09@robburns.com> References: <916BA439-930E-46AF-B27C-8BC752104C09@robburns.com> Message-ID: <4DC26B08-9911-4DFC-9111-F9F6F8BCE55C@robburns.com> Meant to include a link to the mail archive: On Jun 7, 2008, at 12:37 PM, Robert J Burns wrote: > Hello 4all (and especially Gregory), > > I was just looking over the activity (inactivity?) of the forms task > force. Has anyone laid out the precise issues surrounding XForms or > WebForms 2.0 regarding backwards compatibility with legacy UAs. They > both seem to have problems, but XForms woul be a much more ideal state > to achieve than WebForms from an authoring and user standpoint. For > XForms, I can see that the INPUT element has problems since its > defined as canonically empty in HTML and as containing labels in > XForms. I imagine there are other issues, but it would be nice to see > them laid out on the wiki or somewhere else so that the task force > members (and the two WGs? members) were all on the same page. > > It also looks to me that this could be easily addressed by again > including a namespace mechanism in the text/html serialization > (possibly with a default namespace declaration prefix for > ?xmlns:xforms?). > > Take care, > Rob > _______________________________________________ > List_HTML4all.org mailing list > http://www.html4all.org/wiki From rob at robburns.com Wed Jun 11 02:57:17 2008 From: rob at robburns.com (Robert J Burns) Date: Wed, 11 Jun 2008 11:57:17 +0200 Subject: [html4all] Completed logging of issues with HTML5 draft Message-ID: <5EDCC612-239D-477E-9F48-D8202B1D4BFA@robburns.com> FYI 4all ----------------------------- Hello WG, I completed my log of issues surrounding the HTML5 draft from the discussion of the WG up until August [1]. These are added in no particular order, though most of the high priority ones are also in the WG?s issue-tracker (with the exception of the parsing issue[2]). I've read through some of the emails since August and it seems that issues discussed since then were either 1) rehashes of one or more of these issues; 2) already inputted into the issue tracking system; 3) I couldn't understand the POV of the WG member and the discussion has long since petered out. So I think this covers most or even all of the major issues I see right now with the draft. There are however, a few very minor issues and some questions that I will handle mostly through separate emails. For example: ? why has the table summary attribute issue been closed when its needed for table accessibility (I couldn't find any decision to close the issue on the list serve or teleconf minutes)? [3] ? why drop the abbr attribute from the table header cells when it provides needed accessibility support? ? why drop the axis attribute when it is only now achieving CSS support in major browsers?[4] * why is Ruby specified incompletely for HTML5 (no complex Ruby)? [5] As I said, as these are new issues (to me anyway), I'll raise them in separate emails. The wiki pages are my attempt to distill prior discussions of the WG. Take care, Rob [1]: Items 13?50 at: [2]: [3]: [4]: [5]: From joshue.oconnor at cfit.ie Wed Jun 11 06:24:28 2008 From: joshue.oconnor at cfit.ie (Joshue O Connor) Date: Wed, 11 Jun 2008 14:24:28 +0100 Subject: [html4all] Completed logging of issues with HTML5 draft In-Reply-To: <5EDCC612-239D-477E-9F48-D8202B1D4BFA@robburns.com> References: <5EDCC612-239D-477E-9F48-D8202B1D4BFA@robburns.com> Message-ID: <484FD20C.6070501@cfit.ie> Thanks for that Robert. Of particular interest to me are: > ? why has the table summary attribute issue been closed when its > needed for table accessibility (I couldn't find any decision to close > the issue on the list serve or teleconf minutes)? and > ? why drop the abbr attribute from the table header cells when it > provides needed accessibility support? Cheers Josh From rob at robburns.com Wed Jun 11 08:58:04 2008 From: rob at robburns.com (Robert J Burns) Date: Wed, 11 Jun 2008 17:58:04 +0200 Subject: [html4all] Completed logging of issues with HTML5 draft In-Reply-To: <484FD20C.6070501@cfit.ie> References: <5EDCC612-239D-477E-9F48-D8202B1D4BFA@robburns.com> <484FD20C.6070501@cfit.ie> Message-ID: Hi Josh, On Jun 11, 2008, at 3:24 PM, Joshue O Connor wrote: > Thanks for that Robert. > > Of particular interest to me are: > >> ? why has the table summary attribute issue been closed when its >> needed for table accessibility (I couldn't find any decision to close >> the issue on the list serve or teleconf minutes)? Yeah, you'll notice I followed up this email with one specifically about a mechanism for table summary[1]. Take care, Rob [1]: From faulkner.steve at gmail.com Fri Jun 13 01:55:47 2008 From: faulkner.steve at gmail.com (Steven Faulkner) Date: Fri, 13 Jun 2008 09:55:47 +0100 Subject: [html4all] Fwd: Clarification of process for raising html5 accessibility related issues In-Reply-To: <55687cf80806130137k481ea0a9s48b027f830c06e9@mail.gmail.com> References: <55687cf80806130137k481ea0a9s48b027f830c06e9@mail.gmail.com> Message-ID: <55687cf80806130155g625b6fadk82ceaaf366a215a5@mail.gmail.com> Over the past few weeks there has been discussion in the PF WG and the HTML WG about how to best raise/open and track issues related to accessibility features in HTML5 and if they are substantive [1] keep them open until they are resolved by HTML WG decision rather than at the discretion of the HTML5 editor. >From my understanding of what has been agreed [2], such issues will be added to the HTML Issue tracker [3] when they are raised. They then will remain open until they are resolved. How does an issue get on the tracker? This appears to be largely at the discretion of the chairs, unless the issue is raised by a request from other WGs. So how is a HTML WG member to go about getting an issue on the tracker? I would suggest this process: 1. Raise an issue/proposal on the HTML WG mailing list or Bug tracker 2. If it there is no response from the HTML5 editor after a reasonable period of time or dismissed by the HTML5 editor and the HTML WG member(s) involved think it has not been dealt with in a manner that takes into account implications for accessibility, (for example, a decision puts the needs of browser vendors before the needs of people with disabilities), then email the PF WG for advice on the matter. 3. the PF WG will consider the matter, if they think it is a substantive issue that needs further consideration, a formal request will be sent to the HTML WG. [1] substantive issues include those that are likely to be the basis of formal objections at last call or have been formally raised by other working groups such as the PF WG. [2] http://www.w3.org/2008/06/12-html-wg-minutes.html [3] http://www.w3.org/html/wg/tracker/ -- with regards Steve Faulkner Technical Director - TPG Europe Director - Web Accessibility Tools Consortium www.paciellogroup.com | www.wat-c.org Web Accessibility Toolbar - http://www.paciellogroup.com/resources/wat-ie-about.html -- with regards Steve Faulkner Technical Director - TPG Europe Director - Web Accessibility Tools Consortium www.paciellogroup.com | www.wat-c.org Web Accessibility Toolbar - http://www.paciellogroup.com/resources/wat-ie-about.html From rob at robburns.com Fri Jun 13 02:28:16 2008 From: rob at robburns.com (Robert J Burns) Date: Fri, 13 Jun 2008 11:28:16 +0200 Subject: [html4all] Fwd: Clarification of process for raising html5 accessibility related issues In-Reply-To: <55687cf80806130155g625b6fadk82ceaaf366a215a5@mail.gmail.com> References: <55687cf80806130137k481ea0a9s48b027f830c06e9@mail.gmail.com> <55687cf80806130155g625b6fadk82ceaaf366a215a5@mail.gmail.com> Message-ID: <40CB4538-3998-42B5-B801-0B949A081563@robburns.com> Hi Steve and all, I'm all in favor of us clearing up the process surrounding the WG, but I don't want to endorse Mike Smith?s unreasonable position regarding the issue tracker. The issues Gregory added on my behalf are perfectly within established norms for adding issues to the issue tracker. If their are substantive objections to those issues, then the discussion should focus on the substantive objections (i.e., what problems would solving these issues cause for users, what confusion could solving these issues cause for authors, what difficulties would implementors face in implementing solutions to these issues, etc.). We were invited to participate in this WG to create the next version of HTML ? incrementing from 4.01 to 5. Nothing has been introduced yet into this specification to warrant such an increment, but I think solving the issues that have been discussed by the WG in its first 6 ? 14 months would warrant a 5.0 version number. We shouldn't need to all gather together for this WG just to make sure the functionality added by @alt and @summary aren't dropped, but instead to make an HTML specification that really meets the needs of users and authors. I'll repeat this again, because I think it keeps getting lost in the discussion. Nearly all of the issues I raised (38 in all), are drawn from the discussions and deliberations of the WG in the first 6 months of the life of the WG. These are issues just like the other issues raised and opened in the issue tracker. These are not proposals as Mike Smith calls them in his way of dismissing them. The proposed solutions I've included along side those issues are only my first best attempt at providing a workable and elegant solution to the issues raised: and also as solutions intended to help shape the readers understanding of the problem statements and use cases that constitute each issue. I've also included some proposed solutions because Ian has often said he wasn't able to come up with a solution to address the WG members? raised issues. These solutions are the types of solutions I expected to see Ian incorporate into the draft after reviewing the HTML WG list serve for that period (its first 6 months). Yet he claims he reviewed all of those messages and either did not encounter these issues, did not comprehend the issues or could not come up with what he thought was a workable solution to these issues. In every case now I have provided not only the issues distilled from the WG discussions, but also a first step at a workable solution for each one of the issues. So I think we should continue to use the issue tracker to raise the issues that the WG members feel need to be raised. We should continue to use the wiki to shape the use cases, problem statements and proposed solutions for those issues. We should continue to discuss the problems, implementation difficulties, authoring obstacles and user needs surrounding those issues on the HTML WG list serve (which is an official channel for the WG deliberations). And finally, we should expect the editor or editors to be responsive to those issues and incorporate solutions to those issues in to the draft ? engaging the WG in deliberations about the possible pitfalls and drawbacks as the editors encounter them. While certainly we should consider the PF WG as an authority to turn to when needed, we should insist that the WG proceed in a fair and effective manner without constantly hanging the PF WG over their / our heads. The draft should really already reflect much more progress after 15 months than we currently see. Take care, Rob On Jun 13, 2008, at 10:55 AM, Steven Faulkner wrote: > Over the past few weeks there has been discussion in the PF WG and the > HTML WG about how to best raise/open and track issues related to > accessibility features in HTML5 and if they are substantive [1] keep > them open until they are resolved by HTML WG decision rather than at > the discretion of the HTML5 editor. > >> From my understanding of what has been agreed [2], such issues will >> be > added to the HTML Issue tracker [3] when they are raised. They then > will remain open until they are resolved. > > How does an issue get on the tracker? > This appears to be largely at the discretion of the chairs, unless the > issue is raised by a request from other WGs. > > So how is a HTML WG member to go about getting an issue on the > tracker? > > I would suggest this process: > > 1. Raise an issue/proposal on the HTML WG mailing list or Bug tracker > 2. If it there is no response from the HTML5 editor after a reasonable > period of time or dismissed by the HTML5 editor and the HTML WG > member(s) involved think it has not been dealt with in a manner that > takes into account implications for accessibility, (for example, a > decision puts the needs of browser vendors before the needs of people > with disabilities), then email the PF WG for advice on the matter. > 3. the PF WG will consider the matter, if they think it is a > substantive issue that needs further consideration, a formal request > will be sent to the HTML WG. > > > [1] substantive issues include those that are likely to be the basis > of formal objections at last call or have been formally raised by > other working groups such as the PF WG. > [2] http://www.w3.org/2008/06/12-html-wg-minutes.html > [3] http://www.w3.org/html/wg/tracker/ > > > -- > with regards > > Steve Faulkner > Technical Director - TPG Europe > Director - Web Accessibility Tools Consortium > > www.paciellogroup.com | www.wat-c.org > Web Accessibility Toolbar - > http://www.paciellogroup.com/resources/wat-ie-about.html > > > > -- > with regards > > Steve Faulkner > Technical Director - TPG Europe > Director - Web Accessibility Tools Consortium > > www.paciellogroup.com | www.wat-c.org > Web Accessibility Toolbar - > http://www.paciellogroup.com/resources/wat-ie-about.html > > _______________________________________________ > List_HTML4all.org mailing list > http://www.html4all.org/wiki From jason at jasonjgw.net Fri Jun 13 02:54:44 2008 From: jason at jasonjgw.net (Jason White) Date: Fri, 13 Jun 2008 19:54:44 +1000 Subject: [html4all] Fwd: Clarification of process for raising html5 accessibility related issues In-Reply-To: <40CB4538-3998-42B5-B801-0B949A081563@robburns.com> References: <55687cf80806130137k481ea0a9s48b027f830c06e9@mail.gmail.com> <55687cf80806130155g625b6fadk82ceaaf366a215a5@mail.gmail.com> <40CB4538-3998-42B5-B801-0B949A081563@robburns.com> Message-ID: <20080613095444.GA17357@jdc.jasonjgw.net> On Fri, Jun 13, 2008 at 11:28:16AM +0200, Robert J Burns wrote: > I'm all in favor of us clearing up the process surrounding the WG, but > I don't want to endorse Mike Smith?s unreasonable position regarding > the issue tracker. The issues Gregory added on my behalf are perfectly > within established norms for adding issues to the issue tracker. If > their are substantive objections to those issues, then the discussion > should focus on the substantive objections (i.e., what problems would > solving these issues cause for users, what confusion could solving > these issues cause for authors, what difficulties would implementors > face in implementing solutions to these issues, etc.). I agree this is where the priorities should lie. It is more important to fix the HTML working group's issue tracking practices than to discuss, on this list, ways of working around their inadequacies. While it is possible for a working group not to track all issues raised during the early stages of the development of a spec, this practice needs to be put in place in later stages of the W3C process so that the group can formally respond to all issues raised in comments submitted. However, with a large and complex specification such as HTML 5, I would be concerned that unless issues are tracked carefully from an early stage, there is a very real risk that important problems could easily be lost. After all, the purpose of an issue tracker is to ensure that this doesn't happen and that decisions are documented sufficiently; and as the number of issues grows, this becomes increasingly necessary. If issue tracking isn't carried out properly from the start, then problems which are discussed but, for one reason or another, not addressed, are likely to emerge again later in the process, where dealing with them can be much more painful. No reasonable working group participant wants a large number of difficult issues to arise at Last Call or later that could have been more adequately dealt with earlier. Last Call, Candidate Recommendation and Proposed Recommendation are challenging enough as it is, without a host of issues that have previously been raised but then overlooked or disregarded. Also, having significant, dissatisfied constituencies among those who will implement or otherwise use a spec, is just asking for formal objections or negative votes as the W3C process proceeds; so this, too, is precisely a situation which it is rational for working group participants who are committed to the success of the process to ensure is avoided. Of course, HTML is a large spec, and tracking the issues adequately is a correspondingly difficult job. However, the working group is also a large one, which should make it possible to divide up the problem among participants so as to reduce the over-all burden. From rob at robburns.com Fri Jun 13 03:00:52 2008 From: rob at robburns.com (Robert J Burns) Date: Fri, 13 Jun 2008 12:00:52 +0200 Subject: [html4all] Editor Resignation? Message-ID: <4A81BA95-1F29-472D-A3A8-E8D9E58409AF@robburns.com> Hello 4all, I just like to point out a few other things. The HTML WG?s charter calls for the mailing list to the be the primary channel for technical discussions[1]. To me this implies that this is where the editor will engage with the WG to learn how to edit the draft deliverable on the WG?s behalf. Mike Smith has said he wants bugzilla to serve as a place where anyone from the public (in other words those not in the HTML WG) can post issues with the HTML draft. Finally add to that that Hixie now says: ?the two ways to guarantee i see feedback at this point are to mail whatwg or to put it in bugzilla?[2], and it sounds to me that Hixie no longer wishes to serve as the editor for the HTML WG. If that?s the case I wish he would submit a formal resignation rather than going through the motions of pretending to be an HTML WG editor. I don't really know what to make of this, but perhaps some of you more seasoned with the W3C, can make sense of this. Take care, Rob [1]: [2]: From laura.lee.carlson at gmail.com Fri Jun 13 05:52:00 2008 From: laura.lee.carlson at gmail.com (Laura Carlson) Date: Fri, 13 Jun 2008 07:52:00 -0500 Subject: [html4all] Fwd: Clarification of process for raising html5 accessibility related issues In-Reply-To: <55687cf80806130155g625b6fadk82ceaaf366a215a5@mail.gmail.com> References: <55687cf80806130137k481ea0a9s48b027f830c06e9@mail.gmail.com> <55687cf80806130155g625b6fadk82ceaaf366a215a5@mail.gmail.com> Message-ID: <1c8dbcaa0806130552u4246da9eybd93357c2b0d9322@mail.gmail.com> Steve wrote: > So how is a HTML WG member to go about getting an issue on the tracker? > I would suggest this process: Thanks Steve. Looks familiar (smile). Some of what you have listed was part of last November's (pre-tracker and pre-buggzilla) html4all founders "Goals and Objectives" vote [1] and incorporated into goals page [2] under "Foster constructive feedback for the HTML Working Group". The PF piece is under the indirect input. Thanks, Jason for raising a significant point when you say: > It is more important to fix > the HTML working group's issue tracking practices than to discuss, on this > list, ways of working around their inadequacies. People who want your thoughts documented outside of this list, please consider replying to the initial recipients of Steve's email [3] to join the on-going discussion. Best Regards, Laura [1] http://juicystudio.com/survey/results.php?id=12 [2] http://html4all.org/wiki/index.php/Goals [3] http://lists.w3.org/Archives/Public/www-archive/2008Jun/0049.html -- Laura Carlson From laura.lee.carlson at gmail.com Fri Jun 13 05:52:00 2008 From: laura.lee.carlson at gmail.com (Laura Carlson) Date: Fri, 13 Jun 2008 07:52:00 -0500 Subject: [html4all] Fwd: Clarification of process for raising html5 accessibility related issues In-Reply-To: <55687cf80806130155g625b6fadk82ceaaf366a215a5@mail.gmail.com> References: <55687cf80806130137k481ea0a9s48b027f830c06e9@mail.gmail.com> <55687cf80806130155g625b6fadk82ceaaf366a215a5@mail.gmail.com> Message-ID: <1c8dbcaa0806130552u4246da9eybd93357c2b0d9322@mail.gmail.com> Steve wrote: > So how is a HTML WG member to go about getting an issue on the tracker? > I would suggest this process: Thanks Steve. Looks familiar (smile). Some of what you have listed was part of last November's (pre-tracker and pre-buggzilla) html4all founders "Goals and Objectives" vote [1] and incorporated into goals page [2] under "Foster constructive feedback for the HTML Working Group". The PF piece is under the indirect input. Thanks, Jason for raising a significant point when you say: > It is more important to fix > the HTML working group's issue tracking practices than to discuss, on this > list, ways of working around their inadequacies. People who want your thoughts documented outside of this list, please consider replying to the initial recipients of Steve's email [3] to join the on-going discussion. Best Regards, Laura [1] http://juicystudio.com/survey/results.php?id=12 [2] http://html4all.org/wiki/index.php/Goals [3] http://lists.w3.org/Archives/Public/www-archive/2008Jun/0049.html -- Laura Carlson From faulkner.steve at gmail.com Fri Jun 13 06:03:40 2008 From: faulkner.steve at gmail.com (Steven Faulkner) Date: Fri, 13 Jun 2008 14:03:40 +0100 Subject: [html4all] Fwd: Clarification of process for raising html5 accessibility related issues In-Reply-To: <1c8dbcaa0806130552u4246da9eybd93357c2b0d9322@mail.gmail.com> References: <55687cf80806130137k481ea0a9s48b027f830c06e9@mail.gmail.com> <55687cf80806130155g625b6fadk82ceaaf366a215a5@mail.gmail.com> <1c8dbcaa0806130552u4246da9eybd93357c2b0d9322@mail.gmail.com> Message-ID: <55687cf80806130603s4e469692v307536c3625feac0@mail.gmail.com> hi laura, "People who want your thoughts documented outside of this list, please consider replying to the initial recipients of Steve's email [3] to join the on-going discussion." yes, also join the weekly telecon's as this is where HTML WG process decisions are discussed, influenced and made. I personally don't have a problem with using the bug tracker for the inital raising of proposals/issues as long as there is a clear process for progressing it. regards stevef 2008/6/13 Laura Carlson : > Steve wrote: > >> So how is a HTML WG member to go about getting an issue on the tracker? >> I would suggest this process: > > Thanks Steve. Looks familiar (smile). Some of what you have listed was > part of last November's (pre-tracker and pre-buggzilla) html4all > founders "Goals and Objectives" vote [1] and incorporated into goals > page [2] under "Foster constructive feedback for the HTML Working > Group". The PF piece is under the indirect input. > > Thanks, Jason for raising a significant point when you say: > >> It is more important to fix >> the HTML working group's issue tracking practices than to discuss, on this >> list, ways of working around their inadequacies. > > People who want your thoughts documented outside of this list, please > consider replying to the initial recipients of Steve's email [3] to > join the on-going discussion. > > Best Regards, > Laura > > [1] http://juicystudio.com/survey/results.php?id=12 > [2] http://html4all.org/wiki/index.php/Goals > [3] http://lists.w3.org/Archives/Public/www-archive/2008Jun/0049.html > > -- > Laura Carlson > > _______________________________________________ > List_HTML4all.org mailing list > http://www.html4all.org/wiki > -- with regards Steve Faulkner Technical Director - TPG Europe Director - Web Accessibility Tools Consortium www.paciellogroup.com | www.wat-c.org Web Accessibility Toolbar - http://www.paciellogroup.com/resources/wat-ie-about.html From laura.lee.carlson at gmail.com Fri Jun 13 06:24:00 2008 From: laura.lee.carlson at gmail.com (Laura Carlson) Date: Fri, 13 Jun 2008 08:24:00 -0500 Subject: [html4all] Fwd: Clarification of process for raising html5 accessibility related issues In-Reply-To: <55687cf80806130603s4e469692v307536c3625feac0@mail.gmail.com> References: <55687cf80806130137k481ea0a9s48b027f830c06e9@mail.gmail.com> <55687cf80806130155g625b6fadk82ceaaf366a215a5@mail.gmail.com> <1c8dbcaa0806130552u4246da9eybd93357c2b0d9322@mail.gmail.com> <55687cf80806130603s4e469692v307536c3625feac0@mail.gmail.com> Message-ID: <1c8dbcaa0806130624s23eb7bebwec7ecb97ec62af2@mail.gmail.com> Steve wrote: > yes, also join the weekly telecon's as this is where HTML WG process > decisions are discussed, influenced and made. Notice the that the weekly teleconferences have been renamed from "HTML WG Weekly"[1] to "HTML Issue Tracking Teleconference"[2]. > I personally don't have a problem with using the bug tracker for the > inital raising of proposals/issues as long as there is a clear process > for progressing it. A documented step-by-step process that is clear and fair is the whole point. Like I mentioned before [3] policies and procedures can: - Help everyone be aware of what is expected - Help prevent misunderstandings about expectations - Standardize operations - Provide more clarity and consistency - Encourage stability and continuity in operations - Stabilize action despite top-level changes - Discourage actions based on personalities - Help avoid future conflict But most of all, a policy and procedures would help show that the W3C means to be above-board, fair, and accountable and not arbitrary, inconsistent, unjust, partial, disenfranchising, or discriminating. Best Regards, Laura [1] http://www.w3.org/2008/04/17-html-wg-minutes.html [2] http://www.w3.org/2008/06/12-html-wg-minutes.html [3] http://lists.w3.org/Archives/Public/www-archive/2008Jun/0040.html -- Laura L. Carlson From foliot at wats.ca Fri Jun 13 10:06:58 2008 From: foliot at wats.ca (John Foliot) Date: Fri, 13 Jun 2008 10:06:58 -0700 Subject: [html4all] FW: [CfP] process proposal for a special meeting or meetings for fact-finding on issues related to @alt in HTML5 Message-ID: <015001c8cd77$e403b670$b53d42ab@stanford.edu> *** Standard Top Post apology *** Interesting, very interesting. While I will spend some time this weekend putting together my own personal ideas/proposal, methinks my history of applying large amounts of heat may come back to haunt me... (although I also hope that my history of documenting my points with references will hold me in good stead) I hope that all of the html4all-ers submit an application so that we can maximize our representation as best possible... Knowing full well that Al knows who we all are. Here is hoping that this process resolves to real, positive outcomes - I for one have always kept the faith. JF Al Gilman wrote: > ** teaser > > PFWG sent HTML WG a deliberated and consensed opinion that @alt > should be reinstated as a required attribute in HTML5, for now > (until, etc.). Discussions on this point have tended to go around > the same circles without convergence. > > Provoking authors into stuffing garbate in @alt is bad. That is > agreed on all sides. Being able to say "@alt is required" is simple > and productive in accessibility training for authors. That should be > agreed on all sides. But when these two things appear to conflict, > how does W3C make a decision? Find something we can all live with. > > On the advice of the WAI CG, I'm under an action item to organize a > consultative process to try to reduce the heat:light ratio in > discussions on this issue, so we can get on with the business of > developing an HTML5 that W3C Recommends, that is what people actually > use, and that supports accessibility. > > I'm looking for a few people from different walks of the Web who > would be willing to put some time into a search for objective, > agreeable reference points for the HTML WG decision on how to support > WCAG as regards images and text related to those images. > > ** background: > > There have been a number of threads dealing with "should @alt be a > required attribute in the HTML5 specification" and related issues. > There has been discomfort on various sides with the tendency of these > threads to rehash the same arguments repeatedly without converging > toward a consensus that all can live with. > > One of the process patterns that we often invoke in chairing W3C > groups is that if people seem to be talking past one another in > asynchronous communication; to up the interaction bandwidth, and > bring up the issue in a real-time context, in a telecon or F2F > meeting. > > On the advice of the WAI Coordination Group, I (acting as PFWG > chair) propose to organize a telecon or telecons to explore these > issues with an attempt to discover areas of agreement and clarify > areas of disagreement. The HTML WG leadership has graciously agreed > to join in organizing this ad-hoc process. > > ** macroscopic outline of the plan > > The general logical flow is that of a W3C workshop without > the Face-to-Face element or lead-time constraints. > > This activity will develop information for action by > the several Working Groups, not make decisions on their > behalf. > > This message serves as a call for expressions of interest. > Expressions of interest will take the form of a position paper. A > position paper is in concept an up-to-two-print-page review of the > issues with recommendations as to resolution. You are welcome to > encourage notable contributors to the past threads to participate. I > may do some of the same. > > Position papers should be "on the product" that is to say > on the issues affecting the HTML5 specification and the WAI/HTML > coordination process supporting the development of that > specification. They should be sent to with [alt > workshop] at the beginning of their subject line. Positions will not > be recognized for the purposes of participation unless the author > permits their [re-]posting and archiving there. > > Note that "on the product" in this case may include > process arrangements for how HTML5 manages accessibility- related > decisions and coordinates with representatives of the WAI Domain. On > the other hand, submissions of a purely procedural nature may fail to > be recognized for purposes of participation. > > Comments on this process outline are also welcome. See > in particular the issues mentioned in notes below. These > may go to the XTECH list identified above or just > to me with Cc: . > > The panel of known provisional participant (see note about > size and distribution goals) will then be polled to set date/time > particulars. The baseline proposal is a series of up to three > meetings separated by one week between meetings (also up for > comment). > > I, or a convenor or convenors that I designate, will prepare > an agenda from the submitted position papers. The chairs > of the HTML and PFWG groups may inject additional subtopics > if the see gaps in the agenda. > > Scribing rotation and editing duties for the meeting record will be > negotiated with participants in advance of the meeting date/time. > > These special meetings will not make any formal Working Group > consensus decisions. The special meeting(s) may suggest next steps > that will be dealt with as determined by the Chairs of the affected > groups for decision under the W3C Process. > > ** Notes (issues) > > * size and distribution goals > > It it is desired that the participation in the meeting not > get so large that we can't use polling of the participants > at times during the process. Anything over 12 - 15 participants is > at risk of being too large. > > On the other hand, we would prefer if most people reading > the meeting record will feel that their opinion was > presented and was listened to in the conduct of the meeting. > > I may, as organizer, invite some groups of provisional participants > (those who have volunteered to participate by submitting a position > paper) who appear to represent a common perspective to > self-down-select and propose a subteam of representatives for real > time participation. > > * communications channels > > As these issues demonstrate, listserv communication can get old. > Internet technology has evolved over the years. There are now > blogs, Wikis, IM and podcasts. > > The experience in the HTML WG is that real-time meetings > are lightly attended and the de-facto process seems largely > unaffected by what happens there. What do we have to do > to make the sessions I am proposing merit participation? > > The baseline proposal is that meeting time uses one voice > teleconference channel and one IRC channel for logging. The agenda > and the meeting report will be in accessible hypertext. The > real-time and record communications will be visible to the public. > But can we do better? > > Should we use a two-channel chat pattern? One for logging > to the meeting record, and one permitting general chat? > > Should we use a blog or Wiki to gather the position papers, rather > than a listserv? > > Do we have any hope of getting generally-agreeable summary > or index to read-ahead materials, or should the organizers > have to do this as an facilitator duty? > > Are there discussion spaces that are already set up with > these issues in scope that we should use, rather than > spawning ad-hoc resources just for this meeting? > > Should we plan for and set process patterns for asynchronous > discussion between the sessions? > > Is it possible/positive/necessary that we provide readonly access to > the meeting audio as it happens? To the meeting log in real time? > > Should we ask Participants to refrain from private conversations > during the meeting times? Or are side-conversations a necessary evil > and we need to make it clear that this may go on? > > Should we publish to WikiPedia rather than w3.org? The idea would be > that WikiPedia has a mature capability in enforcing an objectivity > ethic. > > ** notes (general) > > * template for the meeting report as an issue paper [strawman for > reference]. > > A good outline for an issue paper breaks the information into these > five sub-topics: > > 1. what squeaks -- perceived points of pain in the present situation > 2. what works -- what in the present situation should be recognized > as successful and constructive > 3. blue sky -- in the best of all possible worlds, how would things > work 4. baby steps -- what are low-risk incremental steps that would > with > confidence improve the situation > 5. the plan -- what to do. Intermediate in risk and performance > between 4. and 5. > > Naturally, that outline would serve well if used in a position paper. > > Position papers that are all about 'the plan' and not about 1. - 4. > may be disqualified. > > * template for meeting process [strawman for reference] > > A common and likely meeting flow would be as follows. > > a. Information/stipulation -- what can be agreed w/o discussion > review the read-ahead > identify points that are unarguable or generally agreed in the > position papers > > b. Outcome possibilities preview > review what could result from the meeting. What forms can 'the > plan' action proposals take? > .. where do they go for action? > > c. Discussion -- group discussion of issues that have implications > for b. and > lack the broad support of what was already available in a. > Record provisional > decisions on the fly. > > d. Recap: > Review/confirm resolutions (real-time, at end of meeting and non- > real-time in > minutes approval cycle) > Review/expand the updated read-ahead basis (a plus b). (in > minute approval). > > Each session may start and/or end with brief review and recap > sessions where > the meeting is not just starting or finally ending. > > The consideration of each topic may begin with a polling pass or two: > each Participant > asked to make an opening statement on the issue. Later phases could > include queue- > ordered turns to speak, the offering of proposed resolutions, and > voting on > proposed resolutions. [sample issue: should we take advantage of non- > real-time > means such as the W3C WBS system for polling out of real time?] > > * references > > Here are some links. You probably know more. A position paper > without at least 3 - 9 useful links to related material may be > disqualified. > > earlier PFWG finding: http://lists.w3.org/Archives/Public/public-html/ > 2008Feb/0082.html > HTML5 editor request: http://lists.w3.org/Archives/Public/wai-xtech/ > 2008Apr/thread.html#msg30 > LauraC request: http://lists.w3.org/Archives/Public/wai-xtech/2008Apr/ > thread.html#msg195 > JimJ review: http://lists.w3.org/Archives/Public/wai-xtech/2008Apr/ > thread.html#msg177 > AlG thoughts: http://lists.w3.org/Archives/Public/wai-xtech/2008Apr/ > 0367.html > format should enforce universal access: http://lists.w3.org/Archives/ > Public/wai-xtech/2008Apr/0411.html > clear away nonsense, then decide: http://lists.w3.org/Archives/Public/ > wai-xtech/2008Apr/0399.html > SteveF action item: > and so on: http://lists.w3.org/Archives/Public/wai-xtech/2008Apr/ > subject.html http://lists.w3.org/Archives/Public/wai-xtech/2008May/ > subject.html From joshue.oconnor at cfit.ie Fri Jun 13 11:39:39 2008 From: joshue.oconnor at cfit.ie (Joshue O Connor) Date: Fri, 13 Jun 2008 19:39:39 +0100 Subject: [html4all] FW: [CfP] process proposal for a special meeting or meetings for fact-finding on issues related to @alt in HTML5 In-Reply-To: <015001c8cd77$e403b670$b53d42ab@stanford.edu> References: <015001c8cd77$e403b670$b53d42ab@stanford.edu> Message-ID: <4852BEEB.9040105@cfit.ie> John Foliot wrote: > I hope that all of the html4all-ers submit an application so that we can > maximize our representation as best possible... Knowing full well that Al > knows who we all are. Here is hoping that this process resolves to real, > positive outcomes - I for one have always kept the faith. Good stuff John. It is a positive sign and a move in the right direction and there is certainly food for thought over the weekend and beyond. Cheers Josh From bruce at brucelawson.co.uk Fri Jun 13 13:06:08 2008 From: bruce at brucelawson.co.uk (Bruce Lawson) Date: Fri, 13 Jun 2008 21:06:08 +0100 Subject: [html4all] FW: [CfP] process proposal for a special meeting or meetings for fact-finding on issues related to @alt in HTML5 In-Reply-To: <4852BEEB.9040105@cfit.ie> References: <015001c8cd77$e403b670$b53d42ab@stanford.edu> <4852BEEB.9040105@cfit.ie> Message-ID: it feels like a step in the right directiom to me, too. Best of luck, John. bruce On Fri, 13 Jun 2008 19:39:39 +0100, Joshue O Connor wrote: > John Foliot wrote: >> I hope that all of the html4all-ers submit an application so that we can >> maximize our representation as best possible... Knowing full well that >> Al >> knows who we all are. Here is hoping that this process resolves to >> real, >> positive outcomes - I for one have always kept the faith. > > Good stuff John. It is a positive sign and a move in the right direction > and there is certainly food for thought over the weekend and beyond. > > Cheers > > Josh > > > _______________________________________________ > List_HTML4all.org mailing list > http://www.html4all.org/wiki -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ From rob at robburns.com Sat Jun 14 16:37:16 2008 From: rob at robburns.com (Robert J Burns) Date: Sun, 15 Jun 2008 01:37:16 +0200 Subject: [html4all] bugzilla Message-ID: <8C50FC66-944C-4703-B435-4DD1EE89BAA6@robburns.com> Dear Co-Chairs, After giving the bugzilla system a try, I have to say I don't think its working any better than the previous approaches. Ian still thinks his job as the WG?s editor is to provide one-line zinger responses to legitimate issues raised by WG members and subsequently resolve the bug report. This is inappropriate. Instead, bugzilla should be used for substantive discussion by the WG and try to arrive at suitable solutions to the issues. Certainly the editor, the chairs and other WG members should be involved in that, but the goal is not to dispatch the issue as quickly as possible with a one-liner. Like the many threads opened on public-html, the problem is not that legitimate issues are being raised. The problem is that some WG members (and Ian has set the example here) feel that it is appropriate to shoot down legitimate issues with inappropriate and often inane responses. The draft will not improve without an end to that. For any workgroup to make effective progress it has to have an editor responsive to the needs of that WG. Focussing on things like demand and whether implementors will implement is entirely unhelpful. No WG member would even suggest a proposal or raise an issue if that WG member thought that implementors wouldn't be willing to fix the problem and that there was a demand for a feature or a need to fix something. Add to that the fact that any speculation about the overall need, demand or likelihood of UA implementation is simply the hunch of one WG member against the hunch of another WG member, and it is clear that this line of debate is not leading us anywhere. If indeed vendor members of this WG really don't want to implement certain things we should get all of that out on the table so we all understand what is taboo. Absent that it is impossible to know what implementors will implement. My impression is that most are anxiously awaiting some real substantive improvements from this WG (which we haven't done yet except for perhaps MediaElement and Event-Source). So these canned answers are again singularly unhelpful for the WG. These responses appear to simply be obstacles and disruptive for WG progress. As it stands, there is very little in the draft that would benefit HTML users and authors. The parsing algorithm is perhaps the most important thing currently in the draft, yet if it isn't changed to make updates easier, then the next HTML WG will have to agin deal with the same UA compatibility issues we face now. There are many content model and semantic facilities proposed by WG members that could make HTML5 a win for users, authors and implementors alike. We only have to get the editor on board with making those changes. Take care, Rob