- From: Ian Hickson <ian@hixie.ch>
- Date: Wed, 27 Jun 2007 22:23:45 +0000 (UTC)
- To: Robert Burns <rob@robburns.com>
- Cc: public-html@w3.org
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