Re: [css3-text] Splitting CSS Text into Level 3 and Level 4

2011/12/14 Florian Rivoal <florianr@opera.com>:
> On Wed, 14 Dec 2011 13:54:37 +0100, MURATA Makoto <eb2m-mrt@asahi-net.or.jp>
> wrote:
>
>> 2011/12/13 Håkon Wium Lie <howcome@opera.com>:
>>>
>>> Koji Ishii wrote:
>>>
>>>  > I see defining some i18n values first and then try to look for
>>>  > general @rule in future is a good incremental approach. But if the
>>>  > WG sees it differently and resolves not to include values that are
>>>  > only used in some scripts, it's very unfortunate for me, but
>>>  > deferring full-size-kana looks better way than defining
>>>  > @text-transform without taking enough time to think about it.
>>>
>>> I'd rather not define script-specific values without a generic
>>> mechanism -- it will lead to difficult discussions about which scripts
>>> should be prioritized and why. But I think it's possible to define
>>> @text-transform within a reasonable time -- this could be a win-win
>>> scenario.
>>
>>
>> Although your desire for a universal solution is very sensible, I
>> do not think that such a solution can be invented without creating
>> and using ad-hoc solutions first.
>
>
> I don't think we can create a (good) generic solution without
> considering the individual use cases it is trying to solve, and
> see if it solves them well. But I disagree that we have to solve
> (ie. spec, write tests for, implement, ship..) these use cases
> individually first to be able to create the generic solution.
>
>
>> I am also worried about universal-but-hard-to-use solutions.
>> For example, some subset of sed or perl would be a very
>> universal solution.  But isn't such a subset overkill?  Hard
>> to use and hard to implement?
>
>
> I don't believe the solution I am proposing will be that hard.
> But that is also why I have started making a draft for it. After
> working on it for a little while, if our conclusion is that it
> is too complicated and is a bad solution, then maybe it should
> be abandoned. But I don't think it will be that hard to use.

If grapheme clusters, word boundaries, and Unicode normalizations are
incorporated, the result will be very complicated.  Note that Unicode
regular expressions Level 1 (Unicode Technical Standard #18) significantly
simplifies grapheme clusters and word boundaries.

The smallest generic solution is one-to-one mapping of UCS code values.
I would be a small subset of your "convert".  I think that it would be
very appropriate as Level 1 of text transformation.


Regards,

Makoto

Received on Wednesday, 14 December 2011 13:49:03 UTC