This is linked from their but just to make it easier to find
http://en.wikipedia.org/wiki/Jenkins_(software). Jenkins is actually very
cool and also helps run (and keep track of) the consumers for our donation
service for example.
James
On Wed, Jun 27, 2012 at 2:16 PM, Chris McMahon
Le 27/06/12 22:06, Derric Atzrott a écrit :
So I hate to be that guy who doesn't know the simple things, but what is
Jenkins? The server has come up in discussion a few times since I joined
this mailing list about a month ago.
Actually if there is a Wiki page where these sorts of things are
I just wonder: Why do we not simply transmit the SVG image, but render a
png for an SVG-file to the browser? Historic reasons?
I think it is because there is no good way for us to know if a browser
supports SVG images other than having a list of user-agents that do and
checking that way.
We
I just wonder: Why do we not simply transmit the SVG image, but render a
png for an SVG-file to the browser? Historic reasons?
I think it is because there is no good way for us to know if a browser
supports SVG images other than having a list of user-agents that do and
checking that way.
On 27 June 2012 14:38, Petr Kadlec petr.kad...@gmail.com wrote:
On 27 June 2012 13:33, Achim Flammenkamp ac...@uni-bielefeld.de wrote:
2) I wonder why the SVG-graphic devolpers use such an improper(?)
rendering-
philosophy. All these articfacts on the Iran-flag would have been avoided, if
On 28/06/12 12:13, Derric Atzrott wrote:
I just wonder: Why do we not simply transmit the SVG image, but render a
png for an SVG-file to the browser? Historic reasons?
I think it is because there is no good way for us to know if a browser
supports SVG images other than having a list of
P.S.: On a related note ... one could think about mocking the database
as a whole for PHPUnit tests. Thereby, one would get rid of
unnecessary database coupling for unit testing, get better
control/detection of side effects, and really solve the database
performance problem for unit tests
You can always have a line on the bottom of a mobile page, with Do
the page render correctly?. And somehow use it to flag pages that
render incorrectly. Wooot, perhaps this flagging may even save the
user agent of the visitor using the link.
--
--
ℱin del ℳensaje.
On Thu, Jun 28, 2012 at 4:32 PM, Tei oscar.vi...@gmail.com wrote:
You can always have a line on the bottom of a mobile page, with Do
the page render correctly?. And somehow use it to flag pages that
render incorrectly. Wooot, perhaps this flagging may even save the
user agent of the visitor
I can imagine how this can be a problem. Thin lines than in your
original render have 1 pixel width, will be removed or suffer a strong
you misunderstood. In the original SVG there are no thin lines. The thin
line was introduced/inserted by buggy down-rendering to the wanted size.
(There are
On 28 June 2012 16:37, Martijn Hoekstra martijnhoeks...@gmail.com wrote:
On Thu, Jun 28, 2012 at 4:32 PM, Tei oscar.vi...@gmail.com wrote:
You can always have a line on the bottom of a mobile page, with Do
the page render correctly?. And somehow use it to flag pages that
render incorrectly.
On Thu, Jun 28, 2012 at 4:13 AM, Derric Atzrott
datzr...@alizeepathology.com wrote:
I just wonder: Why do we not simply transmit the SVG image, but render a
png for an SVG-file to the browser? Historic reasons?
I think it is because there is no good way for us to know if a browser
supports
On Wed, Jun 27, 2012 at 6:35 PM, Krinkle krinklem...@gmail.com wrote:
So, stripping inline styles:
* will not fix bad layouts made with tables (which are probably at least as
common as bad layouts made with inline styles).
* will break unrelated things, because inline styles are not directlty
To summarise my position:
# I think the beta of the mobile site is a great place to __review__
the styles we have across Wikipedia and as well as resolving many of
the problems of the mobile site it would also result in a much more
maintainable Wikipedia.
# I dislike inline styles and don't think
2012/6/28 Jon Robson jdlrob...@gmail.com:
# things rely on those inline styles whether we like it or not.
No... They rely on styles not //inline// styles. This is my main
problem with the current setup! I believe the majority of things done
in inline styles that are essential would be better
What would sort of make sense would be classes like wrong, no or
decrease, which would all have the same red color, but would mean
different things. But now we're heading for unnecessary obstacles to
editors...
Yes. Agreed. I just picked an arbitrary class name here. The only
point I was
What would sort of make sense would be classes like wrong, no or
decrease, which would all have the same red color, but would mean
different things. But now we're heading for unnecessary obstacles to
editors...
Yes. Agreed. I just picked an arbitrary class name here. The only point I
was
2012/6/28 Derric Atzrott datzr...@alizeepathology.com:
I like the idea of class names for different things, and I don't think that
it would unduly burden the editor. As they are already using inline styles,
I think that using classes shouldn't be an undue burden. It is no harder to
say
Assuming you remember all the class names, which ones will work and
which will not (or, worst case, you have documentation handy).
I'd hope documentation would help with identifying class names and one
could imagine extending the visual editor for the most common ones in
future.
Why would
Derric Atzrott wrote:
I like the idea of class names for different things, and I don't think that
it would unduly burden the editor. As they are already using inline styles,
I think that using classes shouldn't be an undue burden. It is no harder to
say class=someClass than it is to say
Hi all,
We have a longstanding request to enable HTML5 on all sites:
https://bugzilla.wikimedia.org/show_bug.cgi?id=27478
We've had it enabled on mediawiki.org for ages, with minimal death and
mayhem. There are two issues listed as blockers:
Bug 30525: Search bar icon/button slightly lower
Replies inline:
On Jun 28, 2012, at 7:38 PM, Jon Robson wrote:
# things rely on those inline styles whether we like it or not.
No... They rely on styles not //inline// styles. This is my main
problem with the current setup! I believe the majority of things done
in inline styles that are
On 29.06.2012, 1:11 Rob wrote:
We have a longstanding request to enable HTML5 on all sites:
https://bugzilla.wikimedia.org/show_bug.cgi?id=27478
We've had it enabled on mediawiki.org for ages, with minimal death and
mayhem. There are two issues listed as blockers:
Bug 30525: Search bar
Am 28/06/12 01:41, Christian Aistleitner schrieb:
Hi Daniel,
On Wed, Jun 27, 2012 at 09:59:19PM +0200, Daniel Kinzler wrote:
* MediaWikiTestCase will notice this group and use temporary tables instead
of
the wiki database's actual tables. The temporary tables are re-created for
every
It is not an SVG!
It is a band-width problem, in this case. I needed about 10 minutes
real-time to download this image at full-size to my computer, but can work
anyway in parallel.
Vector-grafics should have been FAR MORE compressibale then jpeg or other
snapshots from random/real-word
On Fri, Jun 29, 2012 at 7:11 AM, Rob Lanphier ro...@wikimedia.org wrote:
We've had it enabled on mediawiki.org for ages, with minimal death and
mayhem. There are two issues listed as blockers:
We don't have half of the delautomated crap/delinsAnti-vandal
and random other tools/ins running
Plus, vector graphics compress *much better* than raster, but they are
*much slower* presenting them. Try filling a web page of svg flags, and
see how much it takes to load. Or compare times showing times for raster
and vectorial.
Exactly this I do often: Displaying the 208+30 national flags
Anomie pointed out on enwiki's Village Pump[1] the problem with the
Cite extension mentioned on
https://bugzilla.wikimedia.org/show_bug.cgi?id=27478#c12
Will $wgExperimentalHtmlIds be set to false?
How is it configured on mw.org?
Best regards,
Helder
[1]
28 matches
Mail list logo
