Re: How to productively contribute

Thanks Ian, that's helpful. Some further responses below.

On Jun 27, 2007, at 5:23 PM, Ian Hickson wrote:

>
> On Wed, 27 Jun 2007, Robert Burns wrote:
>>>
>>> There shouldn't be "sides".  [...]
>>
>> In your message you suggested when writing to the wiki be sure we're
>> "recording the points put forward by both <em>sides</em> in a neutral
>> fashion". Now you say there shouldn't be "sides". How are we to
>> interpret that?
>
> Assuming you are referring to:
>
> | If all you are doing is arguing back and forth without doing  
> unbiased
> | research, trying to convince your fellow mailing list posters  
> without
> | actually recording the points put forward by both sides in a neutral
> | fashion, then ALL YOUR TIME WILL GO TO WASTE.
>
> ...then apologies for any confusion. The above wasn't supposed to  
> be a set
> of suggestions of what you _should_ do (I covered that in the positive
> paragraphs in that e-mail), it was an example of what not to do. If  
> there
> are two sides, then trying to convince the other side instead of  
> writing
> up the arguments is a waste of time. Ideally, though, there would  
> not be
> any "sides", we would just work together towards a common goal.

I think that would be great if it were true. However, a read through  
the email list will reveal that there are sides. I just can't quite  
figure out what they are?

>>> You shouldn't be so attached to an idea that you can't think of  
>>> other
>>> ideas, or so attached to an idea that you can't see its  
>>> disadvantages.
>>>
>>> You shouldn't need someone else presenting another "side" of the
>>> "argument" to address an issue.

There are cases where I'm having a very hard time coming up with cons  
and I turn to the email list to help with that. Unfortunately, the  
responses are often flippant or don't take the time to even  
understand the proposal. Should I simply leave cons out of the wiki  
page for that particular issue or link to flippant email responses  
(sometimes these come off-list).

>> This might just be my own deficiency then, but in the issues I've  
>> been
>> advocating on, I am having a hard time imagining the objections  
>> when no
>> one clearly explains the objection.
>
> Don't think of it in terms of "objections". Every idea has pros and  
> cons.
> Surely even you can see problems with proposals you are putting  
> forward,
> even if you don't think they are important enough to warrant  
> discarding
> the idea.

Sometimes, but not always. It would definitely be helpful (or it  
should be) to fallback on the email list to assist with cons and  
drawbacks.

This example is quite helpful.

> Let's take an example of something in the spec, the <ol> element.  
> Pretend
> <ol> wasn't in the HTML5 spec. What would the right way to go  
> forward be?
>
>  1. Determine the problem. The problem is that the hypothetical spec
>     without <ol> provides no way to mark up a list of elements in  
> which
>     the order matters. Now, is that true? Well, no, actually, there  
> are at
>     least two other ways to mark up lists in HTML5 which could be  
> used:
>
>       <dl> <dt> 1 <dd> first item  <dt> 2 <dd> second item </dl>
>
>       <table> <tr> <td> first item <tr> <td> second item </table>
>
>     So the problem isn't the lack of a way to mark up an ordered  
> list. The
>     problem is the lack of a way to mark up a list with succint  
> markup.
>     Well, no, there's a way to do that too:
>
>       <ul> <li> item <li> other item </ul>
>
>     But, that doesn't necessarily preserve order. So. The problem  
> is that
>     the ways of marking up ordered lists in the hypothetical spec  
> are not
>     very succint.
>
>  2. Look at solutions. Well, we've already suggested two solutions:
>
>       A. Use <dl> instead, with the <dt> giving the order.
>
>       B. Use <table> instead, with one row per item.
>
>     We could come up with other solutions:
>
>       C. Use <ul>, but introduce a new attribute such as type=1 to
>          indicate that the order matters.
>
>       D. Use <ol>.
>
>       E. Use <p>, but number the paragraphs using an attribute.
>
>       F. Use <p>, but have an attribute that says it is part of a  
> list and
>          make sets of such <p> elements in a row become semantically a
>          list.
>
>       G. Introduce a new element like <list>.
>
>       H. Not support this case.
>
>  3. Discuss pros and cons of each proposal.
>
>       A: pro: works already.
>          con: not very intuitive.
>          con: legacy UAs wouldn't render it like a numbered list  
> with one
>               line per item.
>          con: would have to define processing rules for when the  
> <dt> in't
>               a number vs when it is a number vs when it's mixed.
>
>       B: pro: works already.
>          con: complex.
>          con: legacy UAs wouldn't render it like a numbered list  
> with one
>               line per item.
>          con: would have to define processing rules for when some rows
>               have multiple cells, or when cells span rows, etc.
>
>       C: pro: simple markup.
>          pro: works already.
>          con: legacy UAs wouldn't render it like a numbered list  
> with one
>               line per item.
>
>       D: pro: works already.
>          pro: simple markup.
>          con: makes the language bigger.
>          con: because of legacy UAs supporting it, we're  
> constrained in
>               terms of what we can do with the parser for these  
> elements.
>
>       E: pro: works already.
>          con: legacy UAs wouldn't render it like a numbered list  
> with one
>               line per item.
>          con: unintuitive.
>
>       F: pro: works already.
>          con: legacy UAs wouldn't render it like a numbered list  
> with one
>               line per item.
>          con: unintuitive.
>
>       G: pro: we can design the markup to work exactly as we like.
>          con: doesn't work in legacy UAs at all.
>
>       H: pro: makes the language simpler.
>          con: lists are relatively common and so this would affect  
> a lot
>               of authors.
>
>  4. Put forward relevant data, for instance the relative frequency  
> of use
>     of <ol> vs <ul> in today's pages.
>
> The _wrong_ way would be to exclaim shock and horror at the lack of  
> the
> <ol> element, and insit it be put back in immediately.
>
> Notice that it is *blatently obvious* (to me at least) that we  
> should just
> keep using the <ol> element. Yet I still managed to come up with  
> half a
> dozen other possible solutions, and listed pros and cons for each one.

Well, I'm curious how we proceed from here. If I put on my objective  
hat, <ol> is no more "blatantly obvious" that it be included than  
anything else (already included, proposed or waiting to be proposed).  
If I look at the list of pros and cons, I still don't see "blatantly  
obvious" either. There do seem to be multiple possible approaches one  
might take. Incidentally my opinion and what I would advocate for  
would be <ol>, but acting objectively I could definitely understand a  
different approach.

>> My presumption has been that when facilities of HTML 4.01 have been
>> dropped that there's a new best practice approach that will be  
>> promoted
>> for authors.
>
> To be honest I really haven't been approaching HTML5 as a revision of
> HTML4. If something is in HTML4 but not in the current draft of  
> HTML5, it
> could just be that I haven't looked at the relevant problem yet, or  
> that
> when I looked at the problem the spec seemed to handle the 80%  
> cases well
> enoguh.

That is good to hear. Many members here have taken a very defensive  
posture, often assuming that the HTML5 spec is done (e.g., what is  
missing from the current draft is considered dropped from HTML5 as  
opposed to not yet address as it may be in some cases). I've said  
this elsewhere, but I think its a mistake to publish the differences  
with HTML4.01 document when it may just be certain aspects have not  
been addressed. Similarly, the idea that ruby markup will be part of  
HTML5 should be included in that document when we are ready to  
publish since that's a significant difference with HTML4. Rushing the  
differences document out the door will create a bad first impression  
of our work here at the HTML WG.

> For example, the last time I looked at <table> markup in detail,
> my research suggested that scope="" handled the 80% case fine and  
> thus we
> didn't need anything else (axis, headers, whatever). I look forward to
> studying this again in light of the thorough research that has been  
> done
> since then.

I would think scope="" would handle much more than 80% of cases.  
However, how could handling 80% or even more mean that we don't need  
anything else (0ther than scope="")? Again, with my objective hat on  
I have to conclude that different members of the WG will come to  
different conclusions about what to include in the language. Some may  
suggest that maybe only a 5% use case might warrant including the  
facilities in the language Or 15%. Even if its as high as 20%, it may  
currently get used by authors on only 1% of documents on the internet  
and 3% of documents on intranets. It may be supported by 10% of  
browsers, but 12% of all UAs (by implementation count). So its hard  
to imagine what statistical research we might do that would provide  
evidence of a need for certain facilities. In scientific fields we  
usually try to layout in advance what statistical criteria we think  
needs to be met. Given the difficulty (maybe impossibility in this  
case) with gathering data scientifically the emphasis on doing so  
might be overstated.

>> If this is the case, I would expect my advocacy for things such as
>> retaining @summary attribute might not be appropriate. However, as a
>> member of the WG I would think there would be some way for me to  
>> learn
>> what the alternative to @summary would be (in other words an  
>> attribute
>> or element for describing a table in a way that only someone with a
>> visual impairment would benefit from; after all, some tables speak  
>> for
>> themselves visually which is why a table might be selected for its
>> rhetorical effect).
>
> Well, create a wiki page, and work through the issue.
>
> What's the problem that summary="" is trying to solve? (I actually  
> don't
> really know.)
>
> What ways are there to solve this problem? If the problem is  
> "people use
> <table>s for layout and we need to have a way to tell blind users  
> that the
> tbale structure is irrelevant" then there are other ways to solve  
> it, for
> example making layout <table>s illegal and requiring CSS be used  
> for that
> instead, or adding an attribute that ATs can use to simply ignore the
> table structure without ever telling the user there was a table. If  
> the
> problem is that tables are horrendously complicated and that users  
> need an
> introduction to the structure each time, then one disadvantage of the
> summary="" attribute is that since most users don't see it, it is  
> likely
> that the description will be either missing or wrong. Relevant data  
> would
> be the study of common summary="" attribute text which was posted  
> to this
> list a few weeks ago. And so forth.

Well the @summary example was just a hypothetical one in order to  
understand how this should  be handled generally. Again however I  
don't see how a non-scientific statistical analysis of some data a  
member collected will tell us anything about how to develop the HTML5  
language. If we could actually perform scientific statistical  
analysis (with a budget to go along with it) we might be on to  
something. Yet still, I'm not so sure what we would learn through  
such large expenditures. We know that accessibility features are  
seldom used. When they are used they're often used incorrectly. Those  
who need them cannot consume content without them. If we could pin  
this down to exact percentages I'm not sure what we would gain.

Also, with those facts we could produce a problem assessment, and a  
list of solutions with some pros and cons.

Problem: Data tables are frequently used to make a dramatic point  
visually to the reader. For example, shading or color may fill vast  
parts of the table allowing a quick glance to see how pervasive is  
the correlation between the two axes of the table. For vision- 
impaired users this may not be obvious ever or without a significant  
expenditure of time and effort spent as the user navigates through  
cells and headers to "discover" the obvious visual point of the table.

Solutions:
@summary attribute on <table>
	pro: works in existing implementations
	con: provides no rich semantic text support
<summary> element in <table>
	con: does not work in existing implementations without added CSS  
(perhaps not even then)
	pro: provides rich semantic text
	pro: could be made to work in updated implementations fairly easily
add lengthy text to <caption> intended only for screen reader use
	pro: works in existing implementations
	pro: provides a single solution to sighted and vision-impaired users
	con: provides a single solution to sighted and vision-impaired users  
(i.e., the sighted users need to read through potentially lengthy  
text that to learn it merely says what a glance at the table has  
already told them)
provide no facility for vision impaired users to easily comprehend  
(or comprehend at all) the rhetorical effect of a table
	pro: works in existing implementations
	con: deprecates language features used frequently by some authors  
and users
	con: authors will provide disparate poorly interoperable solutions  
for what HTML5 leaves out

Again, I'm just putting this together as a hypothetical. I hope I'm  
approaching this correctly. I would imagine that others may think of  
other pros or cons. Would it make sense to simply post this to the  
email list and then add it to the wiki? The no-original-research rule  
seems very out-of-place here (though I can definitely understand the  
desire to link to emails or threads of emails discussing the issue).

In terms of statistical research it seems important to say in advance  
what statistical magic bullet we're looking for. Again with my  
objective hat on, I can't think of what statistics would convince one  
way or the other whether a feature belonged in the language (given  
the above pros and cons and solutions). The statistics (again non- 
scientific statistics) might be useful trivia, but I do not see how  
they provide useful information to make a decision about the language  
features and the like. Even the facts presented without statistics  
(those perhaps we can stipulate without much disagreement) do give us  
the answer on what the language could support. We could throw up our  
hands and say that given how indifferent the majority of authors and  
implementors are to the needs of these users we should just give up  
and not even encourage authors to make use of these facilities. Or we  
could conclude that the spec needs to have a chapter devoted to this  
(or these) facilities so that implementations and authors will begin  
to take this more seriously. So again, I'm wondering how we get from  
this to the "blatantly obvious" solution.

Well, I'll stop with that. In summary, I think the email  
conversations can and should be much more useful in preparing to  
write about the pros and cons of an issue. However, I don't think  
that its necessarily the case that we should have to begin on email  
before taking it to the wiki (though I understand that's the rule  
you've laid out). I think we could just as easily (or maybe even more  
easily) begin with a complete formal wiki article and then discuss  
the wiki on the email list and add to the article through the wiki  
process. Perhaps by dropping that rule (the NOR rule), we'd see more  
of these conversations begin on wiki (though we might see some  
negligence in updating the relevant email discussion on the wiki).  
This would address your concerns that the wiki articles are not being  
drafted soon enough. For example, the review tasks we've assigned  
ourselves could begin on the wiki with just a short message to the  
list inviting comment and constructive editing. The initial reviewer  
could be responsible for ensuring the relevant email discussion  
threads (e.g.., the subject headings) were added to the article

Take care,
Rob

Received on Thursday, 28 June 2007 00:35:01 UTC