W3C home > Mailing lists > Public > public-html@w3.org > August 2007

Re: Support for Design Principles (was: Design Principles survey delayed)

From: Steven Faulkner <faulkner.steve@gmail.com>
Date: Thu, 16 Aug 2007 14:33:04 +0100
Message-ID: <55687cf80708160633g4c8766dau4ac9447070fb2f4b@mail.gmail.com>
To: "Geoffrey Sneddon" <foolistbar@googlemail.com>
Cc: "Dan Connolly" <connolly@w3.org>, public-html@w3.org
I have updated  a version of proposed changes to wording the design
principle "Accessibility / Universal Access:"
on the wiki (http://esw.w3.org/topic/HTML/ProposedDesignPrinciples)

similar words have been there for some time, but not picked up by geoffrey
as an alternative wording as they were not clearly identified as such. I
have now remedied that:

 Suggested amended wording of principle

"Design features to be accessible, universal, and inclusive. Access by
everyone regardless of ability is an essential. Do not omit features that
provide access to users unless alternate/equivalent mechanisms are be
provided. Deliverables will satisfy accessibility requirements. To ensure
this we will work closely with the
WAI<http://www.w3.org/2007/03/HTML-WG-charter.html#wai>."



On 16/08/07, Geoffrey Sneddon <foolistbar@googlemail.com> wrote:
>
>
>
> On 15 Aug 2007, at 19:49, Dan Connolly wrote:
>
> > I have an offer from Geoffrey Sneddon to summarize the level of
> > support and dissent for most of the principles. Perhaps that
> > will be available for discussion in tomorrow's teleconference.
>
> This is what I believe is the general consensus having read most
> emails on this mailing list since it began. If anyone wants to
> question any of these, feel free to do so. This corresponds to the
> current version on the wiki, which due to various changes has a
> greater degree of support.
>
> Support Existing Content: The vast majority seem in favour of this,
> though one or two are trying to avoid deviating from SGML (this is
> perhaps against the charter's requirement to "define conformance and
> parsing requirements for 'classic HTML'", though, making many of
> these really objections against what we've been chartered to create).
>
> Degrade Gracefully: I've not to my knowledge heard anything against
> this, though there have been people questioning how it has been
> implemented.
>
> Don't Reinvent The Wheel: There's has been agreement on this since it
> was reworded by Lachlan Hunt (20070813), though one or two minor
> editorial points have been raised. It seems most of the former issues
> were due to how it was worded and misconceptions about what it was
> meant to be.
>
> Evolution Not Revolution: Very little has been said about this at
> all, but no objections.
>
> Solve Real Problems: This has caused some of discussion about what a
> "real-world problem" is. This is another principle that I believe
> would get the vast majority supporting it if it was better explained
> (such as what a "real-world problem" is).
>
> Priority of Constituencies: This is another principle that has been
> mentioned very rarely, without objections. It was brought up recently
> in terms of accessibility and the needs of users.
>
> Media Independence: Again, been mentioned very rarely without
> objections (mainly by Maciej, and since mid-May, only by Maciej).
> There is a recommendation to add a paragraph in the wiki (seemingly
> the only reason for it to appear under the disputed section).
>
> Support World Languages: This has unanimous agreement, as far as I
> can see.
>
> Secure By Design: This, too, has had very little said about it. I
> doubt anyone would question it, however.
>
> Baby Steps: Having been added very recently, most of the discussion
> under a thread of a similar name ("Baby Steps or Backwards Steps")
> have been regarding the recent changes to @alt, and not to the design
> principles. This should probably be merged into "Solve Real
> Problems", to fix the issues there.
>
> Well-Defined Behavior: There is agreement upon this, though some have
> questioned whether this should spread as far as non-conforming
> content (see "Handle Errors" below).
>
> Avoid Needless Complexity: This has scarcely been discussed, and
> consensus can't really be commented on.
>
> Handle Errors: Some have questioned whether our specification that
> defines parsing requirements should go as far as dealing with non-
> conforming content or not, however, the majority are in favour of this.
>
> Accessibility / Universal Access: The only objection I'm aware of is
> the one directly inline i the wiki, questioning the use of "when
> possible". As this is the only objection, there is a vast majority in
> favour of this.
>
> No Version Syntax vs Explicit Versioning: This is present verbatim in
> the current editor's draft. I assume this is questioning a prior
> principle that doesn't exist anymore?
>
> Pave The Cowpaths: Lachlan Hunt's email of 20070815 <http://
> lists.w3.org/Archives/Public/public-html/2007Aug/0472.html> explains
> that the principles are there to guide research, not to make
> decisions. If this was clarified, I expect the objections (such as
> condoning past bad practices) would go. This is as it stands, disputed.
>
> Separation Of Concerns: This is disputed on grounds of "semantics for
> the sake of semantics" being good, and not being purely semantic.
>
> Support Extensions: This is something that's come up several times,
> but the technical feasibility of this has sometimes been questioned.
> This probably needs expanding: Is this meaning extensions through
> namespaces, or just putting further elements (such as <canvas>)
> within the global namespace? The WG is currently split over this.
> Such an explanation may help.
>
> Visible Metadata vs. Metadata Anywhere: There has been questions
> about whether metadata should be visible or not. The WG is very split
> over this. This is unchanged from the editor's draft.
>
> It does, in my opinion, appear as if the majority of the document has
> the majority supporting it. I believe by rewriting parts we can
> increase the size of this majority. However, I do believe we may well
> would in a survey get dissent from the WG. However, in such a large
> WG I doubt we'll have many decisions that resolve without dissent,
> due to the huge number of different points of view, so we will in
> many cases just need to manage dissent to make progress (in line with
> the W3C Process). To advance a TR (in this case, to FPWD), the
> Director reviews any Formal Objections.
>
> - Geoffrey Sneddon
>
>
>
>


-- 
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
Received on Thursday, 16 August 2007 13:33:11 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:38:48 UTC