Fenring

ImageNode edits

Is there a way I can preview a SVG file with the Wikipedia renderer ? Or have I to real-upload it (and revert if I'm not happy with it) ? Is there a sandbox for that ? Can I use Image:CSS-shade.svg for my tests, or should I delete it (how, btw) ? --Fenring 09:12, 17 August 2007 (UTC)

As far as I know you can repeatedly upload multiple versions of the same file if you want to test to make sure it will render correctly when viewed on WP. (Just use "upload new version of this file"). I think you can request deletion for any "test image" you've uploaded per user request. For more information, you might want to check

• http://meta.wikimedia.org/wiki/SVG
• http://commons.wikimedia.org/wiki/Commons:Transition_to_SVG

and "what links here" also. Thanks again for your help. dr.ef.tymac 16:09, 17 August 2007 (UTC)

On WebKit

I really do think we should be consistent with the other engines where possible. So in the Ecmascript Comparison page we should give the layout engines (which is WebCore for WebKit products) along with their associated JavaScript Engines (that are not part of the layout engine). We are technically incorrect, as one layout engine might (in theory) be combined with different Ecmascript Engines; however, this is not a concern right now, as the relationships between those engines tend to be exclusive. So, my question is, would you agree to having the "Engine" named WebCore throughout the series? --Grey (talk) 22:55, 6 January 2008 (UTC)

Hi Grey, why seeking perfect consistency between standards that are inherently different ? The "Comparison of layout engine" series doesn't always compare layout engines anymore (at least for ECMAScript, DOM,...). You know, these articles are usually meant to compare the various implementations found in web browsers. And as more standards will be used in browsers, it seems we'll have more of these comparison pages. Whether or not these standards are related to the layout or not. Thus, I would rather free ourselves from the word "layout engine". A reader who finds this article is probably confused by its title. Moreover, I hope someone will add more engines in the future. Rhino in particular, which has nothing to do with any layout engine (so what to mention in its first header?). What do you think of renaming the articles where appropriate (it means Comparison of ECMAScript engines, Comparison of DOM implementations,...) ? The remaining problem is the layout engines template. Its name is not correct. It should be renamed into something like "That stuff that makes the engines of a browser". Everybody call that a "layout engine". I just disagree. We'll have to split the template into two. One with the layout engines (but I don't think this one is useful), and another called "Comparison of web standards implementations".--Fenring (talk) 00:30, 7 January 2008 (UTC)

I do think that the article names are non-optimal and should be changed (I always did). The problem I see coming up would be to find names (or any identifier really) for, say "DOM Implementations" (and other, new, standards). We'd still have to "head" them with some familiar name, so people know what belongs where. We should try to use names people actually understand, that is all I am saying. And if we use "Gecko" and "Presto" along with "WebKit" then people will make assumptions about them either being layout engines or application frameworks. Maybe we should clarify that the things heading the columns don't necessarily belong to the same category, but I'd be more comfortable if we used one category outthrough, if possible.

I think the Ecmascript engines are not a concern because they all have names of their own (even iCab had InScript). We could head the columns with the actual script-engines' names (i.e. remove the layout engine head-cells) and have a short explanation at the top which engine belongs where (similar to what's already in place for the main "Comparison" article that lists applications using the layout engines). --Grey (talk) 02:53, 7 January 2008 (UTC)

The familiarity of the headers used is not an argument. But I admit I don't have any better solutions. Some say Gecko includes SpiderMonkey (and if the later were a so distinct pluggable entity, why did Mozilla developped Rhino?). And maybe Presto is also to be considered as the entire framework, not only the layout engine. Only Webkit is clear about the distinction WebCore-JavaScriptCore. I'd rather use Gecko and Presto as the name of the "application framework" (though I hate the word), like WebKit is. Calling Presto, Gecko or Trident "layout engines" is very common, but is it accurate ? --Fenring (talk) 19:05, 7 January 2008 (UTC)

As far as I know, Rhino was started at Netscape when Netscape tried to "move to Java" (whatever that means). Spidermonkey seems to be an "ordinary" C Library, though. Regarding accuracy, see below. --Grey (talk) 21:42, 8 January 2008 (UTC)

A more difficult problem would be the HTML5 article, but I think we should just stay consistent in naming with the HTML4 article, because the HTML4 spec is handling more than the layout engine part, too (for example, required UI-representation of longdesc). I don't know where this might lead us, but we end up facing the same problems regardless how we call the "framework". --Grey (talk) 22:55, 6 January 2008 (UTC)

In that case, I'd use the application frameworks names.--Fenring (talk) 00:30, 7 January 2008 (UTC)

Why? If a spec makes requirements to both backend and frontend, browser names would be most appropriate, because it encompasses both, wouldn't it. If HTML5 was free of such requirements (which I can hardly believe), I'd agree to try putting (all) the "proper names" (i.e. WebKit, XPFE, Core-2) into the article. The problem is that, apart from WebKit, they are mostly unknown (XPFE:Mozilla, Core-2:Opera) or non-existant. As above, I'd hate to use the browser's name in one case, the layout engines's name in other and in still another that of the application framework. Now, this might all be different when NOT covering only mainstream browser's components, but that simply isn't the case right now (will it ever be, for HTML5?), so I don't see the benefit in confusing Web Devs (or wannabes) coming there to find info on standards support. --Grey (talk) 02:53, 7 January 2008 (UTC)

We can be precise for WebKit. Use "WebKit" for specs like HTML5. Use "WebCore" for CSS, Graphics or SVG. And use JavaScriptCore for ECMAScript. I like that. I think it can make everyone happy. I think we should not lose that precision just because the other vendors are imprecise (I'm not convinced with XPFE). Using browsers names would sadden me : there are so much. Anyway, I think this article is temporary. I'd like to see HTML5 elements in the HTML article as the spec matures. Same for the javacript features. --Fenring (talk) 19:05, 7 January 2008 (UTC)

After checking, XPFE doesn't seem right to me either. Anyways, using browser names would be the correct/accurate thing to do; my point was that accuracy isn't necessarily the top criterion. Let's take the Spidermonkey case from above. If Gecko links/includes the spidermonkey library, wouldn't that be similar to its linking of "ImageLib" (now to be replaced with "Cairo")? So we should use "ImageLib" or "Cairo" in the graphics article for want of accuracy (whatever the "application framework"). --Grey (talk) 21:42, 8 January 2008 (UTC)

I wouldn't mind if someone do, really. But as far as Gecko includes it, it's not false to speak about Gecko's graphics support. If another popular product includes ImageLib, it's important do the distinction. I think WebKit is more popular and more accurate than WebCore. Just google for "getElementsByClassName WebKit" : 11600 results. Then "getElementsByClassName WebCore" : 147 results. It shows how utterly false it is to speak about WebCore's HTML5 support. Do the same with Gecko and SpiderMonkey. It clearly shows that speaking about Gecko's HTML5 support (even if technically it's SpiderMonkey that is involved) is more popular. So I'd prefer to use Gecko, Presto and WebKit on each of the series articles. For me, these three do belong to the same category. --Fenring (talk) 23:25, 8 January 2008 (UTC)

So you're saying that it is both more popular to speak about Gecko as a layout engine, yet speaking about its inclusion of spidermonkey being popular also. So you propose we carry on the contradiction? Anyways, I think at least in the Ecmascript (btw. it's Ecmascript, not ECMAScript) article we should remove the "layout engines". Since that's what they are, now, since we have lots of sources stating it is whereas we have few if any sources explicitly stating otherwise, and they only cause confusion there. --Grey (talk) 10:48, 13 January 2008 (UTC)

I'm not sure if I understand. About the EcMaScript support article (section below), I totally agree with you. --Fenring (talk) 21:50, 13 January 2008 (UTC)

My point was that there is a contradiction between "gecko is a layout engine" being extremely prevalent on the web and "gecko includes spidermonkey" which is also relatively popular. And that by doing what you propose, we're just carrying on the contradiction, instead of explaining/resolving it. I changed my mind though. I think Gecko, Presto, Trident are not layout engines (at least haven't been since considerable time). Thus I would like the layout engines article to be updated to say just that and moved to a better name (I propose "browser engine" instead of the overly complex "apllication framework", though...). I'd also start to actually do the renaming. Do you think we should discuss this on the pages' talk pages or just be bold and move them? --Grey (talk) 15:49, 23 January 2008 (UTC)

To avoid the vocabulary problem, I think your previous proposal ("Standard support ([standard])") is better than "browser engine comparison". I tend to hate article move wars more then simple edit wars. So to prevent this, I think it's better to discuss it before. I won't be bold on this subject. What do you think of Template:Layout engines's talk page ? (I won't have time to help during the next few days though. If you need support for convincing the others, wait until feb 4th) --Fenring (talk) 10:41, 24 January 2008 (UTC)

I still agree with the format I proposed below (btw. is it "standard support" or "standards support"? The latter comes to my mind easier.), just not for the "main" layout-engines article (sorry I didn't make that clear); since that one is about licensing, platform support and release history. I think the template talk might be a good starting point, but do you think people involved in the articles will notice changes on the template talk? Maybe we should modify the template to raise awareness of the discussion. I don't know how to do this, though. Anyway, if we're going to have a (lengthy) discussion, then I have to agree this has to wait till February. I might start working on the proposal when I got free time, though (summarizing this discussion somehow and naming specific changes). Grey (talk) 17:41, 24 January 2008 (UTC)

renaming of articles

'Comparison of Ecmascript Engines' might be a good idea because every (relevant) engine has a name.

For something that doesn't have any "names" in and of itself, I thought "Standards support (Ecmascript)" might be a good idea for something completely loose from the browser-environment. We can also add more articles for different scripting languages or just about any standard with this naming scheme. The name also implies that it would be possible to write a "real" article about it, with sections such as "History of Ecmascript adoption", or something similar. That means, it need not be a pure comparison anymore. --Grey (talk) 03:10, 7 January 2008 (UTC)

OK, I started to collect some different data. I made a new template and named it [standard support].

It will be implemented by me in the articles of the collection. I took the libraries and plugins also in the boot and then I will be finished with these implementation, i start to collect data for the plugins (more on my own user page!)Mabdul (talk) 03:09, 27 March 2008 (UTC)

I make my last two changes back and want to know now. How good is this template and can we use it? or should we make a template that catogorize the standards? (left column as example html, right presto, trident,...)?!?

Mabdul (talk) 03:21, 27 March 2008 (UTC)

This discusion continues here...--Fenring (talk) 18:35, 31 March 2008 (UTC)

buggy, incorrect, useless

please, take a look on this page and give your comment... User_talk:GreyWanderer Mabdul (talk) 06:09, 16 April 2008 (UTC)

Hello Mabdul. I'm afraid I don't have any opinion about that subject. I suggest you make the edit and be bold, then wait and see for any feedback. Sorry and good luck ! --Fenring (talk) 10:56, 16 April 2008 (UTC)

NowCommons: File:Opera logo.svg

File:Opera logo.svg is now available on Wikimedia Commons as Commons:File:Opera O.svg. This is a repository of free media that can be used on all Wikimedia wikis. The image will be deleted from Wikipedia, but this doesn't mean it can't be used anymore. You can embed an image uploaded to Commons like you would an image uploaded to Wikipedia, in this case: [[File:Opera O.svg]]. Note that this is an automated message to inform you about the move. This bot did not copy the image itself. --Erwin85Bot (talk) 00:40, 16 November 2009 (UTC)

Nomination for deletion of Template:Percent to color

Template:Percent to color has been nominated for deletion. You are invited to comment on the discussion at the template's entry on the Templates for discussion page. Thank you. —Justin (koavf)❤T☮C☺M☯ 16:40, 23 February 2010 (UTC)

Talk:Comparison of layout engines (Cascading Style Sheets)#Trident version numbers

Hello, Fenring. You have new messages at Talk:Comparison of layout engines (Cascading Style Sheets)#Trident version numbers.
You can remove this notice at any time by removing the {{Talkback}} or {{Tb}} template.

mabdul 02:10, 15 April 2010 (UTC)

ArbCom elections are now open!

Hi,
You appear to be eligible to vote in the current Arbitration Committee election. The Arbitration Committee is the panel of editors responsible for conducting the Wikipedia arbitration process. It has the authority to enact binding solutions for disputes between editors, primarily related to serious behavioural issues that the community has been unable to resolve. This includes the ability to impose site bans, topic bans, editing restrictions, and other measures needed to maintain our editing environment. The arbitration policy describes the Committee's roles and responsibilities in greater detail. If you wish to participate, you are welcome to review the candidates' statements and submit your choices on the voting page. For the Election committee, MediaWiki message delivery (talk) 16:35, 23 November 2015 (UTC)