W3C home > Mailing lists > Public > public-html-bugzilla@w3.org > October 2010

[Bug 10807] i18n comment 1 : new attribute: ubi

From: <bugzilla@jessica.w3.org>
Date: Mon, 18 Oct 2010 13:24:55 +0000
To: public-html-bugzilla@w3.org
Message-Id: <E1P7phv-0001ro-S3@jessica.w3.org>
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10807

--- Comment #15 from Aharon Lanin <aharon.lists.lanin@gmail.com> 2010-10-18 13:24:55 UTC ---
(In reply to comment #14)
> (In reply to comment #13)
> > It seems to me that the use cases described in this bug can be most easily
> > addressed as follows:
> > 
> > 1. Add an 'auto' value for the CSS 'direction' property that determines the
> > direction in a suitably automatic way.
> > 
> > 2. Recommend that authors use the <output> element to mark up information from
> > users, and make <output> default to 'direction:auto'. This element defaults to
> > unicode-bidi:isolate.
> > 
> > So for a place name, you'd write:
> > 
> >    <output>Purple Pizza</output> - <a href="ppreviews.html">3 reviews</a>
> > 
> > If you knew the direction, e.g. a phone number, you could write:
> > 
> >    <output dir=ltr>+1 555 123 4567</output>
> > 
> > Are there any use cases that this would not address?
> 
> I have several problems with this solution.
> 
> 1. It is not correct to characterize all or even most content that needs
> isolation (and/or auto-direction) as "user-provided" or as the "output of a
> calculation" or in any way associated with forms (which the output element
> seems to be). For example, let's say I am just authoring a simple HTML document
> in an RTL language, and want to list a few of my favorite bands, e.g. "I LIKE
> a, b, AND c." If I do not use isolation on a, b, and c, this will be displayed
> as:
> 
> .c DNA ,a, b EKIL I
> 
> instead of the intended
> 
> .c DNA ,b ,a EKIL I
> 
> This can be solved by using &rlm; ("a&rlm;, b&rlm;, AND c"), but this is ugly
> and has other problems.
> 
> What I really want to do is bidi-isolate each of a, b, and c even though they
> are not user-provided or calculated, and I have no form in my page.
> 
> For a different example take a web app, e.g. a search app. None of the things
> that need isolation in each search result - the title, the snippet, the
> filename, the size - is generated by the app's user, and there is no
> association with a form. In a sense, they are calculated, but not in the way
> intended for the output element.
> 
> In brief, I do not think that the output element is a good fit for most use
> cases - although having isolation on for output element by default (in addition
> to a more general solution) is probably a good idea.
> 
> 2. It is quite a common occurrence that the item needing isolation is already
> wrapped in an element like <a> or <q> or <span> (or <output>). In fact, if <a>
> and <q> were being invented today, we would want isolation for them by default
> - but we dare not do that now because it would most certainly break some
> existing documents. But having to wrap such items in *two* elements, e.g.
> <a><ubi>BLAH BLAH</ubi></a> - or is it <ubi><a>BLAH BLAH></a></ubi>, is surely
> rubbing salt in the wounds. An attribute with a short name and no need to
> specify a value is a lot less painless to use.
> 
> 3. As far as I understand, adding an "auto" value to the CSS direction property
> is a non-starter. Fantasai should be able to provide more details. For this
> reason, I am also reopening bug 10808.
> 
> 
> Let's deal with the auto-direction issue separately in bug 10808, which I am
> re-opening for reasons described there.
> 
> Basically, you are saying that isolation will be provided by the <output>
> element.

Sorry, I had intended to delete the last two paragraphs of this comment ("Let's
deal ..." and "Basically..."); please disregard them.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
Received on Monday, 18 October 2010 13:24:57 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 16:30:59 UTC