- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Mon, 19 Mar 2012 16:42:55 -0700
- To: public-i18n-bidi@w3.org
On 03/19/2012 04:24 PM, Eric Muller wrote: > I agree with fantasai that CSS needs to pick one way. Otherwise, different implementations could end up displaying characters > in different orders, certainly something that compromises the interchange of text. > > I also think that from the point of view of users, either way would be acceptable. I suspect that very few users will be able > to make sense of a mixture of CSS controls and character controls, regardless of what CSS specifies. The only practical option > for most users will be to enter something, see what comes out of an implementation, and tweak their input as needed to get the > visual ordering they want. > > From the point of view of specification and logical consistency of the system, I would prefer to see bidi control characters > reopened. This would make > > ...<span style='dir:ltr; unicode-bidi:embed'>...</span>... > > and > > ... ‪ ... ‬ ... > > equivalent (whenever the <span> is well formed). One benefit of the equivalence is that it is possible to transform the first > form to the second in a step in a pipeline of HTML processing. With the current definition, this transformation step cannot > happen independently of the reopening step (or more precisely, it has to occur after a transformation that has the effect of > reopening). I used to think that, too. But the problem is that that would be inconsistent with the way plaintext works. Right now the end of the paragraph is basically infinite PDFs. If we transform a piece of plaintext to HTML via <pre>, it should continue to behave the same way; introducing smart re-opening would break that. You get consistent, sensical behavior as long as you use one or the other. It's only when you mix them that things get weird. And in that case, the best behavior depends on exactly what your input is and how you've done the transformation to HTML. ~fantasai
Received on Monday, 19 March 2012 23:43:26 UTC