Re: How to productively contribute

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.


> > 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.
> 
> 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.

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.


> By extension wouldn't this mean that this entire WG exercise is 
> unnecessary. The draft editors will already anticipate our proposals 
> before we make them.

It always helps to have many eyes. I'm sure if we put the <ol> exercise 
above to everyone in this working group, each person would come up with 
their own set of pros and cons and their own set of possible solutions. 
Maybe in fact <ol> *isn't*, on balance, the best solution to lists in 
HTML5, and maybe someone will come up with a brilliant idea that is so 
great that we should use it. With only two editors, we have much less of a 
chance of coming across such ideas. Also, I make a lot of mistakes. If it 
wasn't for people pointing out all the ways that I have made mistakes in 
the HTML5 spec over the years, the spec would be much, much worse.


> In any event, when we advocate for adding a new attribute or element (or 
> retaining an element or attribute from 4.01) as an author conforming / 
> best practice part of the language that is not a part of the current 
> draft, should we simply try to list the disadvantages as we see it 
> (sometimes a null list) and not try to understand or imagine the reasons 
> for deprecating those features? Would it be acceptable to just cite the 
> draft as the opposing side approach? How would the editors respond to 
> such a wiki article?

You shouldn't advocate adding a new attribute or element. You should put 
forward some problems that you see in the draft, and, independently, some 
suggested solutions, and then list the various pros and cons of each 
solution, as well as relevant data, etc. Don't become attached to a 
particular solution.


> 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. 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.


> 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.



> > In any case, if it turns out that you indeed are so blinded by you 
> > opinions that you can't do an objective job, I'm sure other people in 
> > the working group will balance out the wiki page for that set of use 
> > cases and it'll be neutral in the end. So just pretend you're neutral 
> > and go ahead.
> 
> I do not think anyone sincerely bringing up issues on the email list (in 
> order to begin to understand the thinking that went into the current 
> draft) should be accused of being "blinded by your opinions".

I wasn't accusing anyone of anything, indeed everything in my e-mail up to 
that point was assuming that people could easily be objective. I was just 
covering all the bases in case someone _was_ so blinded.


> Those are useful guidelines. However, you're using the term "objective" 
> in a way I've never heard before. Perhaps you could say more about how 
> you understand the term.

Uninfluenced by emotions or personal prejudices; basing one's 
argumentation on observable phenomena; presenting one's reports factually, 
remaining fair and disinterested.


> For example, I would imagine for any assessment of needs for the HTML5 
> language there could be several alternative approaches to address it: 
> each with its own advantages and disadvantages. There will not be a 
> simple or sole answer that addresses any identified need. To me being 
> objective requires acknowledging this and then understanding that each 
> of us will have a different assessment of any of these proposals.

Indeed. I would go further and say that even better would be an approach 
where you attempt to come up with multiple solutions yourself, rather than 
relying on each person in the group to come up with one solution.


> As an example, I have suggested that HTML5 add a <picture> element or 
> something like that which parallels the other newly added embedded 
> content elements, but particularly for still picture images. This would 
> mean that in a distant future an author using HTML5 or its successor 
> could have easily and simply embed a still image into a document and 
> still have a smple fallback content approach as with <audio> and 
> <video>. Bets practice would be to use <picture> instead of <ig> when 
> the targeted browsers all provided support for <picture>.

Presumably then, when you write up the wiki page for the relevant problem, 
you will describe how the problem is addressed by <picture>, as well as 
how <img> addresses it, how <object> addresses it, how each one has pros 
and cons (e.g. pro: <img> works in browsers today, con: <object> is poorly 
implemented, though hopefully going into more detail), and so forth.


> My hope is that I could clearly understand the objection of others 
> before I write a wiki page on this issue.

If you don't understand the points put forward by other people, then just 
write what you do understand, link to _all_ the relevant e-mails, and ask 
the other participants in the discussion to write up their observations. 

I recommend against considering them "opinions" or "objections". I, for 
instance, will often point out problems that I see in proposals even if I 
agree with them. It is important to consider all the pros and cons of all 
proposals. It is even more important to consider proposals in terms of how 
they address underlying problems.

HTH,
-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Wednesday, 27 June 2007 22:24:19 UTC