Skip to content

[css-ruby-1] Proportional or fullwidth parens? #762

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
r12a opened this issue Nov 25, 2016 · 8 comments
Closed

[css-ruby-1] Proportional or fullwidth parens? #762

r12a opened this issue Nov 25, 2016 · 8 comments
Labels
Closed Accepted by Editor Discretion css-ruby-1 Current Work i18n-clreq Chinese language enablement i18n-jlreq Japanese language enablement i18n-klreq Korean language enablement i18n-needs-resolution Issue the Internationalization Group has raised and looks for a response on.

Comments

@r12a
Copy link
Contributor

r12a commented Nov 25, 2016

A.3 Generating Parentheses
https://drafts.csswg.org/css-ruby-1/#default-parens

The CSS code in this section applies ordinary parens '(' and ')' to inline ruby annotations. Shouldn't they be fullwidth parens?

@r12a r12a added css-ruby-1 Current Work i18n-tracker Group bringing to attention of Internationalization, or tracked by i18n but not needing response. labels Nov 25, 2016
@kojiishi
Copy link
Contributor

kojiishi commented Dec 1, 2016

Agree it should be.

@frivoal
Copy link
Collaborator

frivoal commented Dec 1, 2016

Ruby is primarily meant for CJK, but it can be used for annotations in any languages, and only CJK uses full width parens. Should the selector be specialized by :lang() to use full width parens in CJK, and half width otherwise?

@kojiishi
Copy link
Contributor

kojiishi commented Dec 1, 2016

Why don't we default to CJK when the primary use is CJK?

@frivoal
Copy link
Collaborator

frivoal commented Dec 1, 2016

If we provide a switch, CJK is a finite set of language, while the rest isn't, is its easier to say
if (CJK) {...} else { ... } than it is to say
if (en, fr, de, no, it, ru, th, sv, ..................) {...} else { ... }, if you forgive my lousy pseudo code.

I don't think it would be too bad if we just applied the styles CJK wants for all languages, and let authors override that if they're using it for something else, but I thought that as the :lang() selector let's us express the difference, we might as well do so.

@r12a
Copy link
Contributor Author

r12a commented Dec 1, 2016

I believe that we shouldn't emphasise the idea that ruby markup/styling can be used for non CJ languages, since it's really designed specifically with those in mind (which is why it's called 'ruby' rather than 'glossing' or 'annotation') and it lacks features needed for general glossing.

Appendix A however is an odd beast. As i understand it, subsection A.1 is the default style sheet referred to in the heading of App A, but subsections A2 and A3 are really more akin to guides for content authors (not to mention the fact that they don't work for all markup). If i'm right, then it seems to me that it's best to use fullwidth parens for this example and we can leave it to the content author to adapt the code for other languages. (Note that the content author may also choose to use a different type of bracket altogether.)

Also, perhaps we should split Appendix A?

@upsuper
Copy link
Member

upsuper commented Dec 2, 2016

I agree that we shouldn't emphasize usage in non-CJK. Actually I believe ruby is more likely to be used on untagged / mistagged CJK content than any language else.

@frivoal
Copy link
Collaborator

frivoal commented Dec 2, 2016

Actually I believe ruby is more likely to be used on untagged / mistagged CJK content than any language else

Fair enough.

@r12a r12a added i18n-needs-resolution Issue the Internationalization Group has raised and looks for a response on. and removed i18n-tracker Group bringing to attention of Internationalization, or tracked by i18n but not needing response. labels Dec 8, 2016
fantasai added a commit that referenced this issue Feb 2, 2021
@frivoal frivoal closed this as completed Feb 2, 2021
@r12a
Copy link
Contributor Author

r12a commented Feb 5, 2021

Thanks for the edits. I'm satisfied with this resolution. I'll check that the i18n WG agrees, and unless there's an objection, we'll just close our tracker.

@xfq xfq added i18n-clreq Chinese language enablement i18n-jlreq Japanese language enablement i18n-klreq Korean language enablement labels Feb 6, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Closed Accepted by Editor Discretion css-ruby-1 Current Work i18n-clreq Chinese language enablement i18n-jlreq Japanese language enablement i18n-klreq Korean language enablement i18n-needs-resolution Issue the Internationalization Group has raised and looks for a response on.
Projects
None yet
Development

No branches or pull requests

6 participants