Hacker News Reader

Comment by alinajaf | Hacker News Reader

I think your point is that if you want a feature implemented in an OS project, you should implement it yourself. In practice, we're web developers, and it's much easier to just pick up google chrome than it is to get set up with developing firefox, getting into the code and implementing the change.

That being said, I'm seriously considering cowboying up and contributing to get the ruby tag implemented in firefox. This is not because I use Firefox myself, but my users do, and faking it with js/css is brittle as hell.

View on HN

Note that Firefox did show the line (and column, which is impossible to get in Chrome) number if you actually clicked on any point in the view-source window. It just didn't have a gutter on the left with the line numbers.

As far as the ruby tag, if you really are interested I'd be very glad to get you up to speed. There's a partial patch, but it has some issues that should really get dealt with before it lands. Of course every single ruby implementation out there is broken as hell in the relevant ways, so maybe it should just land issues and all... In any case, let me know if you do want to get it into shape. I do have to warn that this is not a small-and-simple project unless you really want to learn about the layout engine internals anyway.

Thanks for the offer. I would take you up on it but as you say (and I sort of expected) it's not going to be a simple project and I have a lot on my plate right now.

The "switch to something else to fix a bug" strategy is clearly unsustainable. What do you do when you find a bug in chrome then? Switch back to firefox? Switch to opera first before you switch back to firefox? Just change browsers every month in the hope that they all have different bugs?

(chrome has plenty of bugs: the latest update on linux has a tendency to hang and use 100% cpu in some glib functions)

On the other hand to do changes to large code bases on short notice is a big asset to your programming skills. See it as a challenge. It's well something you could put up on your resume.

Often the main challenge is just to find the code, and if you can't do that can you deal with any other non toy code bases? Once you found it a lot problems are easy.

nn -- (who has one patch in Firefox)

You can do so, however, note that you still need acceptance for mainline.

Obvious things such as line numbers, are obviously accepted once implemented properly.

Note: the below comment is actually inaccurate, I though ruby tag was the language (as the author mentioned js as alternative). Keeping it for the comments discussing it, but keep in mind I was actually wrong.

Things like a ruby tag might be more complicated than you'd think.

You see, the main difference between Firefox and Chrome (yeah, it's not the UI! ;P) is ideology.

Firefox folks believe in a standard and compatible web. Chrome folks believe in .. implement whatever we think is faster than what we have (or /flamebait hat on, whatever helps Google make money/adverts/lock-in users).

Supporting ruby might fall in the "but it's not standard" "it splits the web" category.

And that's be correct, in my opinion. So you might want to check on that before actually getting the code done, unless you plan to fork.

The ruby tag is not related to the ruby language

http://dev.w3.org/html5/spec/Overview.html#the-ruby-element

Seems to be part of the standard...

Alright, I did not actually know that.

i'd say go right ahead.

I'll note also that it's a draft - something that annoys me with HTML5. New drafts are sent every next day or so, so it's not actually very standard. It's a different story though.

Chrome folks believe in .. implement whatever helps Google make money/adverts/lock-in users.

Citation needed.

I had the hat on.

But for the sake of discussion, please keep entire quotes, instead of rewriting what I wrote initially.

Chrome folks believe in .. implement whatever we think is faster than what we have

For example SPDY is faster. NaCl is faster. That's not bad. It's just not the same focus.

Now, NaCl also helps making money and helps with lock-in for example.

There are several other examples in the -webkit functions and some things which are not part of the actual webkit (only Chrome's version) such as Dart and the like.

While I can't provide a citation, I believe that the contrapositive is true: if it doesn't help Google, it's not going to be implemented. Right now, Google's interests are aligned with a standardised, compatible web, and when Google gets big enough, or greedy enough, it's going to take Chrome in its own direction. Opera still fares badly at Google's services, but they consider IE worth supporting.

> when Google gets big enough [..] it's going to take Chrome in its own direction

Hasn't Google already taken Chrome in its own direction? Chrome includes lots of non-standard technologies like Flash, NaCl, Pepper, Chrome Apps, and soon a Dart VM. Google believes these technologies are good, but no other browser does, and not even WebKit.

Maybe those are good and useful technologies, that is a separate matter. I'm just pointing out that Google is already well in the process of taking Chrome in the direction Google feels is best, regardless of what the rest of the web thinks.

I see. So you're blaming Google now for something you imagine they might do in the future. How could Google defend itself against your accusations?

Not blaming, but worrying about. There is plenty of software that can read Word's .doc files. Yet I store my data as plain text, as I imagine that the software will be killed or end-of-lifed in the future, even though I can use it fine right now. In the same way, I'd rather use a browser designed for an open, standardised Web.

Chrome doesn't have nearly enough market dominance for me to make accusations about it; I just want to minimise any future disaster scenarios.

Reply on news.ycombinator.com