[EMAIL PROTECTED] wrote:
> On 5 elo, 22:43, Masayuki Nakano <[EMAIL PROTECTED]> wrote:
>
>>> 4. DEGREE SIGN is not breakable if after character is character class. But
>>> it's
>>> still breakable if after character is numeric, for compatibility.
>
> Could you give an example where it was actually helpful to allow a
> degree sign to break if followed by a numeric character? I'd rather
> not allow any odd line breaks if it wasn't clear what the benefits
> were, even if we weren't able to come by any examples where it could
> cause confusion. Just that we haven't thought about it here doesn't
> prove that it can't occur in some more or less specific situation in
> some natural or non-natural language.
>
> Actually, each example where an unconventional line break improves the
> typographical appearance is also an example where it may cause
> confusion, since for a Western reader it's kind of natural to assume a
> space there. The same goes for allowing breaks at curly backets,
> semicolons etc. Thus, for each exception, we should consider carefully
> whether the typographical benefits really overweight the danger of
> confusing some users.
>
> We should also keep in mind that the consistent line breaking
> principles in Latin scripts sometimes allowed characters to be used
> even in unconventional ways. For example, occasionally the company
> name Microsoft is written in sarcastic tone with '$' instead of 's':
> Micro$oft. In a similar fashion, a Finnish magazine called Voima
> ('Force') likes to replace the 'i' in its logo with '!': Vo!ma. The
> swapped characters look similar enough that the reader is assumed to
> be able to recognize the word even though there is basically a
> spelling error in it. Personally, I'm not a great fan of this kind of
> character swapping, but it could be considered unfortunate if an
> unexpected break destroyed the (supposedly clever) idea that the
> writer tried to express.
I think that it is important that we use similar rules with IE. Very
many table cells which width is auto are used in the websites of
transitional structure. If a table cell has long words, the min-width of
the cell depends on the width of most long word in it. So, the layout of
the pages depend on line-breaking rules.
If there are two or more cells which widths are auto in same row, the
compatibility depends on line-breaking rule (not defined in HTML/CSS
spec) *and* table layout algorithm (not defined in HTML/CSS spec).
So, we need to keep the compatibility with IE, it is so hard.
If we change the behavior from IE without actual bad example, it is risky.
*However*, the non-breaking behavior is same as the current release
builds (e.g., gecko1.8.1). So, there are no regressions even if I change
the all punctuations (expect some punctuations which is used in
URL/path) to *like-character* class.
It may be reasonable way for now.
I'll post new patch.
And I think that we should implement the prioritized line breaking in
Gecko2 or later. (I'm not able to work on it in Gecko1.9.)
>>> 5. The hyphen is not breakable if the text doesn't have character class, or
>>> next is numeric class. Therefore, we cannot break 2007-Aug-07
>
> Do you mean that the string '2007-Aug-07' is not breakable at all, or
> that it is breakable only before 'Aug'?
'2007-Aug-07' is not broken.
> Not breaking dates at all may be a good idea in itself, but I would
> consider it more important to allow at least some kind of breaks in
> long chemical names, such as '2-bromo-4,4-dichlorophenol'. It may be
> difficult to have it both ways.
yeah, we cannot analyze whether the current word is date or chemical
word. We cannot save both cases...
I have a question, should the chemical name be broken after '-'? If so,
we need to give up to save one case...
>> foo/bar
>> /foo2
>> /bar2/
>>
>> each separated words always have '/', and only '/' lines are not there.
>
> Yes, this looks good (or at least as good a compromise as is
> attainable). It is an important point that a break is not allowed
> before the _ending_ slash so that it cannot end up widowed on the next
> line.
Thanks, I don't want to change this behavior, because this rule matches
to our code, the implementation is simple.
--
Masayuki Nakano <[EMAIL PROTECTED]>
Manager, Internationalization, Mozilla Japan.
Personal Web Site (Written in Japanese): http://www.d-toybox.com/studio/
_______________________________________________
dev-tech-layout mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-layout
