Closed Bug 63574 Opened 24 years ago Closed 23 years ago

Add two CSS list styles (widely used in Korea)

Categories

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

Product:
Core
Component:
CSS Parsing and Computation
Type:
enhancement

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla0.9.3

People

(Reporter: jshin, Assigned: dbaron)

References

(
URL
)

Details

(Keywords: css-moz, css3, intl, Whiteboard: (py8ieh: propose new list styles to WG))

Attachments

(7 files)

patch to add two list styles used in Korea
5.85 KB, patch
Details | Diff | Splinter Review
a new patch to fix two problems raised by dbaron@fas.harvard.edu
29.49 KB, patch
Details | Diff | Splinter Review
a patch to make files in content/html/style/src in line with layout module
8.68 KB, patch
Details | Diff | Splinter Review
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.
1.22 KB, text/html
Details
Use the revised test case for hangul (-moz-hangul) and hangul-consonant (-moz-hangul-consonant) as these are not defined in CSS documents yet.
1.23 KB, text/html
Details
a new patch to reflect mozilla src dir. shuffling
17.01 KB, patch
Details | Diff | Splinter Review
a new patch (diff -u) against the current CVS repository
22.97 KB, patch
Details | Diff | Splinter Review 
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.
Keywords: intl
CC'ing pierre and ftang who have checked in additional CSS
list-styles before.
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.
URL: http://www.jshin.net/~jungshik/moz/ha...
My slow intel box has just finished compiling mozilla with the________
   patch above. It rendered the page at the URL above as intended.
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.
Assignee: clayton → pierre
Component: Layout → Style System
Keywords: css-moz, css3
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.
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

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...
Keywords: patch
Whiteboard: (py8ieh: propose new list styles to WG)
 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
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.
The URL given above(in the URL field) also has a test case
with 14 <LI>s.
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=attinasi@netscape.com
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!)
QA Contact: petersen → blee
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.


   
changing QA to andreasb for now.
QA Contact: blee → andreasb
Changing QA contact to teruko for now.
QA Contact: andreasb → teruko
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...).
Hi David,

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


sr=attinasi
Assigning to myself so I remember to check it in.
Assignee: pierre → dbaron
Priority: -- → P1
Target Milestone: --- → mozilla0.9.3
Checked in 2001-07-03 19:05 PDT.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
> * properties/values not defined by a CSS spec should use the -moz- prefix.
why ? Any CSS spec said we cannot use without -moz- ?

I trust jshin@pantheon.yale.edu (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)
> > * 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.

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.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
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)
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.
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.
Status: REOPENED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → FIXED
I verified this in 8-07 0.9.3 and 8-10-08 Trunk build.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: