Re: Next Tasks on the Text Alternatives Document

First, a disclaimer.  Any errors in that original list were purely mine ;-)
 Some notes inline:

On Mon, Nov 10, 2014 at 1:14 PM, <chaals@yandex-team.ru> wrote:

> Hi,
>
> 10.11.2014, 21:46, "Shane McCarron" <shane@aptest.com>:
>
>
>
>    1. Duplicated text shouldn't be in html specification - it will
>    diverge with this note and there is always a risk that there will be
>    conflicting advise.  Moreover, the HTML spec already references this note.
>
>
>
> Actually, I disagree. The HTML spec gets referenced as a "Standard" in a
> way that the Note should not (since it doesn't get any measure of the
> consensus of the W3C as a whole).
>
> The two documents should be in synch at the point where an HTML
> Recommendation, and perhaps even a Working Draft, is published, but the
> reason for a Note is that editors who are used to the publishing process,
> in groups who do work, can turn them around much faster. Without being a
> formal W3C Recommendation, this can still be useful as an indication of how
> the Working Group's thinking is evolving.
>
> I doubt there is a huge risk of the HTML spec giving contradictory advice
> if we get this note more or less up to scratch, and maintain it as
> necessary.
>

I like when there is disagreement.  It means people care!


>
>    1. When making sure the document is "correct", does "correct" mean
>    what we think people ought to do or should the examples work in browsers?
>    We think the examples should work in browsers.
>
>
>
> I think the examples should work in at least some browsers before they are
> put into the spec. But really, in a Note it is reasonable to describe both
> cases, so long as it is clear which is which.
>
> Implementation status often changes much faster than what we think people
> should do,
>

Fair enough.


>
>    1. What about techniques to avoid, that don't work?  Is it useful to
>    cover those.  We think that it could be helpful if there are obvious bad
>    techniques.
>
>
>
> Agreed, although they need to be really clearly marked
>

class="badExample" ;-)


>    1. (does that include security aspects e.g. if whether alt was used,
>    info on a broken image icon)
>
>
>
> I don't understand the question - please elaborate it a bit?
>

My bad.  We were brainstorming at the time about what information a browser
might make available about ALT.  Obviously currently values for @alt appear
in the DOM.  However, currently there is not a way to tell if that value is
displayed to the user.  If that is important, are there security
implications.  If a default icon is displayed instead of the image (for
whatever reason) is it important to be able to discover it.  If it is
important, are there security implications.  Things like that.


>
>
>
> Once the task force agrees on the general guidance, our plan is to raise
> bugs for specific proposed changes to the document, then iterate with the
> task force on those changes and get them integrated as they are agreed upon.
>
>
> I would suggest raising bugs first, and then we can figure out how to fix
> them in the TF.
>

Exactly.  I was typing too quickly.  Unless the "bug" has an obvious fix,
of course.



-- 
Shane McCarron
Managing Director, Applied Testing and Technology, Inc.