Implement (CSS) Ruby support in next PM

[Scrounger]

Hi everyone,

considering Fx has implemented very advanced Ruby support as of version 38 and was already the last major browser to do so, I would suggest for PM to implement the support for Ruby tags (Ruby annotations/characters) as well.

Now, I won't deny that there are add-ons that give us what we want anyway, but they all tend to be resource heavy and slow for something this basic. Many people complain of these add-ons crashing and slowing down the browser. In any case the developers have stated that the add-ons will no longer be developed for the obvious reason of Fx no longer needing the functionality, so I would like PM to follow suit here.

Here is the leading add-on for ruby support announcing the end of development: https://github.com/sakai135/htmlruby-firefox

This Fx article discusses the specifics of the ruby support implementation: https://hacks.mozilla.org/2015/03/ruby- ... dition-38/

Best regards, keep up the outstanding work.

[_Poke_]

A search for Ruby gives this thread, where MC finds that Firefox's Ruby implementation is a mess. Is that still the case? Your link is about v38 while this was tested in v39 nightly.
viewtopic.php?f=13&t=7630

If it's in a usable state, the next step is to find the bugzilla patches that made it happen.

[Scrounger]

Thanks Poke, did not search, I concede. I sincerely though that the Ruby implementation of Fx was sound. I have found the following bug, which seems to be the nexus of it all, though you might have to look around in the dependent bugs, also. https://bugzilla.mozilla.org/show_bug.cgi?id=33339

HTML Ruby is good, but it is officially dead, so native capability would be greatly appreciated.

[Moonchild]

"officially dead' of course being "I don't see a point in updating the extension if nobody will be using it".

What is the big deal with Ruby anyway? Why does this need to be in the browser core for a very small percentage of users that would actually make use of it?

[_Poke_]

The way it displays in Pale Moon unextended is probably fine for a casual user or small phrases, but Ruby is important for some languages.
I know for sure it's important for Japanese, especially for children/learners who can't read kanji yet. I'm not very familiar with the other East Asian languages but I think they can do similar things, perhaps with a romanised alphabet.

If HTML Ruby still works there's no reason to jump ship for the time being, but this is an important feature for some languages so it would be good to implement, even if it goes unnoticed by English only speakers.

Off-topic:
(I think last time I tried reading any Japanese with ruby was 2 or so years ago, so I got it baked into the site rather than using the Ruby tags you'd likely get today.)

[Moonchild]

The extension does exactly what is expected, from what I've seen. If people need extra functionality for educational purposes, then installing the extension will suit their needs, right?
maybe someone can even tickle the Ruby extension author to maintain it for Pale Moon - I'm sure our users would be grateful

EDIT: as an aside, in case people misread the blog post of Mozilla: the CSS ruby module is not implemented in Firefox (yet), either. It's in their bugtracker for a future release but even v41 won't have it.

[Axiomatic]

The extension does exactly what is expected, from what I've seen. If people need extra functionality for educational purposes, then installing the extension will suit their needs, right?

The extension provides really crude support; HTML ruby works for most cases, and uses. The most common use, I can think of is furigana used to explain kanji (something rather really simple, but massively used by beginners in Japanese). However it does not fully support the full ruby element specification so it really does not do what it would be expected to do at least from my view, which would be full support of the ruby element specification.

I think it would be a parity motive to integrate ruby annotations support in Pale Moon, however I also think since the case of usage is for the small few it can be put on the back burner. (Let Mozilla get it into their release builds, find bugs, patch bugs, and once all that is settled down then maybe port ruby element support to Pale Moon.)

Off-topic:
The ruby element is useful even for English only speakers, transliteration of non-English words on some sites use ruby annotations. Also sites that use reference to the international phonetic alphabet to teach pronunciation often use the ruby element.

[Moonchild]

A few questions here, then:

• What, exactly, is missing from HTMLRuby as far as the annotation element support is concerned? I looked at the "compelling example" page listed in the other thread and I didn't see anything missing from any language that would hinder the use of the element for indicated use.
• How much would it take to add missing features to the extension that are actually used in practice?
• Is the author of the extension approachable?
• How involved is porting ruby annotations from Firefox? Does it have many dependencies?
  I actually like the fact that HTMLRuby is a very manageable amount of JavaScript with no other dependencies or hooks, shifting ruby tag content with CSS to its desired place; It's an elegant solution and I'm afraid Mozilla's solution will somehow make it difficult to port by depending on refactoring and messing with the HTML parser. More information is needed.

[Scrounger]

Well, let me just clear up my own stakes. So I am a learner of the Japanese language and as such I need Ruby support that makes Furigana over japanese Kanji show up nicely. It's pretty much akin to the HTML Ruby addon.

I like the addon and I used it, but it's a memory hog as of its final release version and since then it's been suffering from Beta-syndrome (another example for the syndrome being 7-zip). The add-on will stay that way and while the author might agree to support the addon just for PM I do not think that would be likely. In your last post you sound like you want HTML ruby to become better and get more features?

MC, I am not even East Asian and I am needing this functionality. Please, just throw East Asians a bone here. PM would be the only browser with no Ruby Support, and there is literally nothing coming as everyone else, including Fx now has the support in the core. In't this simple enough to warrant being in the core? How on earth can this be a thing that's supposed to be done by addons? The browser is a parser-renderer for the Website code (as I see it) and this is where the rendering fails, because of missing support. And people who are anywhere near East Asia and even the other use examples that have now been talked about in this thread suggest to me, that this functionality is needed. If there is anything I would like the Furigana part to be implemented as that's the most widely accepted use case. Everything else can be talked about.

Furigana can be found everywhere in Japan-language websites, which is a country this browser should not leave out.

[Moonchild]

This doesn't answer any of my questions
Although it does answer 1, indirectly: that the extension provides the support needed.
I don't think it's a "memory hog", either, at least I have not seen anything to indicate that. The scripting is simplicity itself: check for ruby elements, and if found, restyle the elements to put the annotations above the tagged text. That should not and would not cause memory inflation.

By the way, Firefox 39 still does not align RTL script annotations properly, while the addon does.

[Moonchild]

Also, let me ask you a question: If every main-line browser were to have a feature in the core that hardly anyone uses or even knows about, you're saying that we should adopt it too?
If so, why? Just for the sake of an arms race who can bloat their core with the most features? For PR value?
What's the point in adding code and complexity to a browser core that can be provided JUST to those people who need it by way of extensions that are an essential and integral part of the browser? just because "browser x has it as well" -- which likely does not have this extensibility (or soon won't have)?

I'd much rather keep ruby an option just for the people who do need it - maybe make it easier to discover and install, but otherwise optional.

[squarefractal]

If so, why?

Because I can expect a browser to do its primary job of rendering specified content? If this line of reasoning is to be extended, MathML is of no use either.

On a personal note, I disagree with discarding specifications (whether drafts or finalised) as rarely used, unfinalised, or bloat in this manner.

[Moonchild]

If so, why?

Because I can expect a browser to do its primary job of rendering specified content? If this line of reasoning is to be extended, MathML is of no use either.

On a personal note, I disagree with discarding specifications (whether drafts or finalised) as rarely used, unfinalised, or bloat in this manner.

The question wasn't even directed at you, but here goes:

A web browser can theoretically render any and all content that exists, given enough code. Does it means that it should? No.
"Specifications" in the W3C are also in part determined by the very people who leverage the market; and certainly not all of them are desirable.
If you want strict specifications, then WebP shouldn't be added because it's not standardized, either, to name a thing.

MathML, if it were to be offered as an addition at this point in time, would be met with similar scrutiny on our part. It is, however something that is integral to documentation (and has been part of documents as-is since the early days) so you can't really compare the two. Ruby isn't essential to display the content. There are no hard and fast rules here, squarefractal. You may personally disagree with not adding every draft under the sun, but that's not realistic.

And once more: we already have Ruby as an add-on. Whether it's no longer developed for the moving target that is Mozilla Firefox doesn't really matter to us. Currently, we have a working version. If needed I can make it an integral part of Pale Moon, but I don't see the need for it since there is a solution that both keeps the core lean and gives the choice to have Ruby for the people who need it.

[Axiomatic]

A few questions here, then:

• What, exactly, is missing from HTMLRuby as far as the annotation element support is concerned? I looked at the "compelling example" page listed in the other thread and I didn't see anything missing from any language that would hinder the use of the element for indicated use.
• How much would it take to add missing features to the extension that are actually used in practice?
• Is the author of the extension approachable?
• How involved is porting ruby annotations from Firefox? Does it have many dependencies?
  I actually like the fact that HTMLRuby is a very manageable amount of JavaScript with no other dependencies or hooks, shifting ruby tag content with CSS to its desired place; It's an elegant solution and I'm afraid Mozilla's solution will somehow make it difficult to port by depending on refactoring and messing with the HTML parser. More information is needed.

1. Not sure if it is a bug, but ruby parentheses failed to work with HTML Ruby. Last time I checked (not too long ago), which was very common.
So as multi-line rt tags. (I will come back, and edit this after actually installing the add-on, and do some testing.)

2. Probably not much at all, however if I recall correctly memory leaks were usually common after the developer added support for a Ruby Annotation feature, so I guess it is tricky.

3. Possibly as the extension is on GitHub, however I am unaware whether he would want to keep active development for Pale Moon because he seems to support Ruby Annotations being in the core of Firefox.

4. I do not know. (I will look into it if I have time.)

While it does sound nice the way you put it, Pale Moon is used in many countries one being Japan, many or most websites in Japan use furigana, so with Firefox making it a core feature, web developers will take up to using Ruby only more. The main thought or worry of mine is I doubt the web developers will search for Pale Moon's specific User Agent, and then notify end-users to download HTML Ruby. Rather they will likely redirect them to using a browser that they know their site works on. :-/

I actually support Moonchild's idea in making Ruby Annotations work in browser via add-on support. (If this does end up being the choice, it probably would be nice to add a "Additional Features You May Want" page when users first install Pale Moon to link to add-ons that support specifications that Pale Moon does not include in the core. I say add-ons because if it is possible moving MathML to being a add-on would be nice too.)

[Moonchild]

Sorry if I misunderstand the common use for Ruby -- I don't see multi-line being intended use; it would not be a place to add paragraphs of text, it would be directly-related, short snippets placed with the related words or phrases. Especially in Japanese, multi-line would make no sense considering the compact nature of the language compared to Western script.

Memory leaks can easily be avoided with some careful checking of the JS and applying some best practices to clean up after removing tags. I haven't extensively tested the add-on, though, so I don't know for sure if this is a problem.

[Moonchild]

As an aside, if RubyHTML is acceptable, I can simply bundle it behind a pref with the browser, as well. That way it stays out of the core, is still bundled with the browser, and people can use Ruby without additional downloads required.

[Axiomatic]

Sorry if I misunderstand the common use for Ruby -- I don't see multi-line being intended use; it would not be a place to add paragraphs of text, it would be directly-related, short snippets placed with the related words or phrases. Especially in Japanese, multi-line would make no sense considering the compact nature of the language compared to Western script.

Multi-line rt tag are used, mainly when there is a mesh of kanji so they furigana does not become clustered they put some on the top, and some on the bottom. Other times, Japanese kun'yomi pronunciations go on the top, and Chinese-derived on'yomi pronunciations go on the bottom for when learning kanji. (Yes this is common, usually done on sites to practice for JPLT.)

Memory leaks can easily be avoided with some careful checking of the JS and applying some best practices to clean up after removing tags. I haven't extensively tested the add-on, though, so I don't know for sure if this is a problem.

So I went an tested the add-on. Testing went well with version 8.0.0-beta11, that version supports pretty much everything that is Ruby annotations are commonly used for. (Multi-line rt tags, have a spacing bug however I am unsure if that is because the add-on uses some add-on SDK feature Pale Moon does not support or just a logic error.) While testing it, I came across no memory leaks.

As an aside, if RubyHTML is acceptable, I can simply bundle it behind a pref with the browser, as well. That way it stays out of the core, is still bundled with the browser, and people can use Ruby without additional downloads required.

That sounds good; Pale Moon would have Ruby annotations via HTML Ruby, and if users do not use it they will have no problems with it, and it will be out of their sight. Just a thought though, since HTML Ruby is not a add-on that has a external window to manage its settings, rather it is all inside options.xul which displays inside the add-on manager; is it possible to somehow bring the settings functionality to options (by options I mean in GUI form inside options panel, not about:config).

[Moonchild]

I'll have to give this some more thought - there are a few options but none of them are too desirable for what they entail, both for development and for the end user.

[Moonchild]

I think I have an acceptable solution -- an integration of code based on the extension, that will not activate unless a pref (browser.ruby.enabled) is set to true. Once the pref is set and the browser restarted, ruby will be processed and rendered -- basic and partially complex annotations, but nothing too fancy is supported. When activated, it also enables a (for the extension users familiar) icon in the status bar that when clicked will open a (just as familiar) options window to tweak different settings.
Since I still have the integration to properly set up, this will be in v26 of Pale Moon.

[Axiomatic]

Your idea sounds good, side question that is partially relevant to this topic, will this also make it into the public beta testing for v. 26 of Pale Moon?