W3C home > Mailing lists > Public > public-html@w3.org > August 2007

Re: authoring @lang and @dir (was 3.6. The root element)

From: Robert Burns <rob@robburns.com>
Date: Tue, 7 Aug 2007 15:19:58 -0500
Message-Id: <B9583A0E-B598-4B72-94CA-739BD6D5ED06@robburns.com>
Cc: Sander Tekelenburg <st@isoc.nl>, public-html@w3.org
To: Maciej Stachowiak <mjs@apple.com>

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,

[1]: <http://lists.w3.org/Archives/Public/public-html/2007Jul/1266.html>
Received on Tuesday, 7 August 2007 20:20:50 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:25 UTC