search

w3c / html

Deliverables of the HTML Working Group until October 2018
https://w3c.github.io/html/
Other
1.97k stars 536 forks source link

Longdesc shouldn't be described in text - ignores modularization #507

Closed cwilso closed 8 years ago

cwilso commented 8 years ago

This is actually a re-open/refutation of #258 , but I can't re-open that apparently. The below comment is replicated there.

Note that Longdesc on img was NOT marked as obsolete anymore - a commit was done (with no issue) to that effect: 4aeba86, prior to this issue being filed. However, this change seems to belie the whole point of having modular specs, by putting the image attribute back into the core specification. Given the politics of this particular item, I'm somewhat taken aback that in essence longdesc was was simply re-placed in the spec, given that an express goal was to encourage modularization. I think this change (NOT the removal-of-longdesc-as-obsolete change, that should stay) should be reverted, until such point as we can establish a better pattern of modular pieces being incorporated; this sets a bad precedent, and thumbs its nose at the previous controversy. Not really something to go in right under the wire.

dwsinger commented 8 years ago

I agree, and am also greatly disturbed that such a sensitive topic (longdesc), which has had an FO/Director-Decision on it, no less, was made without a call-for-consensus, any email, any contact with the wider community, any new evidence, and even almost no debate in the issue itself. Perhaps the peace was fragile, but this is startlingly bad.

tantek commented 8 years ago

Agreed with @cwilso except for:

"until such point as we can establish a better pattern of modular pieces being incorporated".

The notion of incorporating modules into a monolithic spec I believe is a leftover from Robin's "5.1 plan" etc. proposals before the WPWG charter happened.

At this point, per the charter, we should be encouraging more modularization, not less, and if there is any monolithic HTML spec to be published, it should continue to shrink as unimplemented features are dropped, and as modules are extracted and published separately.

cwilso commented 8 years ago

@tantek : I meant "when there's a stronger pattern of modularization, I could see having informative sections that show how some modules work together". That certainly didn't come out in what I said, we're on the same page here.

LJWatson commented 8 years ago

Thanks @cwilso @tantek and @dsinger for your comments.

I think (hope) it may be a simple difference of understanding, and that we can find an agreeable path forward.

The Image Description spec is a module of HTML5. It is a Recommendation that exists in its own document - which is my understanding of the way we want modularisation to work.

We linked to the ID spec from HTML core on the basis that there should be some way to conect the dots between HTML core and other modules. On reflection I think we can probably do this in a clearer way - a first step might be to include a table of all HTML5 modules as an easy reference point?

dwsinger commented 8 years ago

Leonie, the previous uneasy compromise was that longdesc would not be in the main HTML spec. but an extension, and our request was that the extension be marked as historic/obsolete. The latter was denied in a FO decision (that was poorly handled), but we nonetheless settled into an uneasy peace, where the objectors could live with it. This move shatters the peace. Why?

johnfoliot commented 8 years ago

I'm sorry David, but I must disagree. I will again quote from Plan 2014 (https://dev.w3.org/html5/decision-policy/html5-2014-plan.html):

Extension specifications are first-class citizens

Some believe that extension specifications are second-class citizens, or somehow “lesser” than the core HTML5 specification. On the contrary, the specifications in the list above are vibrant, active pieces of the Web platform, with significant implementation traction and community credibility. JF: If this is true, then why does it matter where an extension that supports 1 HTML attribute eventually live? What is the difference between HTML5.0 + an attribute extension versus HTML5.1, where the attribute definition is integrated into the larger document? Especially when the W3C management, and Plan 2014, explicitly stated that extensions were full-fledged parts of the HTML5 specification? Complaining that this particular extension must live alone in the corner like some bastard child unloved by many, is a direct contradiction to the plan that was brought forward that was Plan 2014 - it perpetuates the notion that somehow @longdesc really isn't part of HTML5.0, but rather some token olive branch to keep the peace (nudge nudge, wink wink).

Plan 2014 continues: Many extensions recognized as having wide consensus are recognized as part of the default settings of the W3C Validator, so they have an equal footing in validation. JF: This is the case for @longdesc today. Whether as a stand-alone document appended to the end of the HTML5.0 document, or whether the language is moved to a place in the newer HTML5.1 document that is more 'logical' - what is the difference? @longdesc, per Plan 2014 - is a "first-class citizen" of HTML as defined by the W3C today.

The idea that by modularization, we are somehow dividing and conquering bits of HTML that some members don't like is troubling to me, as it is clearly contrary to what was explicitly stated as part of Plan 2014. If 'modularization' is the only way to extend HTML5.0, then why are we even doing an HTML5.1? What is the difference between newly added content to the draft 5.1 spec, and extension specification language that could just as easily live "inside" of HTML5.1 as outside, given that EXTENSIONS SPECS ARE FIRST CLASS CITIZENS?

dwsinger commented 8 years ago

John, I write of a decision "made without a call-for-consensus, any email, any contact with the wider community, any new evidence, and even almost no debate in the issue itself". And your reply is "EXTENSIONS SPECS ARE FIRST CLASS CITIZENS". Can you spell non-sequitur?

LJWatson commented 8 years ago

@dsinger @johnfoliot

I think the misunderstanding stems from the interpretation of the phrase "roll back in" from Plan 2014. We took the phrase to mean moving something bodily into HTML core. When we linked from HTML core to the Image Description spec, it therefore didn't seem to constitute being rolled back in. It was a decision based on the practicalities of how we link to *any module from HTML core.

It is now clear that definition is not shared by everyone! I think it is also clear that we should have done the courteous thing and let Apple know about the approach we planned to take. We were thinking about modules in general, not this module in particular, and so it didn't occur to us to do that. I'm sorry we didn't.

What we need to do now is look at how we do connect the dots between HTML core and other modules. We have a couple at present and there are more in the pipeline. Another possibility is that we create an index document (as opposed to the table I suggested in my earlier comment), which is easily referenced from HTML core and which provides an easy index of all available modules.

tantek commented 8 years ago

Re: modularization and "Plan 2014", I (and others I've spoken with) believed "Plan 2014" to be an obsolete non-normative non-AC-approved document written by someone that has long left the HTML / WP WGs, that was wholly superseded by the AC Approved WPWG charter in 2015: https://www.w3.org/2015/10/webplatform-charter.html and in particular this piece:

The Web Platform Working Group should develop modular specifications to the greatest extent possible for the development of the HTML language

Where "greatest extent" including making any monolithic HTML revisions smaller with modules being taken out, and never any modules put in.

LJWatson commented 8 years ago

Thanks @tantek Now we have four editors working on HTML, we're in a position to ask one of them to look at the first steps we might be able to take in modularising the spec. We had hoped to do this before, but it took us longer than we had hoped to find all our editors.

All things being equal we hope to have something useful to report/propose to the WG at TPAC. If you and/or Mozilla have any candidate chunks of the spec that would be worth prioritising, we'd really like to hear from you - perhaps off this thread though!

johnfoliot commented 8 years ago

David, with respect, you also wrote: "the previous uneasy compromise was that longdesc would not be in the main HTML spec. but an extension" - which I can only interpret as you saying that somehow @longdesc isn't part of HTML5.0. I disagree, and I point to Plan 2014 as for why.

The 'compromise' - the one that I made when I withdrew my Formal Objection to get HTML5.0 out the door via Plan 2014 - was based explicitly on the assurance that extensions were first-class parts of HTML5.0, not some minor addendum that member orgs can take and "be marked as historic/obsolete." That may have been what Apple wanted, but that was not the decision.

As for process issues, David, I agree, our process has become a lot more devolved, and now we have to monitor multiple locations to stay on top of things. But that is the current process, and if that is to be changed, we need to change it ourselves. I would support a move towards a better centralized monitoring method.

Tantek, while I can respect your belief, Plan 2014 was agreed to by all involved, from HTML5 WG members to W3C management at the time it was proposed and subsequently widely shared across the web. Assurances were made then, and Formal Objections withdrawn based upon those assurances, so to say today that it is/was unofficial and/or non-binding is disingenuous at the very least.

johnfoliot commented 8 years ago

Tantek, additionally, asked:https://lists.w3.org/Archives/Public/public-html/2012Oct/0026.html, and answered: https://lists.w3.org/Archives/Public/public-html/2012Oct/0105.html

dwsinger commented 8 years ago

John, there was a compromise, and it's been broken, and in a surreptitious way. That you cannot see that in itself speaks volumes. That you still cannot see that fictional specifications are simply bad ideas astounds me.

ghost commented 8 years ago

Please remove me from your GITHUB group.

I have nothing to do with your project and have no idea why and or how you included me

regards,

David Singer

On Fri, Jun 24, 2016 at 5:14 PM, David Singer notifications@github.com wrote:

John, there was a compromise, and it's been broken, and in a surreptitious way. That you cannot see that in itself speaks volumes. That you still cannot see that fictional specifications are simply bad ideas astounds me.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/w3c/html/issues/507#issuecomment-228274380, or mute the thread https://github.com/notifications/unsubscribe/ABZolrdDc7ee9JD4pWoc-T3qWWDUiI1Gks5qO4PzgaJpZM4I83RM .

David Singer Managing Director

D ​​ +61 ​2 8915 5303 M

Join us for a drink https://www.facebook.com/UnitedCellars https://twitter.com/UnitedCellars https://plus.google.com/+unitedcellars/posts https://www.youtube.com/user/UnitedCellars

Your feedback is important to us. Please fill in our short survey here https://www.surveymonkey.com/r/?sm=NKya2PgA34Z4wLcl9HkHoV0TRN3v0o6Tj0cdy5t8BR4%3d .

http://au.unitedcellars.com/email-signature

This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission.

ZoeBijl commented 8 years ago

Dear dsinger, you can leave on the teams page. Sorry for the inconvenience.

tantek commented 8 years ago

@johnfoliot all citations you provided predate the WPWG charter and AC approval thereof, which as I said in my comment https://github.com/w3c/html/issues/507#issuecomment-228102278, supersedes any/all such informal "Plan NNNN" discussions/documents.

Note also that those "Plan NNNN" references were all discussions in a, from a process perspective, different WG.

The HTMLWG is no more (except for its remaining fragment, the Media TF).

The WPWG is a new WG, with an AC approved charter in 2015: https://www.w3.org/2015/10/webplatform-charter.html (nothing more), and is not beholden to anything from the HTMLWG.

chaals commented 8 years ago

There are people who love, and people who hate, longdesc. It is implemented independently and repeatedly, it is known to run the risk of being wrong, and it is a W3C Recommendation that explicitly extends HTML.

The last of those is the reason for integrating it into HTML without more than two github issues tracking that.

The suggestion that a few lines of text, as the way to integrate a spec whose real content is about a page long, into one two orders of magnitude larger, seems to draw a long bow. Unlike the various ways to incorporate graphics - canvas, SVG, which are mostly external although with more linking text in the HTML spec, or embedding things with img which is mostly defined within the spec, this case doesn't seem to rate on the discussion of modularisation.

If the longdesc spec is rescinded, longdesc would of course be removed. But otherwise it seems this issue should be closed.

dwsinger commented 8 years ago

On Jul 26, 2016, at 18:54 , chaals notifications@github.com wrote:

There are people who love, and people who hate, longdesc. It is implemented independently and repeatedly, it is known to run the risk of being wrong, and it is a W3C Recommendation that explicitly extends HTML.

The last of those is the reason for integrating it into HTML without more than two github issues tracking that.

That’s not a good reason. Such high-handed action by the chairs, without explicitly looking for consensus, has broken the trust relationship. I understand that you have a personal investment in this, but would have expected you to put that on one side when acting as chair.

The suggestion that a few lines of text, as the way to integrate a spec whose real content is about a page long, into one two orders of magnitude larger, seems to draw a long bow.

I don’t know what you mean by a ‘long bow'. Integrating is the precise opposite of the chartered direction of the group, which is modularization.

Unlike the various ways to incorporate graphics - canvas, SVG, which are mostly external although with more linking text in the HTML spec, or embedding things with img which is mostly defined within the spec, this case doesn't seem to rate on the discussion of modularisation.

Perhaps you don’t think it rates, but it defies belief that you could think that doing anything with longdesc would be uncontroversial. If the longdesc spec is rescinded, longdesc would of course be removed. But otherwise it seems this issue should be closed.

As chair, you can close whatever you like. Whether you want people to trust that the group will be run transparently, by consensus, and to the charter is another question.

I thought we had put the years of substituting power plays for efficacy in accessibility were over. I was wrong. We’re clearly back in — maybe still in — the toxic political environment that directly leads to fragmentation and the development of alternative venues. That’s very regrettable. I guess that’s a choice, but why the chairs and team would make it baffles me.

Congratulations on moving the W3C back into the realm of mythical specifications that actively mislead people.

David Singer Manager, Software Standards, Apple Inc.

cwilso commented 8 years ago

Minus the last two paragraphs (which are an aside), I agree completely with David.

If we were in a different political environment around HTML, it is possible this would be a minor point. However, this particular feature is a long-entrenched battleground, and I have to strongly recommend that it NOT walk over the line in being strictly modular, lest we reopen old wounds. As David says, I think the current state damages trust in the WG's work.

tantek commented 8 years ago

I am also in agreement with @dwsinger. And I will add:

it is a W3C Recommendation

The consensus among ALL browser vendors was non-positive on making longdesc a Recommendation. I wrote about this:

http://tantek.com/2015/057/b1/disappointed-in-w3c

Making longdesc a Recommendation was perhaps the most anti-consensus technical act ever done by W3C. It was and still is a low point at W3C.

The fact that ANYONE in the current WPWG would consider even mentioning longdesc in any new work (much less a chair!) demonstrates only how out of touch they are with that history and present reality.

On this point, and others (re-addition of the demonstrably buggy-in-practice "rev" attribute etc.) HTML 5.1 has "gone off the rails" and as it is, is not worthy of being published as a Working Draft, much less a Candidate Recommendation.

Any serious effort to restore HTML5.x work to legitimacy would immediately drop all things added in HTML 5.1 (because it's supposed to be shrinking, via modularization, certainly not growing) and then republish as a Working Draft.

@LJWatson you specifically asked about "first steps we might be able to take in modularising the spec", and that is simple. First do no harm, and in terms of modularising, doing "no harm" means: 1) Stop adding things to HTML5.1 (opposite of modularizing), and 2) Drop everything added since 5.0.

Once it is clear (by actions) that the WG understands that aspect of modularizing, then it makes sense to start talking about what else to modularize and remove from the monolithic HTML 5.1 specification. Until 1 and 2 are demonstrated, both in action, and in understanding, by the chairs, and editors, there is no incentive to invest any time attempting to repair an effort gone badly wrong (an effort that is out of scope per the WPWG Charter that makes it clear that modularizing should be the direction of 5.1, not growth.)

LJWatson commented 8 years ago

Can we please stop revisiting history that can't be changed, and try to work together to find a way forward?

Image Description is a module of HTML. We have at least one other module (ARIA in HTML) and probably others. We need to establish a way of referencing/linking to those modules - preferably a way that is robust enough to cope as we begin the process of modularising HTML core and linking/referencing other HTML modules.

We need to do this in such a way that it is clear when a module is being referenced, that makes it easy and convenient for people to find modules when they are relevant, and which means it is easy to get an overview of what the total set of modules looks like.

To do this I suggested including a table of modules in the index of HTML core. I also suggested greater clarity whenever we link to a module from somewhere inside HTML core.

It would be helpful to get some constructive thoughts about these steps.

dwsinger commented 8 years ago

On Jul 28, 2016, at 12:01 , Léonie Watson notifications@github.com wrote:

Can we please stop revisiting history that can't be changed, and try to work together to find a way forward?

We’re criticizing recent history. What can’t be changed? The Lady of Shallot is now nailed to the perch? Image Description is a module of HTML. We have at least one other module (ARIA in HTML) and probably others. We need to establish a way of referencing/linking to those modules - preferably a way that is robust enough to cope as we begin the process of modularising HTML core and linking/referencing other HTML modules

No, we really don’t. If I go to a lumber yard (timber yard), they do not tell me all the things that can be added onto or used with pieces of wood. Rather, wood screws are identified as wood screws, wood glue is identified as wood glue, and do on.

We need to do this in such a way that it is clear when a module is being referenced, that makes it easy and convenient for people to find modules when they are relevant, and which means it is easy to get an overview of what the total set of modules looks like.

The W3C has a TR page which lists specifications, and other suitable subsets are documented by other groups (e.g. CSS snapshots).

To do this I suggested including a table of modules in the index of HTML core.

No, I would not suggest this. The number of ways HTML can be extended is large. Nor do I understand what is meant by HTML core. I also suggested greater clarity whenever we link to a module from somewhere inside HTML core.

It would be helpful to get some constructive thoughts about these steps.

OK, I manage core spec and some members of the family of file formats that include MP4. The base spec. is carefully written to be independent of all its derivatives, and doesn’t mention them. So, .mp4, .3gp, .3g2, .mj2, and so on have specs that say “we take the base spec. and specialize it in the following ways”. There are also specs that say “to put this kind of material in any member of this family, do the following” (that’s how AVC aka H.264 is documented, so all of these formats store AVC the same way).

This is a modular set of specs.

What we need is a structure for a modular set of specs for HTML. For example (off the top of my head):

you get the idea. Build from the bottom. Refer down to things that you use, don’t include up the things that use you. So the bottom level document does NOT refer to the others.

David Singer Manager, Software Standards, Apple Inc.

LJWatson commented 8 years ago

Thanks @dwsinger "We’re criticizing recent history. What can’t be changed? The Lady of Shallot is now nailed to the perch"

By "history that can't be changed" I meant the fact that Image Desc is a W3C Recommendation and a module of HTML. I already acknowledged in my first comment on this thread that I thought we could do better with what you refer to as "recent history" than we had initially done.

"No, we really don’t. If I go to a lumber yard (timber yard), they do not tell me all the things that can be added onto or used with pieces of wood. Rather, wood screws are identified as wood screws, wood glue is identified as wood glue, and do on."

True, but you also tend to find related products co-located in the same part of the store - the bathroom department or garden centre for example.

"The W3C has a TR page which lists specifications, and other suitable subsets are documented by other groups (e.g. CSS snapshots)."

Indeed, but this is only useful up to a point. When you are looking at CSS module X, it is not easy to discover related CSS modules that may be relevant to the one you're looking at. I think this is something we can try to do better.

"No, I would not suggest this. The number of ways HTML can be extended is large. Nor do I understand what is meant by HTML core."

HTML core is an informal term for the "monolith" spec, minus the current set of modules.

It sounds as though you think a "CSS style" listings page would be ok, but not a listings table within the index of the HTML core?

"OK, I manage core spec and some members of the family of file formats that include MP4. The base spec. is carefully written to be independent of all its derivatives, and doesn’t mention them. So, .mp4, .3gp, .3g2, .mj2, and so on have specs that say “we take the base spec. and specialize it in the following ways”. There are also specs that say “to put this kind of material in any member of this family, do the following” (that’s how AVC aka H.264 is documented, so all of these formats store AVC the same way)."

That's a useful reference point.

"What we need is a structure for a modular set of specs for HTML. For example (off the top of my head):"

Yes we do, and as noted in my comment a month ago, this is something we are looking at and hope to have a proposed plan to present to the WG at TPAC.

"* HTML: introduction, basic parsing rules, data types, escapes, etc. (roughly chapter 1 and 2)

Thanks for suggesting this modularisation pattern. It'll be really helpful as we put a plan together for the WG to consider.

"you get the idea. Build from the bottom. Refer down to things that you use, don’t include up the things that use you. So the bottom level document does NOT refer to the others."

So it seems that we have two basic approaches when it comes to modularising:

  1. Core does not point to modules, and a modules listing page/table may exist.
  2. Core points to related/relevant modules, and a modules listing page/table may exist.

So the question for me becomes, which of these approaches makes things easiest for people reading the specs?

  1. We offer no pointers and trust that people will refer to the listings to discover whether there is a module relevant to their current interest.
  2. We offer pointers (that are clearly marked as pointers to modules), and trust that people will follow them if they are interested.

It seems to me that there are countless examples of the latter approach across the web, and that they are largely done to help people find other things relevant to their current thing of interest.

dwsinger commented 8 years ago

On Jul 28, 2016, at 13:38 , Léonie Watson notifications@github.com wrote:

So the question for me becomes, which of these approaches makes things easiest for people reading the specs?

We offer no pointers and trust that people will refer to the listings to discover whether there is a module relevant to their current interest. We offer pointers (that are clearly marked as pointers to modules), and trust that people will follow them if they are interested. It seems to me that there are countless examples of the latter approach across the web, and that they are largely done to help people find other things relevant to their current thing of interest.

I am not opposed to maps, or listings such as the TR page or CSS snapshots. They collect things into interesting bunches, offer overviews, and so on. What I do NOT like is when base specs refer to the things that use them; then whenever a leaf is added to the tree, you have to look all the way up the tree to see wherever else it should be mentioned.

Roadmaps of HTML — or even W3C — specs are different.

So I think your dichotomy is false; it’s not “offer no pointers” vs. put pointers in the base specs (which you didn’t say).

David Singer Manager, Software Standards, Apple Inc.

LJWatson commented 8 years ago

@dwsinger "I am not opposed to maps, or listings such as the TR page or CSS snapshots. They collect things into interesting bunches, offer overviews, and so on."

Agreed.

"What I do NOT like is when base specs refer to the things that use them; then whenever a leaf is added to the tree, you have to look all the way up the tree to see wherever else it should be mentioned."

So in other words, pointing to modules from the core/base spec is an administrative overhead in spec maintenance terms? If so, that's definitely a consideration.

Thinking off the top of my head... if we take the module breakdown you suggested, we could include a "Related modules" section in each module perhaps?

"So I think your dichotomy is false; it’s not “offer no pointers” vs. put pointers in the base specs (which you didn’t say)."

I think we mean the same thing by refering to "base" and "core". If that's so, the second of the two approaches I outlined did include pointers from core/base:

  1. Core does not point to modules, and a modules listing page/table may exist.
  2. Core points to related/relevant modules, and a modules listing page/table may exist.

If the dichotomy as you outline it is not the case, can you clarify what you think is? If we can distill the different approaches into something clear and manageable, I think we'll be taking a step in the right direction.

dwsinger commented 8 years ago

On Jul 28, 2016, at 14:41 , Léonie Watson notifications@github.com wrote:

@dwsinger https://github.com/dwsinger "I am not opposed to maps, or listings such as the TR page or CSS snapshots. They collect things into interesting bunches, offer overviews, and so on."

Agreed.

"What I do NOT like is when base specs refer to the things that use them; then whenever a leaf is added to the tree, you have to look all the way up the tree to see wherever else it should be mentioned."

So in other words, pointing to modules from the core/base spec is an administrative overhead in spec maintenance terms? If so, that's definitely a consideration.

It’s more than that: it risks overlap of concept, disagreement of text, blurring of IPR considerations, and it’s an admin overhead...

Thinking off the top of my head... if we take the module breakdown you suggested, we could include a "Related modules" section in each module perhaps?

I think it’s important that the overviews and roadmaps be informative, not in normative specs; then if we get a little out of sync, it’s less serious, and there’s no IPR confusion.

"So I think your dichotomy is false; it’s not “offer no pointers” vs. put pointers in the base specs (which you didn’t say)."

I think we mean the same thing by refering to "base" and "core". If that's so, the second of the two approaches I outlined did include pointers from core/base:

Core does not point to modules, and a modules listing page/table may exist. Core points to related/relevant modules, and a modules listing page/table may exist. If the dichotomy as you outline it is not the case, can you clarify what you think is? If we can distill the different approaches into something clear and manageable, I think we'll be taking a step in the right direction.

Yes, I prefer 1, quite strongly.

David Singer Manager, Software Standards, Apple Inc.

paulbrucecotton commented 8 years ago

Image Description is a module of HTML. We have at least one other module (ARIA in HTML) and probably others. We need to establish a way of referencing/linking to those modules - preferably a way that is robust enough to cope as we begin the process of modularising HTML core and linking/referencing other HTML modules.

As far as I know there is no definition of a "HTML module". The noun "module" does appear in HTML 5.1 but nearly always in the title of other specifications ie "CSS Backgrounds and Borders Module Level 3"

I am pointing this out since HTML 5.1 does include the concept of applicable specification:

"When vendor-neutral extensions to this specification are needed, either this specification can be updated accordingly, or an extension specification can be written that overrides the requirements in this specification. When someone applying this specification to their activities decides that they will recognize the requirements of such an extension specification, it becomes an applicable specification for the purposes of conformance requirements in this specification."

The fact that "applicable specifications" are NOT currently listed in HTML 5.1 would appear to be germane to this discussion.

Isn't longdesc just one of many HTML "applicable specifications"?

I would help this discussion if we defined the terms we are using AND if we used terms already defined in the HTML 5.1 spec.

/paulc

LJWatson commented 8 years ago

@paulbrucecotton Thanks for your comments.

"It would help this discussion if we defined the terms we are using AND if we used terms already defined in the HTML 5.1 spec."

Plan 2014 used terms like "core", and "extensions" as a product of "modularity". A "module" is also the product of modularity, so to all intents and purposes the terms "module" and "extension" seem conversationally interchangeable.

Plan 2014 also references the definition of an "applicable specification". So whichever informal term we use, "applicable specification" would seem to describe it in normative terms.

According to the definition of an applicable specification, the conformance of a document with HTML is not dependent on conformance with an accessible specification. It is possible to conform to HTML plus XYZ extension, and it's my undersanding that this is how the validator handles things at present.

"Isn't longdesc just one of many HTML "applicable specifications"?"

That's my understanding, yes.

"The fact that "applicable specifications" are NOT currently listed in HTML 5.1 would appear to be germane to this discussion."

Including a list of applicable specifications seems like the sensible thing to do. The question is whether we include it in HTML5.1 itself, or elsewhere?

We may first need to identify what is/isn't an applicable specification. Plan 2014 describes three types of extension:

  1. Specifications spun out from HTML (Can vas 2D, Web RTC etc.).
  2. Purpose built specifications (Shadow DOM, EME etc.).
  3. Stand-alone specifications referenced from HTML (ARIA, SVG etc.).

A complicating factor is that there is no consistent method for handling these things. We have pulled some extensions back into core (picture, main etc.), we have included some inline (ARIA, CSP), and some have substantial sections (Canvas, SVG etc.).

paulbrucecotton commented 8 years ago

Plan 2014 used terms like "core", and "extensions" as a product of "modularity". A "module" is also the product of modularity, so to all intents and purposes the terms "module" and "extension" seem conversationally interchangeable.

I am not sure that I agree. First I want to point out that Plan 2014 was NOT talking about breaking the main HTML spec up into "extensions" or "modules". It was mainly talking about how new material could be added to HTML by creating separate "extension" specifications.

"* HTML: introduction, basic parsing rules, data types, escapes, etc. (roughly chapter 1 and 2) •HTML: basic structure, content-independent (e.g. , , ), common media-indepdent attributes over all/most elements, and so on (roughly chapter 3 and some of 4, perhaps 5 and 8)

•HTML: scripting •HTML: text (paragraphs, headings, all that kind of stuff) (roughly 4.5) •HTML: forms •HTML: image handling •HTML: continuous media (video, audio, tracks, sources, and so on)"

Thanks for suggesting this modularisation pattern. It'll be really helpful as we put a plan together for the WG to consider.

In the above response to David Singer's "modularity" proposal @LJWatson seem to be using "modularity" to describe how the main HTML spec can be broken up into "modules". In my view this is completely different that what Plan 2014 was talking about when it talked about separate "extension" specifications and possibly different than what HTML defines to be "applicable specifications".

We may first need to identify what is/isn't an applicable specification. Plan 2014 describes three types of extension:

  1. Specifications spun out from HTML (Can vas 2D, Web RTC etc.).
  2. Purpose built specifications (Shadow DOM, EME etc.).
  3. Stand-alone specifications referenced from HTML (ARIA, SVG etc.).

A complicating factor is that there is no consistent method for handling these things. We have pulled some extensions back into core (picture, main etc.), we have included some inline (ARIA, CSP), and some have substantial sections (Canvas, SVG etc.).

I think I have to agree here which is why I am asking that we first define a common terminology. For example, are the parts of HTML described by David Singer's "modularity" proposal "applicable specifications" or just "pieces" of the main HTML specification? I think I have shown above that you are switching back and forth between "modules" and "applicable specification" and so far they do not necessarily mean the same thing.

LJWatson commented 8 years ago

"I think I have to agree here which is why I am asking that we first define a common terminology. For example, are the parts of HTML described by David Singer's "modularity" proposal "applicable specifications" or just "pieces" of the main HTML specification? I think I have shown above that you are switching back and forth between "modules" and "applicable specification" and so far they do not necessarily mean the same thing."

That's a fair point @paulbrucecotton. Ok, here's a first (very rough) effort to put some definition around these terms...

Module: a specification spun out of HTML core, now with its own editor(s) and on the Rec track in its own right. A document that uses a module may be an conforming HTML5 document.

Extension: a specification that extends/adds to HTML core, with its own editors and on the Rec track in its own right. A document that uses an extension may be a conforming HTML5 document, but that state is not dependent on the extension.

Thoughts?

tantek commented 8 years ago

Catching up on some of this back and forth, I don't see the utility of differentiating between a "Module" and an "Extension", I see only additional confusion being propagated between two similar sounding terms.

That kind of bikeshedding also seems like a distraction from the "core" issue(s), which is that HTML5.1 as currently published violates the explicitly intended direction set in the WPWG charter (which frankly is what matters, per W3C process, and respecting wishes of the AC, not a "plan 2014" document done by a previous working group).

Recent history that should and can be changed ASAP to start repairing some of the damage done:

  1. Take HTML5.1 back to Working Draft with all additions since 5.0 removed (including references to):
    a. longdesc (by any name)
    b. RDFa (including reverting any informative examples that depend on RDFa)
    c. 'rev' attribute
    ... any other additions that can be determined. (looking for suggestions from those in this thread and anyone else reviewing 5.1's changes from 5.0).

As already noted by @dwsinger , a. and b. were the subject of long irreconcilable permathreads that reached very tenuous compromises, and thus it's better to revert to said compromises as of 5.0 than make any changes (from 5.0) here which will only destroy any chance of consensus on a 5.1.

c. was a well thought-through and studied explicit removal in 5.0, for which there was no information provided that would alter those analyses, and yet 'rev' was added back in 5.1 basically because there was a github issue asking for it "as a good idea" (summary paraphrasing). I'm a bit shocked this level of institutional memory has apparently been lost among current editors/chairs, institutional memory which IMO is essential to even have a chance of producing a reasonable versioned successor to HTML5.0.

2) Stop work on any further HTML5.x until said 5.1 Working Draft has been produced, since any HTML5.x based on the current 5.1 will only be propagating the same counter-to-charter errors.

LJWatson commented 8 years ago

@Tantek That kind of bikeshedding also seems like a distraction from the "core" issue(s), which is that HTML5.1 as currently published violates the explicitly intended direction set in the WPWG charter (which frankly is what matters, per W3C process, and respecting wishes of the AC, not a "plan 2014" document done by a previous working group)."

Given the topic of this issue, I think that modules spun out of HTML core being conforming, and extensions that add to HTML core being non-conforming, is an important distinction. One at least that deserves more discussion.

HTML modules are mentioned three times in the WP charter.

"...this Working Group is an interim group while discussion is ongoing regarding the proper modularization of HTML and its APIs, and it enables the ongoing specifications to continue to move forward over the next 12 months."

"The Web Platform Working Group should develop modular specifications to the greatest extent possible for the development of the HTML language, allowing extension specifications to define new elements, new attributes, new values for attributes that accept defined sets of keywords, and new APIs."

"HTML A specification defining the core language of the World Wide Web: the Hypertext Markup Language (HTML). The updated HTML specification should be modularized into separate documents."

It may be of interest to note that the last link points to a document written by @darobin on behalf of the previous WG.

We may not have made as much progress as some would like, but as previously noted we only reached our full complement of HTML editors about four months ago. Things may have turned out differently had we had active contributions from members championing modularisation, but as things stood we focused on improving the HTML spec in smaller more achievable ways.

We did take our first step towards modularisation by spinning out ARIA in HTML into its own specification. Previously part of HTML5.0 core, it is now a module specification on the Rec track in its own right.

We have also been looking at possible parts of the HTML5.1 core that we could next spin out into modules. You'll find the most recent discussion around this in the minutes from the HTML editor's call today, and we hope to have space on the TPAC agenda to discuss modularisation in more detail.

LJWatson commented 8 years ago

We discussed the initial subject of this issue on the HTML editor's call today.

We recognise that our original approach was not ideal and that it upset several people. As has been mentioned already, this was not our intention, but the inadvertent result of a different interpretation of Plan 2014.

We also recognise that there is no solution that will please everyone who has invested themselves in this discussion. It has been a protracted and painful experience for everyone, and our initial approach to referencing longdesc didn't help. That said, we hope it is possible to reach an accord that, whilst not perfect, will enable us all to move on from here without further anguish.

With this in mind, we'd like to propose the following steps for resolving this issue:

  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. Keep the longdesc examples in HTML core **.
  4. Create a WG Note listing known extension specifications ***.
  5. Include a link to the HTML Extension Specifications Note from HTML core (probably in the index).

\ Examples throughout the HTML specification are informative, and we include informative examples and information for other specifications and extensions elsewhere in HTML core.

*\ We anticipate that the Note will be updated as we identify new/other extension specifications.

We hope this approach will enable people to use the W3C Image Description Recommendation in conjunction with HTML5.1, whilst at the same time making its status as an HTML Applicable Specification clear.

Constructive thoughts and comments welcome.

LJWatson commented 8 years ago

@dwsinger @cwilso @tantek would very much like to hear your thoughts on the proposal in my previous comment. Thanks.

johnfoliot commented 8 years ago

@tantek I think your interpretation of modularization can be taken too far

cwilso commented 8 years ago

Why leave longdesc example in the core spec, when it's not definitive there?

johnfoliot commented 8 years ago

We are talking about an attribute to an HTML element, and not an API or another related technology. I support the idea of modularization to the point where major activities can be worked on asynchronously, under the collective umbrella of "HTML5", but not to the point where dissatisfied parties can dismiss bits of the HTML (markup language) specification as second-class "modules" which, because the are not "core" can be dismissed away with a wave of the hand.

Specifically, I object to "Remove the longdesc attribute from the table of attributes in HTML core."

I disagree with that direction; this attribute is one of numerous valid attributes that can be applied to a core HTML element; it's not a related technology, and it's not even related to other W3C specs (i.e. CSS, Timed-Text, etc.). The table of attributes in HTML "core" should include all valid attributes, including attributes that were valid in HTML4.1; if the table seeks to then link to the @longdesc extension spec for clarification of the attribute over what came previously in HTML4.1, that would be a reasonable compromise.

As Leonie noted, we have pulled other extensions back into core (picture, main etc.), with no outcry from others, and frankly bringing picture (https://www.w3.org/TR/html/semantics-embedded-content.html#the-picture-element) and main (https://www.w3.org/TR/html/grouping-content.html#the-main-element) into the "core" or base spec makes sense: yes, we want modularization, but not fracture-ization, and ensuring that related concepts are 'bundled' together cohesively for mainstream authors/developers addresses their needs, using the well-worn and time-tested Priority of Constituents: users over authors over implementors over specifiers over theoretical purity (which is how I am interpreting Tantek's desire for "modularization", to the point that we have a big basket of single-page 'modules'.) Bringing emergent elements and attributes specifically related to the markup language that is HTML into a cohesive collection (through a dot release - 5.1) benefits authors greatly, as it puts related content at their fingertips in one place, without having to chase all over the W3C to see what is or isn't usable today.

@tantek wrote:

Recent history that should and can be changed ASAP to start repairing some of the damage done:

Take HTML5.1 back to Working Draft with all additions since 5.0 removed (including references to): a. longdesc (by any name) b. RDFa (including reverting any informative examples that depend on RDFa) c. 'rev' attribute ... any other additions that can be determined. (looking for suggestions from those in this thread and anyone else reviewing 5.1's changes from 5.0).

Question to Tantek - does your suggestion also include picture and main as well? If this WG can justify adding picture and main into "core" (whatever that is), then by the very nature of those justifications @longdesc should also be added in exactly the same fashion.

dwsinger commented 8 years ago

On Aug 4, 2016, at 13:05 , Chris Wilson notifications@github.com wrote:

Why leave longdesc example in the core spec, when it's not definitive there?

Agreed.

Examples belong with the specification of which they are examples. Please.

David Singer Manager, Software Standards, Apple Inc.

dwsinger commented 8 years ago

On Aug 4, 2016, at 13:07 , John Foliot notifications@github.com wrote:

We are talking about an attribute to an HTML element, and not an API or another related technology. I support the idea of modularization to the point where major activities can be worked on asynchronously, under the collective umbrella of "HTML5", but not to the point where dissatisfied parties can dismiss bits of the HTML (markup language) specification as second-class "modules" which, because the are not "core" can be dismissed away with a wave of the hand.

Specifically, I object to "Remove the longdesc attribute from the table of attributes in HTML core.”

No doubt. My strong preference is that there is only one HTML specification, that it reflects reality, and that it’s forward looking. I had some hopes that the W3C would continue to move towards being the owner of that specification, but after taking this significant retrograde step, I have to believe that I have my hopes pinned to the wrong horse.

David Singer Manager, Software Standards, Apple Inc.

LJWatson commented 8 years ago

@dwsinger @cwilso @tantek and @johnfoliot Thanks for raising and/or contributing to this discussion. My hope is that people on different sides of this discussion will be willing to comprimise a little so we can get this done and move on.

We have opened a CFC on the proposal.

tantek commented 8 years ago

@LJWatson I appreciate some forward movement on this issue.

Three things.

  1. I agree with @cwilso and @dwsinger about dropping longdesc examples as well. Which leads to:
  2. You wrote "willing to compromise a little" — this is problematic, as there was already so much compromising when this issue was brought up and resolved in the previous WG, that it is not reasonable to ask for any "re-compromising", except for what was agreed in the charter of the WPWG (which is why I keep citing it). The way I see it, @cwilso @dwsinger and I are acting in extreme good faith by asking only for the previously agreed compromise(s) of separation etc. to be maintained rather than asking for anything more. Based on this good faith behavior, it's really not ok to ask for more compromises.
  3. Do we need to file additional issues for removing RDFa and 'rev' references and examples? Or can those be removed simultaneously? I would rather make all these painful reverts all at once, rather than litigate them piecemeal.
cwilso commented 8 years ago

@LJWatson I appreciate your objectivity and even hand in working on this issue. I also appreciate the willingness to suggest compromises. It pains me that after consideration, I still disagree with making that compromise.

The primary reason I still object to the examples being in the core spec is that I feel having examples of something that isn't in the core spec violates the architectural layering of modularity; I think we should HAVE those examples, but that they should appear in the longdesc spec and in any WG Note that might be produced listing the modules, but not in the core spec itself. The core referencing a module is a layering violation (i.e., it points from a fundamental to a module).

@johnfoliot you stated "Bringing emergent elements and attributes specifically related to the markup language that is HTML into a cohesive collection (through a dot release - 5.1) benefits authors greatly, as it puts related content at their fingertips in one place, without having to chase all over the W3C to see what is or isn't usable today." This is a fallacy, I believe, as nothing in the spec(s) will help authors understand what is or isn't usable today; that's a result of what UAs implement, not what's in the core. It might be a good idea to have a Note or book or other reference that delineates "HTML as she is usable today", but that's not (IMO) the "core" document. I respect your goal of longdesc not being a second-class citizen; but I think modules must be considered as a first-class way of including features, particularly contentious features like longdesc, and it is a important not to muddy the layering waters of core vs module.

dwsinger commented 8 years ago

On Aug 5, 2016, at 15:54 , Chris Wilson notifications@github.com wrote:

@LJWatson I appreciate your objectivity and even hand in working on this issue. I also appreciate the willingness to suggest compromises. It pains me that after consideration, I still disagree with making that compromise.

The primary reason I still object to the examples being in the core spec is that I feel having examples of something that isn't in the core spec violates the architectural layering of modularity; I think we should HAVE those examples, but that they should appear in the longdesc spec and in any WG Note that might be produced listing the modules, but not in the core spec itself. The core referencing a module is a layering violation (i.e., it points from a fundamental to a module).

@johnfoliot you stated "Bringing emergent elements and attributes specifically related to the markup language that is HTML into a cohesive collection (through a dot release - 5.1) benefits authors greatly, as it puts related content at their fingertips in one place, without having to chase all over the W3C to see what is or isn't usable today." This is a fallacy, I believe, as nothing in the spec(s) will help authors understand what is or isn't usable today; that's a result of what UAs implement, not what's in the core. It might be a good idea to have a Note or book or other reference that delineates "HTML as she is usable today", but that's not (IMO) the "core" document. I respect your goal of longdesc not being a second-class citizen; but I think modules must be considered as a first-class way of including features, particularly contentious features like longdesc, and it is a important not to muddy the layering waters of core vs module.

I agree with all that Chris says here, and thank him (and Leonie) for this.

David Singer Manager, Software Standards, Apple Inc.

stevefaulkner commented 8 years ago

The primary reason I still object to the examples being in the core spec is that I feel having examples of something that isn't in the core spec violates the architectural layering of modularity

With my HTML editors hat on We have plenty of examples in HTML that include features that are not in the core spec and are not even in non-core specs. The HTML spec is not only for implementers it is also for authors/developers and where inclusion of technologies that work with HTML core features, in examples, is considered helpful then they should be be included. Note we are talking about editorial, non normative inclusion here. The inclusion of such material is editorial and being so it has and should continue to be the decision of spec editors to include or not.

Let us be clear: I am not arguing for or against the inclusion of non normative examples of longdesc use, I am arguing that a blanket rule that we cannot include examples that make use of non core HTML features, in the spec, is not helpful. If you want to make a case that in this instance, the inclusion of a longdesc attribute is not useful, then by all means do so, but please do not attempt to forbid the HTML editors from including all non core feature examples due to your objection to one attribute.

darobin commented 8 years ago

Whoa.

There are so many different issues mixed up together in this thread you would sort of need an issue tracker just for it. Seriously, what's wrong with using different issues for different problems? This isn't a mailing list where discussion is supposed to be confusing.

I'm not kidding, if this were an open source project, this would have been summarily closed and half of you all would've been banned already.

At the very least, you need to split up:

Longdesc is Mentioned

Some people don't like longdesc. Some people like longdesc. It may well be that whether longdesc should get mentioned in any other HTML specification is a decision that depends on how modularisation is done. However that does not mean that longdesc itself, or the idea of mentioning it, or the way in which it may have come to be mentioned whether ill- or well-intentioned or properly politic should in any way manner or form be mixed up with discussions of modularity. If it depends on modularity being clarified, then mark it as such but for the love of Eris make it its own thing.

What Document Are We Listening To?

There seems to be extensive confusion about Plan 2014 versus After5 versus the breakup list versus the short version of After 5 I was made to write because apparently people don't like reading more than three pages of text if there aren't kittens versus the WPWG charter.

You know what? I don't blame you. That's a lot of documents, all of them meta.

My suggestion is to ignore every single last one of them, apart from the IP parts of the charter. If you can't make your point without referencing some variously formal or official document (unless it's purely legalistic) then you don't have a point.

I realise that those documents represent past consensus, and that should be listened to. But at the end of the day work is done by those who show up. If you disagree with a given orientation, then participate more — to the actual work.

[Note that I have no idea who is active these days, so I'm not pointing fingers.]

An Index for the Platform

This has been a hot issue since longer than I've been around. I remember when SVG was torn between specifying everything and leaving the door open to applicable specifications. I remember when MPEG told us the Web was incomprehensible because there was no document indicating how everything fit together and what must be supported. CSS has gone through this. People regularly ask for an IDL for all the Web APIs, etc. etc.

My suggestion here, as it has always been, is: "if you want to work on this, go for it!" I don't however believe that it is possible to have a discussion of the topic that won't replay previous instances.

If you're feeling mischievous, since it's a genuinely a techno-organisational topic, send it jointly to the TAG and AB. 🍭

How to Modularise

This is hard. It has always been hard. I think that the only way to make it work is to leave it in the editors' hands. Whenever an editor feels like making that work, let them figure it out. If the group likes the result, take it, otherwise explain why. Any experience will be retrospective — the CSS people might help.

The fact is however that you might be able to have a constructive discussion about it if it were in its own issue.

Editorial Freedom

It is customary for editors to enjoy a lot of latitude as to the non-normative aspects of the text. It's a brutally gruelling job, they get to have breaks. Of course this would never entitle them to abusive content or the such, but I don't think we are anywhere near that, even if some people really don't like longdesc. I know that the HTML WG was a lot more micromanagerial of its editors than is the norm (for historical reasons I need not recount); I don't think that's a good thing.

But irrespective of what you think on this topic it should be treated as a separate issue.

With this, I'll return to my cave. 💋 💋 💋

cwilso commented 8 years ago

@stevefaulkner : This was not intended as a blanket condemnation of editorial examples. I would point out that modularity typically increases the need for description of how to utilize modules effectively; my point was more that such examples already existed, and the addition of longdesc examples seems to imply that putting such examples into the core spec is what's required for modules to be "real" or "first-class" - in which case, the whole point of modularity is dramatically weakened. Additionally, longdesc is, was, and I suspect ever shall be a hot wire, and I was advising avoiding stirring up further controversy by inserting it back into the HTML core spec. Like any other HTML module, it will live or die in the future based on actual usage, not by being blessed in the core HTML spec.

@darobin : as always, I miss your guidance. And indeed, this issue has mixed several things together. "Longdesc is mentioned" is certainly the closest to what I had in mind when I filed it; I don't think longdesc should be put in the core spec, even as examples, because it serves as a false flag distraction. However, my internal motivation was certainly "How to modularise" (as I personally have little political skin in the longdesc game). I would encourage the WPWG chairs and/or editors to fork off the "How to modularise" issue; if I do so now, the ball will get dropped (due to other commitments, not a lack of will).

The only further point I'll make is to say that although I agree that precisely what document we are listening to is a distraction, it is critically important that the group drives a consistently-motivated consensus. If we completely ignore past consensus and let whoever shows up dictate today's direction, we will encourage editorial dictatorship, not rough consensus and principle-driven management.

LJWatson commented 8 years ago

@darobin is right - things have become mixed up in this thread, and I'm guilty as charged for helping make that so.

The WP charter mentions HTML modules, but it doesn't describe a modularisation model, define what a module/extension is/isn't or place any constraints on how a module/extension should be referenced. This is something the WG needs to decide and that can then be implemented accordingly - hence the proposed discussion at TPAC.

Until that time, all we have to go on is the current HTML spec - which as @stevefaulkner notes includes informative examples of HTML and non-HTML related specs - per the editor's choice at the time.

I know there have been many comprimises made and many reassurances given throughout the history of the longdesc specification. I believe that despite the often fraught nature of the discussion, that everyone involved in this thread continues to act in good faith.

I'm grateful to @johnfoliot for signalling his consent to the proposal. I remain hopeful that others will also consent to this proposal, so we can complete HTML5.1 and leave the way open for discussion about modularisation in 5.2 (and implementing whatever that may look like then/there).

adanilo commented 8 years ago

Closing, as PR #562 removes this as described in the PR.