- From: Hansen, Eric <ehansen@ets.org>
- Date: Thu, 22 Feb 2001 22:38:48 -0500
- To: "'oedipus@hicom.net'" <oedipus@hicom.net>, w3c-wai-ua@w3.org
Gregory, The suggestion is interesting. If the change were made, would the definition capture what we mean? New, tentative definition of "Conditional content": Conditional content is content that the author does not intend the user agent to render by default, but that the author does intend to make available to the user through the user interface under certain conditions. Some mechanisms for providing conditional content include the "alt" attribute and the OBJECT element in HTML, and the test attributes of SMIL 1.0 and SMIL 2.0. The rendering semantics (when and where) of conditional content may be well-defined in some cases (e.g., "alt" and OBJECT in HTML) and less well-defined in others (e.g., "title" in HTML). Note: The Web Content Accessibility Guidelines 1.0 requires that authors provide text equivalents for non-text content. This is generally done by using the conditional content mechanisms of a markup language. Thanks! - Eric Old defintion of "Optional content" per http://lists.w3.org/Archives/Public/w3c-wai-ua/2001JanMar/0249.html ------------------------------------------------- Part III: Definition of optional content ------------------------------------------------- Optional content is content that the author does not intend the user agent to render by default, but that the author does intend to make available to the user through the user interface under certain conditions. Some mechanisms for providing optional content include the "alt" attribute and the OBJECT element in HTML, and the test attributes of SMIL 1.0 and SMIL 2.0. The rendering semantics (when and where) of optional content may be well-defined in some cases (e.g., "alt" and OBJECT in HTML) and less well-defined in others (e.g., "title" in HTML). Note: The Web Content Accessibility Guidelines 1.0 requires that authors provide text equivalents for non text content. This is generally done by using the optional content mechanisms of a markup language. > -----Original Message----- > From: oedipus@hicom.net [mailto:oedipus@hicom.net] > Sent: Thursday, February 22, 2001 4:58 PM > To: w3c-wai-ua@w3.org > Subject: Conditional versus Optional: Preliminary Observations > > > Conditional versus Optional: Preliminary Observations > > in the minutes from the 22 February 2001 telecon [reference 1], the > following exchange was recorded: > > quote > GR: "Required optional content" is a little weird. > > IJ: Good point! > > Action IJ: Find clearer wording. > > GR: I propose changing "optional content" to "conditional content". > I think that conditional doesn't presume that one form of > content is preferred over another. > > IJ: I don't think "optional" suggests that optional content > is lower class. > unquote > > 1. required bits are not "optional"--"required optional" is an > oxymoron; what is "optional" is the discretionary portion of > the requirement--for example, in the HTML4/XHTML world, deciding > on appropriate ALT text for the IMG element... the A, the L, > the T, the equals sign, and a pair of quotes are required--what > goes between the quotes is the optional bit... > > 2. "conditional" because what is delivered to the requesting UA > is the derivative of the conditions surrounding slash containing > slash initiating the transaction; moreover, the conditions under > which content is delivered (or in which content is capable of > being delivered) are not always/necessarily "optional", as they > may (or are quite likely to) include both those over which the > user has either no or limited control, or of which the user is > ignorant (in a non-pejorative sense)--conditions can also be > predicated upon explicit user choice; server side filters and > transformations, including processing by proxy servers; > configurations slash settings; hardware limitations; language > preference (accept) settings; functional limitations, > environmental limitations; markup support slash standards > compliance ; etc.; the point is that the "content" (the message) > is capable of being delivered by a number of potential messengers > (content/file types), depending upon which is most appropriate-- > e.g. when certain conditions (no matter their source) apply, send > slash receive slash expose slash render X, not Y or Z, but if X > does not exist slash has not been provided, Q will be acceptable... > > 3. "conditional" is completely neutral--no need to speak of > equivalencies; doesn't champion slash pit one form of content > slash modality over another, as it doesn't matter why the > conditions exist, only that the UA respond to them > appropriately, by providing content in the most appropriate > content-type slash form slash modality, whether due to an > explicit request for a particular content type, the explicit > exclusion of unsupported slash unusable slash unwanted content > types, or by preference slash cascade order > > 4. the term "conditional" captures the nuances of the term far > more concretely, and far less ambiguously, than "optional", as > it incorporates user configuration; negotiation transactions > (such as those based on CC/PP, accept headers, etc.); SWITCH- > and SWITCH-like mechanisms; the rendering order of nested > OBJECT elements; SMIL test attributes; and the CSS cascade, to > name but a few > > 5. "optional" is a dangerous term because the plain English > language definition of the word "optional" is, according to > the online edition of Webster's (http://www.m-w.com) > > quote > involving an option : not compulsory > unquote > > which (at least to my ears) eliminates the term from contention, > as use of the ALT attribute for the IMG element is compulsory in > HTML4/XHTML1... > > gregory. > > PS: i know that the example is technology-specific, but that's > simply because the case of IMG is the most familiar and clearest > illustration of the point... > > References: > > [1] (long URI warning!) > http://lists.w3.org/Archives/Public/w3c-wai-ua/2001JanMar/0258.html > ------------------- > Email sent using AnyEmail from http://www.hicom.net >
Received on Thursday, 22 February 2001 22:39:28 UTC