- From: Robert Burns <rob@robburns.com>
- Date: Wed, 27 Jun 2007 19:34:51 -0500
- To: HTML WG <public-html@w3.org>, Ian Hickson <ian@hixie.ch>
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