63574 - Add two CSS list styles (widely used in Korea)

Status: VERIFIED FIXED

(Core :: CSS Parsing and Computation, enhancement, P1)

Description

[Jungshik Shin]

Mozilla has a lot of additional list styles not yet
standardized in CSS2/CSS3 but widely used in certain
locales(and hopefully incorporated into CSS3).
However, it doesn't have two list styles
frequently used in Korea. The patch I'm gonna attach
adds two list styles , HANGUL and HANGUL_CONSONANT.
The first style is enumerating 14 Hangul syllables made of
14 basic consonants of modern Korean combined with
the first Korean vowel. The second style is enumerating
14 basic consonants of modern Korean.

Comment 1

[Jungshik Shin]

Attachment: patch to add two list styles used in Korea

Comment 2

[Katsuhiko Momoi]

CC'ing pierre and ftang who have checked in additional CSS
list-styles before.

Comment 3

[Jungshik Shin]

There's a typo in my patch. Line 50 of the second patch file should
read
   + #define HANGUL_CONSONANT_CHARS_SIZE 14
instead of
   + #define HANGUL_COSONANT_CHARS_SIZE 14
Consequently this chnage has to be made before applying it. I also
put up a test page at the URL above.

Comment 4

[Jungshik Shin]

My slow intel box has just finished compiling mozilla with the________
   patch above. It rendered the page at the URL above as intended.

Comment 5

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

There are at least 2 problems with the patch:
 * some of the diffs look like they remove somebody else's recent changes
 * properties/values not defined by a CSS spec should use the -moz- prefix.
This was a mistake made in the previous set of extra list-style-types and should
also be corrected for those.

Assigning to pierre to get this off clayton's list.

Comment 6

[Jungshik Shin]

Attachment: a new patch to fix two problems raised by [e-mail]

Comment 7

[Jungshik Shin]

I caught the first problem right after sending my patch (it waw due to
that I worked on an out-of-date source tree while running 'cvs diff')
and I thought
I sent another patch without the problem, but apparently it didn't
make it to Bugzilla (there was a little problem with bugzilla, then).

Anyway, I've just sent a new patch that takes care of
both problems (as for the second problem, I added -moz/_moz prefix
for CSS list style names/variables and MOZ_ for constants for 
all non-standard list style types). 

It got compiled fine and the binary thus obtained
renders the URL above as intended.

Comment 8

[Jungshik Shin]

I'm attaching a new patch to 1) add two List style to and 2) make the name
of non-standard list-style have -moz prefix 
in apparently newly created content/html/style/src

Comment 9

[Jungshik Shin]

Attachment: a patch to make files in content/html/style/src in line with layout module

Comment 10

[Hixie (not reading bugmail)]

Should we have someone who knows Hangul review the two new list styles?
Other than that, the patch looks ok to me. We need moa= from Pierre and sr=
from Marc, though.

Pierre, Marc, could you have a look at the patch? Thanks...

Comment 11

[Jungshik Shin]

 Thanks a lot for taking a look at my patch.

> Should we have someone who knows Hangul review the two new list styles?

Wouldn't  15 years' education (thru college) and 2-yr military service
in Korea be enough to be sure about this?  :-)   Two styles are also
available in HLaTeX (Hangul LaTeX). Of course, anybody is welcome to
review two styles.

BTW, not just for two new styles used in Korea I added but also for
any style for which a circled variant exists and circled letters are
given separate code points in Unicode (e.g. circleed Hangul Syllable Ka,
circled Hangl Syllable Na, etc), do we have to implement them as
separate styles? We should NOT if we live in a perfect world where
Unicode 'combining character' mechanism (that is, circled 'something'
can be rendered as such when they're encoded as two
'characters' of 'circle the following letter' + 'the letter', or is it
the other way around? I forgot the order)  universally works.
Other variants like '( something )'  don't have this problem.
I'm inclined to think that we should NOT implement a 'circled variant'
as a separate style even if what I wrote above about 'comining
character mechanism' is the case.

 Jungshik Shin

Comment 12

[Katsuhiko Momoi]

Attachment: A test case for 2 Hangul and Hangul-Consonant list styles. View the HTML page with Mozilla builds to see if the list items appear correctly.

Comment 13

[Katsuhiko Momoi]

Attachment: Use the revised test case for hangul (-moz-hangul) and hangul-consonant (-moz-hangul-consonant) as these are not defined in CSS documents yet.

Comment 14

[Katsuhiko Momoi]

When the fix is checked in, you can use the 2nd revised test case with
-moz ... prefix to see how the list items appear for 2 styles.

The test case has only 10 items for each list style. 
I guess you should add 4 more to make them 14.
CC'ing blee. Bom-shik, please check this out when fixed
yourself or assign it to someone who knows Korean.

Comment 15

[Jungshik Shin]

The URL given above(in the URL field) also has a test case
with 14 <LI>s.

Comment 16

[Marc Attinasi]

The patches look fine. I am a small bit concerned about changing the property
names of the previous list styles since there may be existing content that uses
those names and it will not work after this change. However, since it was
originally wrong, I guess it is best, but we must be sure to notify people of
the change via a posting to the appropriate newsgroups I think.

sr=[e-mail]

Comment 17

[Hixie (not reading bugmail)]

Jungshik Shin: Don't worry, I was not at all doubting your competence, just 
saying that we should make sure at least two people who understand the list
styles' language should check it is right, just like with any other change. :-)

I suggest that whoever verifies this bug makes sure it also makes sense with
more than 14 list items.

Assigning blee as QA contact. (ChrisP: I assume you don't speak Korean, if you 
do then of course feel free to take QA back!)

Comment 18

[Jungshik Shin]

Ian,

I wasn't serious when I wrote '...15 yrs' education.....'. Perhaps, I should
have used triple smilies instead of just one :-).

Anyway, your concern about more than 14 items is worth thinking about. Actually,
I thought about it when I submitted the patch for the first time. It's not
clear what Korean convention is. I may have seen  once or 
twice such a long itemized list using 'Hangul-consonant'. I don't remember
exactly what they used. Using 'consonant-doublet' is most natural, but ....

   This specification does not define how alphabetic systems wrap at the
   end of the alphabet. For instance, after 26 list items, 'lower-latin'
   rendering is undefined. Therefore, for long lists, we recommend that
   authors specify true numbers.

   This specification does not define how alphabetic systems wrap at the
   end of the alphabet. For instance, after 26 list items, 'lower-latin'
   rendering is undefined. Therefore, for long lists, we recommend that
   authors specify true numbers.
 
In case of Hangul-syllable, it's even more unclear. Korean car license plates
use this style and in place of 1st vowel, 3rd,5th,7th,9th vowels of Korean 
alphabets are combined to 14 consonants to form a sequence following
the first 14 (which are formed by combining 14 consonants with
the 1st vowel in Korean alphabet). Hmm, now I'm wondering what they use
nowadays because even consonant+9th vowel may have been used up by now in Seoul.
(each province uses separate numbering).

Hangul LaTeX just gave an error message when either of these
style is used and more than 14 items are given.

BTW, W3C CSS2 spec. has the following:

   This specification does not define how alphabetic systems wrap at the
   end of the alphabet. For instance, after 26 list items, 'lower-latin'
   rendering is undefined. Therefore, for long lists, we recommend that
   authors specify true numbers.


   

Comment 19

[blee]

changing QA to andreasb for now.

Comment 20

[Andreas Becker]

Changing QA contact to teruko for now.

Comment 21

[Jungshik Shin]

Attachment: a new patch to reflect mozilla src dir. shuffling

Comment 22

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Sorry this has been neglected for so long.  Could you post a diff with the -u
option?  Given that I should have time to get it reviewed and checked in (since
pierre doesn't seem to right now...).

Comment 23

[Jungshik Shin]

Attachment: a new patch (diff -u) against the current CVS repository

Comment 24

[Jungshik Shin]

Hi David,

Thank you for your attention to this. I hope this time my patch
will make it :-)

Comment 25

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

r=dbaron

Comment 26

[Marc Attinasi]

sr=attinasi

Comment 27

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Assigning to myself so I remember to check it in.

Comment 28

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Checked in 2001-07-03 19:05 PDT.

Comment 29

[Frank Tang]

> * properties/values not defined by a CSS spec should use the -moz- prefix.
why ? Any CSS spec said we cannot use without -moz- ?

Comment 30

[Frank Tang]

I trust [e-mail] (Jungshik Shin's knowlege about korean since he 
is the author/maintainer of  Hangul and Internet in Korea FAQ 
http://pantheon.cis.yale.edu/~jshin/faq/index-orig.html and have work with us 
for more than 5 years (since Netscaep 2.0)

Comment 31

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

> > * properties/values not defined by a CSS spec should use the -moz- prefix.
> why ? Any CSS spec said we cannot use without -moz- ?

It's a namespace pollution problem.  The CSS WG agreed that vendor extensions 
should begin with -{vnd}- (e.g., -moz-, -opera-, etc.).  This should be 
formally stated in CSS3.

Comment 32

[Teruko Kobayashi]

I tested this in 7-27 0.9.2 Win32 and 7-26 0.9.2 Mac build and 7-16 Mac trunk 
build.  I do not see any hangul name as list.  I see only numbers.
I reopen this.

Comment 33

[Jungshik Shin]

Linux 2001-07-29 works fine. So does M0.9.3 under Windows 2000.
What version did you test?  If it's 0.9.2(released in late June), it's
natural that it doesn't work because 0.9.2 predated the check-in of my
patch (which was on July 3rd)

Comment 34

[Katsuhiko Momoi]

It's Ok on the recent trunk build (0.9.4), e.g. 8/6 Win32 build.

But this is broken on the final 0.9.3 build. That means, it
will be broken on Netscape 6.1 final release also when it
comes out. It should be broken on Mozilla 0.9.3 final release.

Comment 35

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Don't you mean broken on 0.9.2, which is what Netscape 6.1 was based on?  Note 
that the target milestone of this bug is 0.9.3.

This should work in the 0.9.3 release, but not the 0.9.2 release or any of the 
continuation of the 0.9.2 branch.  If you really think this should be added to 
the 0.9.2 branch at this stage, please reopen again, but I have to say I don't 
see any reason to push it onto the 0.9.2 branch.

Comment 36

[Teruko Kobayashi]

I verified this in 8-07 0.9.3 and 8-10-08 Trunk build.