Steffen,
ResourceLoader guarantees the order of module execution if there are
dependencies, such that child always comes after parent, which always comes
after grandparent in a dependency chain. Due to the concatenation of
modules in the order requested, it's unlikely that modules will be
PHP 5.4 added a few important features[1], namely traits, shorthand array
syntax, and function array dereferencing. I've heard that 5.3 is nearing
end of life.
I propose we drop support for PHP 5.3 soon, if possible.
- Trevor
[1] http://php.net/manual/en/migration54.new-features.php
Is that the rule then, we have to make MediaWiki work on anything Ubuntu
still supports?
Is there a rule?
- Trevor
On Thu, Feb 20, 2014 at 12:25 AM, Markus Krötzsch
mar...@semantic-mediawiki.org wrote:
On 20/02/14 05:17, Jamie Thingelstad wrote:
Regarding PHP 5.3 support, I put together a
So, it sounds like we will either maybe drop 5.3 after April, or my newborn
son will be riding a bicycle before we can use Traits in PHP.
Hoping for the former, willing to accept the latter.
- Trevor
On Fri, Feb 21, 2014 at 9:19 AM, AlisonW t...@alisonwheeler.com wrote:
and on my one
I just wanted to add that in the past, as many people know, we tried a few
different kinds of testing and even hired a usability testing firm to help
us. We conducted research in a lab here in SF and also did some remote
testing, compensating participants with gift cards.
We learned that lab
It might be easier to revamp the skin system if there were fewer skins to
port.
- Trevor
On Mon, Mar 10, 2014 at 6:48 PM, MZMcBride z...@mzmcbride.com wrote:
Tomasz Finc wrote:
On Mon, Mar 10, 2014 at 2:10 PM, Jon Robson jdlrob...@gmail.com wrote:
Why is Cologne Blue still in core?
A
I support moving it to an extension and enabling it on deployed sites as to
avoid an disruption in service for the users of the skin.
- Trevor
On Tue, Mar 11, 2014 at 12:21 PM, Jon Robson jdlrob...@gmail.com wrote:
It might be easier to revamp the skin system if there were fewer skins to
I don't think anyone is suggesting removing or even moving Monobook. I
think we are more talking about assigning effort more proportionally to
preference of users. Cologne Blue is not the clear favorite of any group of
users that we know of.
- Trevor
On Tue, Mar 11, 2014 at 12:36 PM, Risker
By making all skins extensions it would also force us to make a few new
APIs which are needed to no longer have skin extensions be second-class
citizens.
This should happen.
- Trevor
On Tue, Mar 11, 2014 at 2:38 PM, Isarra Yos zhoris...@gmail.com wrote:
On 11/03/14 21:21, Jon Robson wrote:
, Trevor Parscal wrote:
By making all skins extensions it would also force us to make a few
new
APIs which are needed to no longer have skin extensions be
second-class
citizens.
This should happen.
- Trevor
Quite so. Think hitting on some of this could
I'm going to start working on some RL modifications to make it possible for
skins outside of core to add skinStyles to other modules, which will help
with making non-core skins equally capable.
- Trevor
On Wed, Mar 12, 2014 at 12:00 PM, Jon Robson jdlrob...@gmail.com wrote:
Yes this is an
Have you read
http://www.mediawiki.org/wiki/ResourceLoader/Developing_with_ResourceLoaderyet?
- Trevor
On Sun, Mar 16, 2014 at 6:04 AM, Justin Folvarcik jfolvar...@gmail.comwrote:
I have a couple questions about the formSpecialPage class and how it works.
For starters, I cannot seem to make
Sorry if that was like RTFM. If you have more specific ResourceLoader
questions, please feel free to ask.
- Trevor
On Sun, Mar 16, 2014 at 7:22 AM, Trevor Parscal tpars...@wikimedia.orgwrote:
Have you read
http://www.mediawiki.org/wiki/ResourceLoader/Developing_with_ResourceLoaderyet
Our goal should be to relinquish control of image sizing to the view, not
build in more or different ways to specify it in the model.
Images should be given semantic classifications, and the skin should decide
how to best display the image. Maybe it will be inline with the content,
maybe it will
We are introducing recommended fields which will be automatically added
when the template is added. We already support required fields which are
automatically added, but we are adding recommended fields so that required
can be reserved for actually required fields. In time, we expect required
will
wrote:
Hoi,
Is there a way to link such templates easily to Wikidata?
Thanks,
GerardM
Op 22 apr. 2014 17:51 schreef Trevor Parscal tpars...@wikimedia.org:
We are introducing recommended fields which will be automatically added
when the template is added. We already support
We are very open to breaking it out into submodules. We should be able to
do this very quickly. In many cases, users of OOUI are only in need of a
few base classes, and we've recently done much more to divide up the style
code to make it possible to load things a la carte. I believe this is
I normally don't chime in on these threads, but I feel compelled.
Rob made a significant contribution to VisualEditor and this change is a
well deserved nod to his growth as an engineer as well as a step in the
right direction to spread knowledge around the organization.
Congrats on the new
Also, please note that includes/lib is meant to be a place for external
libraries. Some of the libraries are ones we have ported or written
ourselves, but we should continue using this space as external libraries
increase in number and change in nature.
- Trevor
On Tue, May 27, 2014 at 9:12 AM,
I'm happy to see us talking about leaving these old browsers behind, but it
seems a few existing policies and situations may have been overlooked in
this thread thus far.
Hopefully this list of things to consider will be helpful:
1. We are planning on moving away from jQuery UI this year as
Jon, I know you mean well, and that you are passionate about solving this
problem, but I do not believe this is the right approach. I've communicated
that in another thread with a smaller group, and you did not respond to me.
Now you are changing key details in the proposal, but the extension code
Indeed, this thread is a bit silly.
If someone wants to make an extension that provides a feature, and someone
else wants to use it, there's nothing wrong with that. But why would such a
thing need proposing?
If the point of Mantle is only to provide a way to bring templates to the
client, then
/HTML_templating_library/Knockoff_-_Tassembly/Mobile_spike
Ryan Kaldari
On Thu, Jul 3, 2014 at 12:05 PM, Trevor Parscal tpars...@wikimedia.org
wrote:
Indeed, this thread is a bit silly.
If someone wants to make an extension that provides a feature, and
someone
else
Seems reasonable for us to consider adding a way to specify packed in RL
to skip additional processing of that module.
- Trevor
On Sun, Jul 13, 2014 at 6:35 PM, Krinkle krinklem...@gmail.com wrote:
On 13 Jul 2014, at 19:40, Max Semenik maxsem.w...@gmail.com wrote:
You can bypass
I want to suggest that we give Brandon a lot of slack here, and be as
supportive as possible.
This is a prototype of a design, which is far better than a mockup of a
design. It is not an actual implementation, but that is totally fine. I
want to see more of this kind of thing, and by being more
On Fri, Aug 22, 2014 at 12:14 PM, S Page sp...@wikimedia.org wrote:
On Fri, Aug 22, 2014 at 11:34 AM, Jon Robson jdlrob...@gmail.com wrote:
Trevor is working on a template widget for oojs which will
make this possible
Great, though I don't understand what this is. Is this a specific
Thanks for summarizing the meeting Jon.
So, let's get Twig/Swig into core then, eh? :)
- Trevor
On Tue, Aug 26, 2014 at 3:53 PM, Jon Robson jrob...@wikimedia.org wrote:
Shahyar, Juliusz, Trevor, Kaldari, Roan and I sat down yesterday and
talked about the future of skins. Hopefully this mail
is a PHP
implementation of Mustache. This doesn't seem to be the case though.
We need a templating solution that works both on the server and the
client.
On Tue, Aug 26, 2014 at 5:21 PM, Trevor Parscal tpars...@wikimedia.org
wrote:
Thanks for summarizing the meeting Jon.
So, let's get Twig
Jon, this is really awesome. I'm excited to be sharing more code.
I'll be taking a look at these patches with Roan today.
- Trevor
On Fri, Sep 12, 2014 at 11:43 AM, Tomasz Finc tf...@wikimedia.org wrote:
On Fri, Sep 12, 2014 at 11:32 AM, Jon Robson jrob...@wikimedia.org
wrote:
After this
On Wed, Dec 12, 2012 at 11:32 AM, Daniel Barrett d...@vistaprint.comwrote:
Will the method for hooking into VE be the same as for WikiEditor? Or
will extension
developers need to support both editors in two different ways?
In general they are both conceptually and technically incompatible.
I've already commented on the bug and in Gerrit, but I will also echo here.
First off, thank you for taking the time to work on VisualEditor, and even
submitting a patch directly into Gerrit. We hope to get more patches this
way.
In this particular case, the solution being offered isn't going to
I have avoided getting involved so I could stay focused on fixing bugs and
making improvements to VisualEditor.
This thread has served it's purpose; to surface various arguments about
whether the preference to disable VisualEditor should be hidden or not. The
conclusion has been reached. The
Don't forget using git (or git compatible system) as a revision backend.
Extensions being developed on-wiki, gadgets defining their own API
extensions, JavaScript templates generating HTML DOM trees, human
sacrifice, dogs and cats living together... mass hysteria!
- Trevor
On Fri, Jul 26, 2013
On Fri, Jul 26, 2013 at 3:43 PM, Yuvi Panda yuvipa...@gmail.com wrote:
On Sat, Jul 27, 2013 at 4:11 AM, Trevor Parscal tpars...@wikimedia.org
wrote:
Don't forget using git (or git compatible system) as a revision backend.
That is darcs!
Somehow I missed that.
Reading the page, thinking
VisualEditor is MIT licensed. It was originally GPLv2 by default as per my
contract with Wikimedia, but early on we got written permission from all
authors to change it. We did this because we wanted to ensure maximum
license compatibility for re-use in non-MediaWiki systems.
- Trevor
On Mon,
It seems to me that the Drafts extension provides a neat feature with
the potential to save data from being lost by accident in many cases. It
also seems like adding a per-user setting to enable/disable it would be
trivial and also useful for the few (or perhaps many) users who may find
it
Seems reasonable for logged in users to opt in for languages they are
going to actually use, but what about anonnomous users? Perhaps it
could be a hidden field with an Ajax(/some fallback) control that only
loads the other languages when the user asks for them, which would
probably be
On 3/31/09 8:21 AM, Domas Mituzas wrote:
(as you know XML generation and parsing really
take time...)
I didn't know that. Ever tried SAX?
Indeed, not all XML software is slow...
http://dotnot.org/blog/archives/2008/02/
- Trevor
___
On 4/24/09 4:38 PM, Alex wrote:
While backwards compatibility is nice, if it stands in the way of
improving something that needs improvement, the improvement should take
priority
Indeed - even Microsoft eventually abandoned Windows 3.1
compatibility... And more recently compatibility with all
I'm glad to see I'm not alone. JavaScript can indeed invoke bad
memories of fragile scripts running in IE5 which are long and awkward
due to limitations in browser technology at the time. However, anyone
who has used a modern library like jQuery on a support browser will
tell you it's very
At the developer's conference in Berlin this past spring, the void that
is current our testing procedures was a common topic of conversation.
Put simply, QA is not exciting work for most people and our
volunteer-oriented development process tends to result in very little or
often no automated
On 8/11/09 12:45 PM, dan nessett wrote:
--- On Tue, 8/11/09, lee wordenwon...@riseup.net wrote:
Placing it in the include path could make it hard to run
more than one version of the MW code on the same server,
since both would probably find the same file and one of them
would likely
When I try and download the Wikipedia Mobile app on my 1st gen iPod
touch it won't let me - saying it requires a microphone... Unless it's
a voice command only UI, this is probably not intended ;)
- Trevor
Sent from my iPod
___
Wikitech-l mailing
On 9/10/09 10:06 AM, Aryeh Gregor wrote:
On Wed, Sep 9, 2009 at 6:50 PM, Tim Starlingtstarl...@wikimedia.org wrote:
I don't know why you're writing this nonsense, you obviously haven't
looked at the code at all.
This paragraph is unnecessary.
Seriously! Please read things
On 9/22/09 6:19 PM, Tim Starling wrote:
Siebrand Mazeland wrote:
Hola,
I just created https://bugzilla.wikimedia.org/show_bug.cgi?id=20768 (Branch
1.16) and Brion was quick to respond that some issues with js2 and the
new-upload stuff need to be ironed out; valid concerns, of course.
On 9/23/09 4:54 PM, Robert Rohde wrote:
On Wed, Sep 23, 2009 at 4:37 PM, apri a.vd.wiela.vd.w...@apri.nl wrote:
I like the XML way of resolving this problem but I think it MediaWiki
has a bigger task to do.
Restructure the wiki language, XML-ize the language completely.
Forms and
On 9/24/09 9:31 AM, Jared Williams wrote:
* Automatically create CSS sprites?
That would be neat, but perhaps a bit tricky.
Just trying to think how it'd work.
Given a CSS selector, and an image, should be able to construct a
stylesheet which sets the background property of
On 9/24/09 1:41 AM, Tim Starling wrote:
Trevor Parscal wrote:
If you are really doing a JS2 rewrite/reorganization, would it be
possible for some of us (especially those of us who deal almost
exclusively with JavaScript these days) to get a chance to ask
questions/give feedback/help
On 9/24/09 1:40 PM, Jared Williams wrote:
-Original Message-
From: wikitech-l-boun...@lists.wikimedia.org
[mailto:wikitech-l-boun...@lists.wikimedia.org] On Behalf Of
Trevor Parscal
Sent: 24 September 2009 19:38
To: wikitech-l@lists.wikimedia.org
Subject: Re: [Wikitech-l] JS2
On 9/24/09 2:34 PM, Jared Williams wrote:
-Original Message-
From: wikitech-l-boun...@lists.wikimedia.org
[mailto:wikitech-l-boun...@lists.wikimedia.org] On Behalf Of
Trevor Parscal
Sent: 24 September 2009 21:49
To: wikitech-l@lists.wikimedia.org
Subject: Re: [Wikitech-l] JS2
This thread has gotten WAY off topic - so I wanted to try and help
clarify a few things and then get it back on-topic if at all possible.
* As Roan mentioned, we are planning on implementing a *wiki-text
*editing interface with collapsible blocks for template calls and
tables. We
On 9/25/09 1:18 PM, Robert Rohde wrote:
Are the XML specifications intended as?
A) A required addition to current and future templates
OR
B) An optional addition to aid / facilitate the functioning of some
advanced tools
The latter case seems far more achievable than the former case.
On 1/7/10 10:55 AM, church.of.emacs.ml wrote:
Hi,
this is slightly off-topic, but I'll go ahead anyway:
Please don't make bugzilla (or any future bug tracker) look like
MediaWiki (Monobook skin). What looks like a Wiki (but aren't) often
gets confused with a Wiki.
Buzgilla is not a Wiki.
On 2/3/10 1:54 PM, Steve Bennett wrote:
On Sun, Jan 31, 2010 at 1:59 AM, David Gerarddger...@gmail.com wrote:
http://danielrw.tumblr.com/post/266672251/hilarious-ie6-splash-screens
Yeah, but something more subtle might actually be appropriate.
Presumably IE6 lingers so long
On 2/3/10 2:01 PM, Aryeh Gregor wrote:
On Wed, Feb 3, 2010 at 4:54 PM, Steve Bennettstevag...@gmail.com wrote:
Yeah, but something more subtle might actually be appropriate.
Presumably IE6 lingers so long because it doesn't cause *users* any
problems. All the headache is on the side of
On 2/5/10 1:12 PM, Daniel Kinzler wrote:
Hi all
Wikimedia Germany invites all MediaWiki developers, Toolserver users, Gadget
hackers, and other people interested in the technical side of Wikimedia
projects
to come to Berlin for a Developer Meet-Up on April 14.-16. Last year's meet-up
in
On 2/9/10 10:58 AM, Jack Phoenix wrote:
On Mon, Feb 8, 2010 at 11:16 PM, Roan Kattouwroan.katt...@gmail.comwrote:
Not any more, the Vector skin itself has been stable for months. All
the usability work is currently done in the UsabilityInitiative
extension.
Ah, good to know. I
On 2/9/10 4:07 PM, Aryeh Gregor wrote:
On Tue, Feb 9, 2010 at 4:56 PM, Platonidesplatoni...@gmail.com wrote:
We will be glad to have you on it, Trevor. Rewriting the skin system is
not urgent, although I would like to have a newskin compatible vector
skin before releasing 1.16. This way,
On 2/9/10 4:54 PM, Chad wrote:
On Tue, Feb 9, 2010 at 7:30 PM, Trevor Parscaltpars...@wikimedia.org wrote:
On 2/9/10 4:07 PM, Aryeh Gregor wrote:
On Tue, Feb 9, 2010 at 4:56 PM, Platonidesplatoni...@gmail.comwrote:
We will be glad to have you on it, Trevor. Rewriting
On 2/10/10 6:55 AM, Roan Kattouw wrote:
2010/2/10 Aryeh Gregorsimetrical+wikil...@gmail.com:
I'm also concerned by the fact that at least some (I haven't looked
closely) of the Usability Initiative stuff seems to work only in
Vector. For instance, apparently EditWarning doesn't work at
On 2/10/10 3:50 PM, Platonides wrote:
Aryeh Gregor wrote:
On Tue, Feb 9, 2010 at 8:35 PM, Trevor Parscaltpars...@wikimedia.org
wrote:
Merging Monobook and Modern is actually a good point for one of my other
ideas, which is to have themes for skins. In other words, same HTML
Michael Dale, Tim Starling and I have been planning the integration of
the things being done of the js2-work branch into phase3. Michael and I
today discussed some of the changes we are looking to make, and we
wanted to make contact with stakeholders about them.
* Create a new folder:
On 3/10/10 4:27 PM, Danese Cooper wrote:
Good afternoon Wikimedians,
The deadline for application from Open Source Projects to Google Summer
of Code 2010 is looming (in about 48 hours), and I'm coordinating the
formal Wikimedia Foundation entry. There has already been some
excellent
On 3/17/10 1:02 PM, Marco Schuster wrote:
On Wed, Mar 17, 2010 at 5:37 PM, Aryeh Gregor
simetrical+wikil...@gmail.com wrote:
On Wed, Mar 17, 2010 at 10:39 AM, Platonidesplatoni...@gmail.com wrote:
Would it help adding alink rel=prefetch to the first video in the page?
I think we should really consider LOLCODE for this sort of thing.
http://en.wikipedia.org/wiki/Lolcode
It's just more fun!
- Trevor
On 3/23/10 3:44 PM, Tim Starling wrote:
Conrad Irwin wrote:
On 03/23/2010 05:23 PM, Aryeh Gregor wrote:
On Tue, Mar 23, 2010 at 1:00 PM, Roan
On 3/28/10 9:06 AM, Niklas Laxström wrote:
^demon, Happy-melon, ialex, ashley and I have been preparing a new
class. It is intended to be replacement for the old wfMsg* functions
that many seem to dislike.
The most important reasons why we want to replace them are below.
There is some more at
-parameters( 4 )-escape() etc. That would however mean
that the magic properties wouldn't be strings, but objects themselves. not
sure
if that's good for performance...
just some thoughts
-- daniel
Trevor Parscal schrieb:
I have been experimenting with a very different approach
On 3/30/10 12:26 PM, Siebrand Mazeland wrote:
From: Trevor Parscal
Sent: Tuesday, March 30, 2010 5:47 PM
[..] but switching to _ from - might start being popular anyways so a switch
over
might be something we could consider.
[sm] personally I very much prefer - over _ in message keys
On 3/30/10 4:08 PM, Chad wrote:
On Tue, Mar 30, 2010 at 7:01 PM, Trevor Parscaltpars...@wikimedia.org
wrote:
On 3/30/10 12:26 PM, Siebrand Mazeland wrote:
From: Trevor Parscal
Sent: Tuesday, March 30, 2010 5:47 PM
[..] but switching to _ from - might start being popular
On 6/1/10 8:24 AM, Roan Kattouw wrote:
2010/6/1 Conrad Irwinconrad.ir...@gmail.com:
The other solution is to use a proper MVC framework, and define
everything in terms of modifications to the wikitext (and you can then
constrain what those modifications are to avoid mangling) and run that
Good advice here, but I would just say we should mention that git --amend
is still recommended if you committed something and then realized there was
a mistake.
- Using it to fix a typo or minor error in a commit = awesome.
- Using it to pile up tons of changes across tons of files = not
No offense to those who have chimed in, but seriously, this is a silly
discussion.
Do we really have the bandwidth to be 15 messages deep on this thread?
- Trevor
On Thu, Mar 29, 2012 at 5:24 PM, Tim Starling tstarl...@wikimedia.orgwrote:
On 29/03/12 00:10, Chad wrote:
Hi everyone,
+1 to all the points for using return values.
If we have to implement an output buffer in Lua, we have probably
failed. Output buffering is is messy and prone to error. It's certainly not
a good design from a usability standpoint, and it's generally messy to deal
with.
Template invocations
I think you could use a multi-step process to solve this problem with the
help of the community.
1. Detect when inline styles are used on a page and add that page to a
list of pages that might have problems being rendered on mobile.
1. Make a special page that displays this list and
The namespace separator might be ugly, but it's in good company with the
rest of the syntax of PHP.
- Trevor
On Wed, May 16, 2012 at 4:48 PM, Terry Chay tc...@wikimedia.org wrote:
On May 16, 2012, at 3:52 PM, Max Semenik wrote:
Frankly, the namespace syntax in PHP is so atrocitous that I
I think a better answer to your question is: nothing that's been
officially resourced at this time.
We currently have a 2-device strategy, which means we redirect some devices
to a mobile site, and the rest remain at the normal desktop site. The
closest thing to responsive design we have in
I've always wondered about something:
Given the 2 rules:
- Lines should be broken at between 80 and 100 columns.[1]
- You should make no assumptions about the number of spaces per tab.[2]
I have a couple of questions:
- What should we do if someone who uses 1 space tabs writes a 99
Sadly the length of lines is a poor measure of the nested-ness of a
program, and sufficiently complex algorithms aren't always better broken
into multiple parts, such as in cases where the loops are very tight and
the function call overhead would be costly.
- Trevor
On Wed, Aug 8, 2012 at 11:09
Trevor Parscal changed our jsMessage setup to be a
floating auto-hiding notification bubble.
https://gerrit.wikimedia.org/**r/#/c/17605/https://gerrit.wikimedia.org/r/#/c/17605/
The end implementation felt half-baked to me. Since it just swapped text
for notification replacement. And didn't support
VisualEditor doesn't use a 3rd party framework, mostly because I don't
really believe in them - that's another topic though. Here are some
thoughts on this topic:
- I suggest you create some classes (JavaScript prototypes) in a
namespace, such as a global 'WikiData' object (which can be
That was unfortunate - I've been ridiculed (by Max) for things I've said
before as well, I feel your pain Ori.
That said however, I generally agree with this piece. I have more faith
than the author seems to have that we are on the right track to doing
better work in the future, but the points
Well said. Thank you for sharing.
- Trevor
On Tue, Aug 21, 2012 at 12:18 PM, Ori Livneh o...@wikimedia.org wrote:
On Tuesday, August 21, 2012 at 12:04 PM, Trevor Parscal wrote:
One of the most important points here is about experimenting on users;
and
it should be taken seriously. I
On Tue, Aug 21, 2012 at 1:20 PM, S Page sp...@wikimedia.org wrote:
(There is My preferences Appearance check Exclude me from feature
experiments; though it's probable some artifacts will leak out, as
happened for a few weeks in the bug he references.)
As the person who implemented that
The idea that we are trying to attract new users at the detriment of the
existing ones is putting words in our mouths, but I do know what you mean.
The good news is that many of us are very conscious about these issues.
Here are some excerpts, for instance from the VisualEditor software design
$( 'div' ) is the way to go.
- Trevor
On Mon, Aug 27, 2012 at 4:37 PM, Mark Holmquist mtrac...@member.fsf.orgwrote:
Hence, I think we should change our coding conventions to always use `$(
'div /' )`.
+1 for valid XHTML. Considering that bytes are cheap and validity is good,
this seems
On Tue, Aug 28, 2012 at 12:57 AM, Tim Starling tstarl...@wikimedia.orgwrote:
Personally, I would use document.getElementById() to do that. It's
standard, and it's faster and more secure.
I think your premature optimization disorder (POD) is flaring up again.
jQuery performance is something
On Tue, Aug 28, 2012 at 10:06 AM, Jon Robson jdlrob...@gmail.com wrote:
I knew there was a good reason I use $( 'div/' )
One of those things I learn then forget why I'm doing it. I've apparently
not being following styling guidelines ;-)
Actually you were following the guidelines, but they
Rob is correct that using addClass is the preferable way to go for classes,
and attr is the preferable way to go for other attributes. They are both
are safe since they use setAttribute internally which escapes the values.
- Trevor
On Tue, Aug 28, 2012 at 10:29 AM, Rob Lanphier
jQuery internally maps 'tagName' to document.createElement( 'tagName' ).
This is a feature, and is used throughout jQuery internally. It's not very
well documented as such, but Timo is adding it to the documentation as to
resolve the confusion around this. $( 'div' ) is a shortcut added to
jQuery
On Tue, Aug 28, 2012 at 11:00 AM, Ryan Kaldari rkald...@wikimedia.orgwrote:
In that case, perhaps we should just say that all of the options are fine:
$( 'div' )
$( 'div/' )
$( 'div/div' )
but emphasize not to use attributes in the tag creation.
Unless you are creating an input or a
On Tue, Aug 28, 2012 at 11:15 AM, Daniel Friesen dan...@nadir-seen-fire.com
wrote:
That's an unintentional side effect. jQuery does not officially support $(
'div' ) without a closing /div or /.
And yet they use it themselves internally? As I mentioned, Timo is a jQuery
maintainer and said
+1
Thank you for grounding this conversation in reality.
- Trevor
On Tue, Aug 28, 2012 at 12:18 PM, Krinkle krinklem...@gmail.com wrote:
Okay, sorry for being away for 30 minutes while I enjoyed dinner.
Someone[1] pointed me to this thread and suggested I chime in, so here I
go.
On Aug
On Thu, Aug 30, 2012 at 3:24 AM, Daniel Werner
daniel.wer...@wikimedia.dewrote:
By the way, you can also use
$( 'div/', { 'class': 'foo', 'title': 'myTitle', ... } );
Just be aware this also allows you to use things like 'html' and 'text'
which are not attributes at all, but call .html() or
In VisualEditor we ended up putting all CSS rules that include images in
*.icons-raster.css and *.icons-vector.css files, which are loaded
dynamically based on the window.devicePixelRatio property.
It has it's flaws, but the good thing is that it spares the device from
loading both versions. I
It's important to separate supporting retina display mobile and desktop
devices. Apple's web site uses the load both method to show off the retina
display MacBook - which is more likely to have a faster internet connection
and is a more powerful machine in general.
- Trevor
On Tue, Sep 18, 2012
I'm glad this area is getting a lot of interest - unfortunately I haven't
been able to keep up on this thread but I wanted to give a suggestion
related to adding icons.
It's reasonable to take an option that provides a URL to an icon image, but
we should have a common (customizable per skin and
as sprites.
--
Munaf Assaf
On Wednesday, September 19, 2012 at 11:41 AM, Trevor Parscal wrote:
I'm glad this area is getting a lot of interest - unfortunately I haven't
been able to keep up on this thread but I wanted to give a suggestion
related to adding icons.
It's reasonable
On Wed, Sep 19, 2012 at 11:54 AM, Munaf Assaf mas...@wikimedia.org wrote:
I wasn't clear; that's exactly what we're doing in the Agora CSS library.
You are adding an icon feature to me.notify in the Agora CSS library?
I know the answer is no, we are creating icons that can be used for that
I've supported this change for a very long time, glad to see it's on the
table.
+1
- Trevor
On Fri, Nov 2, 2012 at 11:23 PM, Ori Livneh o...@wikimedia.org wrote:
Hi,
Change 31065 drops the possessive prefix from toolbar labels, per the
outcome of the discussion on bug 41672. Unless there
Whether it be a targeted list of browsers, a list of browsers we explicitly
ignore, or something else entirely, anything that helps us balance
engineering resources is a good thing.
In 2010 I suggested a rule, which became somewhat of a policy, that WMF
won't spend time/money supporting browsers
1 - 100 of 275 matches
Mail list logo
