- From: Robert Burns <rob@robburns.com>
- Date: Tue, 7 Aug 2007 15:19:58 -0500
- To: Maciej Stachowiak <mjs@apple.com>
- Cc: Sander Tekelenburg <st@isoc.nl>, public-html@w3.org
On Aug 7, 2007, at 2:51 PM, Maciej Stachowiak wrote: > > On Aug 7, 2007, at 11:02 AM, Robert Burns wrote: > >> >> On Aug 7, 2007, at 5:34 AM, Maciej Stachowiak wrote: >> >>> >>> On Aug 2, 2007, at 12:56 AM, Robert Burns wrote: >>> >>>> >>>> BTW, can you provide a use-case for setting @dir to the opposite >>>> value to what a particular script would usually have (i.e., >>>> setting @dir to 'ltr' for Arabic or Hebrew or 'rtl' for Latin or >>>> Cyrillic or the like). I cannot think of any use-case myself. >>>> >>> >>> I can't personally read any RTL scripts, so I can't tell you all >>> the details offhand. But things can get complicated when mixing >>> multiple scripts, and I imagine it is often useful to control >>> neutral text directionality separately. >>> >>> Here is a quick survey I did of a tiny handful of sites in >>> Hebrew, Arabic and Farsi: >>> >>> http://news.bbc.co.uk/hi/arabic/news/ - does not use the dir >>> attribute at all, so it currently gets the default of ltr >>> http://persianblog.com/home.php - does not use the dir attribute >>> at all, so it currently gets the default of ltr >>> http://www.google.co.il/ - explicitly sets dir=ltr around a div >>> that contains hebrew text >>> http://www.walla.co.il/ - does not use dir attribute at all, but >>> sets both "direction: ltr" and "direction: rtl" via CSS for >>> different elements >>> >>> These are some of the top sites in their respective languages, so >>> it's pretty clear to me that for compatibility with web content, >>> lang and dir must remain independent. >> >> >> I'm not sure who you're arguing Maciej. This is the second email >> you've posted about keeping @lang and @dir independent. No one has >> suggested collapsing them. > > You asked for a use case, I showed you how it's used in the wild. > You suggested that dir is redundant given lang, and I pointed out > it isn't. You asked for use cases for making dir something other > than the natural script direction, and I provided examples of real > sites using it. Maybe you could clarify what your own point is in > discussing dir and lang. No, those do not address the topic of this thread at all. Richard Ishida provided the use-case I asked for and I thanked him for it (related to tables that go in one direction and table cell going in the other direction). It seems that you're the one who feels the need to score points here. In my post above I point out a place where you are wrong (thinking @dir is only about neutral direction Unicode characters) and I pointed out a place where I was wrong (applying @dir to only block- level situations). How is that not accepting my own mistakes. > > In previous post, you said this: > > Robert Burns from a previous post: >> I'm not really sure what you're asking. But what I'm trying to say >> is that fully expressing a language using @lang or @xml:lang >> provides all of the information required to deduce the >> directionality. So to take just one of the examples I gave above: >> >> lang='iw-LATN'=> dir='LTR' >> >> In that case the @dir attribute is technically redundant. > > Was this meant to suggest a change to the spec, or simply an off- > topic musing? No, it was meant for all of us participating in the thread (and that means trying to read the thread in context) to understand the reasons we have these attributes and the reasons we may or may not want to require them on the root element (either one or the other attribute or both attributes). If you think that's an off-topic musing then I don't know how to interpret that. > By the way I have seen a number of interactions where you say > something seemingly incorrect, then object to people pointing it > out. You both claim they are needlessly argumentative, and deny > that you made the error they point out. This is a technical list, > we are not here to score points, but to make a high quality > technical specification. Flagging technical errors and > misunderstandings in comments on the spec is a critical part of > this process, as much as comments on the spec itself. Our goal here > is to determine facts, not prove how smart we are, and part of that > is being graceful in admitting error and handling criticism. So I > think your reactions to disagreement (such as telling Anne "you > don't have to respond to every post") are not constructive. What I've object to is the way errors are pointed out. And I've object to the way errors are pointed out to others too. Because the way errors are pointed out often times here does look like point- scoring. Rather than recognizing that someone may have made an error because of a problem with the draft. Certainly it is an interaction between the reader and the draft, but since we want this recommendation to be readable by a wider audience than has even gathered here, it should be taken as symptomatic of a problem with the draft. I understand that the drafters of this spec are here on the list and that these suggestions can sometimes seem like undue criticism, but my (and other's) interest is in improving the draft. I will say again, I think there is much great work in this draft. There are many improvements over the previous recommendations. Any criticisms I make of it are only intended to make it as good as we can make it. On the issue of telling Anne "you don't have to respond to every post"[1], that arose in a similar thread where the discussion was over the meaning in the draft. It wasn't clear to a reviewer nor to me. Anne replied several times in a defensive way that wasn't as helpful as it could have been. What I think was going on there in retrospect was that the draft was saying that the @xmlns attribute was to provide easier compatibility with authoring with an xmlns like text'html serialization.. The reviewer and I were both trying to understand what the draft said on the topic. Anne was intervening — seemingly to help out,. However, Anne also wanted to register his dissatisfaction with that part of the draft, but didn't make that clear. So the conversation went round and round as Anne seemed to say to me that the draft is saying X and then seemed to say that the draft is not saying X. However, I think what Anne was saying was that the draft says X, but Anned doesn't understand why we should bother saying X. This is my own surmising of what went on. I could be completely wrong. The point was Anne was very defensively saying: "Personally I'm not really sure how it can be made more clear.", when it was in serious need of clarification. I have been quite frustrated we these defensive posts and replied in an inappropriate manner. I'm sorry for that. What I meant to say, as I've said over and over, is that we should all think about how our posts will shape the discussion. That doesn't mean posting less, it doesn't mean posting smaller message. Some of you need to post much longer messages. It does no good to post some truncated thought that generates a flurry of misunderstanding across a dozen threads (an that has happened). Deciding not to clarify things only let's the flurry go on and on. And again, you responded here is proof that we need both the @lang and the @dir attributes, when I have repeatedly said that's not what the thread is discussing. How is that not an attempt at point- scoring. Three times now you have pointed out evidence for why we need separate attributes. Two of those times after I replied to tell you that was not the topic of the thread. > If you feel that your post itself was misunderstood, then of course > feel free to correct that, but we are now getting pretty far > removed from the spec. I think we now both agree that dir and lang > must remain independent in implementations and that both need to be > allowed in conforming content. I do not think we're getting far from the spec. These conversations help clarify things. We also trying to distill the important parts to the Wiki. Each of us can focus on the parts we find interesting, important and germane and trust that the wiki distillation process will work: meaning we don't have to read everything on the list. Take care, Rob [1]: <http://lists.w3.org/Archives/Public/public-html/2007Jul/1266.html>
Received on Tuesday, 7 August 2007 20:20:50 UTC