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

RE: CFC on referencing the Image Description (longdesc) extension

From: Katie Haritos-Shea GMAIL <ryladog@gmail.com>
Date: Fri, 12 Aug 2016 14:02:41 -0400
To: "'Chris Wilson'" <cwilso@google.com>, "'David Singer'" <singer@mac.com>
Cc: 'Léonie Watson' <tink@tink.uk>, "'Edward O'Connor'" <eoconnor@apple.com>, "'HTML WG'" <public-html@w3.org>
Message-ID: <45b001d1f4c3$b8fb92f0$2af2b8d0$@gmail.com>
It sounded like a very good compromise to me, and I thought it had been agreed to and that is why it was going to CfC, and why I supported it.


Though I wasn’t *happy* about the agreement (but was willing to accept it), compromise means "you don't get everything you want", right?






* katie *


Katie Haritos-Shea 
Principal ICT Accessibility Architect (WCAG/Section 508/ADA/AODA)


Cell: 703-371-5545 |  <mailto:ryladog@gmail.com> ryladog@gmail.com | Oakton, VA |  <http://www.linkedin.com/in/katieharitosshea/> LinkedIn Profile | Office: 703-371-5545 |  <https://twitter.com/Ryladog> @ryladog


From: Chris Wilson [mailto:cwilso@google.com] 
Sent: Friday, August 12, 2016 12:16 PM
To: David Singer <singer@mac.com>
Cc: Léonie Watson <tink@tink.uk>; Edward O'Connor <eoconnor@apple.com>; HTML WG (public-html@w3.org) <public-html@w3.org>
Subject: Re: CFC on referencing the Image Description (longdesc) extension


In the interest of clarifying my contribution to the discussion in the issue in Github, I believe we should:

1. Remove the longdesc attribute from the table of attributes in HTML core.

2. Remove the IDL information for the longdesc attribute from HTML core.

3. Remove the longdesc examples in HTML core.

4. Create a WG Note listing known extension specifications, and giving examples of how those modules work.

5. Optionally include a non-normative link to that Note from HTML core (probably in the index).


IOW, longdesc (or any other module) should not be directly referenced in the core.  There should be informative examples, but they should not be in the Core, or it's not a Core document, it's comprehensive (e.g. every future module will want to be listed in the Core, or it will believe it is "second-class").



On Fri, Aug 12, 2016 at 9:02 AM, David Singer <singer@mac.com <mailto:singer@mac.com> > wrote:


I think we’re fine with the other actions in the CfC, but like Ted, I strongly feel examples belong with the specification of the thing they exemplify (or, if an example of integration of several specs is needed, in separate informative and tutorial material such as those that the accessibility groups in W3C are chartered to produce).


> On Aug 12, 2016, at 3:18 , Léonie Watson <tink@tink.uk <mailto:tink@tink.uk> > wrote:
> On 11/08/2016 21:31, Edward O'Connor wrote:
>> Hi Léonie,
> Hello Ted. Good to have your input on this, thanks.
>> You wrote:
>>> 3. Keep the longdesc examples in HTML core **.
>> This doesn't make sense to me. When we moved Microdata into its own spec
>> because people objected to it being in HTML 5, we also removed Microdata
>> from the examples in the HTML spec (e.g.
>> <https://www.w3.org/Bugs/Public/show_bug.cgi?id=18726>). Also, in
>> general, including features defined in extensions in examples in the
>> core spec strikes me as bad layering.
> At the moment there is no real consistency in the way we reference specs (applicable or otherwise) from HTML. My hope is that over the next few months the WG will be able to discuss and agree on definitions for modules (as opposed to extensions), and a method for referencing either/both of those things. The idea being that we'd then be able to start putting that plan into action across HTML.
> In the meantime the hope is that by removing all the normative references and leaving only informative examples, we can find a consensus that will see us through until the WG has consensus around modularisation/extension handling etc. (and enough active contributors to make it happen).
> Léonie.
> --
> @LeonieWatson tink.uk <http://tink.uk>  Carpe diem

Dave Singer

singer@mac.com <mailto:singer@mac.com> 

Received on Friday, 12 August 2016 18:03:14 UTC

This archive was generated by hypermail 2.3.1 : Friday, 12 August 2016 18:03:15 UTC